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,003% веб-страниц. [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 Consortium , последний представлял в основном производителей вычислительного оборудования. Две группы пытались синхронизировать свои назначения символов, чтобы разрабатываемые кодировки были взаимно совместимы. Ранняя 2-байтовая кодировка изначально называлась «Unicode», но теперь называется «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, опубликованном в 2000 году IETF . [ 14] [15]
UTF-16 указан в последних версиях международного стандарта ISO/IEC 10646 и стандарта Unicode. «UCS-2 теперь следует считать устаревшим. Он больше не относится к форме кодирования ни в 10646, ни в стандарте Unicode». [1] [2] UTF-16 никогда не будет расширен для поддержки большего количества кодовых точек или для поддержки кодовых точек, которые были заменены суррогатами, поскольку это нарушит политику стабильности Unicode в отношении общей категории или суррогатных кодовых точек. [16] (Любая схема, которая остается самосинхронизирующимся кодом, потребует выделения по крайней мере одной кодовой точки Basic Multilingual Plane (BMP) для начала последовательности. Изменение назначения кодовой точки запрещено.)
Каждая кодовая точка Unicode кодируется как одна или две 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. [17] ):
Визуально распределение U' между W1 и W2 выглядит следующим образом: [18]
U' = yyyyyyyyyxxxxxxxxxxxx // 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 допускает непарные суррогаты в именах файлов [19] и других местах, что обычно означает, что они должны поддерживаться программным обеспечением, несмотря на их исключение из стандарта 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-битных байта, порядок байтов может зависеть от порядка байтов ( endianness ) компьютерной архитектуры.
Чтобы помочь в распознавании порядка байтов кодовых единиц, UTF-16 позволяет метке порядка байтов (BOM), кодовой точке со значением U+FEFF, предшествовать первому фактическому кодированному значению. [nb 2] (U+FEFF — это невидимый символ неразрывного пробела нулевой ширины /ZWNBSP.) [nb 3] Если архитектура порядка байтов декодера совпадает с архитектурой кодера, декодер обнаруживает значение 0xFEFF, но декодер с противоположным порядком байтов интерпретирует BOM как несимвольное значение U+FFFE, зарезервированное для этой цели. Этот неверный результат дает подсказку для выполнения замены байтов для оставшихся значений.
Если BOM отсутствует, RFC 2781 рекомендует [nb 4] предполагать кодировку big-endian (BE). На практике, поскольку Windows использует порядок little-endian (LE) по умолчанию, многие приложения предполагают кодировку little-endian. Также надежно определить порядок байтов, ища нулевые байты, исходя из предположения, что символы меньше U+0100 встречаются очень часто. Если больше четных байтов (начиная с 0) являются нулевыми, то это big-endian.
Стандарт также позволяет явно указывать порядок байтов, указав UTF-16BE или UTF-16LE в качестве типа кодировки. Когда порядок байтов указан явно таким образом, BOM специально не предполагается добавлять к тексту, а U+FEFF в начале должен обрабатываться как символ ZWNBSP. Большинство приложений игнорируют BOM во всех случаях, несмотря на это правило.
Для интернет - протоколов IANA одобрила "UTF-16", "UTF-16BE" и "UTF-16LE" в качестве названий для этих кодировок (имена нечувствительны к регистру). Псевдонимы UTF_16 или UTF16 могут иметь смысл в некоторых языках программирования или программных приложениях, но они не являются стандартными названиями в интернет-протоколах.
Аналогичные обозначения, UCS-2BE и UCS-2LE , используются для обозначения версий UCS-2 .
«Символ» может использовать любое количество кодовых точек Unicode. [20] Например, символ флага эмодзи занимает 8 байт, поскольку он «создается из пары скалярных значений Unicode» [21] (и эти значения находятся за пределами BMP и требуют 4 байта каждое). UTF-16 никоим образом не помогает в «подсчете символов» или в «измерении ширины строки».
UTF-16 часто называют более компактным, чем UTF-8, для восточноазиатских языков, поскольку он использует два байта для символов, которые занимают 3 байта в UTF-8. Поскольку реальный текст содержит много пробелов, цифр, знаков препинания, разметки (например, веб-страниц) и управляющих символов, которые занимают только один байт в 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 Insider 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 , используемая в носителях CD-ROM , кодирует имена файлов с помощью UCS-2BE (до шестидесяти четырех символов Unicode на имя файла).
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"явно ограничивает себя 4 шестнадцатеричными цифрами. Следующие примеры иллюстрируют синтаксис для не-BMP символа U+1D11E 𝄞 МУЗЫКАЛЬНЫЙ СИМВОЛ G CLEF :
"\U0001D11E". [38]"\x{1D11E}"."\u{1D11E}"."\uD834\uDD1E".[...] термин UCS-2 теперь следует считать устаревшим. Он больше не относится к форме кодирования ни в 10646, ни в стандарте Unicode.
UCS-2 — устаревший термин, который относится к реализации Unicode до Unicode 1.1 [...]
-16 использует одну 16-битную кодовую единицу для кодирования более 60 000 наиболее распространенных символов в Unicode.
Впервые идея этого списка десяти лучших возникла у меня более 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 на целевое использование кода или его обмен с несколькими платформами и Интернетом. Кроме того, это приводит к меньшему количеству проблем с интернационализацией в приложениях и играх и сокращает тестовую матрицу, необходимую для правильной работы.