UTF-16 ( 16-битный формат преобразования Unicode ) — это кодировка символов , способная кодировать все 1 112 064 допустимых кодовых точки Unicode (фактически это количество кодовых точек продиктовано конструкцией UTF-16). Кодирование имеет переменную длину , поскольку кодовые точки кодируются одной или двумя 16-битными кодовыми единицами . UTF-16 возник из более ранней устаревшей 16-битной кодировки фиксированной ширины, теперь известной как UCS-2 (для 2-байтового универсального набора символов), когда стало ясно, что требуется более 216 ( 65 536) кодовых точек, [1 ] включая большинство смайликов и важные символы CJK , например, для личных названий и географических названий. [2]
UTF-16 используется такими системами, как Microsoft Windows API , язык программирования Java и JavaScript /ECMAScript. Он также иногда используется для файлов данных обычного текста и текстовой обработки в Microsoft Windows. Он используется SMS (стандарт SMS определяет UCS-2, но на самом деле почти все пользователи реализуют UTF-16, чтобы смайлы работали). [ нужна цитата ]
UTF-16 — единственная кодировка, разрешенная (до сих пор) в сети, которая несовместима с ASCII [3] [nb 1] и никогда не пользовалась популярностью в сети, где ее декларируют менее 0,004% веб-страниц [5] (и многие из них на самом деле имеют формат UTF-8, но помечены неправильно [6] ). Для сравнения, на UTF-8 приходится более 98% всех веб-страниц. [7] Рабочая группа по технологиям веб-гипертекстовых приложений (WHATWG) считает UTF-8 «обязательной кодировкой для всего [текста]» и что по соображениям безопасности браузерные приложения не должны использовать UTF-16. [8]
В конце 1980-х годов началась работа над разработкой единой кодировки для «Универсального набора символов» ( UCS ), которая заменила бы более ранние кодировки, специфичные для конкретного языка, одной координированной системой. Целью было включить все необходимые символы из большинства языков мира, а также символы из технических областей, таких как наука, математика и музыка. Первоначальная идея заключалась в замене типичных 256-символьных кодировок, для которых требовался 1 байт на символ, кодировкой, использующей 65 536 (2 16 ) значений, для которой требовалось 2 байта (16 бит) на символ.
Над этим параллельно работали две группы: ISO/IEC JTC 1/SC 2 и Консорциум Unicode , причем последний представлял в основном производителей компьютерного оборудования. Обе группы попытались синхронизировать назначение символов, чтобы разрабатываемые кодировки были взаимно совместимыми. Ранняя 2-байтовая кодировка первоначально называлась «Юникод», но теперь называется «UCS-2». [9]
Когда становилось все более очевидным, что 216 символов недостаточно, [10] IEEE представил большее 31-битное пространство и кодировку ( UCS-4 ), которая требовала бы 4 байта на символ. Консорциум Unicode сопротивлялся этому как потому, что 4 байта на символ тратили много памяти и дискового пространства, так и потому, что некоторые производители уже вложили значительные средства в технологию 2 байта на символ. Схема кодирования UTF-16 была разработана как компромисс и представлена в версии 2.0 стандарта Unicode в июле 1996 года. [11] Она полностью определена в RFC 2781, опубликованном в 2000 году IETF . [12] [13]
UTF-16 указан в последних версиях международного стандарта ISO/IEC 10646 и стандарта Unicode. «UCS-2 теперь следует считать устаревшим. Он больше не относится к форме кодировки ни в 10646, ни в стандарте Unicode». [14] UTF-16 никогда не будет расширяться для поддержки большего количества кодовых точек или для поддержки кодовых точек, которые были заменены суррогатными кодами, поскольку это нарушит политику стабильности Unicode в отношении общей категории или суррогатных кодовых точек. [15] (Любая схема, которая остается самосинхронизирующимся кодом , потребует выделения хотя бы одной кодовой точки базовой многоязычной плоскости (BMP) для запуска последовательности. Изменение назначения кодовой точки запрещено.)
Каждая кодовая точка Юникода кодируется одной или двумя 16-битными кодовыми единицами . Кодовые точки меньше 2 16 («в BMP») кодируются одной 16-битной кодовой единицей, равной числовому значению кодовой точки, как в более старой версии UCS-2. Кодовые точки, большие или равные 2 16 («выше BMP»), кодируются с использованием двух 16-битных кодовых единиц. Эти две 16-битные кодовые единицы выбираются из суррогатного диапазона UTF-16 0xD800–0xDFFF , который ранее не назначался символам. Значения в этом диапазоне не используются как символы, и UTF-16 не предоставляет законного способа кодировать их как отдельные кодовые точки. Таким образом, поток UTF-16 состоит из одиночных 16-битных кодов вне суррогатного диапазона и пар 16-битных значений, находящихся в пределах суррогатного диапазона.
И UTF-16, и UCS-2 кодируют кодовые точки в этом диапазоне как отдельные 16-битные кодовые единицы, численно равные соответствующим кодовым точкам. Эти кодовые точки в базовой многоязычной плоскости (BMP) являются единственными кодовыми точками, которые могут быть представлены в UCS-2. [ нужна цитация ] Начиная с версии Unicode 9.0, некоторые современные нелатинские азиатские, ближневосточные и африканские сценарии выходят за пределы этого диапазона, как и большинство символов эмодзи .
Кодовые точки из других плоскостей кодируются как две 16-битные кодовые единицы , называемые суррогатной парой . Первая единица кода — это старший суррогат , а вторая — младший суррогат (они также известны как «ведущие» и «конечные» суррогаты соответственно, аналогично начальному и конечному байтам UTF-8. [16] ):
Визуально иллюстрируемое распределение U' между W1 и W2 выглядит так: [17]
U' = yyyyyyyyyyxxxxxxxxxxxx // 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).
Официальный стандарт Unicode гласит, что никакие формы UTF, включая UTF-16, не могут кодировать суррогатные кодовые точки. Поскольку им никогда не будет присвоен символ, не должно быть причин их кодировать. Однако Windows допускает непарные суррогаты в именах файлов [18] и других местах, что обычно означает, что они должны поддерживаться программным обеспечением, несмотря на их исключение из стандарта Unicode.
UCS-2, UTF-8 и UTF-32 могут кодировать эти кодовые точки тривиальными и очевидными способами, и большое количество программного обеспечения делает это, даже несмотря на то, что стандарт утверждает, что такие меры следует рассматривать как ошибки кодирования.
Можно однозначно закодировать непарный суррогат (старшая суррогатная кодовая точка, за которой не следует младшая, или младшая, которой не предшествует старшая) в формате UTF-16, используя кодовую единицу, равную кодовой точке. . Результат не является допустимым UTF-16, но большинство реализаций кодировщика и декодера UTF-16 делают это при переводе между кодировками. [ нужна цитата ]
Чтобы закодировать U+10437 (𐐷) в UTF-16:
Чтобы декодировать U+10437 (𐐷) из UTF-16:
В следующей таблице суммированы это преобразование, а также другие. Цвета показывают, как биты кодовой точки распределяются между байтами UTF-16. Дополнительные биты, добавленные в процессе кодирования UTF-16, показаны черным цветом.
UTF-16 и UCS-2 создают последовательность 16-битных кодовых единиц. Поскольку большинство протоколов связи и хранения определены для байтов, и каждое устройство, таким образом, занимает два 8-битных байта, порядок байтов может зависеть от порядка байтов (порядка байтов) компьютерной архитектуры.
Чтобы помочь распознать порядок байтов кодовых единиц, UTF-16 позволяет метке порядка байтов (BOM), кодовой точке со значением U+FEFF, предшествовать первому фактическому кодированному значению. [nb 2] (U+FEFF — это невидимый неразрывный пробел нулевой ширины / символ ZWNBSP.) [nb 3] Если порядковый номер архитектуры декодера совпадает с архитектурой кодера, декодер обнаруживает значение 0xFEFF, но противоположное Декодер -endian интерпретирует спецификацию как несимвольное значение U+FFFE, зарезервированное для этой цели. Этот неверный результат подсказывает, что нужно выполнить замену байтов для оставшихся значений.
Если спецификация отсутствует, RFC 2781 рекомендует [nb 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 .
«Символ» может использовать любое количество кодовых точек Юникода. [19] Например, символ флага эмодзи занимает 8 байт, поскольку он «составлен из пары скалярных значений Юникода» [20] (и эти значения находятся за пределами 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 [21] ), включая Windows 10 . В Windows XP код выше U+FFFF не включен ни в один шрифт, поставляемый с Windows для европейских языков. [22] [23] Старые системы Windows NT (до Windows 2000) поддерживают только UCS-2 . [24] Файлы и сетевые данные, как правило, представляют собой смесь кодировок UTF-16, UTF-8 и устаревших байтовых кодировок.
Хотя некоторая поддержка UTF-8 существовала даже в Windows XP, [25] она была улучшена (в частности, возможность называть файл с использованием UTF-8) в инсайдерской сборке Windows 10 17035 и обновлении от мая 2019 года. По состоянию на май 2019 года Microsoft рекомендует использовать в программном обеспечении UTF-8 в Windows и Xbox вместо других 8-битных кодировок. [26] Неясно, рекомендуют ли они использовать UTF-8 вместо UTF-16, хотя они заявляют, что «UTF-16 [..] — это уникальное бремя, которое Windows накладывает на код, предназначенный для нескольких платформ». [27]
Операционная система IBM i обозначает CCSID ( кодовую страницу ) 13488 для кодировки UCS-2 и CCSID 1200 для кодировки UTF-16, хотя система обрабатывает их оба как UTF-16. [28]
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 ). [29]
Файловая система 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 в зависимости от наибольшей кодовой точки в строке. [30] В Python 3.12 исключены некоторые функции (для расширений CPython), чтобы упростить переход на UTF-8 для всех строк. [31]
Первоначально Java использовала UCS-2 и добавила поддержку дополнительных символов UTF-16 в J2SE 5.0 . Недавно они рекомендовали поддержку дампа для любой 8-битной кодировки, кроме UTF-8 [32] , но внутри UTF-16 все еще используется.
JavaScript может использовать UCS-2 или UTF-16. [33] Начиная с ES2015, в язык были добавлены строковые методы и флаги регулярных выражений, которые позволяют обрабатывать строки с точки зрения независимости от кодировки.
Swift , предпочтительный язык приложений Apple, использовал UTF-16 для хранения строк до версии 5, которая переключилась на UTF-8. [34]
Многие языки делают кодировку частью строкового объекта и, таким образом, хранят и поддерживают большой набор кодировок, включая UTF-16. Большинство считают UTF-16 и UCS-2 разными кодировками. Примерами являются язык PHP [35] и MySQL . [36]
Чтобы определить, какую кодировку использует система внутри, нужно запросить «длину» строки, содержащей один символ, отличный от BMP. Если длина равна 2, то используется UTF-16. 4 указывает UTF-8. 3 или 6 могут обозначать CESU-8 . 1 может указывать на UTF-32, но, скорее всего, указывает на то, что язык декодирует строку до кодовых точек перед измерением «длины».
Во многих языках строки в кавычках требуют нового синтаксиса для цитирования символов, отличных от BMP, поскольку "\uXXXX"синтаксис стиля C явно ограничивается четырьмя шестнадцатеричными цифрами. Следующие примеры иллюстрируют синтаксис символа, отличного от BMP, U+1D11E 𝄞 МУЗЫКАЛЬНЫЙ СИМВОЛ G CLEF :
"\U0001D11E". [37]"\x{1D11E}"."\u{1D11E}"."\uD834\uDD1E".UTF-16 использует одну 16-битную кодовую единицу для кодирования более 60 000 наиболее распространенных символов Юникода.
Впервые идея создания этого списка первой десятки пришла мне в голову более 10 лет назад, и это было вызвано некоторыми средами, которые до сих пор поддерживали только кодовые точки BMP.
Идея, конечно же, заключалась в том, чтобы мотивировать разработчиков таких сред поддерживать элементы кода, выходящие за рамки BMP, путем предоставления перечисленного списка причин для этого.
И да, до сих пор существуют среды, поддерживающие только коды BMP, например приложение VivaDesigner.
Кодировки UTF-16 — единственные кодировки, которые в данной спецификации должны рассматриваться как несовместимые с ASCII.
Кодировка UTF-8 является наиболее подходящей кодировкой для обмена Unicode, универсальным набором кодированных символов.
Поэтому для новых протоколов и форматов, а также существующих форматов, развернутых в новых контекстах, данная спецификация требует (и определяет) кодировку UTF-8.
[..] Проблемы, описанные здесь, исчезают при использовании исключительно UTF-8, что является одной из многих причин, по которым UTF-8 теперь является обязательной кодировкой для всех текстовых объектов в Интернете.
[…] файловая система рассматривает пути и имена файлов как непрозрачную последовательность символов WCHAR.
Начиная с версии Windows 1903 (обновление от мая 2019 г.), вы можете использовать свойство ActiveCodePage в appxmanifest для упакованных приложений или манифест Fusion для неупакованных приложений, чтобы заставить процесс использовать UTF-8 в качестве кодовой страницы процесса.
[...]
соответствует
только при работе в Windows версии 1903 (обновление от мая 2019 г.) или более поздней версии, а описанному выше свойству ActiveCodePage присвоено значение UTF-8.
В противном случае он учитывает кодовую страницу устаревшей системы.
Мы рекомендуем использовать
явно.
CP_ACPCP_UTF8CP_UTF8
Работая в UTF-8, вы можете обеспечить максимальную совместимость [..] Windows изначально работает в UTF-16 (или WCHAR), что требует преобразования кодовых страниц с помощью MultiByteToWideChar и WideCharToMultiByte.
Это уникальное бремя, которое Windows возлагает на код, предназначенный для нескольких платформ.
[..] Microsoft Game Development Kit (GDK) и Windows в целом продвигаются вперед к поддержке UTF-8, чтобы устранить это уникальное бремя Windows по нацеливанию кода или взаимообмену с несколькими платформами и Интернетом.
Кроме того, это приводит к меньшему количеству проблем с интернационализацией в приложениях и играх и уменьшает матрицу тестов, необходимую для правильной работы.