✖


Jump to content

UTF-16

(Перенаправлено с кодовой страницы 1200 )
UTF-16
Первые 2 16 Кодовые точки Юникода. Белая полоса внизу — это суррогатные половины, используемые UTF-16.
Язык(и) Международный
Стандартный Стандарт Юникод
Классификация Формат преобразования Unicode , кодировка переменной ширины
Расширяет УКС-2
Преобразует/кодирует ISO/IEC 10646 ( Юникод )

UTF-16 ( 16-битный формат преобразования Unicode ) — это кодировка символов , способная кодировать все 1 112 064 допустимых кодовых точки Unicode (фактически это количество кодовых точек продиктовано конструкцией UTF-16). Кодирование имеет переменную длину , поскольку кодовые точки кодируются одной или двумя 16-битными кодовыми единицами . UTF-16 возник из более ранней устаревшей 16-битной кодировки фиксированной ширины, теперь известной как «UCS-2» (для 2-байтового универсального набора символов), [1] [2] как только выяснилось, что более 2 16 (65 536) кодовых точек было необходимо, [3] включая большинство смайлов и важные символы CJK, такие как личные имена и названия мест. [4]

UTF-16 используется такими системами, как Microsoft Windows API , язык программирования Java и JavaScript /ECMAScript. Он также иногда используется для файлов данных обычного текста и текстовой обработки в Microsoft Windows. Он используется более современными реализациями SMS . [5]

UTF-16 — единственная кодировка (все еще), разрешенная в Интернете, несовместимая с ASCII. [6] [номер 1] и никогда не пользовался популярностью в Интернете, где о нем заявляют менее 0,004% веб-страниц. [8] Для сравнения, на UTF-8 приходится более 98% всех веб-страниц. [9] Рабочая группа по технологиям веб-гипертекстовых приложений (WHATWG) считает UTF-8 «обязательной кодировкой для всего [текста]» и что по соображениям безопасности браузерные приложения не должны использовать UTF-16. [10]

История

[ редактировать ]

В конце 1980-х годов началась работа над разработкой единой кодировки для «Универсального набора символов» ( UCS ), которая заменила бы более ранние кодировки, специфичные для конкретного языка, одной координированной системой. Цель состояла в том, чтобы включить все необходимые символы из большинства языков мира, а также символы из технических областей, таких как наука, математика и музыка. Первоначальная идея заключалась в замене типичных 256-символьных кодировок, для которых требовался 1 байт на символ, кодировкой, использующей 65 536 (2 16 ) значения, для которых потребуется 2 байта (16 бит) на символ.

Над этим параллельно работали две группы: ISO/IEC JTC 1/SC 2 и Консорциум Unicode , причем последний представлял в основном производителей компьютерного оборудования. Обе группы попытались синхронизировать назначение символов, чтобы разрабатываемые кодировки были взаимно совместимыми. Ранняя 2-байтовая кодировка первоначально называлась «Юникод», но теперь называется «UCS-2». [1] [2] [11]

Когда стало все более ясно, что 2 16 персонажей не хватит, [12] IEEE представил увеличенное 31-битное пространство и кодировку ( UCS-4 ), которая требовала 4 байта на символ. сопротивлялся этому Консорциум Unicode как потому, что 4 байта на символ тратили много памяти и дискового пространства, так и потому, что некоторые производители уже вложили значительные средства в технологию 2 байта на символ. Схема кодирования UTF-16 была разработана как компромисс и представлена ​​в версии 2.0 стандарта Unicode в июле 1996 года. [13] Полностью он описан в RFC 2781, опубликованном IETF в 2000 году . [14] [15]

