stringtranslate.com

UTF-8

UTF-8 — это стандарт кодировки символов переменной длины , используемый для электронной связи. Определенное стандартом Unicode , название происходит от формата преобразования Unicode — 8-битного . [1]

UTF-8 способен кодировать все 1 112 064 [a] допустимых кодовых точек Unicode , используя от одной до четырех однобайтовых ( 8-битных) кодовых единиц. Кодовые точки с меньшими числовыми значениями, которые обычно встречаются чаще, кодируются с использованием меньшего количества байтов. Он был разработан для обратной совместимости с ASCII : первые 128 символов Unicode, которые однозначно соответствуют ASCII, кодируются с использованием одного байта с тем же двоичным значением, что и ASCII, так что действительный текст ASCII является допустимым UTF-8. -закодированный также в Юникоде.

UTF-8 был разработан как превосходная альтернатива UTF-1 , предложенной кодировке переменной длины с частичной совместимостью с ASCII, в которой отсутствовали некоторые функции, включая самосинхронизацию и полностью совместимую с ASCII обработку символов, таких как косая черта. Кен Томпсон и Роб Пайк создали первую реализацию операционной системы Plan 9 в сентябре 1992 года. [2] [3] Это привело к ее принятию X/Open в качестве спецификации для FSS-UTF , [4] которая сначала была официально принята. представлен на USENIX в январе 1993 года [5] и впоследствии принят Инженерной группой Интернета (IETF) в RFC 2277 ( BCP 18 ) [6] для будущей работы над интернет-стандартами, заменяя однобайтовые наборы символов, такие как Latin-1, в старых RFC. .

UTF-8 приводит к меньшему количеству проблем с интернационализацией [7] [8] , чем любая альтернативная кодировка текста, и он реализован во всех современных операционных системах , включая Microsoft Windows , и таких стандартах, как JSON , где, как это происходит все чаще, он — единственная разрешенная форма Unicode .

UTF-8 является доминирующей кодировкой во Всемирной паутине (и интернет-технологиях), на которую по состоянию на 2024 год будет приходиться 98,1% всех веб-страниц, 99,1% из 10 000 лучших страниц и до 100% для многих языков . [9] Практически во всех странах и языках 95% и более кодировок UTF-8 в Интернете используются.

Именование

Официальное название кодировки — UTF-8 , это написание используется во всех документах Консорциума Unicode. В большинстве стандартов его также официально указывают в верхнем регистре, но все это также не учитывает регистр и utf-8часто используется в коде. [ нужна цитата ]

Некоторые другие варианты написания также могут быть приняты стандартами, например веб-стандарты (которые включают заголовки CSS , HTML , XML и HTTP ) явно разрешают utf8 (и запрещают «unicode») и многие псевдонимы для кодировок. [10] Не следует использовать варианты написания с пробелами, например «UTF 8». Официальный орган по присвоению номеров в Интернете также указывает csUTF8 как единственный псевдоним [11] , который используется редко.

В Windows UTF-8 — это кодовая страница 65001 [12] (т.е. CP_UTF8в исходном коде).

В MySQL UTF-8 называется utf8mb4[13] (где utf8mb3и его псевдоним utf8является подмножеством кодировки символов в базовой многоязычной плоскости [14] ). В HP PCL идентификатор символа для UTF-8 — 18N. [15]

В базе данных Oracle (начиная с версии 9.0) AL32UTF8[16] означает UTF-8. См. также CESU-8 , почти синоним UTF-8, который следует использовать редко.

UTF-8-BOM и UTF-8-NOBOM иногда используются для текстовых файлов, которые содержат или не содержат метку порядка байтов (BOM) соответственно. [ нужна цитация ] Особенно в Японии кодировку UTF-8 без спецификации иногда называют UTF-8N . [17] [18]

Кодирование

UTF-8 кодирует кодовые точки от одного до четырех байтов, в зависимости от значения кодовой точки. В следующей таблице символы x заменяются битами кодовой точки:

Первые 128 кодовых точек (ASCII) требуют одного байта. Для кодирования следующих 1920 кодовых точек требуется два байта, что охватывает остальную часть почти всех алфавитов латинского алфавита , а также расширений IPA , греческого , кириллического , коптского , армянского , иврита , арабского , сирийского алфавитов , алфавитов таана и нко , как а также Объединение диакритических знаков . Три байта необходимы для оставшихся 61 440 кодовых точек базовой многоязычной плоскости (BMP), включая большинство китайских, японских и корейских символов . Четыре байта необходимы для 1 048 576 кодовых точек в других плоскостях Unicode , которые включают в себя эмодзи (пиктографические символы), менее распространенные символы CJK , различные исторические сценарии и математические символы .

«Символ» может занимать более 4 байтов, поскольку он состоит из более чем одной кодовой точки. Например, символ национального флага занимает 8 байтов, поскольку он «составлен из пары скалярных значений Юникода» как за пределами BMP. [19] [с]

Процесс кодирования

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

  1. Кодовая точка Unicode для знака евро € — U+20AC.
  2. Поскольку эта кодовая точка находится между U+0800 и U+FFFF, для кодирования потребуется три байта.
  3. Шестнадцатеричное число 20AC — двоичное 0010 0000 10 10 1100 . Два ведущих нуля добавляются, поскольку для трехбайтового кодирования требуется ровно шестнадцать бит от кодовой точки.
  4. Поскольку длина кодировки будет три байта, ее ведущий байт начинается с трех единиц, затем 0 ( 1110... ).
  5. Четыре старших бита кодовой точки сохраняются в оставшихся четырех младших битах этого байта ( 1110 0010 ), оставляя 12 бит кодовой точки еще не закодированными ( ... 0000 10 10 1100 ).
  6. Все байты продолжения содержат ровно шесть битов, начиная с кодовой точки. Таким образом, следующие шесть бит кодовой точки сохраняются в младших шести битах следующего байта, а 10 сохраняется в двух старших битах, чтобы пометить его как байт продолжения (то есть 10 000010 ).
  7. Наконец, последние шесть бит кодовой точки сохраняются в шести младших битах последнего байта, и снова 10 сохраняется в двух старших битах ( 10 101100 ).

Три байта 1110 0010 10 000010 10 101100 можно более кратко записать в шестнадцатеричном виде , как E2 82 AC .

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

