Насколько хорошо работает Node.поддержка JS для Unicode?
по его спецификация языка JavaScript имеет некоторые проблемы с Unicode (если я правильно понимаю), поскольку текст всегда обрабатывается как один символ, состоящий из 16 бит внутри.
JavaScript: Хорошие Части высказывается аналогичным образом.
когда вы ищете Google для поддержки UTF-8 V8, вы получаете противоречивые заявления.
Итак: каково состояние поддержки Unicode в узле.в JS (0.10.26 был текущая версия, когда был задан этот вопрос)? Правильно ли он обрабатывает UTF-8 все возможные кодовые точки или нет?
Если нет: какие возможны обходные пути?
2 ответов
два источника, которые вы цитируете,спецификация языка и "JavaScript: хорошие части" Крокфорда (стр. 103) говорят то же самое, хотя последний говорит это гораздо более кратко (и ясно, если вы уже знаете предмет). Для справки приведу Крокфорда:
JavaScript был разработан в то время, когда Unicode должен был иметь не более 65 536 символов. С тех пор он вырос, чтобы иметь емкость более 1 миллиона символов.
символы JavaScript составляют 16 бит. Этого достаточно, чтобы покрыть оригинальный 65,536 (который теперь известен как основной многоязычный самолет). Каждый из оставшихся миллионов символов может быть представлен в виде пары символов. Unicode рассматривает пару как один символ. JavaScript считает, что пара-это два разных символа.
спецификация языка вызывает 16-разрядный блок "символ"и" кодовый блок". В "Юникоде", или "код точки", с другой рука, может (в редких случаях) нужны две 16-битные "кодовые единицы", которые будут представлены.
все строковые свойства и методы JavaScript, такие как length
, substr()
, etc., работа с 16-битными "символами" (было бы очень неэффективно работать с 16-битными/32-битными символами Юникода, т. е. символами UTF-16). Например, это означает, что, если вы не будете осторожны, с substr()
вы можете оставить одну половину 32-битного символа Юникода UTF-16. JavaScript не будет жаловаться, пока вы его не отобразите, и возможно, даже не будет жаловаться, если ты это сделаешь. Это потому, что, как говорится в спецификации, JavaScript делает не проверьте, что символы действительны UTF-16, это только предполагает они.
в вашем вопросе вы спрашиваете
Делает [Узел.js] обрабатывать UTF-8 будет ли все возможные кодовые точки правильно, или нет?
Так как все возможные кодовые точки UTF-8 преобразуются в UTF-16 (как один или два 16-битных "символа") на входе перед все остальное происходит, и наоборот, на выходе ответ зависит от того, что вы подразумеваете под "правильно", но если вы принимаете интерпретацию JavaScript этого "правильно", ответ "да".
тип строки JavaScript-UTF-16, поэтому его поддержка Unicode составляет 100%. все UTF формы поддерживают все кодовые точки Unicode.
вот общая разбивка общих форм:
- UTF-8 - 8-разрядные кодовые единицы; переменная ширина (кодовые точки-1-4 кодовых единицы)
- UTF-16 - 16-битовые кодовые единицы; переменная ширина (кодовые точки-1-2 кодовых единицы); big-прямой или с прямым порядком байтов
- UTF-32 - 32-долото кодовые единицы; фиксированная ширина; big-endian или little endian
UTF-16 был популяризирован, когда считалось, что каждая кодовая точка будет соответствовать 16 битам. Но это было не так. UTF-16 был позже переработан, чтобы кодовые точки могли принимать две единицы кода, а старая версия была переименована в UCS-2.
однако, оказывается, что видимые ширины не очень хорошо приравниваются к блокам памяти, так что UTF-16 и UTF-32 имеют ограниченную полезность. Естественный язык сложные и во многих случаях последовательности кодовых точек удивительно сочетаются.
измерение ширины для "символа" зависит от контекста. Память? Количество видимых графем? Ширина рендеринга в пикселях?
UTF-16 остается в общем использовании, потому что многие из современных популярных языков / сред (Java / JavaScript / Windows NT) родились в 90-х. Она не сломана. Однако, в UTF-8, как правило, предпочтительнее.
Если вы страдаете от проблема потери/повреждения данных обычно возникает из-за дефекта в транскодере или неправильного его использования.