Почему существует несколько кодировок Unicode?

Я думал, что Unicode был разработан, чтобы обойти всю проблему наличия множества различных кодировок из-за небольшого адресного пространства (8 бит) в большинстве предыдущих попыток (ASCII и т. Д.).

Почему тогда так много кодировок Юникода? Даже несколько версий (по сути) одного и того же, как UTF-8, UTF-16 и т. Д.

Потому что люди не хотят тратить 21 бит на каждого персонажа. Во всех современных системах это, по сути, означало бы использование трех байтов на символ, что в три раза больше, чем люди привыкли, поэтому они вообще не хотели принимать Unicode. Необходимо было найти компромиссы: например, UTF-8 отлично подходит для английского текста, потому что устаревшие файлы ASCII вообще не нужно конвертировать, но он менее полезен для европейских языков и мало используется для азиатских языков.

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

Unicode - это 21-битная кодировка символов, уникально описывающая «CodePoints», где каждая кодовая точка представлена ​​глифом (графическое представление).

• 16 битов, используемых для идентификации кодовой точки на плоскости (большинство кодовых точек на плоскости 0).
• 5 бит для определения плоскости.

Поддерживаемые кодировки:

• UTF-8 (для кодирования каждой точки с использованием 8-битных значений)
• UTF-16 (для кодирования каждой точки с использованием 16-битных значений)
• UTF-32 (для кодирования каждой точки с использованием 32-битных значений)

Но независимо от кодировки, когда вы декодируете, все они отображаются обратно на конкретную кодовую точку, которая имеет одинаковое значение (вот почему это круто).

• 'A' (U + 65)
  UTF-32 => 0x00000041 UTF-16 => 0x0041 UTF-8 => 0x41
• ЛАТИНСКАЯ МАЛЕНЬКАЯ ЛИГАТУРА OE '(U + 0153)
  UTF-32 => 0x00000153 UTF-16 => 0x0153 UTF-8 => 0xC5 0x93
• Неназначенный (U + 11153)
  UTF-32 => 0x00011153 UTF-16 => 0xD804 0xDD53 UTF-8 => 0xF0 0x91 0x85 0x93

UTF-8,

Это формат переменного размера. Где каждая кодовая точка представлена ​​от 1 до 4 байтов.

UTF-16

Это формат переменного размера. Кодовые точки в «Базовой многоязычной плоскости» (BMP или Plane 0) могут быть представлены одним одиночным 16-битным значением. Кодовые точки в других плоскостях представлены суррогатной парой (2 16-битные значения).

UTF-32

Это формат с фиксированным размером. Все кодовые точки представлены одним 32-битным значением.

Я думаю, что полезно разделить 2 идеи:

1. Unicode - отображение символов со всего мира на кодовые точки.
2. Кодирование - отображение кодовых точек на битовые комбинации (UTF-8, UTF-16 и т. Д.).

UTF-8, UTF-16 и другие кодировки имеют свои преимущества и недостатки. Об этом лучше проконсультироваться в Википедии .

UTF-7, UTF-8, UTF-16 и UTF-32 - это просто форматы алгоритмического преобразования одной и той же кодировки (кодовых точек) символов. Они являются кодировками одной системы кодификации символов.

Они также алгоритмически легче перемещаться вперед и назад, чем большинство предыдущих схем для работы с наборами символов, превышающими 256 символов.

Это сильно отличается от общей кодификации глифов в зависимости от страны, а иногда и от поставщика. В одном только японском языке было множество вариаций одного JIS, не говоря уже о EUC-JP и преобразовании JIS, ориентированном на кодовую страницу, которое использовали машины DOS / Windows, называемое Shift-JIS. (В некоторой степени они были алгоритмическими преобразованиями, но они не были особенно простыми, и существовали различия в зависимости от поставщиков в доступных символах. Умножьте это на пару сотен стран и постепенную эволюцию более сложных систем шрифтов (после «зеленого экрана») эра), и у вас был настоящий кошмар.

