Аргумент в пользу UTF-8: это очень просто. кодировщик и декодер в JavaScript. Опять же, UTF-8 - это не Unicode .

Аргумент против UTF-8: он всегда немного сложнее, чем длина + байты, что приводит к потенциальным расхождениям в реализации.

Опять же, UTF-8 - это не Unicode.

Что ты вообще говоришь ? Это бессмысленный приговор.

Я думаю, вы пытаетесь сказать, что нет необходимости тянуть библиотеку интернационализации. Это правда - требование кодирования строк в UTF-8 не имеет ничего общего со всеми более сложными частями Unicode, такими как канонизация. Это полезные инструменты, когда вы выполняете работу со строками, которая взаимодействует с людьми, но так же, как библиотека триггеров полезна для людей, занимающихся математикой, и не имеет отношения к решению, как кодировать целые числа.

Но UTF-8 - это буквально кодировка Unicode; ваше заявление бессмысленно, как написано. ^ _ ^

Но UTF-8 - это буквально кодировка Unicode; ваше заявление бессмысленно, как написано. ^ _ ^

Да, я конкретно имею в виду кодировку кодовых точек, которую описывает UTF-8, а не собственно обработку кодовых точек (для целей этого предложения кодовая точка - это непрозрачное целое число). UTF-8 похож на var [u] int, но больше подходит для символов. Кроме того, UTF-8 - не единственная кодировка Unicode, и ее можно использовать для кодирования целых чисел, отличных от Unicode. Итак, UTF-8 - это не Unicode.

Еще одно предложение будет рассматривать отдельные кодовые точки и что-то делать с ними. Это не то предложение.

И не было бы причин для этого. Ни один веб-API не обнаружил необходимости в самоанализе кодовых точек, помимо строгого сравнения и сортировки на равенство, если только он не является буквально i18n API.