UTF-16 указан в последних версиях международного стандарта ISO/IEC 10646 и стандарта Unicode. «UCS-2 теперь следует считать устаревшим. Он больше не относится к форме кодировки ни в 10646, ни в стандарте Unicode». [1] [2] UTF-16 никогда не будет расширяться для поддержки большего количества кодовых точек или для поддержки кодовых точек, которые были заменены суррогатными кодами, поскольку это нарушит политику стабильности Unicode в отношении общей категории или суррогатных кодовых точек. [16] (Любая схема, которая остается самосинхронизирующимся кодом, потребует выделения хотя бы одной кодовой точки базовой многоязычной плоскости (BMP) для запуска последовательности. Изменение назначения кодовой точки запрещено.)

Описание

[ редактировать ]

Юникода Каждая кодовая точка кодируется одной или двумя 16-битными кодовыми единицами . Кодовые точки менее 2 16 («в BMP») кодируются одной 16-битной кодовой единицей, равной числовому значению кодовой точки, как в более старой версии UCS-2. Кодовые точки больше или равны 2 16 («выше BMP») кодируются с использованием двух 16-битных кодовых единиц. Эти две 16-битные кодовые единицы выбираются из суррогатного диапазона UTF-16. 0xD800–0xDFFF , которые ранее не были назначены символам. Значения в этом диапазоне не используются как символы, и UTF-16 не предоставляет законного способа кодировать их как отдельные кодовые точки. Таким образом, поток UTF-16 состоит из одиночных 16-битных кодов вне суррогатного диапазона и пар 16-битных значений, находящихся в пределах суррогатного диапазона.

От U+0000 до U+D7FF и от U+E000 до U+FFFF

[ редактировать ]
От U+D800 до U+DFFF имеют специальное назначение, см. ниже.

И UTF-16, и UCS-2 кодируют кодовые точки в этом диапазоне как отдельные 16-битные кодовые единицы, численно равные соответствующим кодовым точкам. Эти кодовые точки в базовой многоязычной плоскости (BMP) являются единственными кодовыми точками, которые могут быть представлены в UCS-2. [ нужна ссылка ] Начиная с версии Unicode 9.0, некоторые современные нелатинские азиатские, ближневосточные и африканские алфавиты выходят за пределы этого диапазона, как и большинство символов эмодзи .

Кодовые точки от U+010000 до U+10FFFF

[ редактировать ]

Кодовые точки из других плоскостей кодируются как две 16-битные кодовые единицы, называемые суррогатной парой . Первая единица кода — это старший суррогат , а вторая — младший суррогат (они также известны как «ведущие» и «конечные» суррогаты соответственно, аналогично начальному и конечному байтам UTF-8. [17] ):