Пример

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

Например, вьетнамская фраза Mình noi tiếng Việt ( 𨉟呐㗂越, «Я говорю по-вьетнамски») кодируется следующим образом:

Макет кодовой страницы

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

  7-битные (однобайтовые) кодовые точки. За ними не должен следовать байт продолжения. [20]
  Байты продолжения. [21] В ячейке показано шестнадцатеричное значение шести добавляемых битов. [д]
  За ведущими байтами последовательности из нескольких байтов должно следовать ровно N -1 байтов продолжения. [22] В подсказке показан диапазон кодовых точек и блоки Юникода, закодированные последовательностями, начинающимися с этого байта.
  Ведущие байты, в которых не все расположения байтов продолжения действительны. E0 и F0 могут начать слишком длинное кодирование. F4 может начинать кодовые точки больше U+10FFFF. ED может начинать кодовые точки в диапазоне U+D800–U+DFFF, которые являются недопустимыми суррогатными половинками UTF-16 . [23]
  Не используйте действительную последовательность UTF-8. C0 и C1 можно было использовать только для «слишком длинного» кодирования 1-байтового символа. [24] От F5 до FD — это ведущие байты 4-байтовых или более длинных последовательностей, которые могут кодировать только кодовые точки, превышающие U+10FFFF. [23] FE и FF никогда не придавали никакого значения. [25]

Слишком длинные кодировки

В принципе, можно было бы увеличить количество байтов в кодировке, дополнив кодовую точку ведущими нулями. Чтобы закодировать знак евро из приведенного выше примера в четыре байта вместо трех, его можно дополнить ведущими нулями, пока его длина не станет 21 бит - 000 000010 000010 101100 , и закодировать как 11110 000 10 000010 10 000010 10 101100 (или F0 82 82 AC в шестнадцатеричном формате). Это называется слишком длинным кодированием .

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

Неверные последовательности и обработка ошибок

Не все последовательности байтов действительны в формате UTF-8. Декодер UTF-8 должен быть подготовлен для:

Многие из первых декодеров UTF-8 декодировали их, игнорируя неверные биты и принимая слишком длинные результаты. Тщательно созданный недопустимый UTF-8 может заставить их либо пропускать, либо создавать символы ASCII, такие как NUL, косая черта или кавычки. Неверный UTF-8 использовался для обхода проверок безопасности в таких известных продуктах, как веб-сервер Microsoft IIS [26] и контейнер сервлетов Apache Tomcat. [27] RFC 3629 гласит: «Реализации алгоритма декодирования ДОЛЖНЫ защищать от декодирования недопустимых последовательностей». [23] Стандарт Unicode требует, чтобы декодеры «...рассматривали любую неправильно сформированную последовательность кодовых единиц как состояние ошибки. Это гарантирует, что она не будет ни интерпретировать, ни выдавать неправильно сформированную последовательность кодовых единиц».

Начиная с RFC 3629 (ноябрь 2003 г.), старшие и младшие суррогатные половины, используемые UTF-16 (от U+D800 до U+DFFF), а также кодовые точки, не кодируемые UTF-16 (те, что после U+10FFFF), не являются допустимыми значениями Unicode. и их кодировка UTF-8 должна рассматриваться как недопустимая последовательность байтов. Отсутствие декодирования непарных суррогатных половин делает невозможным сохранение недопустимого UTF-16 (например, имен файлов Windows или UTF-16, разделенного между суррогатными элементами) как UTF-8, [28] , хотя это возможно с WTF-8.

Некоторые реализации декодеров выдают исключения при ошибках. [29] Недостаток этого метода заключается в том, что он может превратить ошибки, которые в противном случае были бы безобидными (например, ошибка «нет такого файла»), в отказ в обслуживании . Например, ранние версии Python 3.0 завершали работу немедленно, если переменные командной строки или среды содержали недопустимый код UTF-8. [30]

Начиная с Unicode 6 [31] (октябрь 2010 г.), стандарт ( глава 3 ) рекомендует «лучшую практику», при которой ошибка либо имеет длину в один байт, либо заканчивается до первого запрещенного байта. В этих декодерах E1,A0,C0 — это две ошибки (2 байта в первой). Это означает, что длина ошибки не превышает трех байтов и никогда не содержит начала допустимого символа, и существует 21 952 различных возможных ошибки. [32] Стандарт также рекомендует заменять каждую ошибку символом замены «�» (U+FFFD).

Эти рекомендации не часто выполняются. Обычно каждый байт считается ошибкой, и в этом случае E1,A0,C0 — это три ошибки (каждая длиной 1 байт). Это означает, что существует всего 128 различных ошибок, и их также часто заменяют 128 разными символами, чтобы сделать декодирование «без потерь». [33]

Знак порядка байтов

Если знак порядка байтов Unicode (BOM, U+FEFF, технически символ U+FEFF ZERO WIDTH NO-BREAK SPACE ) находится в начале файла UTF-8, первые три байта будут 0xEF , 0xBB , 0xBF .

Стандарт Unicode не требует и не рекомендует использовать спецификацию для UTF-8, но предупреждает, что она может встретиться в начале файла, перекодированного из другой кодировки. [34] Хотя текст ASCII, закодированный с использованием UTF-8, обратно совместим с ASCII, это неверно, если игнорируются рекомендации стандарта Unicode и добавляется спецификация. Спецификация может сбить с толку программное обеспечение, которое не подготовлено к этому, но в противном случае может принять UTF-8, например, языки программирования, которые допускают байты, отличные от ASCII, в строковых литералах , но не в начале файла. Тем не менее, существовало и до сих пор существует программное обеспечение, которое всегда вставляет спецификацию при написании UTF-8 и отказывается правильно интерпретировать UTF-8, если только первый символ не является спецификацией (или файл содержит только ASCII). [35]

Принятие

Заявлен набор символов для 10 миллионов самых популярных веб-сайтов с 2010 года.
Использование основных кодировок в сети в 2001–2012 годах, как зафиксировано Google, [36] при этом UTF-8 обогнал все остальные в 2008 году и более 60% сети в 2012 году (с тех пор приближается к 100%). UTF-8 — единственная кодировка Unicode, указанная там (явно), а остальные предоставляют только подмножества Unicode. Фигура, состоящая только из ASCII, включает все веб-страницы, содержащие только символы ASCII, независимо от объявленного заголовка.

