UTF-32
UTF-32 (32- битный формат преобразования Юникода фиксированной длины, ) — это кодировка используемая для кодирования кодовых точек Юникода , которая использует ровно 32 бита (четыре байта ) на кодовую точку (но количество ведущих бит должно быть равно нулю, поскольку их гораздо меньше). чем 2 32 Кодовые точки Юникода, которым на самом деле требуется всего 21 бит). [1] UTF-32 — это кодировка фиксированной длины, в отличие от всех других форматов преобразования Unicode, которые представляют собой кодировки переменной длины. Каждое 32-битное значение в UTF-32 представляет одну кодовую точку Юникода и точно равно численному значению этой кодовой точки.
Основное преимущество UTF-32 заключается в том, что кодовые точки Unicode индексируются напрямую. Поиск N-й кодовой точки в последовательности кодовых точек является операцией с постоянным временем . Напротив, код переменной длины требует линейного времени для подсчета N кодовых точек от начала строки. Это делает UTF-32 простой заменой в коде, использующем целые числа , увеличивающиеся на единицу, для проверки каждого места в строке , как это обычно делается для ASCII . Однако кодовые точки Unicode редко обрабатываются полностью изолированно, например, для объединения последовательностей символов и эмодзи. [2]
Основным недостатком UTF-32 является неэффективность использования пространства: на каждую кодовую точку используется четыре байта , включая 11 бит, которые всегда равны нулю. Символы за пределами BMP относительно редки в большинстве текстов (за исключением, например, текстов с некоторыми популярными смайликами) и обычно могут игнорироваться при оценке размера. Это делает UTF-32 почти в два раза больше UTF-16 . Он может быть в четыре раза больше размера UTF-8 в зависимости от количества символов в подмножестве ASCII . [2]
История [ править ]
Исходный стандарт ISO/IEC 10646 определяет 32-битную форму кодирования , называемую UCS-4 , в которой каждая кодовая точка в универсальном наборе символов (UCS) представлена 31-битным значением от 0 до 0x7FFFFFFF (знаковый бит не использовался). и ноль). В ноябре 2003 года стандарт Unicode был ограничен RFC 3629, чтобы соответствовать ограничениям кодировки UTF-16 : явный запрет кодовых точек, превышающих U+10FFFF (а также старшие и младшие суррогаты от U+D800 до U+DFFF). Это ограниченное подмножество определяет UTF-32. [3] [1] Хотя стандарт ISO имел (по состоянию на 1998 год в Unicode 2.1) «зарезервированные для частного использования» адреса от 0xE00000 до 0xFFFFFF и от 0x60000000 до 0x7FFFFFFF. [4] эти области были удалены в более поздних версиях. Поскольку в документе «Принципы и процедуры» рабочей группы 2 ISO/IEC JTC 1/SC 2 указано, что все будущие назначения кодовых точек будут ограничены диапазоном Unicode, UTF-32 сможет представлять все кодовые точки UCS, а UTF-32 и UCS-4 идентичны. [5]
Утилита фиксированной ширины [ править ]
Фиксированное количество байтов на кодовую точку имеет ряд теоретических преимуществ, но у каждого из них есть проблемы на практике:
- Усечение становится проще, но незначительно по сравнению с UTF-8 и UTF-16 (обе из которых могут искать точку усечения в обратном направлении, просматривая максимум 2–4 единицы кода). [а] [ нужна цитата ]
- Нахождение N-го символа в строке. Для фиксированной ширины это просто проблема O (1) это проблема O (n) . , тогда как для кодирования с переменной шириной [6] Программисты-любители часто сильно переоценивают, насколько это полезно: в действительности алгоритмы, которые знают n без предварительного изучения n -1 символов перед ним (проблема O(n)), очень редки или вообще отсутствуют. [ нужна цитата ] Кроме того, кодовые точки Юникода часто не эквивалентны тому, что пользователь считает «символом», например, оба этих эмодзи представляют собой три кодовых точки: «👨🦲 Мужчина: Лысый». [7] и «👩🦰 Женщина: Рыжие волосы». [8] [9]
- Быстрое определение «ширины» строки. На практике даже при использовании шрифта с «фиксированной шириной» и ограничении символов BMP определение ширины строки по количеству кодовых точек невозможно. Существуют комбинированные формы ширину 2 , такие как «é», выраженные с использованием двух кодовых точек «e» + «́» и «фиксированная ширина», которые могут присваивать иероглифам CJK , а некоторые кодовые точки занимают несколько позиций символов на одну кодовую точку (« графема кластеры» для CJK). [6]
Используйте [ править ]
UTF-32 в основном используется во внутренних API, где данные представляют собой отдельные кодовые точки или глифы , а не строки символов. Например, в современном рендеринге текста часто встречается [ нужна цитата ] что последним шагом является создание списка структур, каждая из которых содержит координаты (x,y) , атрибуты и одну кодовую точку UTF-32, идентифицирующую глиф для рисования. Часто информация, не относящаяся к Юникоду, хранится в «неиспользуемых» 11 битах каждого слова. [ нужна цитата ]
Использование строк UTF-32 в Windows (где wchar_t составляет 16 бит) практически не существует. В системах Unix строки UTF-32 иногда, но редко, используются внутри приложений из-за типа wchar_t определяется как 32-битный. Версии Python до 3.2 можно скомпилировать для использования их вместо UTF-16 ; начиная с версии 3.3 все строки Юникода хранятся в кодировке UTF-32, но с оптимизированными ведущими нулевыми байтами «в зависимости от [кодовой точки] с наибольшим порядковым номером Юникода (1, 2 или 4 байта)», чтобы сделать все кодовые точки такого размера. . [10] Сид7 [11] и Лассо [ нужна цитата ] языки программирования кодируют все строки с помощью UTF-32, полагая, что прямая индексация важна, тогда как язык программирования Julia отошел от встроенной поддержки UTF-32 с выпуском 1.0, упростив язык до использования только строк UTF-8 (со всеми другие кодировки считаются устаревшими и перенесены из стандартной библиотеки в пакет [12] ) в соответствии с «Манифестом UTF-8 Everywhere». [13]
Варианты [ править ]
Хотя суррогатные половины технически недействительны, они часто кодируются и допускаются. Это позволяет преобразовать недопустимый UTF-16 (например, имена файлов Windows) в UTF-32, аналогично тому, как -8 WTF работает вариант UTF -8. Иногда вместо символов, отличных от BMP, кодируются парные суррогаты, аналогично CESU-8 . Из-за большого количества неиспользуемых 32-битных значений также можно сохранить недопустимый UTF-8, используя значения, отличные от Unicode, для кодирования ошибок UTF-8, хотя стандарта для этого не существует.
См. также [ править ]
Примечания [ править ]
- ^ Для UTF-8: выберите точку для усечения. Если байт перед ним равен 0–0x7F или байт после него отличается от байтов продолжения 0x80–0xBF, строка может быть усечена в этой точке. В противном случае выполните поиск такой точки до 3 байтов назад и обрежьте ее. Если не найден, обрезать в исходной позиции. Это работает, даже если в UTF-8 есть ошибки кодировки. UTF-16 тривиален и должен поддерживать не более одного слова.
Ссылки [ править ]
- ^ Перейти обратно: а б Констебль, Питер (13 июня 2001 г.). «Сопоставление кодовых точек с формами кодировки Unicode» . Компьютеры и системы письма - SIL International . Проверено 03 октября 2022 г.
- ^ Перейти обратно: а б «Часто задаваемые вопросы — UTF-8, UTF-16, UTF-32 и спецификация» . Юникод . Проверено 4 сентября 2022 г.
- ^ «Общедоступные стандарты – ISO/IEC 10646:2020» . Стандарты ИСО . Проверено 12 октября 2021 г.
Пункт 9.4: «Поскольку суррогатные кодовые точки не являются скалярными значениями UCS, кодовые единицы UTF-32 в диапазоне 0000 D800–0000 DFFF имеют неправильный формат». Пункт 4.57: «[Кодовое пространство UCS] состоит из целых чисел от 0 до 10 FFFF (шестнадцатеричное)». Пункт 4.58: «[скалярное значение UCS] любая кодовая точка UCS, за исключением кодовых точек с высоким и низким суррогатным кодом».
- ^ «Приложение B — Универсальный набор символов (UCS)» . ДКУУГ Стандартизация . Архивировано из оригинала 22 января 2022 года . Проверено 03 октября 2022 г.
- ^ «C.2 Формы кодирования в ISO/IEC 10646» (PDF) . Стандарт Юникод, версия 6.0 . Маунтин-Вью, Калифорния: Консорциум Unicode . Февраль 2011. с. 573. ИСБН 978-1-936213-01-6 .
Он [UCS-4] теперь рассматривается просто как синоним UTF-32 и считается канонической формой представления символов в формате 10646.
- ^ Перейти обратно: а б Горегаокар, Маниш (14 января 2017 г.). «Давайте перестанем приписывать значение точкам кода» . В погоне за ленью . Проверено 14 июня 2020 г.
Люди начинают подразумевать, что кодовые точки что-то значат и что индексирование или нарезка O(1) на границах кодовых точек — полезная операция.
- ^ «👨🦲 Мужчина: Лысый Эмодзи» . Эмоджипедия . Проверено 12 октября 2021 г.
- ^ «👩🦰 Женщина: рыжеволосый смайлик» . Эмоджипедия . Проверено 12 октября 2021 г.
- ^ «↔️ Последовательности Emoji ZWJ (соединение нулевой ширины)» . emojipedia.org . Проверено 12 октября 2021 г.
- ^ Лёвис, Мартин. «PEP 393 — гибкое строковое представление» . python.org . Питон . Проверено 26 октября 2014 г.
- ^ «Использование UTF-32 имеет ряд преимуществ» .
- ^ JuliaStrings/LegacyStrings.jl: устаревшие строковые типы Юникода , JuliaStrings, 17 мая 2019 г. , получено 15 октября 2019 г.
- ^ «Манифест UTF-8 повсюду» .
Внешние ссылки [ править ]
- Стандарт Unicode 5.0.0, глава 3 – формально определяет UTF-32 в § 3.9, D90 (стр. PDF 40) и § 3.10, D99-D101 (стр. PDF 45).
- Приложение № 19 стандарта Unicode – официально определено UTF-32 для Unicode 3.x (март 2001 г.; последнее обновление в марте 2002 г.)
- Регистрация новых кодировок: UTF-32, UTF-32BE, UTF-32LE – объявление о добавлении UTF-32 в реестр кодировок IANA (апрель 2002 г.)