декодер UTF-16
Низкий
Высокий
DC00 DC01    ...    ДФФФ
Д800 010000 010001 ... 0103FF
Д801 010400 010401 ... 0107FF
⋮ ⋮ ⋮ ⋱ ⋮
ДБФФ 10FC00 10FC01 ... 10FFFF
  • 0x10000 вычитается из кодовой точки (U) , оставляя 20-битное число (U') в диапазоне шестнадцатеричных чисел 0x00000–0xFFFFF.
  • Старшие десять битов (в диапазоне 0x000–0x3FF) добавляются к 0xD800, чтобы получить первую 16-битную кодовую единицу или старший суррогат (W1) , который будет находиться в диапазоне 0xD800–0xDBFF .
  • Младшие десять битов (также в диапазоне 0x000–0x3FF) добавляются к 0xDC00, чтобы дать вторую 16-битную кодовую единицу или младший суррогат (W2) , который будет находиться в диапазоне 0xDC00–0xDFFF .

Визуально распределение U' между W1 и W2 выглядит следующим образом: [18] 

U' = yyyyyyyyyyxxxxxxxxxx  // U - 0x10000W1 = 110110yyyyyyyyyy      // 0xD800 + yyyyyyyyyyW2 = 110111xxxxxxxxxx      // 0xDC00 + xxxxxxxxxx

Поскольку диапазоны для старших суррогатов ( 0xD800–0xDBFF ), младшие суррогаты ( 0xDC00–0xDFFF ), а допустимые символы BMP (0x0000–0xD7FF, 0xE000–0xFFFF) не пересекаются , суррогатный символ не может соответствовать символу BMP или две соседние кодовые единицы выглядеть как допустимая суррогатная пара . Это значительно упрощает поиск. Это также означает, что UTF-16 самосинхронизируется на 16-битных словах: можно определить, начинает ли кодовая единица символ, без проверки предыдущих кодовых единиц (т. е. тип кодовой единицы можно определить по диапазонам значений, в которых она падает). UTF-8 разделяет эти преимущества, но многие более ранние схемы многобайтового кодирования (например, Shift JIS и другие азиатские многобайтовые кодировки) не позволяли однозначного поиска и могли быть синхронизированы только путем повторного анализа с начала строки. UTF-16 не является самосинхронизирующимся, если один байт потерян или если обход начинается со случайного байта.

Поскольку все наиболее часто используемые символы находятся в формате BMP, обработка суррогатных пар часто тщательно не проверяется. Это приводит к постоянным ошибкам и потенциальным дырам в безопасности даже в популярном и хорошо проверенном прикладном программном обеспечении (например, CVE — 2008-2938 , CVE- 2012-2135 ).

От U+D800 до U+DFFF (суррогаты)

[ редактировать ]

Официальный стандарт Unicode гласит, что никакие формы UTF, включая UTF-16, не могут кодировать суррогатные кодовые точки. Поскольку им никогда не будет присвоен символ, не должно быть причин их кодировать. Однако Windows допускает непарные суррогаты в именах файлов. [19] и других местах, что обычно означает, что они должны поддерживаться программным обеспечением, несмотря на их исключение из стандарта Unicode.

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

Можно однозначно закодировать непарный суррогат (старшая суррогатная кодовая точка, за которой не следует младшая, или младшая, которой не предшествует старшая) в формате UTF-16, используя кодовую единицу, равную кодовой точке. . Результат не является допустимым UTF-16, но большинство реализаций кодировщика и декодера UTF-16 делают это при переводе между кодировками. [ нужна ссылка ]

Примеры

[ редактировать ]

Чтобы закодировать U+10437 (𐐷) в UTF-16:

  • Вычтите 0x10000 из кодовой точки, оставив 0x0437.
  • Для старшего суррогата сдвиньте вправо на 10 (делите на 0x400), затем добавьте 0xD800, в результате чего получится 0x0001 + 0xD800 = 0xD801.
  • Для младшего суррогата возьмите младшие 10 бит (остаток от деления на 0x400), затем добавьте 0xDC00, в результате чего получится 0x0037 + 0xDC00 = 0xDC37.

Чтобы декодировать U+10437 (𐐷) из UTF-16:

  • Возьмите старший заместитель (0xD801) и вычтите 0xD800, затем умножьте на 0x400, в результате чего получим 0x0001 × 0x400 = 0x0400.
  • Возьмите младший заместитель (0xDC37) и вычтите 0xDC00, в результате чего получится 0x37.
  • Сложите эти два результата вместе (0x0437) и, наконец, добавьте 0x10000, чтобы получить окончательную кодовую точку 0x10437.

В следующей таблице суммированы это преобразование, а также другие. Цвета показывают, как биты кодовой точки распределяются между байтами UTF-16. Дополнительные биты, добавленные в процессе кодирования UTF-16, показаны черным цветом.

Характер Двоичная кодовая точка Двоичный UTF-16 UTF-16 шестнадцатеричный
кодовые единицы 		UTF-16BE
шестнадцатеричные байты 		UTF-16LE
шестнадцатеричные байты
$ U+00240000 0000 0010 01000000 0000 0010 0100002400 2424 00
€ U+20AC0010 0000 1010 11000010 0000 1010 110020AC20 ACAC 20
𐐷 U+104370001 0000 0100 0011 01111101 1000 0000 0001 1101 1100 0011 0111D801 DC37D8 01 DC 3701 D8 37 DC
𤭢 U+24B620010 0100 1011 0110 00101101 1000 0101 0010 1101 1111 0110 0010D852 DF62D8 52 DF 6252 D8 62 DF

Схемы кодирования порядка байтов

[ редактировать ]

UTF-16 и UCS-2 создают последовательность 16-битных кодовых единиц. Поскольку большинство протоколов связи и хранения определены для байтов, и каждое устройство, таким образом, занимает два 8-битных байта, порядок байтов может зависеть от порядка байтов (порядка байтов) компьютерной архитектуры.

Чтобы помочь распознать порядок байтов кодовых единиц, UTF-16 позволяет метке порядка байтов (BOM), кодовой точке со значением U+FEFF, предшествовать первому фактическому кодированному значению. [номер 2] (U+FEFF — это невидимый неразрывный пробел нулевой ширины /ZWNBSP). [номер 3] Если архитектура декодера с порядком байтов соответствует архитектуре кодера, декодер обнаруживает значение 0xFEFF, но декодер с противоположным порядком байтов интерпретирует спецификацию как несимвольное значение U+FFFE, зарезервированное для этой цели. Этот неверный результат подсказывает, что нужно выполнить замену байтов для оставшихся значений.

Если спецификация отсутствует, RFC 2781 рекомендует [номер 4] предполагается кодирование с прямым порядком байтов (BE). На практике, поскольку Windows по умолчанию использует порядок с прямым порядком байтов (LE), многие приложения предполагают кодировку с прямым порядком байтов. Также можно надежно определить порядок байтов, ища нулевые байты, при условии, что символы меньше U+0100 очень распространены. Если более четные байты (начиная с 0) равны нулю, то это обратный порядок байтов.

Стандарт также позволяет явно указывать порядок байтов, указав UTF-16BE или UTF-16LE в качестве типа кодировки. Когда порядок байтов указан таким образом явно, спецификация не должна добавляться к тексту, а U+FEFF в начале следует обрабатывать как символ ZWNBSP. Несмотря на это правило, большинство приложений во всех случаях игнорируют спецификацию.

Для интернет- протоколов IANA утвердила названия этих кодировок «UTF-16», «UTF-16BE» и «UTF-16LE» (имена нечувствительны к регистру). Псевдонимы UTF_16 или UTF16 могут иметь смысл в некоторых языках программирования или программных приложениях, но они не являются стандартными именами в интернет-протоколах.

Похожие обозначения UCS-2BE и UCS-2LE используются для обозначения версий UCS-2 .

Размер

[ редактировать ]

«Символ» может использовать любое количество кодовых точек Юникода. [20] Например, символ флага эмодзи занимает 8 байт, поскольку он «составлен из пары скалярных значений Юникода». [21] (и эти значения находятся за пределами BMP и требуют по 4 байта каждое). UTF-16 никоим образом не помогает «подсчитывать символы» или «измерять ширину строки».

Часто утверждается, что UTF-16 более экономичен, чем UTF-8, для восточноазиатских языков, поскольку он использует два байта для символов, которые в UTF-8 занимают 3 байта. Поскольку реальный текст содержит много пробелов, цифр, знаков препинания, разметки (например, для веб-страниц) и управляющих символов, которые в UTF-8 занимают только один байт, это справедливо только для искусственно созданных плотных блоков текста. [ нужна ссылка ] Более серьезные претензии можно предъявить к деванагари и бенгали , которые используют многобуквенные слова и все буквы занимают 3 байта в UTF-8 и только 2 в UTF-16.

Кроме того, китайский стандарт кодирования Unicode GB 18030 всегда создает файлы того же размера или меньше, чем UTF-16, для всех языков, а не только для китайского (он делает это за счет принесения в жертву самосинхронизации).

Использование

[ редактировать ]

UTF-16 используется для текста в API ОС всех поддерживаемых на данный момент версий Microsoft Windows (и включая, по крайней мере, все, начиная с Windows CE / 2000 / XP / 2003 / Vista / 7). [22] ), включая Windows 10 . В Windows XP код выше U+FFFF не включен ни в один шрифт, поставляемый с Windows для европейских языков. [23] [24] Старые системы Windows NT (до Windows 2000) поддерживают только UCS-2 . [25] Файлы и сетевые данные, как правило, представляют собой смесь кодировок UTF-16, UTF-8 и устаревших байтовых кодировок.

