Кодирование переменной ширины
 | Эта статья нуждается в дополнительных ссылок для проверки . ( декабрь 2009 г. ) |
Кодирование переменной ширины — это тип схемы кодирования символов , в которой коды разной длины используются для кодирования набора символов (репертуара символов) для представления, обычно на компьютере . [1] [а] Наиболее распространенными кодировками переменной ширины являются многобайтовые кодировки , которые используют различное количество байтов ( октетов ) для кодирования разных символов. (Некоторые авторы, особенно в документации Microsoft , используют термин «многобайтовый набор символов», который является неправильным , поскольку размер представления является атрибутом кодировки, а не набора символов.)
Ранние кодировки с переменной шириной, использующие менее байта на символ, иногда использовались для упаковки английского текста в меньшее количество байтов в приключенческих играх для первых микрокомпьютеров . Однако диски (которые, в отличие от лент, допускали произвольный доступ, позволяющий загружать текст по требованию), увеличение компьютерной памяти и алгоритмы сжатия общего назначения сделали такие приемы в значительной степени устаревшими.
Многобайтовые кодировки обычно являются результатом необходимости увеличения количества символов, которые можно закодировать без нарушения обратной совместимости с существующим ограничением. Например, с помощью одного байта (8 бит) на символ можно закодировать 256 возможных символов; для кодирования более 256 символов очевидным выбором будет использование двух или более байтов на единицу кодирования, два байта (16 бит) позволят использовать 65 536 возможных символов, но такое изменение нарушит совместимость с существующими системами и, следовательно, может оказаться невозможным. быть вообще осуществимым. [б]
Общая структура [ править ]
Поскольку целью системы многобайтового кодирования является минимизация изменений в существующем прикладном программном обеспечении, некоторые символы должны сохранять свои ранее существовавшие однозначные коды, даже если другие символы имеют в своих кодах несколько единиц. В результате в кодировании переменной ширины есть три типа единиц: одиночные элементы , которые состоят из одной единицы, ведущие единицы , которые идут первыми в последовательности из нескольких единиц, и конечные единицы , которые идут после последовательности из нескольких единиц. Программному обеспечению ввода и отображения, очевидно, необходимо знать структуру схемы многобайтового кодирования, но другому программному обеспечению обычно не нужно знать, представляет ли пара байтов два отдельных символа или только один символ.
Например, четырехсимвольная строка « I♥NY » закодирована в UTF-8 следующим образом (показана в виде шестнадцатеричных байтовых значений): 49 Е2 99 А5 4Е 59 . Из шести единиц в этой последовательности 49, 4E и 59 являются одиночными (для I, N и Y ), E2 является ведущей единицей, а 99 и A5 являются замыкающими единицами. Символ сердца представлен комбинацией ведущей единицы и двух замыкающих частей.
UTF-8 позволяет программе легко идентифицировать три типа единиц, поскольку они попадают в отдельные диапазоны значений. Старые кодировки переменной ширины обычно не так хорошо разработаны, поскольку диапазоны могут перекрываться. Приложение обработки текста, которое занимается кодированием переменной ширины, должно затем сканировать текст с начала всех определенных последовательностей, чтобы идентифицировать различные единицы и правильно интерпретировать текст. В таких кодировках можно столкнуться с ложными срабатываниями при поиске строки в середине текста. Например, если шестнадцатеричные значения DE, DF, E0 и E1 могут быть либо ведущими, либо конечными единицами, то поиск последовательности из двух единиц DF E0 может привести к ложному положительному результату в последовательности DE DF E0 E1, что состоит из двух последовательных двухединичных последовательностей. Существует также опасность того, что одна поврежденная или потерянная единица может сделать неправильной всю интерпретацию большого количества последовательностей из нескольких единиц. В кодировании с переменной шириной, где все три типа единиц не пересекаются, поиск строки всегда работает без ложных срабатываний, и (при условии, что декодер хорошо написан) повреждение или потеря одной единицы повреждает только один символ.
Многобайтовые кодировки CJK [ править ]
Впервые многобайтовые кодировки использовались для кодирования китайского, японского и корейского языков, которые имеют большие наборы символов, значительно превышающие 256 символов. Сначала кодирование было ограничено 7 битами. В кодировках ISO -2022-JP, ISO-2022-CN и ISO-2022-KR использовался диапазон 21–7E (шестнадцатеричный) как для ведущих, так и для завершающих единиц, и они отделялись от одиночных элементов с помощью escape-последовательностей ISO 2022, чтобы переключение между однобайтовым и многобайтовым режимом. Сначала можно было закодировать в общей сложности 8836 символов (94 × 94), а затем с переключением — дополнительные наборы символов 94 × 94. Схемы кодирования ISO 2022 для CJK до сих пор используются в Интернете. Характер этих кодировок с сохранением состояния и большое перекрытие делают их очень неудобными для обработки.
На платформах Unix 7-битные кодировки ISO 2022 были заменены набором 8-битных схем кодирования, расширенным кодом Unix: EUC-JP, EUC-CN и EUC-KR. Вместо того, чтобы различать многоединичные последовательности и одиночные последовательности с escape-последовательностями, что делало кодировку сохраняющей состояние, многоединичные последовательности были отмечены установкой наиболее значимого бита, то есть находящимся в диапазоне 80–FF (шестнадцатеричный), в то время как одиночные последовательности были только в диапазоне 00–7F. Ведущие и конечные единицы находились в диапазоне от A1 до FE (шестнадцатеричном), то есть в том же диапазоне, что и их диапазон в кодировках ISO 2022, но со старшим битом, установленным в 1. С этими кодировками было достаточно легко работать, если все вашими разделителями были символы ASCII , и вы избегали усечения строк до фиксированной длины, но разрыв в середине многобайтового символа все равно мог привести к серьезному повреждению.
На ПК ( платформы DOS и Microsoft Windows ) были установлены две кодировки для японского и традиционного китайского языка, в которых все одиночные, ведущие и конечные единицы перекрываются: Shift-JIS и Big5 соответственно. В Shift-JIS ведущие единицы имели диапазон 81–9F и E0–FC, следящие единицы имели диапазон 40–7E и 80–FC, а одиночные единицы имели диапазон 21–7E и A1–DF. В Big5 ведущие единицы имели диапазон A1–FE, следящие единицы имели диапазон 40–7E и A1–FE, а одиночные единицы имели диапазон 21–7E (все значения в шестнадцатеричном формате). Это перекрытие снова усложнило обработку, хотя, по крайней мере, большинство символов имели уникальные байтовые значения (хотя, как ни странно, обратная косая черта их не имеет).
Кодировки переменной ширины Unicode [ править ]
есть В стандарте Unicode две кодировки переменной ширины: UTF-8 и UTF-16 (также имеется кодировка фиксированной ширины UTF-32 ). Первоначально стандарты Unicode и ISO 10646 должны были иметь фиксированную ширину: Unicode был 16-битным, а ISO 10646 — 32-битным. [ нужна цитата ] ISO 10646 предоставил кодировку переменной ширины, называемую UTF-1 , в которой одиночные элементы имели диапазон 00–9F, ведущие единицы — диапазон A0–FF, а конечные единицы — диапазоны A0–FF и 21–7E. Из-за этого плохого дизайна, похожего на Shift JIS и Big5 в перекрытии значений, изобретатели операционной системы Plan 9 , первой полностью реализовавшей Unicode, отказались от нее и заменили ее гораздо лучше разработанной кодировкой переменной ширины для Unicode. : UTF-8, в котором одиночные элементы имеют диапазон 00–7F, ведущие единицы имеют диапазон C0–FD (теперь фактически C2–F4, чтобы избежать слишком длинных последовательностей и сохранить синхронность с возможностями кодирования UTF-16; см. UTF -8 статья), а следовые отряды имеют диапазон 80–BF. Ведущий блок также сообщает, сколько следящих блоков следует за ним: один после C2–DF, два после E0–EF и три после F0–F4. [с]
UTF-16 был разработан, чтобы освободиться от ограничения исходного Unicode (1.x) в 65 536 символов без нарушения совместимости с 16-битной кодировкой. В UTF-16 одиночные элементы имеют диапазон 0000–D7FF (55 296 кодовых точек) и E000–FFFF (8192 кодовых точки, всего 63 488), ведущие единицы — диапазон D800–DBFF (1024 кодовых точки) и конечные единицы — диапазон DC00– DFFF (1024 кодовых точки, всего 2048). Начальные и конечные единицы, называемые старшими суррогатами и младшими суррогатами соответственно, в терминологии Unicode, отображают 1024×1024 или 1 048 576 дополнительных символов, что составляет 1 112 064 (63 488 кодовых точек BMP + 1 048 576 кодовых точек, представленных старшими и младшими суррогатными парами) кодируемых кодовых точек. или скалярные значения в языке Юникода (суррогатные значения не кодируются).
См. также [ править ]
- wchar_t широкие символы
- Набор многобайтовых символов Lotus (LMBCS)
- Трехбайтовый набор символов (TBCS)
- Двухбайтовый набор символов (DBCS)
- Набор однобайтовых символов (SBCS)
Примечания [ править ]
- ^ Однако эта концепция задолго до появления электронного компьютера, как видно из азбуки Морзе .
- ^ В качестве реального примера можно привести UTF-16 , которая представляет наиболее распространенные символы именно так, как только что описано (и использует пары 16-битных кодовых единиц для менее распространенных символов), так и не получила распространения в качестве кодировки текста. предназначен для обмена из-за его несовместимости с повсеместной 7-/8-битной кодировкой ASCII , а его предполагаемую роль вместо этого выполняет UTF-8 , который сохраняет совместимость ASCII.
- ^ В исходной версии UTF-8, с момента ее публикации в 1992 году до тех пор, пока ее кодовое пространство не было ограничено кодовым пространством UTF-16 в 2003 году, диапазон ведущих единиц, кодирующих конечные последовательности из трех единиц, был больше (F0 – F7); кроме того, за ведущими подразделениями F8–FB следовали четыре следящих подразделения, а за FC–FD – пять. FE – FF никогда не были допустимыми ведущими или конечными единицами ни в одной версии UTF-8.
Ссылки [ править ]
- ^ Криспин, М. (1 апреля 2005 г.). Эффективные форматы преобразования Unicode UTF-9 и UTF-18 . дои : 10.17487/rfc4042 .