Другой вариант - длина байта + UTF-8 для каждой кодовой точки ( @jfbastien, если только это не то, что вы имели в виду, когда

Я согласен с определением «кодовых точек UTF-8», которые представляют собой просто целые числа. Бинарная спецификация должна оставить все как есть. Отдельные программы для внедрения могут определять правила, касающиеся разрешенных кодовых точек, нормализации и других нюансов. Инструменты анализа могут выдавать предупреждения о потенциальных проблемах совместимости.

Я думаю, что решения по обработке ошибок также следует оставить на усмотрение разработчиков. Система, которая обращается к функциям WASM по индексу, а не по имени, не нуждается в том, чтобы они были действительными (и их было бы легко пропустить с помощью префикса длины байта).

Вот попытка обобщить основные проблемы и их причины. Исправления и дополнения приветствуются.

Должен ли wasm требовать, чтобы идентификаторы импорта / экспорта модулей были действительными в кодировке UTF-8?

Насколько я понимаю, причины против:

• Обработка импорта и экспорта находится на критическом пути для запуска приложения, и есть желание избежать всего, что могло бы его замедлить.
• Широкий инвариант «базовая спецификация wasm не интерпретирует строки». Интерпретация строк в целом сложна, и есть желание инкапсулировать ее и иметь широкие инварианты и границы, о которых можно рассуждать на высоком уровне.
• Декодеры WebAssembly часто чувствительны к безопасности, поэтому существует общее желание минимизировать объем используемого кода.
• Некоторые производители WebAssembly могут захотеть встраивать произвольные данные в эти идентификаторы, и им удобнее кодировать данные так, как они хотят, вместо того, чтобы преобразовывать их в строковую форму.

Следует ли wasm рекомендовать UTF-8 там, где он не требуется?

Причина в том, что даже если мы не можем этого требовать, упоминание UTF-8 может предотвратить ненужную несовместимость между экосистемой.

Насколько я понимаю, причина против заключается в том, что даже упоминание UTF-8 может поставить под угрозу концептуальную инкапсуляцию проблем интерпретации строк.

Должен ли wasm указывать UTF-8 для имен разделов имен?

Причина в следующем: вся цель этих имен - преобразовать в строки для отображения, что невозможно без кодировки, поэтому мы должны просто указать UTF-8, чтобы инструментам не приходилось угадывать.

Насколько я понимаю, причина против: если у wasm есть другие строковые вещи в других областях, которые не имеют обозначенной кодировки (т.е. импорт / экспорт, как обсуждалось выше), то для согласованности он не должен назначать кодировки для каких-либо строк. .

@sunfishcode дает хорошее резюме, но я хочу добавить три важных момента.

@jfbastien , было бы самой бессмысленной из всех альтернатив ограничивать двоичный _syntax_ (кодировку), но не _semantics_ (набор символов) для строк. Итак, для всех практических целей UTF-8 подразумевает Unicode. И опять же, дело не только в двигателях. Если вы определяете имена как Unicode, то вы делаете это принудительно во всех экосистемах Wasm во всех средах. А это в значительной степени означает, что все среды должны иметь некоторую поддержку Unicode.

@tabatkins , я думаю, что в основе вашего аргумента лежит ошибка домена. Ни одна из строк, о которых мы говорим, не ориентирована на пользователя. Это имена, ориентированные на разработчиков. Многие / большинство языков программирования не поддерживают идентификаторы Unicode, как и инструменты. Может ли, например, gdb обрабатывать идентификаторы источника Unicode? Я так не думаю. Поэтому довольно оптимистично (или, скорее, нереально) предполагать, что все потребители сошлись на Unicode _ в этом пространстве_.

И, наконец, разногласия заключаются не в том, должен ли Wasm в Интернете использовать UTF-8, а в том, где мы это указываем.

Я думаю, что в основе вашего аргумента лежит ошибка домена. Ни одна из строк, о которых мы говорим, не ориентирована на пользователя. Это имена для разработчиков. Многие / большинство языков программирования не поддерживают идентификаторы Unicode, как и инструменты. Может ли, например, gdb обрабатывать идентификаторы источника Unicode? Я так не думаю. Поэтому довольно оптимистично (или, скорее, нереально) предполагать, что все потребители сошлись на Unicode в этом пространстве.

"с обращением к разработчикам" означает "с произвольным обращением к инструментальной цепочке", что означает, что вам необходимо заранее согласовать кодирование, иначе инструменты должны будут выполнять "обнаружение" кодирования (то есть угадывание, что особенно плохо, когда применяется к коротким значениям) или иметь внеполосную информацию. Разработчики по-прежнему остаются пользователями. ^ _ ^

Если вы думаете, что многие инструментальные цепочки не будут понимать Unicode, тогда я не уверен, почему вы думаете, что они понимают любую другую произвольную двоичную кодировку. Если это ваше ограничение, просто укажите и потребуйте ASCII, который на 100% поддерживается везде. Если вы не желаете ограничиваться ASCII, то вам нужно принять, что существует единственная принятая схема кодирования, отличная от ASCII - UTF-8.

Сказать «да, большинство вещей, вероятно, поддерживает только ASCII, но мы позволим разработчикам помещать туда все, что они хотят, на всякий случай » - это худший из обоих миров.

Сказать «да, большинство вещей, вероятно, поддерживает только ASCII, но мы позволим разработчикам помещать туда все, что они хотят, на всякий случай» - это худшее из обоих миров.

@tabatkins , никто этого не предлагает. Как я уже сказал, вопрос не в том, _ где_, а _ где_ определять такие специфические для платформы / среды вопросы. Предполагается, что Wasm можно встраивать в самый широкий и самый разнородный диапазон сред, некоторые из которых намного богаче других (например, JS поддерживает идентификаторы Unicode). Следовательно, вы хотите разрешить выбор для каждой платформы. Следовательно, это относится к спецификациям API платформы, а не к основной спецификации.

Нет выбора! Если ваша среда внедрения не поддерживает не-ASCII, вы просто не используете не-ASCII в своих строках . (И если это так, вам все равно нужна гарантия кодирования - например, UTF-16 не совместим с ASCII!)

Если ваша среда поддерживает не-ASCII, вам нужно знать, какую кодировку использовать, и правильный выбор во всех ситуациях - UTF-8.

Какую среду вы представляете, где полезно не знать кодировку ваших строк?

было бы самой бессмысленной из всех альтернатив ограничивать двоичный синтаксис (кодировку), но не семантику (набор символов) для строк. Итак, для всех практических целей UTF-8 подразумевает Unicode.

Нет, абсолютно не так. Например, вполне разумно одновременно (а) ограничить строку символами ASCII и (б) указать, что она закодирована в UTF-8. Использование символов ASCII не подразумевает кодировку, иначе все кодировки будут совместимы с ASCII! (Например, UTF-16 - нет.) Так что вам все равно нужно что-то указать; UTF-8, будучи «совместимым с ASCII», подходит для этого.

Опять же, если вы согласны с ограничением этих имен только ASCII, тогда разумно указать кодировку US-ASCII. Если вы хотите, чтобы можно было выйти за рамки ASCII, то разумно указать кодировку UTF-8. Обязать что-либо еще или вообще ничего не требовать (и заставлять всех потребителей угадывать или использовать внеполосную информацию) - единственные необоснованные возможности.

И опять же, дело не только в двигателях. Если вы определяете имена как Unicode, то вы делаете это принудительно во всех экосистемах Wasm во всех средах. А это в значительной степени означает, что все среды должны иметь некоторую поддержку Unicode.

Опять же, похоже, что вы говорите о библиотеках интернационализации. Мы обсуждаем только то, как декодировать байтовые последовательности обратно в строки; для этого требуется только знание того, как декодировать UTF-8, что чрезвычайно тривиально и чрезвычайно быстро.

Если вы не выполняете удобные для человека манипуляции со строками, все, что вам нужно, - это возможность сравнивать строки по кодовым точкам и, возможно, сортировать строки по кодовым точкам, ни то, ни другое не требует какой-либо «поддержки Unicode». Это все, что используется существующими веб-технологиями, например, и я не вижу причин, по которым в средах Wasm в целом нужно было бы делать что-то более сложное, чем это.

Я за то, чтобы использовать utf8 для всех строк. Чистое декодирование / кодирование utf8 кажется довольно низкой нагрузкой (по сравнению со всем остальным) для не-веб-сред. Кроме того, из того, что я видел, время, потраченное на проверку utf8 для импорта / имен, будет незначительным по сравнению со временем, затраченным на все остальное, поэтому я не думаю, что здесь есть аргумент производительности.

Фактически, даже если бы мы не указали utf8 в основной спецификации wasm, у вас было бы плохое время для взаимодействия с чем угодно, если бы ваша настраиваемая цепочка инструментов также не использовала utf8, если только вы не полный остров, и тогда, возможно, вы просто скажете "К черту" и все равно делай свои собственные вещи, не относящиеся к UTF8 ... потому что тогда кого это волнует.

Что я действительно хотел бы сделать, так это решить № 984, который, похоже, блокирует это ...

@lukewagner Я не думаю, что # 984 заблокирован на этом. 😄

Я полагаю, вы правы.

Какую среду вы представляете, где полезно не знать кодировку ваших строк?

@tabatkins , кажется, я все еще недостаточно ясно

у вас было бы плохое время, взаимодействующее с чем угодно, если бы ваша настраиваемая инструментальная цепочка также не использовала utf8, если вы не полный остров

@lukewagner , я действительно ожидаю, что Wasm будет использоваться на множестве «континентов», которые потенциально имеют мало общего. И где они это делают, вы можете указать взаимодействие (на практике кодирование имен, вероятно, будет наименьшей проблемой для совместного использования модулей между разными платформами - это хост-библиотеки). Даже полные острова не являются нереалистичными, особенно со встроенными системами (которые также, как правило, мало используют Unicode).

Одна из самых сложных частей реализации механизма WebAssembly, не основанного на браузере, - это заставить все работать так, как это происходит в браузере (в основном, это части JS). Я ожидаю, что если кодировка не будет стандартизирована, мы получим стандарт де-факто, в котором все копируют то, что делается для целевой веб-страницы. Это только приведет к тому, что будет сложнее найти информацию о том, как декодировать эти строки.

Может быть полезно разрешить некоторым средам дополнительно ограничивать разрешенный контент, но отказ от UTF-8 только приведет к большим трудностям.

@ MI3Guy , встречное предложение - указать кодировку UTF-8 как часть JS API. Итак, если вы создаете встраивание JS, тогда он определен как UTF-8 в любом случае и не имеет для вас никакого значения. (Однако мы также хотим разрешить использование других API-интерфейсов для встраивания, которые не относятся ни к Web, ни к JavaScript.)

Верно. Я хочу сказать, что если вы не выполняете встраивание JS, вы вынуждены имитировать многое из того, что делает модуль внедрения JS, чтобы использовать цепочку инструментов WebAssembly.

Сделайте varuint для количества кодовых точек + UTF-8 для каждой кодовой точки.

Я просто хочу высказаться против этого варианта. Это усложняет ситуацию, не может и не может применяться к пользовательским разделам и не дает никаких преимуществ, которые я вижу - чтобы узнать количество кодовых точек в строке UTF-8, на практике вы всегда заканчиваете сканирование строки для недопустимые кодировки, так что вы можете также подсчитывать кодовые точки, пока вы на нем.

Не все является подмножеством UTF-8, например Latin1 все еще довольно широко используется. Возможно, вам все равно, но основная спецификация Wasm не является задачей ставить ненужные камни на пути разнообразия окружающей среды.

Верный; UTF-8 отличается практически от всех кодировок, когда вы выходите из диапазона ASCII. Я не уверен, что вы думаете об этом, тем не менее. На самом деле использование кодировки Latin-1 плохо именно потому, что существует множество других кодировок, которые выглядят одинаково, но кодируют разные буквы . Если вы попытались использовать имя «æther» в своем коде Wasm и закодировали его в Latin-1, то кто-то другой (оправданно) попытается прочитать имя с помощью инструментальной цепочки UTF-8, он получит ошибку декодирования. Или, может быть, другой человек совершал аналогичную ошибку, но вместо этого использовал кодировку Windows-1250 (предназначенную для языков Центральной / Восточной Европы) - он получал бессмысленное слово «ćther».

Я действительно не уверен, какое «разнообразие» вы здесь пытаетесь защитить. Буквально нет никакой пользы от использования любой другой кодировки и тонны недостатков. Каждый символ, который вы можете закодировать в другой кодировке, присутствует в Unicode и может быть закодирован в UTF-8, но обратное почти никогда не бывает. Сегодня нет подходящих инструментов, которые не могли бы работать с UTF-8; технологии буквально два десятилетия .

Я постоянно говорю вам, что веб-стандарты разрешили этот вопрос много лет назад не потому, что Wasm - это веб-спецификация, которая должна соответствовать веб-правилам, а потому, что кодирование текста - это проблема экосистемы, с которой почти у всех одни и те же проблемы, и сеть уже решила с болью сделать это неправильно, и научился делать это правильно. Нет ничего хорошего в том, чтобы снова ошибиться в Wasm; каждая среда, которая должна кодировать текст, либо переходит прямо к UTF-8 с самого начала, либо совершает те же ошибки и страдает от той же боли, что и все остальные, а затем в конечном итоге останавливается на UTF-8. (Или, в редких случаях, разрабатывает достаточно изолированную среду, которую они могут стандартизировать для другой кодировки, и лишь изредка платит цену за взаимодействие с внешней средой. Но они стандартизируют кодировку , что и является целью всего этого.)

Итак, если вы создаете встраивание JS, тогда он определен как UTF-8 в любом случае и не имеет для вас никакого значения. (Однако мы также хотим разрешить использование других API-интерфейсов для встраивания, которые не относятся ни к Web, ни к JavaScript.)

Эта проблема не имеет ничего общего с Интернетом или JS. Каждой части экосистемы нужна известная, последовательная кодировка текста, и есть одна, которая широко согласована в средах программирования, странах и языках: UTF-8.

Я голосую за 'Do varuint для длины (в байтах) + UTF-8 для каждого байта'. Предполагая, что это не спорный выбор - почти каждая реализация строки хранит строки как «количество кодовых единиц», а не «количество кодовых точек», потому что это проще - тогда не реальный вопрос »должна ли проверка завершиться неудачей, если строка не действительный UTF-8 "?

Как я указывал в # 970, недопустимый UTF-8 может быть преобразован в UTF-16, поэтому, если недопустимый UTF-8 разрешен, программное обеспечение, которое не хочет хранить исходные байты, не обязано. С другой стороны, проверить, действителен ли UTF-8, несложно (хотя мы должны ответить - следует ли принимать слишком длинные последовательности? Суррогатные символы?)

В целом я склонен сказать, что разрешите UTF-8. В странном случае, когда у кого-то есть байты, которые они не могут преобразовать в UTF-8 (возможно, потому, что кодировка неизвестна), произвольные байты можно транслитерировать в UTF-8.

Я действительно не уверен, какое «разнообразие» вы здесь пытаетесь защитить.

@tabatkins , да, похоже, в этом суть недоразумения.

Важно понимать, что WebAssembly, несмотря на свое название, не ограничивается сетью. Мы очень осторожно определяем его в подходящих слоях, чтобы каждый слой можно было использовать как можно шире.

В частности, его _core_ на самом деле не является веб-технологией _ вообще_. Вместо этого попробуйте думать об этом как о _virtual ISA _. Такая абстракция полезна в широком спектре различных сред, от очень богатых (Интернет) до очень элементарных (встроенные системы), которые не обязательно имеют какое-либо отношение друг к другу, могут быть в значительной степени несовместимы и иметь конфликтующие ограничения ( что Wasm не в состоянии изменить).

Таким образом, не имеет большего смысла навязывать Unicode _core_ Wasm, чем, скажем, накладывать Unicode на все строковые литералы в языке программирования C. Вы бы только принудили некоторых потенциальных клиентов нарушить этот стандарт. В чем выгода?

Однако помимо этой базовой спецификации будут существовать дополнительные уровни спецификаций, которые определяют ее встраивание и API в _конкретные_ среды (например, JavaScript). Имеет смысл исправить строковые кодировки на этом уровне, и мы обязательно должны это сделать.

PS: Слоган, определяющий сферу применения Wasm, заключается в том, что это абстракция над обычным оборудованием, а не абстракция над общими языками программирования. А аппаратное обеспечение не зависит от программного обеспечения, такого как кодирование строк. Вот для чего нужны ABI.

@ Россберг-хром

Таким образом, нет смысла накладывать Unicode на ядро ​​Wasm, чем, скажем, накладывать Unicode на все строковые литералы в языке программирования C. Вы бы только принудили некоторых потенциальных клиентов нарушить этот стандарт. В чем выгода?

Согласен на 100%. Однако эта проблема не связана с Unicode, это касается исключительно UTF-8, кодировки для целых чисел, без обязательной интерпретации целых чисел как Unicode.

Я не понимаю, согласны ли мы с этим. Не могли бы вы уточнить: вас устраивает UTF-8, и если нет, то почему?

@jfbastien , было бы более продуктивно требовать соответствия UTF-8 для всех строковых литералов C?

Как я отмечал ранее, для меня нет смысла ограничивать кодировку, но не набор символов. Это похоже на определение синтаксиса без семантики. Зачем тебе это делать? Вы получаете ноль с точки зрения взаимодействия, но по-прежнему создаете искусственные препятствия для сред, которые не используют UTF-8 (что в любом случае делает только среда Unicode).

@jfbastien , было бы более продуктивно требовать соответствия UTF-8 для всех строковых литералов C?

Я не понимаю, вы можете уточнить?

Как я отмечал ранее, для меня нет смысла ограничивать кодировку, но не набор символов. Это похоже на определение синтаксиса без семантики. Зачем тебе это делать? Вы получаете ноль с точки зрения взаимодействия, но по-прежнему создаете искусственные препятствия для сред, которые не используют UTF-8 (что в любом случае делает только среда Unicode).

Я думаю, что суть обсуждения.

@tabatkins коснулся прецедентов именно этого:

Опять же, похоже, что вы говорите о библиотеках интернационализации. Мы обсуждаем только то, как декодировать байтовые последовательности обратно в строки; для этого требуется только знание того, как декодировать UTF-8, что чрезвычайно тривиально и чрезвычайно быстро.

Если вы не выполняете удобные для человека манипуляции со строками, все, что вам нужно, - это возможность сравнивать строки по кодовым точкам и, возможно, сортировать строки по кодовым точкам, ни то, ни другое не требует какой-либо «поддержки Unicode». Это все, что используется существующими веб-технологиями, например, и я не вижу причин, по которым в средах Wasm в целом нужно было бы делать что-то более сложное, чем это.

Итак, я согласен: это предложение, по вашим словам, «определение синтаксиса без семантики». Это очень распространенная вещь. Фактически, текущая спецификация WebAssembly с длиной + байты уже делает это!

Я хотел бы понять, в чем состоит препятствие. Я действительно не вижу ни одного.

Важно понимать, что WebAssembly, несмотря на свое название, не ограничивается сетью.

Я только что заявил в предыдущем комментарии, что это не имеет ничего общего с Интернетом. Вы все время пытаетесь использовать этот аргумент, и он меня действительно сбивает с толку. То, что я говорю, не имеет ничего общего с Интернетом; Я просто указываю на опыт Интернета как на важный пример извлеченных уроков.

Таким образом, нет смысла накладывать Unicode на ядро ​​Wasm, чем, скажем, накладывать Unicode на все строковые литералы в языке программирования C. Вы бы только принудили некоторых потенциальных клиентов нарушить этот стандарт. В чем выгода?

Вы не делаете точку вы думаете , что вы делаете - C действительно имеет встроенный в кодировке, так как строковые литералы использовать кодировку ASCII. (Если вам нужно что-то еще, вы должны сделать это вручную, экранируя соответствующие последовательности байтов.) В более современном C ++ вы можете иметь строковые литералы UTF-16 и UTF-8, и хотя вы все еще можете помещать произвольные байты в строку с помощью \x экранирует, \u экранирует, по крайней мере, убедитесь, что значение является допустимым кодом.

Все это необходимо, потому что нет встроенного отображения символов в байты . Вот что делает кодировка. Опять же, отсутствие указанной кодировки просто означает, что пользователи языка, когда они получают последовательности байтов от других сторон, должны угадывать кодировку, чтобы преобразовать их обратно в текст.

Вы получаете ноль с точки зрения взаимодействия, но по-прежнему создаете искусственные препятствия для сред, которые не используют UTF-8 (что в любом случае делает только среда Unicode).

Вы можете , пожалуйста , точку в среду в существование , которое использует символы, которые не включены в Unicode? Вы продолжаете отстаивать эту позицию с точки зрения теоретической чистоты / разнообразия среды, но буквально весь смысл Unicode состоит в том, чтобы включать все символы . Это единственный набор символов, который может стать хоть сколько-нибудь убедительным аргументом в пользу этого, и когда вы используете набор символов Unicode, предпочтительной универсальной кодировкой является UTF-8.

Какое разнообразие вы пытаетесь защитить? Было бы здорово увидеть хоть один пример. : /

@tabatkins :

Важно понимать, что WebAssembly, несмотря на свое название, не
ограничено Интернетом.

Я только что заявил в предыдущем комментарии, что в этом нет ничего
делать с Интернетом. Вы продолжаете использовать этот аргумент, и это действительно
сбивает меня с толку. То, что я говорю, не имеет ничего общего с Интернетом; Я просто
указывая на опыт Интернета как на важный пример извлеченных уроков.

Я пытаюсь подчеркнуть, что Wasm должен быть применим ко многим
платформы по возможности современные или нет. Вы продолжаете спорить со счастливым концом
спектра, где все используется Unicode и / или UTF-8, и все
иначе просто устарело.

Вы не делаете точки вы думаете , что вы делаете - C действительно есть

встроенная кодировка, поскольку строковые литералы используют кодировку ASCII. (Если хочешь
все остальное, что вам нужно сделать вручную, избегая соответствующего байта
последовательности.) В более современном C ++ вы можете иметь строки UTF-16 и UTF-8
литералы, и хотя вы все еще можете помещать произвольные байты в строку с помощью
\ x экранирует, \ u экранирует, по крайней мере, убедитесь, что значение является допустимым
кодовая точка.

Нет, это неверно. Спецификация C не требует ASCII. Это даже не
требуется совместимость с ASCII. Это позволяет практически произвольному "источнику"
наборов символов "и строковые литералы могут содержать любой символ из полного
установленный. Нет никаких ограничений по кодировке, это полностью
определяется реализацией. Были реализации C, работающие на
Платформы EBCDIC, и это все еще поддерживается текущим стандартом. GCC
может обрабатывать исходники в любой кодировке iconv (их около 140
помимо UTF-8), например UTF-16, популярный в Азии. C ++ ничем не отличается.

(Это также должно ответить на вопрос @jfbastien .)

Все это необходимо, потому что нет встроенного отображения изсимволы в байты . Вот что делает кодировка. Опять же, не имея
указанная кодировка просто означает, что пользователи языка, когда они получают
байтовые последовательности от других сторон, должны угадать кодировку, чтобы включить
их обратно в текст.

Опять же: это _ будет подходящим образом определено для каждой среды. Когда кто-то
получает модуль Wasm от кого-то другого, работающего в той же экосистеме
тогда нет проблем. Ни одному разработчику JS никогда не придется заботиться.

Если, однако, кто-то получает модуль из _другой экосистемы_, тогда
есть много других источников несовместимости, о которых стоит беспокоиться, например
ожидания по поводу API, встроенных библиотек и т. д. Обе стороны должны будут
в любом случае явно выражайте свои предположения о взаимодействии. Согласование имени
кодирование будет наименьшей из их проблем.

Вы получаете ноль с точки зрения взаимодействия, но все равно создаете искусственные препятствия для

среды, которые не используют UTF-8 (что только в средах Unicode
в любом случае).

Вы можете , пожалуйста , точку в среду в существование , которое использует
символы, которые не включены в Юникод? Вы продолжаете защищать это
позиции с теоретической точки зрения чистоты / разнообразия окружающей среды, но
буквально весь смысл Unicode состоит в том, чтобы включать всеперсонажей . Это единственный набор символов, с помощью которого можно удаленно
веский аргумент в пользу этого, и когда вы используете символ Unicode
установлен, UTF-8 является предпочтительной универсальной кодировкой.

Какое разнообразие вы пытаетесь защитить? Было бы здорово увидеть даже
единственный пример. : /

Например, вот список встроенных ОС: https://en.wikipedia.org/wiki/
Категория: Embedded_operating_systems
Некоторые из них, вероятно, используют UTF-8, некоторые нет. Некоторые могут найти применение Wasm,
скорее всего, не будет. Но для нас нет никакой пользы в уменьшении
им удобно.

Одна запись из этого списка, с которой вы, вероятно, все еще знакомы, - это DOS. В качестве
как бы все мы ни хотели, чтобы он умер, системы DOS все еще живы, и они используют
OEM.

@jfbastien :

Итак, я согласен: это предложение, по вашим словам, «определение синтаксиса без
семантика ". Это очень распространенная вещь. Фактически, WebAssembly
текущая длина + байты уже делают это!

Я знаю, что все те редкие случаи, когда это происходит, связаны с
обеспечение аварийного выхода для поведения, зависящего от реализации. Это
также единственный разумный вариант использования. Однако здесь это не имеет смысла. если ты
хотите обеспечить такой аварийный люк для струн, тогда зачем требовать
UTF-8, вместо того, чтобы разрешать «синтаксис» байтовой строки? Этот синтаксис без
семантика как дезорганизатор, а не как активатор.

Я хотел бы понять, в чем состоит препятствие. Я действительно не вижу ни одного.
>
Некоторые клиенты не могут просто использовать все байтовые значения, а должны пройти через
избыточные кодировки UTF, которые не используются в их экосистеме. Все это
инструменты в их цепочках инструментов также должны будут возиться с этим. Это
создает дополнительные случаи ошибок (вне диапазона значений), которые не
иначе существуют для них.

Позвольте мне спросить наоборот: в чем выгода (в их экосистемах)?
Я действительно не вижу ни одного.

@tabatkins
Хочу убедиться, что понимаю, где проходит разделительная линия.
Чтобы было ясно, вы предлагаете ТОЛЬКО кодировку кодовых точек utf-8 независимо от того, являются ли они недопустимыми в комбинации (это можно сделать в 10 строках кода).
Например, в спецификации можно использовать жирные заглавные буквы, чтобы указать: вы делаете что-то не так, если считаете, что вам нужна библиотека интернационализации для реализации Wasm?

Цели этого будут:

• Убедитесь, что любой действительный wasm, который попадает в сеть, может, по крайней мере, отображать символы тофу для недопустимого материала.
• Поощряйте инструменты, которые генерируют wasm (даже в контексте вне Интернета), отдавать предпочтение юникоду над другими кодировками, когда им нужно выйти за рамки ascii. (Мягкий толчок в этом направлении, поскольку полной проверки не происходит).

Вопросов?

• Есть ли опасность, что это станет постепенным требованием для дополнительной проверки? Я думаю, что меня больше всего беспокоит в этом пространстве, что всегда будет необоснованным бременем проглатывать, скажем, отделение интенсивной терапии как зависимость.

• Я предполагаю, что это подразумевает цель активного поощрения кодировок, таких как Latin1, которые конфликтуют с UTF-8? Т.е. инструментальные цепочки, которые генерируют это, будут несовместимы, реализации, которые принимают это аналогичным образом.

• Мне кажется, что в Интернете исторически возникали проблемы с объединением этого пространства из-за перекрывающегося использования битов из регионов, которые ранее кодировали острова. С другой стороны, у меня сложилось впечатление, что UTF-8 настраивает такие вещи, что затраты на переход непропорционально ложатся на людей, не использующих ASCII, и что в некоторых регионах есть больше проблем. Я бы предположил, что переход на Unicode является практической неизбежностью (и почти полностью). Есть ли какой-то централизованный документ / объект, на который мы можем указать, чтобы узнать, как некоторые политические и региональные проблемы, связанные с Unicode, были решены в Интернете?

@ Россберг-хром

• Я вижу логическую непоследовательность в проверке некоторых аспектов кодирования, но не других. С другой стороны, у меня сложилось впечатление, что utf8 на данный момент широко распространен (и что небольшой толчок в инструментах + проверка имеет низкую стоимость). Ваш главный дискомфорт - добавление простой проверки utf-8 в спецификацию - несоответствие или что-то еще?

Чтобы было ясно, вы предлагаете ТОЛЬКО кодировку кодовых точек utf-8 независимо от того, являются ли они недопустимыми в комбинации (это можно сделать в 10 строках кода).

Да, хотя я не верю, что существуют недопустимые комбинации; есть только несколько отдельных кодовых точек (те, которые зарезервированы для суррогатов UTF-16), которые технически недопустимы для кодирования как UTF-8. Тем не менее, если желателен полный байтовый контроль, кодировка WTF-8 действительно существует, но мы должны очень четко заявить, что «да, мы хотим, чтобы эти строки иногда действительно содержали в себе произвольные нестроковые данные» в качестве цели, если мы идем туда. Формат WTF-8 (и WTF-16) предназначен только для предоставления формальной спецификации для сред, которые имеют ограничения обратной совместимости для обеспечения правильного форматирования UTF- *.

Например, в спецификации можно использовать жирные заглавные буквы, чтобы указать: вы делаете что-то не так, если считаете, что вам нужна библиотека интернационализации для реализации Wasm?

Да, i18n не требуется ни в каком виде. Например, CSS по умолчанию использует UTF-8 и просто выполняет сравнение / сортировку необработанных кодовых точек, когда это разрешает вещи за пределами диапазона ASCII. У Васма тоже нет причин идти дальше этого.

Есть ли опасность, что это станет постепенным требованием для дополнительной проверки? Я думаю, что меня больше всего беспокоит в этом пространстве, что всегда будет необоснованным бременем проглатывать, скажем, отделение интенсивной терапии как зависимость.

Веб-платформе до сих пор не требовалась дополнительная проверка пустых имен. Мой опыт подсказывает, что в этом никогда не будет необходимости.

Я предполагаю, что это подразумевает цель активного [недобросовестного] исправления кодировок, таких как Latin1, которые конфликтуют с UTF-8? Т.е. инструментальные цепочки, которые генерируют это, будут несовместимы, реализации, которые принимают это аналогичным образом.

Да, с переходом к «Дис couraging» в ваших словах. ^ _ ^ Все дело в том, что производители и потребители могут надежно кодировать и декодировать строки в / из байтовых последовательностей, не догадываясь о том, что делает другая конечная точка. Это было ужасной болью для каждой среды, которая когда-либо сталкивалась с этим, и сейчас для этого есть широко распространенное решение.

Мне кажется, что в Интернете исторически возникали проблемы с объединением этого пространства из-за перекрывающегося использования битов из регионов, которые ранее кодировали острова. С другой стороны, у меня сложилось впечатление, что UTF-8 настраивает такие вещи, что затраты на переход непропорционально ложатся на людей, не использующих ASCII, и что в некоторых регионах есть больше проблем. Я бы предположил, что переход на Unicode является практической неизбежностью (и почти полностью). Есть ли какой-то централизованный документ / объект, на который мы можем указать, чтобы узнать, как некоторые политические и региональные проблемы, связанные с Unicode, были решены в Интернете?

Да, у него определенно были проблемы при переходе; HTML по-прежнему требуется использовать по умолчанию Latin-1 из-за обратной совместимости, и все еще есть некоторые небольшие участки веб-контента, которые предпочитают кодировку для конкретного языка (в основном Shift-JIS, кодировку для японского языка). Но подавляющее большинство стран мира перешло на другой режим за последние два десятилетия, и сейчас этот переход считается более или менее завершенным.

«UTF-8 обременяет людей, не использующих ASCII» долгое время оставался пагубным, но почти полностью ложным слухом. Большинство европейских языков включают в себя большую часть алфавита ASCII, поэтому большая часть их текста представляет собой однобайтовые последовательности и в конечном итоге меньше, чем UTF-16. То же самое относится к системам письма, таким как пиньинь. Языки CJK в основном занимают 3-байтовую область UTF-8, но они также включают большое количество символов ASCII, особенно в языках разметки или языках программирования, поэтому также, как правило, смотрите меньшие или аналогичные размеры кодировки для UTF-8, как для UTF-16 или их специализированные кодировки.

Только для больших объемов необработанного текста в алфавитах CJK или не-ASCII, таких как кириллица, мы видим, что UTF-8 фактически занимает больше места, чем специализированная кодировка. Однако это были проблемы в начале 90-х , когда емкость жесткого диска измерялась в мегабайтах, и небольшое увеличение размеров текстовых файлов было действительно значительным. Это не было проблемой почти 20 лет; разница в размерах сейчас совершенно несущественна.

Что касается «перехода на Unicode», это уже произошло повсеместно. Текстовый формат, который не требует кодирования с помощью UTF-8, в наши дни совершает ужасную, антиисторическую ошибку.

Я не уверен в каком-либо конкретном документе, который описывает это, но готов поспорить, что они где-то существуют. ^ _ ^

Если цель состоит в том, чтобы сохранить бинарную спецификацию как можно более чистой, давайте полностью удалим имена. В любом случае все его внутренние ссылки основаны на индексе.

Вместо этого добавьте в спецификацию JavaScript обязательный настраиваемый раздел, требующий UTF-8. Другие среды, такие как мэйнфрейм советских времен, на который ссылается @ rossberg-chromium, могут определять свои собственные настраиваемые разделы. Один файл WASM может поддерживать обе платформы, предоставляя оба настраиваемых раздела. Для пользовательского инструментария было бы относительно просто создать недостающий раздел малоизвестной платформы путем преобразования более популярного.

Если цель состоит в том, чтобы сохранить бинарную спецификацию как можно более чистой, давайте полностью удалим имена. В любом случае все его внутренние ссылки основаны на индексе.

Это переработка того, как работает импорт / экспорт. Этого нет на столе, и его следует предложить в другом выпуске, нежели этот.

@bradnelson , AFAICS, предписывающий конкретную кодировку, но без набора символов
сочетает в себе худшее из обоих миров: это требует затрат с точки зрения
ограничения, сложность и накладные расходы без реальной выгоды с точки зрения
взаимодействие. Думаю, я все еще не понимаю, в чем будет смысл.

@ rossberg-chromium Основное преимущество, которое здесь преследуют, - избавить инструменты и библиотеки от бремени предположений.

Поскольку основное преимущество, которое здесь преследуется, состоит в том, чтобы избавить инструменты и библиотеки от бремени догадок, любой из обсуждаемых выше вариантов (UTF-8 против WTF-8 и т. Д.) Будет лучше, чем ничего, потому что даже в худшем случае «Я уверен, что я не могу буквально перекодировать эти байты» лучше, чем «эти байты выглядят так, как будто они могут быть windows-1252; может быть, я попробую». Известно, что угадывание подвержено ошибкам, и основное стремление к этому состоит в том, чтобы избавить инструменты и библиотеки от бремени предположений.

@sunfishcode , как? Я все еще заблудился.

Итак, вот конкретный сценарий. Предположим, мы на разных платформах, и я пытаюсь передать вам модуль. Предположим, что моя платформа использует EBCDIC, а ваша ASCII. Абсолютно законно в соответствии с текущим предложением. Тем не менее, мой модуль будет совершенно бесполезен для вас и вашей цепочки инструментов.

Обе эти кодировки являются 7-битными, поэтому UTF-8 даже не входит в изображение.

Итак, что принесет UTF-8? Что ж, я мог «расшифровать» любую полученную неизвестную строку. Но насколько мне известно, результатом является просто еще один непрозрачный двоичный объект с 31-битным значением. Он не предоставляет никакой информации. Я понятия не имею, как связать это с моими собственными струнами.

Итак, зачем мне вообще декодировать неизвестную строку? Ну, я бы не стал! С таким же успехом я мог бы работать с исходным двоичным двоичным объектом с 8-битными значениями и экономить место и циклы. Однако спецификация все равно потребует от меня тратить циклы на тщательную проверку кодировки.

Учитывая все это, что (ядро) Wasm или инструменты выиграют, приняв это конкретное предложение?

AFAICS, предписывающий конкретную кодировку, но без набора символов
сочетает в себе худшее из обоих миров: это требует затрат с точки зрения
ограничения, сложность и накладные расходы без реальной выгоды с точки зрения
взаимодействие. Думаю, я все еще не понимаю, в чем будет смысл.

Мы определенно навязываем набор символов - набор символов Unicode. JF раньше очень запутанно формулировал вещи, не обращайте внимания. Это не значит, что нам нужно добавить проверки в Wasm, чтобы это действительно было реализовано; декодеры обычно достаточно надежны, чтобы работать с недопустимыми символами. (Интернет, например, обычно просто заменяет их символом U + FFFD REPLACEMENT CHARACTER.)

Итак, вот конкретный сценарий. Предположим, мы на разных платформах, и я пытаюсь передать вам модуль. Предположим, что моя платформа использует EBCDIC, а ваша ASCII. Абсолютно законно в соответствии с текущим предложением. Тем не менее, мой модуль будет совершенно бесполезен для вас и вашей цепочки инструментов.

Вам нужно перестать притворяться, что системы, которым уже несколько десятилетий, не только актуальны, но и настолько актуальны, что они оправдывают принятие решений, которые идут вразрез со всем, что мы узнали о кодировании боли за те же самые несколько десятилетий. Вы никому не помогаете, настаивая на том, что веб-сборка изгибается для максимального удобства при общении с древними мэйнфреймами, игнорируя при этом выгоду от возможности надежной передачи текстовых данных всем остальным в мире. Вы просто навредите языку и усложните жизнь пользователям на 99,9% (по очень скромной оценке).

Через весь этот беспорядок прошло множество различных систем. Войны кодирования не были забавой; они потратили кучу денег и много времени и привели к большому количеству искаженного текста. Но мы закончили эти войны. Юникод был создан, распространен и стал доминирующим набором символов во всем мире до такой степени, что все остальные наборы символов на данный момент буквально не более чем исторические курьезы. У нас все еще есть низкоуровневые споры о том, использовать ли UTF-16 или UTF-8, но, по крайней мере, эти два обычно легко отличить друг от друга (посмотрите на спецификацию или найдите преобладание нулевых байтов) и в целом UTF -8 легко доминирует.

Вы настаиваете на свободе кодирования, игнорируя всю эту историю, все уроки, извлеченные за два десятилетия с момента появления Unicode. Он игнорирует весь опыт и знания, вложенные в разработку современных систем, которые сделали проблемы кодирования невидимыми для большинства пользователей, потому что системы могут рассчитывать на то, что все кодируется определенным образом. Вы создадите серьезные, пагубные и дорогостоящие проблемы, если будете упорствовать в этом, по одному моджибаке за раз.

@ Россберг-хром

Итак, вот конкретный сценарий. Предположим, мы на разных платформах, и я пытаюсь передать вам модуль. Предположим, что моя платформа использует EBCDIC, а ваша ASCII. Абсолютно законно в соответствии с текущим предложением. Тем не менее, мой модуль будет совершенно бесполезен для вас и вашей цепочки инструментов.

Итак, что принесет UTF-8? Что ж, я мог «расшифровать» любую полученную неизвестную строку. Но насколько мне известно, результатом является просто еще один непрозрачный двоичный объект с 31-битным значением. Он не предоставляет никакой информации. Я понятия не имею, как связать это с моими собственными струнами.

UTF-8 точно скажет вам, как связать его с вашими собственными строками. Это именно та проблема, которую он решает. (WTF-8 тоже, когда может, и однозначно скажет вам, когда не может.)

Вы имеете в виду произвольную структуру данных, преобразованную в строковую форму, а затем закодированную как UTF-8? Это правда, что вы не сможете распутать его, но вы можете, по крайней мере, однозначно отобразить искаженное имя в виде строки, что является улучшением по сравнению с отсутствием чего-либо для некоторых случаев использования.

Вы имеете в виду приведенное выше обсуждение использования UTF-8 в качестве кодировки непрозрачных целых чисел, а не Unicode? Думаю, дискуссия несколько запуталась. Это заманчиво назвать «кодирующей синтаксис» и интернационализация «семантику», но затеняет полезное различие: UTF-8 все еще можно сказать , что некоторые средства последовательности байт «Ö» , не говоря , что потребители должны делать с этой информацией. Используемый таким образом, это кодировка Unicode, но она не требует затрат, которые использовались выше в разделе «Поддержка Unicode».

Итак, зачем мне вообще декодировать неизвестную строку? Что ж, я бы не стал! С таким же успехом я мог бы работать с исходным двоичным двоичным объектом с 8-битными значениями и экономить место и циклы. Однако спецификация все равно потребует от меня тратить циклы на тщательную проверку кодировки.

Теперь я создал SpiderMonkey с полной проверкой UTF-8 идентификаторов импорта / экспорта wasm, включая сверхдлинные и суррогаты. Мне не удалось обнаружить разницу в производительности в WebAssembly.validate ни на AngryBots, ни на небольшом тестовом примере, скомпилированном с помощью emscripten, который, тем не менее, имеет 30 операций импорта.

Спецификация - это компромисс между несколькими проблемами. Я ценю время запуска, поэтому я провел несколько экспериментов и измерил его. Я призываю других проводить собственные эксперименты.

Кроме того, UTF-8 - не единственная кодировка Unicode, и ее можно использовать для кодирования целых чисел, отличных от Unicode. Итак, UTF-8 - это не Unicode.

Какие целые числа могут кодироваться UTF-8, которые не являются частью Unicode (т. Е. Вне диапазона от U + 0000 до U + 10FFFF)? Это утверждение кажется ложным.

Если вы не проверяете свои символы, вы можете закодировать любое 21-битное целое число.

Не совсем уверен, почему бы нам не проверить ...

@flagxor https://encoding.spec.whatwg.org/ описывает различные кодировки, доступные в Интернете. Обратите внимание, что ни один из них не выходит за пределы набора символов Unicode, но, очевидно, не все они совместимы друг с другом по байтам.

Что сделает «проверка»? Сделать вашу программу wasm недействительной? Я не думаю, что есть какие-то реальные последствия, которые можно было бы разумно наложить.

Например, использование недопустимого escape-кода в CSS просто помещает U + FFFD в вашу таблицу стилей, это не делает ничего странного.

@annevk :

Кроме того, UTF-8 - не единственная кодировка Unicode, и ее можно использовать для кодирования целых чисел, отличных от Unicode. Итак, UTF-8 - это не Unicode.

Какие целые числа могут кодироваться UTF-8, которые не являются частью Unicode (т. Е. Вне диапазона от U + 0000 до U + 10FFFF)? Это утверждение кажется ложным.

Как минимум: U + FFFE и U + FFFF не являются символами в Юникоде. Кодовые точки (значения целых чисел) никогда не будут использоваться Unicode для кодирования символов, но они могут быть закодированы в UTF-8.

Однако они все еще являются кодовыми точками Unicode. Я бы не стал уделять слишком много внимания «персонажам».

Декодирование @tabatkins в U + FFFD разумно, но это ограничивает количество целых чисел, которые вы можете получить.

Таким образом, нет смысла накладывать Unicode на ядро ​​Wasm, чем, скажем, накладывать Unicode на все строковые литералы в языке программирования C. Вы бы только принудили некоторых потенциальных клиентов нарушить этот стандарт. В чем выгода?

Обратите внимание, что в C11 добавлены типы char16_t и char32_t а также префикс u для строковых литералов в кодировке UTF-16, префикс U для Строковые литералы в кодировке UCS-4 и префикс u8 для строковых литералов в кодировке UTF-8. Я не копал достаточно глубоко, чтобы найти обоснование для их добавления, но полагаю, что «работа с Unicode в стандартном C / C ++ - это кошмар», по крайней мере, часть мотивации.

@tabatkins , @sunfishcode , ладно, значит, вы говорите не об одном и том же. Но AFAICT @jfbastien явно и неоднократно заявлял, что его предложение касается указания UTF-8 без набора символов Unicode.

Это также единственная интерпретация, при которой сохраняется претензия на низкую стоимость.

Потому что, если мы действительно _до_ предположим, что UTF-8 подразумевает Unicode, тогда это требование, безусловно, намного дороже, чем просто кодирование / декодирование UTF-8 для любого инструмента в любой системе, которая еще не поддерживает (подмножество) Unicode - они Потребуется включить полный уровень перекодирования.

@tabatkins , ядро ​​Wasm будет встроено в уже существующие системы - иногда по другим причинам, кроме переносимости, - которые он не имеет права изменять или навязывать что-либо. Если они сталкиваются с проблемами, которые вы описываете, то они существуют независимо от Wasm. _Мы_ не можем исправить их проблемы.

Вероятным результатом _попытки_ навязать Unicode всем им будет то, что некоторые потенциальные просто нарушат эту часть спецификации, сделав ее совершенно спорной (или, что еще хуже, они вообще проигнорируют Wasm).

Если мы укажем OTOH на соответствующем уровне, мы не рискуем - ничего не теряя на практике.

Потому что, если мы действительно предполагаем, что UTF-8 подразумевает Unicode, тогда это требование, безусловно, намного дороже, чем просто кодирование / декодирование UTF-8 для любого инструмента в любой системе, которая еще не поддерживает (подмножество) Unicode - они Потребуется включить полный уровень перекодирования.

Какие существуют платформы, которые используют собственный набор символов, отличный от Unicode, а не ASCII, не имеют средств для преобразования этих символов в / из Unicode и должны использовать идентификаторы, отличные от ASCII, в Wasm? (Я имею в виду действительно существующую, а не какую-то гипотетическую российскую организацию, которая решила использовать Wasm в DOS.)

@rocallahan Я считаю, что @ rossberg-chromium связана (или, по крайней мере, я был бы) с такими устройствами, как встроенные системы, которым не нужна дополнительная стоимость полной библиотеки ICU. Они либо будут вынуждены принять раздувание, либо не выполнять полную проверку, либо не принимать файлы wasm, содержащие символы, отличные от ascii (которые они могут не контролировать).

Кроме того, строго говоря, такие устройства часто включают оборудование с нестандартными наборами символов, например:
https://www.crystalfontz.com/product/cfah1602dyyhet-16x2-character-lcd?kw=&origin=pla#datasheets
https://www.crystalfontz.com/products/document/1078/CFAH1602DYYHET_v2.1.pdf
(Который имеет тупой смешанный набор символов ascii + latin1 + японский)
Но вопрос в том, что вы обязаны подтверждать, что в любом случае имеет значение.

@tabatkins, хотя я думал, указал, что намерение:

• Обязать UTF-8 + Unicode как единственную "правильную" интерпретацию байтов.
• Явно укажите, что Unicode не должен проверять модуль для проверки (для экономии затрат)

Я считаю, что @ rossberg-chromium обеспокоен (или, по крайней мере, я бы так интересовался) такими устройствами, как встроенные системы, которым не нужна дополнительная стоимость полной библиотеки ICU. Они либо будут вынуждены принять раздувание, либо не выполнять полную проверку, либо не принимать файлы wasm, содержащие символы, отличные от ascii (которые они могут не контролировать).

Как неоднократно говорилось, это отвлекающий маневр. Нет необходимости делать что-либо удаленно, связанное с ОИТ; Интернет определенно не делает этого. Пожалуйста, прекратите распространять эту неверную информацию.

«Полная проверка» - чрезвычайно тривиальная операция, выполняемая автоматически как часть соответствующей операции декодирования UTF-8.

В чате с @tabatkins я думаю, что очень важно прояснить здесь одну вещь:
ТРЕБУЕТСЯ соответствующий декодер Unicode, чтобы допускать произвольные комбинации модификаторов, нераспределенных кодовых точек и т. Д. Таким образом, случайное сочетание модификаторов и т. Д., Даже если оно не дает ничего разумного, должно быть разрешено Unicode. Декодер, отклоняющий бессмысленные комбинации, будет несовместим.

Таким образом, требование правильного декодирования UTF-8 четко ограничено тем, что вы можете сделать с помощью нескольких строк кода, является точной операцией и, по сути, эквивалентно указанию интерпретации байтов unicode + utf-8.

да. Разбор UTF-8 чрезвычайно тривиален; единственными сложностями являются несколько кодовых точек, которые вам не разрешено кодировать в UTF-8, которые совместимый декодер вместо этого будет анализировать как один или несколько символов U + FFFD.

Но это операция, которую должна выполнить конечная точка . Wasm не должен заниматься этим; совместимые декодеры могут обрабатывать любой произвольный битовый шаблон, который вы им задаете. (Они просто решат, что большая часть мусорного битового шаблона - это символы U + FFFD.) Все, что я просил все это время, - это требование соответствия на уровне автора, чтобы эти строки были закодированы с помощью UTF-8. Если вы нарушите это, ваша инструментальная цепочка может пометить это как ошибку, но сам Wasm ничего не должен делать.

Это похоже на, например, CSS, определяющий грамматику для того, что составляет действительную таблицу стилей, но все же технически принимает любой произвольный битовый шаблон.

Кроме того, строго говоря, такие устройства часто включают оборудование с нестандартными наборами символов, например:

Существование таких наборов символов не имеет отношения к Wasm, если только вы не ожидаете, что люди будут писать идентификаторы Wasm в их (не-ASCII диапазонах).

Правильно, все средства «использовать UTF-8» - это https://encoding.spec.whatwg.org/#utf -8-decoder. ICU даже близко не соответствует требованиям.

25 февраля 2017 года в 01:13 Брэд Нельсон [email protected] написал:

В чате с @tabatkins https://github.com/tabatkins одна вещь
что, я думаю, очень важно прояснить здесь:
ТРЕБУЕТСЯ соответствующий декодер Unicode, чтобы разрешить произвольные
комбинации модификаторов, нераспределенные кодовые точки и т. д. Таким образом, случайное сочетание
модификаторы и т. д., даже если это не дает ничего разумного, это
требуется для разрешения Unicode. Декодер, отвергающий чушь
комбинации будут несовместимы.

Таким образом, требование правильного декодирования UTF-8 четко ограничено.
то, что вы можете сделать с помощью нескольких строк кода, - это точная операция,
и по существу эквивалентен указанию unicode + utf-8
интерпретация байтов.

Чтобы прояснить то, что я сказал. Я не спорю, что полное отделение интенсивной терапии, вероятно, не было бы
необходимо (хотя, например, сортировка имен по кодовым точкам звучит плохо
юзабилити).

Однако утверждение, что остается только тривиальное декодирование, неверно.
либо потому, что это не заканчивается на валидации. Платформы, отличные от Unicode
будут вынуждены выполнить перекодировку для фактической обработки своих строк.
Более того, им придется столкнуться с проблемой персонажей, которые
не может быть сопоставлен (в любом направлении), поэтому у вас все еще будет совместимость
вопросы в общем, просто пинали в жару.

>

Кроме того, строго говоря, такие устройства часто включают оборудование, в котором есть
нестандартные наборы символов, например:

Существование таких наборов символов не имеет отношения к Wasm, если только вы
ожидайте, что люди будут писать идентификаторы Wasm в их (не-ASCII диапазонах).

@rocallahan https://github.com/rocallahan , они все еще должны иметь возможность
взять произвольный Unicode. Но что бы они с этим сделали? Если Wasm
реализация на такой платформе ограничена ASCII, тогда это будет
нарушая предложенную спец. (Я бы также подумал, что подразумевая, что
чьи-то символы, отличные от ASCII, неактуальны априори могут быть культурно
под вопросом. Это должно быть их решение.)

Более того, им придется иметь дело с проблемой символов, которые нельзя отобразить (в любом направлении), поэтому у вас все равно будут проблемы с совместимостью в целом, просто отложите в сторону.

Это теоретическая проблема?

И если это разумное беспокойство, мы должны еще раз взвесить (стоимость * возникновения) работы с этим со стоимостью практически любого другого пользователя Wasm в мире, который не может зависеть от кодировки и вынужден иметь дело с То же самое кодирование - черт возьми, веб-платформа должна была пройти, и в конечном итоге исправлена, насколько это было возможно.

Платформы, не поддерживающие Unicode, будут вынуждены выполнять перекодирование для фактической обработки своих строк.

Но в каких случаях строки Wasm должны взаимодействовать со строками платформы? Насколько я могу судить, мы говорим только о кодировании строк в метаданных Wasm, а не о кодировании строк, которыми манипулирует реальный код модуля. (Если это не так, прошу прощения ...) Тогда я могу думать только о нескольких возможных случаях, когда может потребоваться взаимодействие / перекодирование:

• Модуль Wasm импортирует идентификатор платформы
• Платформа импортирует идентификатор Wasm
• Вы можете извлечь имена Wasm и распечатать их или сохранить с использованием строк платформы, например, для дампа трассировки стека.

Верно?

Для гипотетических встроенных систем, не поддерживающих Unicode, для первых двух случаев совет прост: ограничьте идентификаторы, импортируемые через границу платформы, в ASCII, тогда требуемое перекодирование будет тривиальным. Модули Wasm по-прежнему могли использовать полные имена Unicode для внутренних целей и для связи друг с другом.

Что касается третьей проблемы - если у вас есть закрытый мир модулей Wasm, вы можете ограничить их идентификаторы до ASCII. Если нет, то на практике вы столкнетесь с идентификаторами UTF8, и вам лучше иметь возможность их перекодировать, и вы будете довольны спецификацией UTF8!

подразумевая, что чьи-то символы, отличные от ASCII, априори не имеют значения

Это аргумент соломенного человека. Позиция здесь такова: «Если вам нужны идентификаторы, отличные от ASCII, используйте Unicode или реализуйте перекодирование в / из Unicode», и он не вызвал критики как «культурно сомнительный» в других спецификациях, AFAIK.

>

И если это обоснованное беспокойство, мы должны еще раз взвесить (возникновение

• стоимость) борьбы с этим по сравнению со стоимостью практически любого другогопользователь Wasm в мире, который не может зависеть от кодировки, и
  иметь дело с той же кодировкой - черт возьми, через веб-платформу,
  и в итоге исправили, как могли.

@tabatkins , нет, еще раз (и почему-то мне кажется, что я повторил эти 100
раз уже): в каждой спецификации встраивания _ будет_ указываться кодировка и
набор символов. На любую платформу вы можете положиться. Вы бы только когда-либо бежали
в вопросы кодирования, если вы пытались взаимодействовать между двумя несвязанными
экосистемы - которые уже будут несовместимы по более глубоким причинам, чем
струны. И это повлияет только на взаимодействие с платформами, которые в противном случае
исключить полностью. Таким образом, вы ничего не теряете, но получаете возможность использовать
Wasm на более разнообразных платформах.

Вы инженеры-программисты. Таким образом, я полагаю, вы понимаете и цените
ценность модульности и многоуровневости, чтобы разделить проблемы и максимизировать
повторное использование. Это относится и к спецификациям.

>

Платформы, не поддерживающие Unicode, будут вынуждены выполнять транскодирование, чтобы фактически
обращаться со своими струнами.

В каких случаях строки Wasm должны взаимодействовать со строками платформы,
хотя? Насколько я могу судить, мы говорим только о кодировании
строки в метаданных Wasm, а не кодировка строк, которыми управляет
фактический код модуля. (Если это не так, прошу прощения ...) Тогда я могу только думать
из нескольких возможных случаев, когда может потребоваться взаимодействие / перекодирование:

• Модуль Wasm импортирует идентификатор платформы
• Платформа импортирует идентификатор Wasm
• Вы можете извлечь имена Wasm и распечатать их или сохранить с помощью платформы
  строки, например, чтобы сбросить трассировку стека.

Верно?

да. Другими словами, каждый раз, когда вам действительно нужно _использовать_ строку.

Для гипотетических встроенных систем, не поддерживающих Unicode, для первых двух случаев
совет прост: ограничьте количество идентификаторов, импортируемых через платформу
граница с ASCII, то требуемая перекодировка тривиальна. Модули wasm
могли по-прежнему использовать полные имена Unicode для внутренних целей и для связи друг с другом.

По третьему вопросу - если у вас закрытый мир модулей Wasm, вы
могут ограничивать свои идентификаторы до ASCII. Если нет, то на практике вы
встречаются идентификаторы UTF8, и вам лучше иметь возможность их перекодировать, и
вы будете довольны спецификацией UTF8!

Согласно предложению вам не разрешено ничего ограничивать ASCII! К
Допустим, что основная спецификация должна быть более разрешающей. Итак, вы делаете
моя точка зрения.

каждая спецификация внедрения _ будет определять кодировку и набор символов. На любую платформу вы можете положиться. Вы столкнетесь с вопросами кодирования, только если попытаетесь взаимодействовать между двумя несвязанными экосистемами, которые уже будут несовместимы по более глубоким причинам, чем строки.

А как насчет таких инструментов обработки Wasm, как дизассемблеры? Разве не было бы ценной возможность написать дизассемблер, работающий с любым модулем Wasm, независимо от вариантов "встраивания спецификации"?

Согласно предложению вам не разрешено ничего ограничивать ASCII!

Согласно предложению, модули Wasm не будут ограничиваться ASCII, но если разработчик решит сделать все свои идентификаторы определенными вне модулей Wasm в формате ASCII (например, как это фактически делают почти все системные библиотеки!), Это выйдет за рамки Wasm. спец.

Если разработчик решил печатать только символы ASCII в трассировке стека и заменить все символы Unicode, отличные от ASCII, на ? или аналогичные, это должно быть разрешено спецификацией, поскольку на практике всегда существуют символы Unicode, которые вы не используете. в любом случае у меня нет шрифта.

Сказав все это, определение подмножества Wasm, в котором все имена Wasm являются ASCII, было бы довольно безобидным, поскольку такие модули Wasm будут правильно обрабатываться инструментами, которые обрабатывают имена Wasm как UTF8.

Вы инженеры-программисты. Таким образом, я предполагаю, что вы понимаете и цените ценность модульности и многоуровневости для разделения проблем и максимального повторного использования. Это относится и к спецификациям.

Да, я инженер-программист. Я также специалист по спецификациям, поэтому я понимаю ценность согласованности и установления норм, которые улучшают работу экосистемы. Наборы символов и кодировки - одна из тем, в которой ценность возможности модульности и выбора значительно перевешивается ценностью согласованности и предсказуемости. У нас есть буквально десятилетия доказательств этого. Вот почему я продолжаю повторять себе - вы игнорируете историю и рекомендации многих экспертов, некоторые из которых показали в этой самой теме, и многие другие , которые я представляю мнение, когда вы настаиваете , что нам нужно дайте свободу в этом отношении.

Прочитав весь этот (длинный) поток, я думаю, что единственный способ разрешить это обсуждение - это явно указать, что раздел имен, который мы описываем, в двоичном формате и улучшаем в https://github.com/WebAssembly/design/pull / 984 - это кодировка UTF-8 , и я предлагаю просто назвать этот раздел «utf8-names» . Это делает кодировку явной, и почти наверняка все инструменты, которые хотят манипулировать двоичными файлами WASM на всех соответствующих платформах, сегодня в любом случае хотят использовать UTF-8. Их можно простить за то, что они говорят только на UTF-8.

Я чутко отношусь к проблемам @ rossberg-chromium по поводу других платформ и в некоторой степени согласен. Однако это легко поправимо. Как кто-то предложил ранее в потоке, эти системы более чем приветствуются для добавления нестандартного раздела «ascii-names» или любой другой кодировки, которую использует их экосистема. С явными именами становится очевидно, какие инструменты с какими разделами работают. Для модулей, которые работают только с DOS, это станет очевидным из наличия разделов, относящихся к DOS. ИМО было бы катастрофой интерпретировать имена этих двоичных файлов как имеющие другую кодировку.

(Между прочим, это происходит из военных историй о системе, которая случайно потеряла кодировки строк для загружаемого пользователем контента и никогда не смогла их восстановить. Система умерла ужасной судорожной смертью. Буквально были потеряны миллионы долларов .)

Мы могли бы даже принять стандарт именования разделов имен (хех), чтобы все они были "\

@titzer Да, настраиваемые разделы - это решение для экзотических или специализированных платформ, которые не хотят иметь ничего общего с UTF8. Однако я бы не решился прописать в спецификации: если платформа настолько специфична в своем режиме работы, что ее даже не беспокоит сопоставление кодовых точек UTF-8 с их собственными предпочтениями, они могут захотеть сделать гораздо больше с настраиваемыми разделами, чем просто предоставление имен в их предпочтительной кодировке.

Я рекомендую уделять больше внимания использованию настраиваемых разделов для конкретных деталей платформы в спецификации и позволить собственным спецификациям платформы определять эти детали. Общие инструменты WASM могут поддерживать их через какую-то архитектуру подключаемых модулей.

@titzer Переход на utf8-names звучит нормально. В качестве бонуса это сгладит переход, поскольку браузеры могут легко поддерживать как «имена» (в старом формате), так и «utf8-names» (в формате # 984) для одного или двух выпусков, прежде чем отбрасывать «имена», которые, в свою очередь, устраняет срочность развертывания этого.

Извините, если это уже было решено выше, но для ясности: есть ли какие-либо предлагаемые изменения в именах импорта / экспорта из того, что сейчас находится в BinaryEncoding.md?

utf8-names звучит нормально.

Тот же вопрос, что и @lukewagner по импорту / экспорту.

@lukewagner @jfbastien Хороший вопрос. Я не видел решения выше. Я думаю, что прежде всего мы не хотим менять двоичный формат, который у нас есть сейчас. Так что это действительно те умственные искажения, через которые мы должны пройти, чтобы убедить себя в том, что мы сделали рационально :-)

AFAICT в настоящее время мы предполагаем, что строки в импорте / экспорте являются неинтерпретируемыми последовательностями байтов. Хорошо. Я думаю, что разумно считать, что кодировка строк, используемых для импорта / экспорта, определяется исключительно устройством для внедрения, в отличие от раздела имен; Например, JS всегда использует UTF-8. Раздел имен имеет явную кодировку в имени раздела имен.

Краткая версия: кодирование имен в декларациях импорта / экспорта является свойством среды внедрения, кодирование имен в разделе имен явным образом определяется строкой, используемой для идентификации раздела пользователя (например, «utf8-names»).

WDYT?

Меня это устраивает и соответствует тому, что было до слияния # 984 (по модулю names => utf8-names ).

Я думаю, что раздел имен не так важен, как импорт / экспорт, где и возникают настоящие проблемы совместимости:

• Загрузите раздел mojibaked names, и вы получите забавный Error.stack и отладку.
• Загрузите импорт / экспорт моджибакса, и ничего не работает.

Я не думаю, что это действительно изменение двоичного формата, поскольку все внедряемые элементы уже предполагают это.

Прежде чем закончить, я бы полагался на рекомендации людей, которые лучше меня разбираются в этой теме.

Вам нужно будет решить, как вы декодируете UTF-8. Вы заменяете ошибочные последовательности на U + FFFD или останавливаетесь при первой ошибке? То есть вам нужно либо https://encoding.spec.whatwg.org/#utf -8-decode-without-bom, либо https://encoding.spec.whatwg.org/#utf -8-decode-without- бомба или неудача. В любом случае загрузка, скорее всего, не удастся, если только ресурс не использовал U + FFFD в своем имени.

Как это сейчас описано, мы генерируем исключение, если байтовый массив имени импорта / экспорта не может декодироваться как UTF-8 в строку JS. После этого у вас есть строка JS, и поиск при импорте определяется в терминах Get .

Чтобы проверить мое понимание, если бы мы сделали https://encoding.spec.whatwg.org/#utf -8-decode-without-bom-or-fail, это означало бы, что после успешной проверки проверка на равенство кодовых точек и последовательностей будет эквивалентно проверке на равенство байтовой последовательности?

да.

После обсуждения выше я поддерживаю проверку UTF-8 для имен импорта / экспорта в основной спецификации.

В частности, это будет utf-8-decode-without-bom-or-fail и равенство кодовых точек и последовательностей (чтобы движки могли выполнять равенство байтовых последовательностей ), чтобы движки избегали пугающих и дорогостоящих частей Unicode и интернационализации. И это согласуется с встраиванием в Интернет. Я экспериментировал с этим и обнаружил, что основные накладные расходы незначительны.

• Re: Аппаратные ISA не зависят от кодирования: оборудование, о котором мы здесь говорим, не имеет импорта / экспорта как такового, поэтому аналогия не применима напрямую. Единственное место, где я знаю, где такое оборудование использует идентификаторы байтовых последовательностей любого типа, cpuid x86, действительно определяет конкретную кодировку символов: UTF-8.

• Re: Layering: Как программисты, мы также знаем, что разделение на слои и модуляризация - это средства, а не самоцель. Например, мы можем полностью исключить LEB128 из основной спецификации. Это обеспечило бы большую разбиение на слои и модуляризацию. LEB128, возможно, предвзято относится к вариантам использования в Интернете.

• Re: «Встроенные системы»: приведен пример DOS, но каков будет пример того, что требование UTF-8 для имен импорта / экспорта потребовало бы от системы DOS, что было бы дорогостоящим или непрактичным для нее?

• Re: Islands: WebAssembly также определяет конкретный порядок байтов, требует поддержки чисел с плавающей запятой, 8-битных единиц адреса и делает другие варианты, даже несмотря на то, что существуют реальные настройки, в которых это было бы ненужным бременем. WebAssembly делает подобный выбор, когда ожидает, что они укрепят общую платформу, которой могут поделиться многие люди.

• Re: Произвольные структуры данных в именах импорта / экспорта: это теоретически полезно, но это также можно сделать путем преобразования данных в строки. Манипуляция менее удобна, но не сложна. Так что здесь есть компромисс, но небольшой (и, возможно, если есть общая потребность в прикреплении метаданных к импорту / экспорту, было бы лучше иметь явный механизм, чем обременять идентификаторы дополнительными целями).

• Re: Двоичная совместимость: Я также согласен с JF, что это изменение все еще возможно. utf-8-decode-without-bom-or-fail означал бы отсутствие тихих изменений поведения, и в настоящее время все известные производители wasm сохраняют свой вывод совместимым с веб-встраиванием (даже если они также поддерживают другие встраивания), поэтому они ' re уже находится в UTF-8.

PR с конкретным предложением для имен UTF-8 теперь размещен по адресу https://github.com/WebAssembly/design/issues/1016.

В # 1016 это исправлено.