Хотя некоторая поддержка UTF-8 имеется даже в Windows XP, [26] он был улучшен (в частности, возможность называть файл с использованием UTF-8) в инсайдерской сборке Windows 10 17035 и обновлении за май 2019 года. По состоянию на май 2019 года Microsoft рекомендует использовать в программном обеспечении UTF-8 в Windows и Xbox вместо других 8-битных кодировок. [27] Неясно, рекомендуют ли они использовать UTF-8 вместо UTF-16, хотя они заявляют, что «UTF-16 [..] — это уникальное бремя, которое Windows налагает на код, предназначенный для нескольких платформ». [28]

Операционная система IBM i обозначает CCSID ( кодовую страницу ) 13488 для кодировки UCS-2 и CCSID 1200 для кодировки UTF-16, хотя система обрабатывает их оба как UTF-16. [29]

UTF-16 используется операционными системами Qualcomm BREW ; среды .NET ; и Qt набор инструментов для кроссплатформенных графических виджетов .

ОС Symbian , используемая в телефонах Nokia S60, и телефонах Sony Ericsson UIQ использует UCS-2. Телефоны iPhone используют UTF-16 для службы коротких сообщений вместо UCS-2, описанного в стандартах 3GPP TS 23.038 ( GSM ) и IS-637 ( CDMA ). [30]