UTF-8 является наиболее распространенной кодировкой во Всемирной паутине с 2008 года. [37] По состоянию на февраль 2024 года UTF-8 используется 98,1% опрошенных веб-сайтов. [9] [e] Хотя на многих страницах для отображения контента используются только символы ASCII, очень немногие веб-сайты теперь заявляют, что их кодировка - только ASCII, а не UTF-8. [38] Более 50% отслеживаемых языков на 100% используют UTF-8.

Многие стандарты поддерживают только UTF-8, например, это требуется для обмена JSON (без метки порядка байтов (BOM)). [39] UTF-8 также является рекомендацией WHATWG для спецификаций HTML и DOM , в которой говорится, что «кодировка UTF-8 является наиболее подходящей кодировкой для обмена Unicode » [8], а Консорциум электронной почты рекомендует, чтобы все сообщения электронной почты программы смогут отображать и создавать почту с использованием UTF-8. [40] [41] Консорциум Всемирной паутины рекомендует UTF-8 в качестве кодировки по умолчанию в XML и HTML (а не только использование UTF-8, а также объявление его в метаданных), «даже если все символы находятся в диапазоне ASCII. .. Использование кодировок, отличных от UTF-8, может привести к неожиданным результатам». [42]

Многие программы имеют возможность чтения/записи UTF-8. Однако пользователю может потребоваться изменить параметры обычных настроек или может потребоваться спецификация (метка порядка байтов) в качестве первого символа для чтения файла. Примеры программного обеспечения, поддерживающего UTF-8, включают Microsoft Word , [43] [44] [45] Microsoft Excel (2016 и более поздние версии), [46] [47] Google Drive , LibreOffice и большинство баз данных.

Однако для локальных текстовых файлов использование UTF-8 менее распространено, поскольку продолжают использоваться устаревшие однобайтовые кодировки (и несколько многобайтовых CJK ). Основной причиной этого являются устаревшие текстовые редакторы, которые отказываются читать UTF-8, если первые байты файла не кодируют метку порядка байтов (BOM). [48]

Некоторые последние версии программного обеспечения могут только читать и записывать UTF-8 или, по крайней мере, не требуют спецификации. [49] Блокнот Windows во всех поддерживаемых в настоящее время версиях Windows по умолчанию использует кодировку UTF-8 без спецификации (отличие от устаревшего/неподдерживаемого Блокнота Windows 7 ), что приводит его в соответствие с большинством других текстовых редакторов. [50] Для некоторых системных файлов в Windows 11 требуется кодировка UTF-8 [51] без необходимости спецификации, а почти все файлы в macOS и Linux должны быть в формате UTF-8 без спецификации. [ нужна цитация ] Java 18 по умолчанию читает и записывает файлы в формате UTF-8, [52] , а в более старых версиях (например, версиях LTS )  для этого был изменен только NIO API. Многие другие языки программирования по умолчанию используют UTF-8 для ввода-вывода , включая Ruby  3.0 [53] [54] и R  4.2.2. [55] Все поддерживаемые в настоящее время версии Python поддерживают UTF-8 для ввода-вывода, даже в Windows (где она включена для функции open()[ 56] ), и существуют планы сделать UTF-8 вводом-выводом по умолчанию в Python 3.15 на всех платформах. [57] [58] C++23 использует UTF-8 как единственный переносимый формат файлов исходного кода (на удивление, раньше его не было). [59]

Использование UTF-8 в памяти намного ниже, чем в других областях, вместо него часто используется UTF-16 . Это происходит особенно в Windows, но также и в JavaScript , Python, [f] Qt и многих других кроссплатформенных программных библиотеках. Основной причиной этого является совместимость с Windows API ; изначально этот выбор был сделан из-за убеждения, что прямая индексация BMP улучшит скорость. Перевод из/на внешний текст в формате UTF-8 замедляет работу программного обеспечения и, что более важно, приводит к ошибкам, когда разные фрагменты кода не выполняют одинаковый перевод.

Обратная совместимость является серьезным препятствием для изменения кода на использование UTF-8 вместо 16-битной кодировки, но это происходит. Строковый примитив по умолчанию в Go , [61] Julia , Rust , Swift 5 , [62] и PyPy [63] во всех случаях использует внутренне UTF-8, тогда как Python, начиная с Python 3.3, в некоторых случаях внутренне использует UTF-8 ( для расширений Python C API); [60] [64] в будущей версии Python планируется хранить строки в формате UTF-8 по умолчанию; [65] [66] и современные версии Microsoft Visual Studio внутренне используют UTF-8. [67] В SQL Server 2019 от Microsoft добавлена ​​поддержка UTF-8, и ее использование приводит к увеличению скорости на 35% и «почти на 50% снижению требований к памяти». [68]

Все поддерживаемые в настоящее время версии Windows в той или иной степени поддерживают UTF-8 (включая Xbox ); [7] частичная поддержка существует, по крайней мере, с Windows XP . По состоянию на май 2019 года Microsoft изменила свою предыдущую позицию, рекомендуя только UTF-16; появилась возможность устанавливать UTF-8 в качестве «кодовой страницы» для Windows API; Microsoft рекомендует программистам использовать UTF-8, [69] и даже заявляет, что «UTF-16 [..] представляет собой уникальное бремя, которое Windows налагает на код, предназначенный для нескольких платформ». [7]

История

Международная организация по стандартизации (ISO) намеревалась составить универсальный многобайтовый набор символов в 1989 году. Проект стандарта ISO 10646 содержал необязательное приложение под названием UTF-1, которое обеспечивало кодирование потока байтов его 32-битных кодовых точек. . Эта кодировка была неудовлетворительной с точки зрения производительности, среди других проблем, и самая большая проблема, вероятно, заключалась в том, что в ней не было четкого разделения между ASCII и не-ASCII: новые инструменты UTF-1 были бы обратно совместимы с текстом в кодировке ASCII, но Текст в кодировке UTF-1 может сбить с толку существующий код, ожидающий ASCII (или расширенный ASCII ), поскольку он может содержать байты продолжения в диапазоне 0x21–0x7E, что означает что-то еще в ASCII, например, 0x2F для '/', разделителя каталогов путей Unix . , и этот пример отражается в названии и вводном тексте его замены. Приведенная ниже таблица составлена ​​на основе текстового описания в приложении.