Зачем вам нужны эти формы преобразования Unicode? Поскольку во многих унаследованных системах использовались последовательности из 7-битных символов в диапазоне ASCII, вам нужно было 7-битное чистое решение для безопасной передачи данных через эти системы без искажений, поэтому вам понадобился UTF-7. Тогда были более современные системы, которые могли бы иметь дело с 8-битными наборами символов, но обычно нулевые значения имели для них особое значение, поэтому UTF-16 для них не работал. 2 байта могли закодировать всю базовую многоязычную плоскость Unicode в своем первом воплощении, поэтому UCS-2 казался разумным подходом для систем, которые собирались быть «осведомленными об Unicode с нуля» (например, Windows NT и Java VM); тогда расширения за этим требовали дополнительных символов, что привело к алгоритмическому преобразованию кодировок на 21 бит, которые были зарезервированы стандартом Unicode, и родились суррогатные пары; что потребовало UTF-16. Если у вас было какое-то приложение, в котором согласованность ширины символов была важнее, чем эффективность хранения, UTF-32 (когда-то назывался UCS-4) был вариантом.

UTF-16 - это единственная вещь, с которой трудно справиться, и это легко смягчается небольшим диапазоном символов, на которые влияет это преобразование, и тем фактом, что ведущие 16-битные последовательности находятся в совершенно отличном диапазоне от конечного 16-битные последовательности. Это также намного проще, чем пытаться двигаться вперед и назад во многих ранних восточноазиатских кодировках, где вам либо нужен конечный автомат (JIS и EUC) для работы с escape-последовательностями, либо потенциально вы можете вернуться назад на несколько символов, пока не найдете что-то гарантированное быть только ведущим байтом (Shift-JIS). UTF-16 имеет некоторые преимущества в системах, которые также могут эффективно передавать 16-битные последовательности.

Если вам не приходилось переживать десятки (сотни, действительно) различных кодировок, или вам не приходилось создавать системы, которые поддерживают несколько языков в разных кодировках, иногда даже в одном документе (например, WorldScript в более старых версиях MacOs), вы можете подумать форматов преобразования юникод как ненужная сложность. Но это значительно уменьшает сложность по сравнению с более ранними альтернативами, и каждый формат решает реальные технические проблемы. Они также действительно эффективно конвертируются между собой, не требуя сложных справочных таблиц.

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

Unicode был разработан, чтобы обойти всю проблему одного числа, представляющего много разных вещей в зависимости от используемой кодовой страницы. Числа 0 - 127 представляют одинаковые символы в любой кодовой странице Ansi. Это то, что также известно как диаграмма ASCII или набор символов. В кодовых страницах Ansi, которые допускают 256 символов, числа 128 - 255 представляют разные символы в разных кодовых страницах.

Например

• Число $ 57 представляет собой заглавную букву W во всех кодовых страницах, но
• Число $ EC представляет символ бесконечности на кодовой странице 437 (США), но "LATIN SMALL LETTER N WITH CEDILLA" на кодовой странице 775 (Балтика)
• Знак Cent номер 9B на кодовой странице 437, а номер 96 на кодовой странице 775

То, что сделал Unicode, это перевернуло все это с ног на голову. В Unicode нет «повторного использования». Каждое число представляет один уникальный символ. Число $ 00A2 в Unicode - это знак цента, а знак цента больше нигде в определении Unicode.

Почему тогда так много кодировок Юникода? Даже несколько версий (по сути) одного и того же, как UTF-8, UTF-16 и т. Д.

Нет нескольких версий одной и той же кодировки. Существует несколько кодировок одной и той же карты определения символов Unicode, и они были «изобретены» для администрирования в соответствии с требованиями к хранилищу для различного использования различных языковых плоскостей, которые существуют в Unicode.