Файловая система Joliet , используемая на носителях компакт-дисков , кодирует имена файлов с помощью UCS-2BE (до шестидесяти четырех символов Юникода на имя файла).

Python версии 2.0 официально использовал только UCS-2 внутри, но декодер UTF-8 в «Unicode» выдавал правильный UTF-16. Также была возможность скомпилировать Python так, чтобы он внутри использовал UTF-32, иногда это делалось в Unix. Python 3.3 переключил внутреннюю память на использование одного из ISO-8859-1 , UCS-2 или UTF-32 в зависимости от наибольшей кодовой точки в строке. [31] В Python 3.12 отсутствуют некоторые функции (для расширений CPython), чтобы упростить переход на UTF-8 для всех строк. [32]

Первоначально Java использовала UCS-2 и добавила поддержку дополнительных символов UTF-16 в J2SE 5.0 . Недавно они призвали отказаться от поддержки любой 8-битной кодировки, кроме UTF-8. [33] но внутри все еще используется UTF-16.

JavaScript может использовать UCS-2 или UTF-16. [34] Начиная с ES2015, в язык были добавлены строковые методы и флаги регулярных выражений, которые позволяют обрабатывать строки с точки зрения независимости от кодировки.

UEFI по умолчанию использует UTF-16 для кодирования строк.

Swift , предпочтительный язык приложений Apple, использовал UTF-16 для хранения строк до версии 5, которая переключилась на UTF-8. [35]

Многие языки делают кодировку частью строкового объекта и, таким образом, хранят и поддерживают большой набор кодировок, включая UTF-16. Большинство считают UTF-16 и UCS-2 разными кодировками. Примеры: PHP. язык [36] и MySQL . [37]

Чтобы определить, какую кодировку использует система внутри, нужно запросить «длину» строки, содержащей один символ, отличный от BMP. Если длина равна 2, то используется UTF-16. 4 указывает UTF-8. 3 или 6 могут обозначать CESU-8 . 1 может указывать на UTF-32, но, скорее всего, указывает на то, что язык декодирует строку до кодовых точек перед измерением «длины».

