Блин, запутался совсем! Всегда считал, что Unicode-кодировка это просто 2 байта на символ. Причем существует только одна кодовая таблица, в которой содержаться алфавиты всех языков мира + еще всякие вспомогательные символы.

А тут еще всяки utf-7, utf-8... Это что за черти такие? Помогите разобраться

Здравствуйте, Аноним, Вы писали:

А>А тут еще всяки utf-7, utf-8... Это что за черти такие? Помогите разобраться

Здесь всё написано: http://www.unicode.org

Здравствуйте, Аноним, Вы писали:

А>Блин, запутался совсем! Всегда считал, что Unicode-кодировка это просто 2 байта на символ. Причем существует только одна кодовая таблица, в которой содержаться алфавиты всех языков мира + еще всякие вспомогательные символы.

А>А тут еще всяки utf-7, utf-8... Это что за черти такие? Помогите разобраться

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

Все символы пронумерованы, т.е. им сопоставлены числовые значения. Таблица нумерации называется UCS (Unicode Character Set): есть UCS-2 (емкостью до 2^16 символов) и UCS-4 (до 2^64 штук).
Естественно, что ASCII <= UCS-2 <= UCS-4, т.е. они включают друг друга.

Способы кодирования строки символов — варьируются.
Среди них стандартом зафиксированы кодировки UTF (Unicode Text Format)
* UTF-32: на один символ по 4 байта, что позволяет кодировать весь диапазон UCS-4 одним элементом. Т.е. сколько символов, столько и элементов в строке.
* UTF-16: на один символ по 2 байта. Достаточно для равномерного кодирования диапазона UCS-2; чтобы кодировать UCS-4 — используется мультиворд (по аналогии с мультибайтом): префиксное слово и до двух слов расширения.
* UTF-8: на один символ от 1 байта (в диапазоне ASCII, т.е. 0-127) до 3 байт (весь диапазон UCS-2) и даже до 5 байт (UCS-4).
* UTF-7: строка кодируется 7-битными элементами, причем даже для ASCII приходится потратить до 2 элементов. Весь UCS-4 кодируется то ли 7, то ли 9 элементами (не помню).

Зачем такое разнообразие?

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

UTF-8 удобен тем, что на ASCII тратится ровно 1 байт, при этом получается вполне читаемый текст. Это нормальная мультибайтная кодировка, и с кодированными строками можно работать как обычно (в том числе — с концевым 0), в отличие от UTF-16, UTF-32 (где каждый второй байт может быть 0).
Альтернатива UTF-8 — это текст HTML, где все символы за пределами ASCII кодируются знаком &#nnnnn;. Очевидно, что UTF-8 компактнее.

Еще одно удобство UTF-7 и UTF-8 — независимость от порядка байтов в слове. Об этом — ниже.

UTF-16 — его преимущество аналогично UTF-8: самый популярный диапазон, т.е. UCS-2, кодируется одним двухбайтным словом. Для экзотических кодовых страниц (за пределами UCS-2), конечно, придется повыкручиваться, но это редкость.
Большее (по сравнению с байтовыми кодировками) потребление памяти уравновешено большей скоростью обработки (мультибайт/мультиворд медленнее однобайта/одноворда).

UTF-32 — скорость обработки ставится на первое место, в ущерб памяти.

Теперь о порядке байтов.
Поскольку минимально адресуемая величина — это байт, то (особенно при записи в файл) окажется, что слово UTF-16 или UTF-32 можно записать 2 разными способами: младшими байтами вперед либо старшими:
0x1234 -> 0x12, 0x34 (big endian)
0x1234 -> 0x34, 0x12 (little endian)
Исторически сложилось, что в интернете используется big endian — из-за того, что компьютеры Digital Equipment (PDP, VAX) были более распространены.
А у Intel внутреннее представление little endian. (На мой взгляд, оно более логично; но когда создавался DEC, меня еще не было ). Соответственно, little endian — стандарт для Windows.

Для того, чтобы понять, как же закодирован (LE|BE) файл в UTF-16, который мы получили со стороны — в его начало приписывается специальный признак: число 0xFEFF.
Если кодировка little endian, то это будут байты 0xFF, 0xFE (по-русски — "яю").
Если big endian — 0xFE, 0xFF (соответственно, "юя").

Здравствуйте, Кодт, Вы писали:

Спасибо, добрый человек

Здравствуйте, Кодт, Вы писали:

То есть получается, что сами символы определяются в таблицах UCS, а закодировать любой из символов таблицы можно по-разному (UTF-32,16,8)?

Просто эффективность (количество байтов на символ) кодирования той или иной строки символов будет зависеть от выбранного способа представления (UTF-32, 16,8)?

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Кодт, Вы писали:

А>То есть получается, что сами символы определяются в таблицах UCS, а закодировать любой из символов таблицы можно по-разному (UTF-32,16,8)?

А>Просто эффективность (количество байтов на символ) кодирования той или иной строки символов будет зависеть от выбранного способа представления (UTF-32, 16,8)?

Именно так.
Эффективность = затраты памяти + удобство + скорость. В разных случаях главенствует то или иное.

Здравствуйте, Кодт, Вы писали:

К>Все символы пронумерованы, т.е. им сопоставлены числовые значения. Таблица нумерации называется UCS (Unicode Character Set): есть UCS-2 (емкостью до 2^16 символов) и UCS-4 (до 2^64 штук).
К>Естественно, что ASCII <= UCS-2 <= UCS-4, т.е. они включают друг друга.

Так все-таки есть единая таблица, включающая все символы всех алфавитов мира — UCS-4?

Здравствуйте, Кодт, Вы писали:

К>Все символы пронумерованы, т.е. им сопоставлены числовые значения. Таблица нумерации называется UCS (Unicode Character Set): есть UCS-2 (емкостью до 2^16 символов) и UCS-4 (до 2^64 штук).
К>Естественно, что ASCII <= UCS-2 <= UCS-4, т.е. они включают друг друга.

А зачем существует несколько таблиц? Разве нельpя было сделать только одну, самую "большую" — USC-4

Здравствуйте, Кодт, Вы писали:

К>Юникод — это свод значений (смыслов) и изображений всевозможных символов

"Смыслов" — в некотром роде да, "изображений" — нет.
См. стандарт 4.0.0 -> "General Structure" -> "Unicode Design Principles" -> "Characters, Not Glyphs".

К>UTF (Unicode Text Format)

На самом деле Unicode Transformation Format

Повторюсь — согласен, что это мелочи

Здравствуйте, Аноним, Вы писали:

К>>Естественно, что ASCII <= UCS-2 <= UCS-4, т.е. они включают друг друга.

А>А зачем существует несколько таблиц? Разве нельpя было сделать только одну, самую "большую" — USC-4

Существование "в природе" таблицы ASCII — данность.
Пока хватало 2^16 — заполняли UCS-2 (включив, естественно, ASCII в его состав).
Стало очевидно, что может не хватить — расширили до 2^32 — получился UCS-4.

Здравствуйте, Dimentiy, Вы писали:

К>>Юникод — это свод значений (смыслов) и изображений всевозможных символов

D>"Смыслов" — в некотром роде да, "изображений" — нет.
D>См. стандарт 4.0.0 -> "General Structure" -> "Unicode Design Principles" -> "Characters, Not Glyphs".

Да, извиняюсь. Начертание (глиф), естественно, не может стандартизироваться — это дело конкретных шрифтов или других изобразительных средств, если что-то вообще нужно изображать.

Здравствуйте, Кодт, Вы писали:

К>Существование "в природе" таблицы ASCII — данность.
К>Пока хватало 2^16 — заполняли UCS-2 (включив, естественно, ASCII в его состав).
К>Стало очевидно, что может не хватить — расширили до 2^32 — получился UCS-4.

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

Здравствуйте, Аноним, Вы писали:

А>А как осуществляется идентификация — какая таблица используется для представления документа. Ведь при использовании разных таблиц количество байт на символ будет разным

Наверное точнее будет сказать не "таблица", а "способ кодирования"...

Здравствуйте, Кодт, Вы писали:

К>Существование "в природе" таблицы ASCII — данность.
К>Пока хватало 2^16 — заполняли UCS-2 (включив, естественно, ASCII в его состав).
К>Стало очевидно, что может не хватить — расширили до 2^32 — получился UCS-4.
А когда выяснится, что мы не одни во вселенной, придется UCS-8 делать

Здравствуйте, Аноним, Вы писали:

К>>Существование "в природе" таблицы ASCII — данность.
К>>Пока хватало 2^16 — заполняли UCS-2 (включив, естественно, ASCII в его состав).
К>>Стало очевидно, что может не хватить — расширили до 2^32 — получился UCS-4.

А>А как осуществляется идентификация — какая таблица используется для представления документа. Ведь при использовании разных таблиц количество байт на символ будет разным

Пойми, это одна и та же таблица. Единственная.
Просто диапазоны номеров называются:
0-127 — ASCII
0-65535 — UCS-2
0-крендильон — UCS-4

Если символ имеет номер больше 65535, то в кодировке UTF-16 ему соответствует серия из 2-3 слов, а в UTF-8 — из 5 байт.