В июле 1992 года комитет X/Open XoJIG искал лучшее кодирование. Дэйв Проссер из Unix System Laboratories представил предложение о более быстрой реализации и представил улучшение, заключающееся в том, что 7-битные символы ASCII будут представлять только самих себя; все многобайтовые последовательности будут включать только байты, в которых установлен старший бит. Название File System Safe UCS Transformation Format (FSS-UTF) и большая часть текста этого предложения были позже сохранены в окончательной спецификации. [70] [71] [72] [73]

ФСС-UTF

В августе 1992 года это предложение было распространено представителем IBM X/Open среди заинтересованных сторон. Модификация Кена Томпсона из группы операционной системы Plan 9 в Bell Labs сделала ее самосинхронизирующейся , позволяя читателю начать с любого места и сразу же обнаружить границы символов, ценой несколько меньшей эффективности по битам, чем в предыдущем предложении. Он также отказался от использования предвзятости и вместо этого добавил правило, согласно которому разрешено только самое короткое кодирование; дополнительная потеря компактности относительно незначительна, но читателям теперь приходится следить за недопустимыми кодировками, чтобы избежать проблем с надежностью и особенно безопасностью. Дизайн Томпсона был обрисован 2 сентября 1992 года на подставке для столовых приборов в закусочной в Нью-Джерси вместе с Робом Пайком . В последующие дни Пайк и Томпсон реализовали его и обновили Plan 9 , чтобы использовать его повсюду, а затем сообщили о своем успехе обратно в X/Open, которая приняла его в качестве спецификации FSS-UTF. [72]

UTF-8 был впервые официально представлен на конференции USENIX в Сан-Диего , с 25 по 29 января 1993 года. Рабочая группа по проектированию Интернета приняла UTF-8 в своей Политике в отношении наборов символов и языков в RFC 2277 ( BCP 18) для будущего Интернета. стандарты работают, заменяя однобайтовые наборы символов , такие как Latin-1, в старых RFC. [6]

В ноябре 2003 года RFC 3629 ограничил UTF-8,  чтобы он соответствовал ограничениям кодировки символов UTF-16 : явный запрет кодовых точек, соответствующих старшим и младшим суррогатным символам, удалил более 3% трехбайтовых последовательностей и положил конец при U+10FFFF удалено более 48% четырехбайтовых последовательностей и все пяти- и шестибайтовые последовательности.

Стандарты

В различных документах стандартов существует несколько текущих определений UTF-8:

Они заменяют определения, данные в следующих устаревших работах:

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

Сравнение с другими кодировками

Некоторые из важных особенностей этого кодирования заключаются в следующем:

Однобайтовый

Другие многобайтовые

UTF-16

Производные

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

ЦЭСУ-8

Технический отчет Unicode № 26 [79] присваивает имя CESU-8 нестандартному варианту UTF-8, в котором символы Unicode в дополнительных плоскостях кодируются с использованием шести байтов, а не четырех байтов, требуемых UTF-8. Кодировка CESU-8 обрабатывает каждую половину четырехбайтовой суррогатной пары UTF-16 как двухбайтовый символ UCS-2, давая два трехбайтовых символа UTF-8, которые вместе представляют исходный дополнительный символ. Символы Юникода в базовой многоязычной плоскости отображаются так, как обычно в UTF-8. Отчет был написан, чтобы признать и формализовать существование данных, закодированных как CESU-8, несмотря на то, что Консорциум Unicode не рекомендует их использование, и отмечает, что возможной преднамеренной причиной кодировки CESU-8 является сохранение двоичной сортировки UTF-16.

Кодировка CESU-8 может быть результатом преобразования данных UTF-16 с дополнительными символами в UTF-8 с использованием методов преобразования, которые предполагают данные UCS-2, то есть им не известны четырехбайтовые дополнительные символы UTF-16. В первую очередь это проблема операционных систем, которые широко используют UTF-16 внутри себя, таких как Microsoft Windows . [ нужна цитата ]

В базе данных Oracle в наборе символов UTF8используется кодировка CESU-8, и он устарел. В AL32UTF8наборе символов используется соответствующая стандартам кодировка UTF-8, поэтому он является предпочтительным. [80] [81]

CESU-8 запрещено использовать в документах HTML5 . [82] [83] [84]

MySQL utf8mb3

В MySQL набор utf8mb3символов определяется как данные в кодировке UTF-8 с максимум тремя байтами на символ, что означает, что поддерживаются только символы Unicode в базовой многоязычной плоскости (т. е. из UCS-2 ). Символы Юникода в дополнительных плоскостях явно не поддерживаются. utf8mb3устарел в пользу utf8mb4набора символов, в котором используется соответствующая стандартам кодировка UTF-8. utf8является псевдонимом для utf8mb3, но предполагается, что он станет псевдонимом utf8mb4в будущей версии MySQL. [14] Можно, хотя и не поддерживается, хранить данные в кодировке CESU-8 utf8mb3, обрабатывая данные UTF-16 с дополнительными символами, как если бы это был UCS-2.

Модифицированный UTF-8

Модифицированная UTF-8 (MUTF-8) возникла на языке программирования Java . В модифицированной UTF-8 нулевой символ (U+0000) использует двухбайтовую удлиненную кодировку 110 00000 10 000000 (шестнадцатеричный C0 80 ) вместо 00000000 (шестнадцатеричный 00 ). [85] Модифицированные строки UTF-8 никогда не содержат фактических нулевых байтов, но могут содержать все кодовые точки Unicode, включая U+0000, [86] что позволяет обрабатывать такие строки (с добавленным нулевым байтом) традиционными строковыми функциями с нулевым завершением. . Все известные реализации модифицированного UTF-8 также обрабатывают суррогатные пары, как в CESU-8 .

При обычном использовании язык поддерживает стандарт UTF-8 при чтении и записи строк через InputStreamReaderи OutputStreamWriter(если это набор символов платформы по умолчанию или запрошен программой). Однако он использует модифицированную UTF-8 для сериализации объектов [87] среди других приложений DataInputи DataOutputдля собственного интерфейса Java [ 88] и для встраивания константных строк в файлы классов . [89]

