Jump to content

UTF-32

(Перенаправлено с UTF-32LE )

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 года RFC 3629 ограничил Unicode, чтобы он соответствовал ограничениям кодировки 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-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 байта)», чтобы сделать все кодовые точки такого размера. . [8] Сид7 [9] и Лассо [ нужна ссылка ] языки программирования кодируют все строки с помощью UTF-32, полагая, что прямая индексация важна, тогда как язык программирования Julia отошел от встроенной поддержки UTF-32 с выпуском 1.0, упростив язык до использования только строк UTF-8 (со всеми другие кодировки считаются устаревшими и перенесены из стандартной библиотеки в пакет [10] ) в соответствии с «Манифестом UTF-8 Everywhere». [11]

Варианты

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

Хотя суррогатные половины технически недействительны, они часто кодируются и допускаются. Это позволяет преобразовать недопустимый UTF-16 (например, имена файлов Windows) в UTF-32, аналогично тому, как работает вариант UTF- 8 WTF -8. Иногда вместо символов, отличных от BMP, кодируются парные суррогаты, аналогично CESU-8 . Из-за большого количества неиспользуемых 32-битных значений также можно сохранить недопустимый UTF-8, используя значения, отличные от Unicode, для кодирования ошибок UTF-8, хотя стандарта для этого не существует.

См. также

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


Примечания

[ редактировать ]
  1. ^ Для UTF-8: выберите точку для усечения. Если байт перед ним равен 0–0x7F или байт после него отличается от байтов продолжения 0x80–0xBF, строка может быть усечена в этой точке. В противном случае выполните поиск такой точки до 3 байтов назад и обрежьте ее. Если не найден, обрезать в исходной позиции. Это работает, даже если в UTF-8 есть ошибки кодировки. UTF-16 тривиален и должен поддерживать не более одного слова.
  1. ^ Jump up to: а б Констебль, Питер (13 июня 2001 г.). «Сопоставление кодовых точек с формами кодировки Unicode» . Компьютеры и системы письма - SIL International . Проверено 3 октября 2022 г.
  2. ^ Jump up to: а б «Часто задаваемые вопросы — UTF-8, UTF-16, UTF-32 и спецификация» . Юникод . Проверено 4 сентября 2022 г.
  3. ^ «Общедоступные стандарты – 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, кроме кодовых точек с высоким и низким суррогатным кодом».
  4. ^ «Приложение B — Универсальный набор символов (UCS)» . ДКУУГ Стандартизация . Архивировано из оригинала 22 января 2022 года . Проверено 3 октября 2022 г.
  5. ^ «C.2 Формы кодирования в ISO/IEC 10646» (PDF) . Стандарт Юникод, версия 6.0 . Маунтин-Вью, Калифорния: Консорциум Unicode . Февраль 2011. с. 573. ИСБН  978-1-936213-01-6 . Он [UCS-4] теперь рассматривается просто как синоним UTF-32 и считается канонической формой представления символов в формате 10646.
  6. ^ Jump up to: а б Горегаокар, Маниш (14 января 2017 г.). «Давайте перестанем приписывать значение точкам кода» . В погоне за ленью . Проверено 14 июня 2020 г. Люди начинают подразумевать, что кодовые точки что-то значат и что индексирование или нарезка O(1) на границах кодовых точек является полезной операцией.
  7. ^ «👨‍🦲 Мужчина: Лысый Эмодзи» . Эмоджипедия . Проверено 12 октября 2021 г.
  8. ^ Лёвис, Мартин. «PEP 393 — гибкое строковое представление» . python.org . Питон . Проверено 26 октября 2014 г.
  9. ^ «Использование UTF-32 имеет ряд преимуществ» .
  10. ^ JuliaStrings/LegacyStrings.jl: устаревшие строковые типы Юникода , JuliaStrings, 17 мая 2019 г. , получено 15 октября 2019 г.
  11. ^ «Манифест UTF-8 повсюду» .
[ редактировать ]
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: e2706f8ab2d4b42fb5c187bb7f92d34c__1720980120
URL1:https://arc.ask3.ru/arc/aa/e2/4c/e2706f8ab2d4b42fb5c187bb7f92d34c.html
Заголовок, (Title) документа по адресу, URL1:
UTF-32 - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)