Здравствуйте, Кодт, Вы писали:

К>Пойми, это одна и та же таблица. Единственная.
К>Просто диапазоны номеров называются:
К>0-127 — ASCII
К>0-65535 — UCS-2
К>0-крендильон — UCS-4

Да, это я децл "оговорился". См. мой "поправочный" постинг

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, Аноним, Вы писали:

К>* UTF-7: строка кодируется 7-битными элементами, причем даже для ASCII приходится потратить до 2 элементов. Весь UCS-4 кодируется то ли 7, то ли 9 элементами (не помню).

Это не так. UTF-7 — очень сцепифическая кодировка.

В отличие от UTF-8 и UTF-16, символам не сопоставлены однозначные последовательности байтов (слов).

Используется только некоторое подмножество кодов ASCII (не используются "~", "\", что-то еще — не помню). Исходное состояние потока таково: символы этого подмножества, кроме "+" представляют сами себя. Символ "+" переводит поток в состояние кодирования: последовательность символов из набора UCS-2 или UCS-4 представляется сперва в кодировке UTF-16 (возможно, с применением суррогатов), затем полученная последовательность байтов кодируется алгоритмом BASE64. Признак конца такой последовательности и перехода в исходное состояние — символ "-". Сочетание "+-" обозначает сам символ "+".

Здравствуйте, Аноним, Вы писали:

А>Это не так. UTF-7 — очень сцепифическая кодировка.

А>В отличие от UTF-8 и UTF-16, символам не сопоставлены однозначные последовательности байтов (слов).

А>Используется только некоторое подмножество кодов ASCII (не используются "~", "\", что-то еще — не помню). Исходное состояние потока таково: символы этого подмножества, кроме "+" представляют сами себя. Символ "+" переводит поток в состояние кодирования: последовательность символов из набора UCS-2 или UCS-4 представляется сперва в кодировке UTF-16 (возможно, с применением суррогатов), затем полученная последовательность байтов кодируется алгоритмом BASE64. Признак конца такой последовательности и перехода в исходное состояние — символ "-". Сочетание "+-" обозначает сам символ "+".

Ух ты ж елы палы! А я, не найдя документации по UTF-7, не смог самостоятельно догадаться, что это за чача.

К>Исторически сложилось, что в интернете используется big endian — из-за того, что компьютеры Digital Equipment (PDP, VAX) были более распространены.

Мне приходилось видеть DECовские машины с весьма близкого расстояния и я вас уверяю: внутреннее представление байт в них little endian

К>А у Intel внутреннее представление little endian. (На мой взгляд, оно более логично; но когда создавался DEC, меня еще не было ).

К>>Существование "в природе" таблицы ASCII — данность.
К>>Пока хватало 2^16 — заполняли UCS-2 (включив, естественно, ASCII в его состав).
К>>Стало очевидно, что может не хватить — расширили до 2^32 — получился UCS-4.

А>А как осуществляется идентификация — какая таблица используется для представления документа. Ведь при использовании разных таблиц количество байт на символ будет разным

А никак. Разработчиков стандарта это не заботит. Так же как и обратная совместимость.

Вообще-то мне очень не верится, что для представления всех символов недостаточно 2-х байт

Здравствуйте, Аноним, Вы писали:

К>>Исторически сложилось, что в интернете используется big endian — из-за того, что компьютеры Digital Equipment (PDP, VAX) были более распространены.

А>Мне приходилось видеть DECовские машины с весьма близкого расстояния и я вас уверяю: внутреннее представление байт в них little endian

Да, приношу извинения за напраслину в адрес DEC.

Интересно, а с чьей тогда подачи в интернете принят big endian? Sun, что ли?

Hello, Кодт!
You wrote on Tue, 07 Oct 2003 13:18:41 GMT:

К>>> Исторически сложилось, что в интернете используется big endian — из-за
К>>> того, что компьютеры Digital Equipment (PDP, VAX) были более
К>>> распространены.

А>> Мне приходилось видеть DECовские машины с весьма близкого расстояния и
А>> я вас уверяю: внутреннее представление байт в них little endian

К> Да, приношу извинения за напраслину в адрес DEC.

К> Интересно, а с чьей тогда подачи в интернете принят big endian? Sun, что
К> ли?

Не помню, с чего СМ-2М драли (вроде HP какой-то), но там точно был big endian



Best regards,
Sergey.

Здравствуйте, Кодт, Вы писали:

К>Ух ты ж елы палы! А я, не найдя документации по UTF-7, не смог самостоятельно догадаться, что это за чача.

Найти оное никаких проблем:
ftp://ftp.rfc-editor.org/in-notes/rfc2152.txt