Формат dex, определенный Dalvik , также использует ту же модифицированную UTF-8 для представления строковых значений. [90] Tcl также использует ту же модифицированную UTF-8 [91], что и Java, для внутреннего представления данных Unicode, но использует строгий CESU-8 для внешних данных.

WTF-8

В WTF-8 (формат шаткого преобразования, 8-битный) допускаются непарные суррогатные половины (от U+D800 до U+DFFF). [92] Это необходимо для хранения возможно недопустимого кода UTF-16, например имен файлов Windows. Многие системы, работающие с UTF-8, работают таким образом, не рассматривая его как другую кодировку, поскольку она проще. [93]

Термин «WTF-8» также использовался в шутку для обозначения ошибочно дважды закодированного UTF-8 [94] [95], иногда подразумевая, что закодированы только байты CP1252 . [96]

ПЭП 383

Версия 3 языка программирования Python рассматривает каждый байт недопустимого байтового потока UTF-8 как ошибку (см. также изменения в новом режиме UTF-8 в Python 3.7 [97] ); это дает 128 различных возможных ошибок. Были созданы расширения, позволяющие без потерь преобразовать любую последовательность байтов, которая считается UTF-8, в UTF-16 или UTF-32 путем перевода 128 возможных байтов ошибок в зарезервированные кодовые точки и преобразования этих кодовых точек обратно в ошибки. байт для вывода UTF-8. Самый распространенный подход — преобразовать коды в U+DC80...U+DCFF, которые представляют собой низкие (конечные) суррогатные значения и, следовательно , «недействительный» UTF-16, используемый Python PEP 383 (или «surrogateescape»). подход. [33] Другая кодировка под названием MirBSD OPTU-8/16 преобразует их в U+EF80...U+EFFF в области частного использования . [98] В любом подходе значение байта кодируется в младших восьми битах выходной кодовой точки.

Эти кодировки очень полезны, поскольку они позволяют избежать необходимости иметь дело с «недопустимыми» байтовыми строками намного позже, если это вообще возможно, и позволяют массивам байтов «текста» и «данных» быть одним и тем же объектом. Если программа хочет использовать UTF-16 внутри себя, необходимо сохранить и использовать имена файлов, которые могут использовать недопустимый UTF-8; [99] поскольку API файловой системы Windows использует UTF-16, необходимость поддержки недопустимого UTF-8 здесь меньше. [33]

Чтобы кодировка была обратимой, стандартные кодировки UTF-8 кодовых точек, используемые для ошибочных байтов, должны считаться недействительными. Это делает кодировку несовместимой с WTF-8 или CESU-8 (правда, только для 128 кодовых точек). При перекодировании необходимо быть осторожным с последовательностями кодовых точек ошибок, которые преобразуются обратно в действительный UTF-8, который может использоваться вредоносным программным обеспечением для получения неожиданных символов на выходе, хотя это не может создавать символы ASCII, поэтому считается сравнительно безопасен, поскольку вредоносные последовательности (например, межсайтовый скриптинг ) обычно основаны на символах ASCII. [99]

Смотрите также

Примечания

  1. ^ 17 самолетов , умноженных на 2 16 кодовых точек на плоскость, минус 2 11 технически недействительных суррогатов .
  2. ^ Битов x достаточно для кодирования до 0x1FFFFF, но текущий RFC 3629 §3 ограничивает кодировку UTF-8 кодовой точкой U+10FFFF, чтобы соответствовать ограничениям UTF-16. Устаревший RFC 2279 допускал кодировку UTF-8 до (тогда законной) кодовой точки U+7FFFFFF.
  3. ^ Некоторые сложные символы смайликов могут потребовать даже большего; смайлик с флагом трансгендеров (🏳️‍⚧️), который состоит из последовательности из пяти кодовых точек U+1F3F3 U+FE0F U+200D U+26A7 U+FE0F, требует для кодирования шестнадцати байтов, а для флага Шотландии (🏴футбол) Для футбола футбола) требуется в общей сложности двадцать восемь байтов для последовательности из семи кодовых точек U+1F3F4 U+E0067 U+E0062 U+E0073 U+E0063 U+E0074 U+E007F.
  4. ^ Например, в ячейке 9D указано +1D. Шестнадцатеричное число 9D в двоичном формате равно 10011101 , и поскольку 2 старших бита ( 10 ) зарезервированы для обозначения этого байта продолжения, остальные 6 битов ( 011101 ) имеют шестнадцатеричное значение 1D.
  5. ^ Опрос W3Techs.com [9] основан на кодировке, заявленной в ответе сервера, см. https://w3techs.com/forum/topic/22994.
  6. ^ Python использует ряд кодировок для того, что он называет «Юникод», однако ни одна из этих кодировок не является UTF-8. Python 2 и ранняя версия 3 использовали UTF-16 в Windows и UTF-32 в Unix. В более поздних реализациях Python 3 используются три кодировки фиксированной длины: ISO-8859-1 , UCS-2 и UTF-32, в зависимости от необходимой максимальной кодовой точки. [60]