Unicode определяет (или имеет пространство для определения) 4.294.967.295 уникальных символов. Если вы хотите сопоставить их с диском / памятью без каких-либо алгоритмических преобразований, вам нужно 4 байта на символ. Если вам нужно хранить тексты с символами из всех языковых плоскостей, то, вероятно, вам нужен UTF-32 (который представляет собой прямую 1-символьную 4-байтовую кодировку хранения определения Unicode).

Но вряд ли в каких-либо текстах используются символы всех языковых плоскостей. И тогда использование 4 байтов на символ кажется большой тратой. Особенно, если принять во внимание, что большинство языков на земле определены в рамках так называемой Базовой многоязычной плоскости (BMP): первые 65536 чисел определения Unicode.

И вот тут-то и появился UTF-16. Если вы используете только символы из BMP, UTF-16 будет очень эффективно хранить это, используя только два байта на символ. Он будет использовать больше байтов только для символов за пределами BMP. Различие между UTF-16LE (Little Endian) и UTF-16BE (Big Endian) действительно имеет отношение только к тому, как числа представляются в памяти компьютера (байтовый паттерн, A0означающий hex $ A0 или значение $ 0A).

Если ваш текст использует еще меньше разных символов, как большинство текстов на западноевропейских языках, вы захотите еще больше ограничить требования к хранению ваших текстов. Следовательно, UTF-8, который использует один байт для хранения символов, присутствующих в диаграмме ASCII (первые 128 чисел) и выбора из символов Ansi (вторые 128 чисел различных кодовых страниц). Он будет использовать только больше байтов для символов за пределами этого набора «наиболее часто используемых символов».

Итак, резюмируем:

• Юникод - это отображение символов на всех языках мира (и некоторых клингонов для загрузки), а затем некоторых (математических, музыкальных и т. Д.) Уникальных чисел.
• Кодировки - это алгоритмы, определенные для хранения текстов, использующих номера этой уникальной карты символов как можно более эффективно, учитывая «среднее использование» символов в текстах.

Юникод определяет карту между числами и символами. Однако, когда вы отправляете номер получателю, вам все равно нужно определить, как представлять этот номер. Вот для чего нужен UTF. Он определяет, как представлять число в потоке байтов.

Смысл UTF-32 прост: это самое простое представление кодовых точек Unicode. Так почему же не все в UTF-32? Две основные причины:

Одним из них является размер . UTF-32 требует 4 байта для каждого символа. Для текста, который использует только символы в основном многоязычном месте, это вдвое больше места, чем в UTF-16. Для английского текста это в 4 раза больше места, чем US-ASCII.

Главная причина - обратная совместимость . Каждая кодировка Unicode, отличная от «некодированной» UTF-32, была разработана для обратной совместимости с предшествующим стандартом.

• UTF-8: обратная совместимость с US-ASCII.
• UTF-16: обратная совместимость с UCS-2 (16-битный Unicode до того, как он был расширен за пределы BMP).
• UTF-7: обратная совместимость с не 8-битными чистыми почтовыми серверами.
• GB18030: обратная совместимость с кодировками GB2312 и GBK для китайского языка.
• UTF-EBCDIC: обратная совместимость с базовым латинским подмножеством EBCDIC.

Я думал, что Unicode был разработан, чтобы обойти всю проблему наличия множества различных кодировок

Так было и так было. Гораздо проще конвертировать между UTF-8, -16 и -32, чем иметь дело со старой системой сотен различных кодировок символов для разных языков и разных ОС.

Вы знаете, что zip-файл может сжать файл до гораздо меньшего размера (особенно текстовый), а затем распаковать его в идентичную копию исходного файла.

Алгоритм архивирования на самом деле имеет несколько различных алгоритмов с различными характеристиками на выбор: сохраненный (без сжатия), сжатый, уменьшенный (методы 1-4), имплозированный, токенизированный, дефлированный, Deflate64, BZIP2, LZMA (EFS), WavPack, PPMd, где он теоретически может попробовать все из них и выбрать лучший результат, но обычно просто пойти с дефлированным.

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