Во многих языках строки в кавычках нуждаются в новом синтаксисе для цитирования символов, отличных от BMP, как в стиле C. "\uXXXX" синтаксис явно ограничивается четырьмя шестнадцатеричными цифрами. Следующие примеры иллюстрируют синтаксис символа, отличного от BMP. U+1D11E 𝄞 МУЗЫКАЛЬНЫЙ СИМВОЛ G КЛЮЧ :

  • Наиболее распространенным ( C++ , C# , D и некоторыми другими языками) является буква «U» в верхнем регистре с 8 шестнадцатеричными цифрами, например "\U0001D11E". [38]
  • Регулярные выражения Java 7, ICU и Perl используют "\x{1D11E}".
  • ECMAScript 2015 (JavaScript) использует "\u{1D11E}".
  • Во многих других случаях (например, Java вне регулярных выражений) [39] единственный способ получить символы, отличные от BMP, — это ввести суррогатные половинки по отдельности: "\uD834\uDD1E".

См. также

[ редактировать ]

Примечания

[ редактировать ]
  1. ^ UTF-32 также несовместим с ASCII, но не указан в качестве веб-кодировки. [7]
  2. ^ Кодировка UTF-8 дает значения байтов строго меньше 0xFE, поэтому любой байт в последовательности спецификации также идентифицирует кодировку как UTF-16 (при условии, что UTF-32 не ожидается).
  3. ^ Использование U+FEFF в качестве символа ZWNBSP вместо спецификации устарело в пользу U+2060 (WORD JOINER); см. Часто задаваемые вопросы о метке порядка байтов (BOM) на сайте Unicode.org. Но если приложение интерпретирует исходную спецификацию как символ, символ ZWNBSP невидим, поэтому влияние минимально.
  4. ^ В разделе 4.3 RFC   2781 говорится, что если спецификации нет, «текст СЛЕДУЕТ интерпретировать как имеющий обратный порядок байтов». Согласно разделу 1.2, значение термина «СЛЕДУЕТ» регулируется РФК   2119 . В разделе 3 этого документа говорится: «...в определенных обстоятельствах могут существовать веские причины игнорировать тот или иной пункт, но необходимо понять все последствия и тщательно взвесить, прежде чем выбирать другой курс».

Ссылки

[ редактировать ]
  1. ^ Jump up to: а б с «C.2 Формы кодирования в ISO/IEC 10646» (PDF) . Стандарт Юникод, версия 6.0 . Маунтин-Вью, Калифорния: Консорциум Unicode . Февраль 2011. с. 573. ИСБН  978-1-936213-01-6 . [...] термин UCS-2 теперь следует считать устаревшим. Он больше не относится к форме кодировки ни в 10646, ни в стандарте Unicode.
  2. ^ Jump up to: а б с «Часто задаваемые вопросы: в чем разница между UCS-2 и UTF-16?» . unicode.org . Архивировано из оригинала 18 августа 2003 г. Проверено 19 марта 2024 г. UCS-2 — это устаревшая терминология, которая относится к реализации Unicode до версии Unicode 1.1 [...]
  3. ^ «Что такое UTF-16?» . Консорциум Юникод . Юникод, Инк . Проверено 7 января 2023 г. UTF-16 использует одну 16-битную кодовую единицу для кодирования более 60 000 наиболее распространенных символов Юникода.
  4. ^ Лунде, Кен (9 января 2022 г.). «Список десяти лучших 2022 года: зачем поддерживать кодовые элементы Beyond-BMP?» . Середина . Проверено 7 января 2024 г. Впервые идея создания этого списка первой десятки пришла мне в голову более 10 лет назад, и это было вызвано некоторыми средами, которые до сих пор поддерживали только кодовые точки BMP. Идея, конечно же, заключалась в том, чтобы мотивировать разработчиков таких сред поддерживать элементы кода, выходящие за рамки BMP, путем предоставления перечисленного списка причин для этого. И да, до сих пор существуют среды, поддерживающие только коды BMP, например приложение VivaDesigner.
  5. ^ Чад Селф (08 ноября 2012 г.). «Приключения в Юникоде СМС» . Твилио. Архивировано из оригинала 8 сентября 2015 г. Проверено 28 августа 2015 г.
  6. ^ «HTML-уровень жизни» . w3.org . 10.06.2020. Архивировано из оригинала 8 сентября 2020 г. Проверено 15 июня 2020 г. Кодировки UTF-16 — единственные кодировки, которые в данной спецификации должны рассматриваться как несовместимые с ASCII.
  7. ^ «Стандарт кодирования» . кодирование.spec.whatwg.org . Проверено 22 апреля 2023 г.
  8. ^ «Статистика использования UTF-16 для веб-сайтов, январь 2024 г.» . w3techs.com . Проверено 7 января 2024 г.
  9. ^ «Статистика использования UTF-8 для веб-сайтов, декабрь 2023 г.» . w3techs.com . Проверено 1 декабря 2023 г.
  10. ^ «Стандарт кодирования» . кодирование.spec.whatwg.org . Проверено 22 октября 2018 г. Кодировка UTF-8 является наиболее подходящей кодировкой для обмена Unicode, универсальным набором кодированных символов. Поэтому для новых протоколов и форматов, а также существующих форматов, развернутых в новых контекстах, данная спецификация требует (и определяет) кодировку UTF-8. [..] Проблемы, описанные здесь, исчезают при использовании исключительно UTF-8, что является одной из многих причин, по которым UTF-8 теперь является обязательной кодировкой для всех текстовых объектов в Интернете.
  11. ^ «MySQL :: Справочное руководство MySQL 5.7 :: 10.1.9.4 Набор символов ucs2 (кодировка Unicode UCS-2)» . dev.mysql.com .
  12. ^ «Что такое UTF-16?» . Консорциум Юникод . Юникод, Инк . Проверено 29 марта 2018 г.
  13. ^ «Вопросы о формах кодирования» . Проверено 12 ноября 2010 г.
  14. ^ ISO/IEC 10646:2014 «Информационные технологии – универсальный набор кодированных символов (UCS)», разделы 9 и 10.
  15. ^ Стандарт Unicode версии 7.0 (2014 г.), раздел 2.5.
  16. ^ «Политика стабильности кодировки символов Юникода» . unicode.org .
  17. ^ Аллен, Джули Д.; Андерсон, Дебора; Беккер, Джо ; Кук, Ричард, ред. (2014). «3.8 Суррогаты» (PDF) . Стандарт Unicode, версия 7.0 — основная спецификация . Маунтин-Вью: Консорциум Unicode . п. 118. Архивировано (PDF) из оригинала 9 октября 2022 г. Проверено 3 ноября 2014 г.
  18. ^ Жержо, Франсуа; Хоффман, Пол (февраль 2000 г.). «UTF-16, кодировка ISO 10646» . www.tools.ietf.org . Проверено 18 июня 2019 г.
  19. ^ «Ограничение максимальной длины пути» . Майкрософт . 18 июля 2022 г. Проверено 10 октября 2022 г. […] файловая система рассматривает пути и имена файлов как непрозрачную последовательность символов WCHAR.
  20. ^ «Это не неправильно, что "🤦🏼‍♂️".длина == 7" . hsivonen.fi . Проверено 15 марта 2021 г.
  21. ^ «Документация разработчика Apple» . разработчик.apple.com . Проверено 15 марта 2021 г.
  22. ^ Юникод (Windows) . Проверено 8 марта 2011 г. «Эти функции используют кодировку UTF-16 (широкие символы) (…), используемую для встроенной кодировки Unicode в операционных системах Windows».
  23. ^ «Юникод» . microsoft.com . Проверено 20 июля 2009 г.
  24. ^ «Суррогаты и дополнительные персонажи» . microsoft.com . Проверено 20 июля 2009 г.
  25. ^ «Описание хранения данных UTF-8 в SQL Server» . microsoft.com. 7 декабря 2005 г. Проверено 1 февраля 2008 г.
  26. ^ «[Обновлено] Патч для cmd.exe для Windows XP для cp 65001 — Страница 2 — DosTips.com» . www.dostips.com . Проверено 17 июня 2021 г.
  27. ^ «Используйте кодовые страницы UTF-8 в приложениях Windows» . Learn.microsoft.com . Проверено 6 июня 2020 г. Начиная с версии Windows 1903 (обновление от мая 2019 г.), вы можете использовать свойство ActiveCodePage в appxmanifest для упакованных приложений или манифест Fusion для неупакованных приложений, чтобы заставить процесс использовать UTF-8 в качестве кодовой страницы процесса. [...] CP_ACP приравнивается к CP_UTF8 только при работе в Windows версии 1903 (обновление от мая 2019 г.) или более поздней версии, а описанному выше свойству ActiveCodePage присвоено значение UTF-8. В противном случае он учитывает кодовую страницу устаревшей системы. Мы рекомендуем использовать CP_UTF8 явно.
  28. ^ «Поддержка UTF-8 в Microsoft Game Development Kit (GDK) — Microsoft Game Development Kit» . Learn.microsoft.com . Проверено 05 марта 2023 г. Работая в UTF-8, вы можете обеспечить максимальную совместимость [..] Windows изначально работает в UTF-16 (или WCHAR), что требует преобразования кодовых страниц с помощью MultiByteToWideChar и WideCharToMultiByte. Это уникальное бремя, которое Windows возлагает на код, предназначенный для нескольких платформ. [..] Microsoft Game Development Kit (GDK) и Windows в целом продвигаются вперед к поддержке UTF-8, чтобы устранить это уникальное бремя Windows по нацеливанию кода или взаимообмену с несколькими платформами и Интернетом. Кроме того, это приводит к меньшему количеству проблем с интернационализацией в приложениях и играх и уменьшает матрицу тестов, необходимую для правильной работы.
  29. ^ «UCS-2 и его связь с Unicode (UTF-16)» . ИБМ . Проверено 26 апреля 2019 г.
  30. ^ Селф, Чад (8 ноября 2012 г.). «Приключения в Юникоде СМС» . Твилио. Архивировано из оригинала 09.11.2012 . Проверено 28 августа 2015 г.
  31. ^ «PEP 0393 — Гибкое строковое представление» . Python.org . Проверено 29 мая 2015 г.
  32. ^ «PEP 623 — удалить wstr из Unicode | peps.python.org» . peps.python.org . Проверено 24 февраля 2023 г.
  33. ^ «JEP 400: UTF-8 по умолчанию» . openjdk.org . Проверено 12 марта 2023 г.
  34. ^ «Внутренняя кодировка символов JavaScript: UCS-2 или UTF-16? · Матиас Байненс» .
  35. ^ «Строка UTF-8» . Свифт.орг . 20 марта 2019 г. Проверено 20 августа 2020 г.
  36. ^ «PHP: Поддерживаемые кодировки символов — Руководство» . php.net .
  37. ^ «MySQL :: Справочное руководство MySQL 8.0 :: 10.9.2 Набор символов utf8mb3 (3-байтовая кодировка Unicode UTF-8)» . dev.mysql.com . Проверено 24 февраля 2023 г.
  38. ^ «ECMA-334: 9.4.1 escape-последовательности Юникода» . ru.csharp-online.net . Архивировано из оригинала 15 февраля 2013 г.
  39. ^ Лексическая структура: экранирование Unicode в «Спецификация языка Java, третье издание» . Сан Микросистемс, Инк . 2005 . Проверено 11 октября 2019 г.
[ редактировать ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=UTF-16&oldid=1236977366"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 252874d2256a888bcc78d71c3ebbf065__1722077880
URL1:https://arc.ask3.ru/arc/aa/25/65/252874d2256a888bcc78d71c3ebbf065.html
Заголовок, (Title) документа по адресу, URL1:
UTF-16 - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)