Рекомендации

  1. ^ «Глава 2. Общая структура». Стандарт Unicode (изд. 6.0). Маунтин-Вью, Калифорния, США: Консорциум Unicode . ISBN 978-1-936213-01-6.
  2. ^ аб Пайк, Роб (30 апреля 2003 г.). «История UTF-8».
  3. ^ Пайк, Роб; Томпсон, Кен (1993). «Hello World или Καλημέρα κόσμε или こんにちは 世界» (PDF) . Материалы зимней конференции USENIX 1993 года .
  4. ^ «Безопасная файловая система UCS — формат преобразования (FSS-UTF) — предварительная спецификация X/Open» (PDF) . unicode.org .
  5. ^ "Материалы зимней конференции USENIX 1993 года" . usenix.org .
  6. ^ аб Альвестранд, Харальд Т. (январь 1998 г.). Политика IETF в отношении наборов символов и языков. IETF . дои : 10.17487/RFC2277 . БКП 18. RFC 2277.
  7. ^ abc «Поддержка UTF-8 в Microsoft Game Development Kit (GDK) — Microsoft Game Development Kit». Learn.microsoft.com . Проверено 5 марта 2023 г. Работая в UTF-8, вы можете обеспечить максимальную совместимость [..] Windows изначально работает в UTF-16 (или WCHAR), что требует преобразования кодовых страниц с помощью MultiByteToWideChar и WideCharToMultiByte. Это уникальное бремя, которое Windows возлагает на код, предназначенный для нескольких платформ. [..] Microsoft Game Development Kit (GDK) и Windows в целом продвигаются вперед к поддержке UTF-8, чтобы устранить это уникальное бремя Windows по нацеливанию кода или взаимообмену с несколькими платформами и Интернетом. Кроме того, это приводит к меньшему количеству проблем с интернационализацией в приложениях и играх и уменьшает матрицу тестов, необходимую для правильной работы.
  8. ^ ab «Стандарт кодирования». кодирование.spec.whatwg.org . Проверено 15 апреля 2020 г.
  9. ^ abc «Обзор использования кодировок символов с разбивкой по рейтингу». W3Techs . Проверено 2 февраля 2024 г.
  10. ^ «Стандарт кодирования § 4.2. Имена и метки» . ЧТОРГ . Проверено 29 апреля 2018 г.
  11. ^ «Наборы символов». Управление по присвоению номеров в Интернете . 23 января 2013 г. Проверено 8 февраля 2013 г.
  12. ^ Ливиу (07.02.2014). «Кодовая страница UTF-8 65001 в Windows 7 — часть I» . Проверено 30 января 2018 г. Раньше под XP (и, непроверенно, но, вероятно, и под Vista) циклы for просто не работали, пока была активна кодовая страница 65001.
  13. ^ «MySQL :: Справочное руководство MySQL 8.0 :: 10.9.1 Набор символов utf8mb4 (4-байтовая кодировка Unicode UTF-8)» . Справочное руководство MySQL 8.0 . Корпорация Оракл . Проверено 14 марта 2023 г.
  14. ^ ab «MySQL :: Справочное руководство MySQL 8.0 :: 10.9.2 Набор символов utf8mb3 (3-байтовая кодировка Unicode UTF-8)» . Справочное руководство MySQL 8.0 . Корпорация Оракл . Проверено 24 февраля 2023 г.
  15. ^ «Наборы символов HP PCL | Блог поддержки языка управления принтером (PCL и PXL)» . 19 февраля 2015 г. Архивировано из оригинала 19 февраля 2015 г. Проверено 30 января 2018 г.
  16. ^ «Руководство по поддержке глобализации баз данных» . docs.oracle.com . Проверено 16 марта 2023 г.
  17. ^ "БОМ". Суйкавики (на японском языке). Архивировано из оригинала 17 января 2009 г.
  18. ^ Дэвис, Марк . «Формы Юникода». ИБМ . Архивировано из оригинала 6 мая 2005 г. Проверено 18 сентября 2013 г.
  19. ^ "Строка". Разработчик Apple . Проверено 15 марта 2021 г.
  20. ^ «Глава 3» (PDF) , Стандарт Юникод , стр. 54
  21. ^ «Глава 3» (PDF) , Стандарт Юникод , стр. 55
  22. ^ «Глава 3» (PDF) , Стандарт Юникод , стр. 55
  23. ^ abc Yergeau, Ф. (ноябрь 2003 г.). UTF-8, формат преобразования ISO 10646. IETF . дои : 10.17487/RFC3629 . СТД 63. RFC 3629 . Проверено 20 августа 2020 г.
  24. ^ «Глава 3» (PDF) , Стандарт Юникод , стр. 54
  25. ^ «Глава 3» (PDF) , Стандарт Юникод , стр. 55
  26. ^ Марин, Марвин (17 октября 2000 г.). «Часто задаваемые вопросы о вредоносных программах: анализ уязвимостей UNICODE в Windows NT | Обход папок веб-сервера MS00-078» . Институт САНС . Архивировано из оригинала 27 августа 2014 г.
  27. ^ «CVE-2008-2938». Национальная база данных уязвимостей .
  28. ^ «PEP 529 — Измените кодировку файловой системы Windows на UTF-8» . Python.org . Проверено 10 мая 2022 г. Этот PEP предлагает изменить кодировку файловой системы по умолчанию в Windows на utf-8 и изменить все функции файловой системы для использования API-интерфейсов Unicode для путей к файловой системе. [..] может правильно обойти все символы, используемые в путях (в POSIX с обработкой суррогатного преобразования; в Windows, потому что str сопоставляется с собственным представлением). В Windows байты не могут передавать туда и обратно все символы, используемые в путях.
  29. ^ «Ввод данных (платформа Java SE 8)» . docs.oracle.com . Проверено 24 марта 2021 г.
  30. ^ «Недекодируемые байты в интерфейсах системных символов» . python.org . 22 апреля 2009 г. Проверено 13 августа 2014 г.
  31. ^ «Юникод 6.0.0».
  32. ^ 128 1-байтовый, (16+5)×64 2-байтовый и 5×64×64 3-байтовый. Их может быть несколько меньше, если для каждого байта продолжения выполняются более точные тесты.
  33. ^ abc фон Лёвис, Мартин (22 апреля 2009 г.). «Недекодируемые байты в интерфейсах системных символов». Фонд программного обеспечения Python . ПЭП 383.
  34. ^ «Глава 2» (PDF) , Стандарт Unicode — версия 15.0.0 , стр. 39
  35. ^ «Часто задаваемые вопросы по UTF-8 и Unicode для Unix/Linux» .
  36. ^ Дэвис, Марк (3 февраля 2012 г.). «Unicode более 60 процентов Интернета». Официальный блог Google . Архивировано из оригинала 9 августа 2018 г. Проверено 24 июля 2020 г.
  37. ^ Дэвис, Марк (5 мая 2008 г.). «Переход на Юникод 5.1». Официальный блог Google . Проверено 13 марта 2023 г.
  38. ^ «Статистика использования и рыночная доля ASCII для веб-сайтов, январь 2024 г.» . W3Techs . Проверено 1 января 2024 г.
  39. ^ Брэй, Тим (декабрь 2017 г.). Брей, Т. (ред.). Формат обмена данными нотации объектов JavaScript (JSON). IETF. дои : 10.17487/RFC8259 . РФК 8259 . Проверено 16 февраля 2018 г.
  40. ^ «Использование международных символов в интернет-почте». Консорциум Интернет-почты. 1 августа 1998 г. Архивировано из оригинала 26 октября 2007 г. Проверено 8 ноября 2007 г.
  41. ^ «Стандарт кодирования». кодирование.spec.whatwg.org . Проверено 15 ноября 2018 г.
  42. ^ «Указание кодировки символов документа». HTML 5.2 (Отчет). Консорциум Всемирной паутины . 14 декабря 2017 года . Проверено 3 июня 2018 г.
  43. ^ «Выбирайте кодировку текста при открытии и сохранении файлов» . Поддержка Майкрософт . Проверено 1 ноября 2021 г.
  44. ^ «utf 8 — кодировка символов файлов Microsoft Word DOC и DOCX?». Переполнение стека . Проверено 1 ноября 2021 г.
  45. ^ «Экспорт файла .txt UTF-8 из Word» .
  46. ^ «excel — файлы XLSX имеют кодировку UTF-8 по определению?». Переполнение стека . Проверено 1 ноября 2021 г.
  47. ^ «Как открыть CSV-файл UTF-8 в Excel без неправильного преобразования символов японского и китайского языков для Mac и Windows?». ответы.microsoft.com . Проверено 1 ноября 2021 г.
  48. ^ «Как мне заставить Блокнот сохранять текст в UTF-8 без спецификации?». Переполнение стека . Проверено 24 марта 2021 г.
  49. ^ Галлоуэй, Мэтт (октябрь 2012 г.). «Кодировка символов для разработчиков iOS. Или UTF-8, что теперь?». www.galloway.me.uk . Проверено 02 января 2021 г. на самом деле вы обычно просто предполагаете UTF-8, поскольку это, безусловно, самая распространенная кодировка.
  50. ^ «Блокнот Windows 10 получает улучшенную поддержку кодировки UTF-8» . Мигающий компьютер . Проверено 24 марта 2021 г. Microsoft теперь по умолчанию сохраняет новые текстовые файлы в формате UTF-8 без спецификации, как показано ниже.
  51. ^ «Настройка меню «Пуск» Windows 11» . docs.microsoft.com . Проверено 29 июня 2021 г. Убедитесь, что ваш LayoutModification.json использует кодировку UTF-8.
  52. ^ «JEP 400: UTF-8 по умолчанию» . openjdk.java.net . Проверено 30 марта 2022 г.
  53. ^ «Функция № 16604: Установите по умолчанию для Encoding.default_external значение UTF-8 в Windows» . bugs.ruby-lang.org . Ruby master — система отслеживания проблем Ruby . Проверено 1 августа 2022 г.
  54. ^ «Функция № 12650: используйте кодировку UTF-8 для ENV в Windows» . bugs.ruby-lang.org . Ruby master — система отслеживания проблем Ruby . Проверено 1 августа 2022 г.
  55. ^ «Новые функции в R 4.2.0». Блог Jumping Rivers . Р-блогеры. 01.04.2022 . Проверено 1 августа 2022 г.
  56. ^ «PEP 540 – добавить новый режим UTF-8» . peps.python.org . Проверено 23 сентября 2022 г.
  57. ^ «PEP 686 — сделать режим UTF-8 по умолчанию | peps.python.org» . peps.python.org . Проверено 26 июля 2023 г.
  58. ^ «PEP 597 - добавить дополнительное EncodingWarning» . Python.org . Проверено 24 августа 2021 г.
  59. ^ «Поддержка UTF-8 в качестве переносимой кодировки исходного файла» (PDF) .
  60. ^ ab «PEP 393 – Гибкое строковое представление». Python.org . Проверено 18 мая 2022 г. Поскольку взаимодействие с другими библиотеками часто требует какого-то внутреннего представления, спецификация выбирает UTF-8 в качестве рекомендуемого способа представления строк коду C. [..] Указатели data и utf8 указывают на одну и ту же память, если в строке используются только символы ASCII (использования только Latin-1 недостаточно). [..] Рекомендуемый способ создания объекта Unicode — использовать функцию PyUnicode_New [..] Для доступа к представлению UTF-8 предусмотрена новая функция PyUnicode_AsUTF8.
  61. ^ «Представление исходного кода». Спецификация языка программирования Go. golang.org (Отчет) . Проверено 10 февраля 2021 г.
  62. ↑ Цай, Майкл Дж. (21 марта 2019 г.). «Строка UTF-8 в Swift 5» (блог) . Проверено 15 марта 2021 г. Переход на UTF-8 реализует одну из долгосрочных целей строки — обеспечить высокопроизводительную обработку, [...] а также закладывает основу для предоставления еще более производительных API в будущем.
  63. ^ «Выпущен PyPy v7.1; теперь для строк Unicode используется внутренняя UTF-8» . Маттип. Статусный блог PyPy . 24 марта 2019 г. Проверено 21 ноября 2020 г.
  64. ^ «Объекты и кодеки Unicode». Документация Python . Проверено 19 августа 2023 г. Представление UTF-8 создается по требованию и кэшируется в объекте Unicode.
  65. ^ «PEP 623 – удалить wstr из Unicode» . Python.org . Проверено 21 ноября 2020 г. Пока мы не отбросим устаревший объект Unicode, очень сложно попробовать другие реализации Unicode, например реализацию на основе UTF-8 в PyPy.
  66. ^ Воутерс, Томас (11 июля 2023 г.). «Python Insider: выпущена бета-версия Python 3.12.0 4» . Инсайдер Python . Проверено 26 июля 2023 г. Устаревшие члены wstr и wstr_length реализации C объектов Юникода были удалены согласно PEP 623.
  67. ^ "/validate-charset (проверка совместимости символов)". docs.microsoft.com . Проверено 19 июля 2021 г. Visual Studio использует UTF-8 в качестве внутренней кодировки символов во время преобразования между исходным набором символов и набором символов выполнения.
  68. ^ «Представляем поддержку UTF-8 для SQL Server». techcommunity.microsoft.com . 2019-07-02 . Проверено 24 августа 2021 г. Например, изменение существующего типа данных столбца с NCHAR(10) на CHAR(10) с использованием параметров сортировки с поддержкой UTF-8 приводит к сокращению требований к памяти почти на 50%. [..] В диапазоне ASCII при интенсивном вводе-выводе чтения/записи в UTF-8 мы измерили среднее улучшение производительности на 35 % по сравнению с UTF-16 при использовании кластеризованных таблиц с некластеризованным индексом в строковом столбце и повышение производительности в среднем на 11 % по сравнению с UTF-16 при использовании кучи.
  69. ^ «Используйте кодовую страницу Windows UTF-8 — приложения UWP» . docs.microsoft.com . Проверено 6 июня 2020 г. Начиная с версии Windows 1903 (обновление от мая 2019 г.), вы можете использовать свойство ActiveCodePage в appxmanifest для упакованных приложений или манифест Fusion для неупакованных приложений, чтобы заставить процесс использовать UTF-8 в качестве кодовой страницы процесса. [...] соответствует только при работе в Windows версии 1903 (обновление от мая 2019 г.) или более поздней версии, а описанному выше свойству ActiveCodePage присвоено значение UTF-8. В противном случае он учитывает кодовую страницу устаревшей системы. Мы рекомендуем использовать явно.CP_ACPCP_UTF8CP_UTF8
  70. ^ «Приложение F. Формат преобразования FSS-UTF/безопасной файловой системы UCS» (PDF) . Стандарт Юникод 1.1 . Архивировано (PDF) из оригинала 7 июня 2016 г. Проверено 7 июня 2016 г.
  71. ^ Уистлер, Кеннет (12 июня 2001 г.). «FSS-UTF, UTF-2, UTF-8 и UTF-16». Архивировано из оригинала 7 июня 2016 г. Проверено 7 июня 2006 г.
  72. ^ аб Пайк, Роб (30 апреля 2003 г.). «История UTF-8» . Проверено 7 сентября 2012 г.
  73. ^ Пайк, Роб (6 сентября 2012 г.). «UTF-8 вчера исполнилось 20 лет» . Проверено 7 сентября 2012 г.
  74. ^ ISO/IEC 10646:2014 §9.1, 2014.
  75. ^ Стандарт Unicode, версия 15.0 §3.9 D92, §3.10 D95, 2021 г.
  76. ^ Стандартное приложение Unicode № 27: Unicode 3.1, 2001.
  77. ^ Стандарт Unicode, версия 5.0 §3.9–§3.10 гл. 3, 2006.
  78. ^ Стандарт Unicode, версия 6.0 §3.9 D92, §3.10 D95, 2010 г.
  79. ^ Макгоуэн, Рик (19 декабря 2011 г.). «Схема кодирования совместимости для UTF-16: 8-бит (CESU-8)». Консорциум Юникод . Технический отчет Unicode № 26.
  80. ^ «Поддержка набора символов» . Документация по базе данных Oracle 19c, Справочник по языку SQL . Корпорация Оракл .
  81. ^ «Поддержка многоязычных баз данных с помощью Unicode § Поддержка стандарта Unicode в базе данных Oracle». Руководство по поддержке глобализации баз данных . Корпорация Оракл .
  82. ^ «8.2.2.3. Кодировки символов» . Стандарт HTML 5.1 . W3C .
  83. ^ «8.2.2.3. Кодировки символов» . Стандарт HTML5 . W3C .
  84. ^ «12.2.3.3 Кодировки символов» . HTML Уровень жизни . ЧТОРГ .
  85. ^ «Документация Java SE для интерфейса java.io.DataInput, подраздел «Модифицированный UTF-8»» . Корпорация Оракл . 2015 . Проверено 16 октября 2015 г.
  86. ^ «Спецификация виртуальной машины Java, раздел 4.4.7: «Структура CONSTANT_Utf8_info»». Корпорация Оракл . 2015 . Проверено 16 октября 2015 г.
  87. ^ «Спецификация сериализации объектов Java, глава 6: Протокол потока сериализации объектов, раздел 2: Элементы потока» . Корпорация Оракл . 2010 . Проверено 16 октября 2015 г.
  88. ^ «Спецификация собственного интерфейса Java, глава 3: Типы JNI и структуры данных, раздел: Модифицированные строки UTF-8» . Корпорация Оракл . 2015 . Проверено 16 октября 2015 г.
  89. ^ «Спецификация виртуальной машины Java, раздел 4.4.7: «Структура CONSTANT_Utf8_info»». Корпорация Оракл . 2015 . Проверено 16 октября 2015 г.
  90. ^ «АРТ и Далвик». Проект Android с открытым исходным кодом . Архивировано из оригинала 26 апреля 2013 г. Проверено 9 апреля 2013 г.
  91. ^ «UTF-8 по крупицам» . Вики Тклера . 28 февраля 2001 г. Проверено 03 сентября 2022 г.
  92. ^ Сапен, Саймон (11 марта 2016 г.) [25 сентября 2014 г.]. «Кодировка WTF-8». Архивировано из оригинала 24 мая 2016 г. Проверено 24 мая 2016 г.
  93. ^ Сапен, Саймон (25 марта 2015 г.) [25 сентября 2014 г.]. «Кодировка WTF-8 § Мотивация». Архивировано из оригинала 16 августа 2020 г. Проверено 26 августа 2020 г.
  94. ^ "WTF-8.com". 18 мая 2006 г. Проверено 21 июня 2016 г.
  95. ^ Шпеер, Робин (21 мая 2015 г.). «ftfy (исправляет текст для вас) 4.0: меньше менять и больше исправлять». Архивировано из оригинала 30 мая 2015 г. Проверено 21 июня 2016 г.
  96. ^ «WTF-8, формат преобразования кодовой страницы 1252» . Архивировано из оригинала 13 октября 2016 г. Проверено 12 октября 2016 г.
  97. ^ «PEP 540 — Добавить новый режим UTF-8» . Python.org . Проверено 24 марта 2021 г.
  98. ^ "RTFM optu8to16(3), optu8to16vis(3)" . www.mirbsd.org .
  99. ^ Аб Дэвис, Марк ; Суиньяр, Мишель (2014). «3.7 Включение преобразования без потерь». Вопросы безопасности Unicode . Технический отчет Unicode № 36.

Внешние ссылки