Один и тот же символ может иметь несколько форм; в Юникод эти формы входят одной кодовой позицией:
· если это сложилось исторически. Например, у арабских букв есть четыре формы: обособленная, в начале, в середине и в конце[34];
· либо если в одном языке принята одна форма, а в другом — другая. Болгарская кириллица отличается от русской, а китайские иероглифы — от японских.
С другой стороны, если исторически в шрифтах были две разных кодовых позиции, они остаются разными и в Юникоде. Строчная греческая сигма имеет две формы, и у них разные позиции. Буква расширенной латиницы Å (A с кружком) и знакангстрема Å, греческая буква μ и обозначение приставки «микро-» µ — разные символы.
Конечно же, похожие символы в неродственных письменностях ставятся в разные кодовые позиции. Например, буква А в латинице, кириллице, греческом и чероки — разные символы.
Крайне редко один и тот же символ ставится в две разные кодовые позиции для упрощения обработки текста. Математический штрих и такой же штрих для индикации мягкости звуков — разные символы, второй считается буквой.
Модифицирующие символы
Представление символа «Й» (U+0419) в виде базового символа «И» (U+0418) и модифицирующего символа «̆» (U+0306)
Графические символы в Юникоде подразделяются на протяжённые и непротяжённые (бесширинные). Непротяжённые символы при отображении не занимают места в строке. К ним относятся, в частности, знаки ударения и прочие диакритические знаки. Как протяжённые, так и непротяжённые символы имеют собственные коды. Протяжённые символы иначе называются базовыми (англ. base characters), а непротяжённые — модифицирующими (англ. combining characters); причём последние не могут встречаться самостоятельно. Например, символ «á» может быть представлен как последовательность базового символа «a» (U+0061) и модифицирующего символа «́» (U+0301) или как монолитный символ «á» (U+00E1).
Особый тип модифицирующих символов — селекторы варианта начертания (англ. variation selectors). Они действуют только на те символы, для которых такие варианты определены. В версии 5.0 варианты начертания определены для ряда математических символов, для символов традиционного монгольского алфавита и для символов монгольского квадратного письма.
Алгоритмы нормализации
Поскольку одни и те же символы можно представить различными кодами, сравнение строк байт за байтом становится невозможным. Алгоритмы нормализации (англ. normalization forms) решают эту проблему, выполняя приведение текста к определённому стандартному виду. Приведение осуществляется путём замены символов на эквивалентные с использованием таблиц и правил. «Декомпозицией» называется замена (разложение) одного символа на несколько составляющих символов, а «композицией», наоборот, — замена (соединение) нескольких составляющих символов на один символ.
В стандарте Юникода определены 4 алгоритма нормализации текста: NFD, NFC, NFKD и NFKC.
NFD
NFD, англ. n ormalization f orm D («D» от англ. d ecomposition), форма нормализации D — каноническая декомпозиция — алгоритм, согласно которому выполняется рекурсивная замена монолитных символов (англ. precomposed characters) на несколько составных (англ. composite characters) в соответствии с таблицами декомпозиции.
Примеры:
| → |
|
|
| → |
|
|
|
| → |
|
|
|
| → |
|
|
|
NFC
NFC, англ. n ormalization f orm C («C» от англ. c omposition), форма нормализации C — алгоритм, согласно которому последовательно выполняются каноническая декомпозиция и каноническая композиция. Сначала каноническая декомпозиция (алгоритм NFD) приводит текст к форме D. Затем каноническая композиция — операция, обратная NFD, обрабатывает текст от начала к концу с учётом следующих правил:
· символ S считается начальным, если имеет класс модификации равный нулю согласно таблице символов Юникода;
· в любой последовательности символов, начинающейся с символа S, символ C блокируется от S, только если между S и C есть какой-либо символ B, который либо является начальным, либо имеет одинаковый или больший класс модификации, чем C. Это правило распространяется только на строки, прошедшие каноническую декомпозицию;
· символ считается первичным композитом, если имеет каноническую декомпозицию в таблице символов Юникода (или каноническую декомпозицию для хангыля и он не входит в список исключений);
· символ X может быть первично совмещён с символом Y, если и только если существует первичный композит Z, канонически эквивалентный последовательности <X, Y>;
· если очередной символ C не блокируется последним встреченным начальным базовым символом L и он может быть успешно первично совмещён с ним, то L заменяется на композит L-C, а C удаляется.
Пример:
|
| → |
|
NFKD
NFKD, англ. n ormalization f orm KD, форма нормализации KD — совместимая декомпозиция — алгоритм, согласно которому последовательно выполняются каноническая декомпозиция и замены символов текста по таблицам совместимой декомпозиции. Таблицы совместимой декомпозиции предусматривают замену на почти эквивалентные символов[35]:
· похожих на буквы (ℍ и ℌ);
· обведённых кружками (①);
· с изменёнными размерами (ｶ и カ);
· повёрнутых (︷ и {);
· степеней (⁹ и ₉);
· дробей (¼);
· других (™).
Примеры:
| → |
|
| → |
|
| → |
|
| → |
|
| → |
|
| → |
|
| → |
|
NFKC
NFKC, англ. n ormalization f orm KC, форма нормализации KC — алгоритм, согласно которому последовательно выполняются совместимая декомпозиция (алгоритм NFKD) и каноническая композиция (алгоритм NFC).
Примеры [править | править вики-текст]
| Исходный текст | NFD | NFC | NFKD | NFKC | ||||||||||||||||||||||
|
|
|
|
| ||||||||||||||||||||||
|
|
|
|
| ||||||||||||||||||||||
|
|
|
|
| ||||||||||||||||||||||
|
|
|
|
| ||||||||||||||||||||||
|
|
|
|
| ||||||||||||||||||||||
|
|
|
|
| ||||||||||||||||||||||
|
|
|
|
| ||||||||||||||||||||||
|
|
|
|
| ||||||||||||||||||||||
|
|
|
|
|
Двунаправленное письмо
Стандарт Юникод поддерживает письменности языков как с направлением написания слева направо (англ. left-to-right, LTR), так и с написанием справа налево (англ. right-to-left, RTL) — например, арабское и еврейское письмо. В обоих случаях символы хранятся в «естественном» порядке; их отображение с учётом нужного направления письма обеспечивается приложением.
Кроме того, Юникод поддерживает комбинированные тексты, сочетающие фрагменты с разным направлением письма. Данная возможность называется двунаправленность (англ. bidirectional text, BiDi). Некоторые упрощённые обработчики текста (например, в сотовых телефонах) могут поддерживать Юникод, но не иметь поддержки двунаправленности. Все символы Юникода поделены на несколько категорий: пишущиеся слева направо, пишущиеся справа налево, и пишущиеся в любом направлении. Символы последней категории (в основном это знаки пунктуации) при отображении принимают направление окружающего их текста.
Представленные символы
Схема основной мультиязычной плоскости Юникода
Основная статья: Символы, представленные в Юникоде
Юникод включает практически все современные письменности, в том числе:
· арабскую,
· армянскую,
· бенгальскую,
· бирманскую,
· глаголицу,
· греческую,
· грузинскую,
· деванагари,
· еврейскую,
· кириллицу,
· китайскую (китайские иероглифы активно используются в японском языке, а также изредка в корейском),
· коптскую,
· кхмерскую,
· латинскую,
· тамильскую,
· корейскую (хангыль),
· чероки,
· эфиопскую,
· японскую (которая включает в себя, кроме слоговой азбуки, ещё и китайские иероглифы)
и другие.
С академическими целями добавлены многие исторические письменности, в том числе: германские руны, древнетюркские руны, древнегреческая письменность, египетские иероглифы, клинопись, письменность майя, этрусский алфавит.
В Юникоде представлен широкий набор математических и музыкальных символов, а также пиктограмм.
В Юникод принципиально не включаются государственные флаги, логотипы компаний и продуктов, хотя они и встречаются в шрифтах (например, логотип Apple в кодировке MacRoman (0xF0) или логотип Windows в шрифте Wingdings (0xFF)). В юникодовских шрифтах логотипы должны размещаться только в области пользовательских символов.
ISO/IEC 10646
Консорциум Юникода работает в тесной связи с рабочей группой ISO/IEC/JTC1/SC2/WG2, которая занимается разработкой международного стандарта 10646 (ISO/IEC 10646). Между стандартом Юникода и ISO/IEC 10646 установлена синхронизация, хотя каждый стандарт использует свою терминологию и систему документации.
Сотрудничество Консорциума Юникода с Международной организацией по стандартизации (англ. International Organization for Standardization, ISO) началось в 1991 году. В 1993 году ISO выпустила стандарт DIS 10646.1. Для синхронизации с ним Консорциум утвердил стандарт Юникода версии 1.1, в который были внесены дополнительные символы из DIS 10646.1. В результате значения закодированных символов в Unicode 1.1 и DIS 10646.1 полностью совпали.
В дальнейшем сотрудничество двух организаций продолжилось. В 2000 году стандарт Unicode 3.0 был синхронизирован с ISO/IEC 10646-1:2000. Предстоящая третья версия ISO/IEC 10646 будет синхронизирована с Unicode 4.0. Возможно, эти спецификации даже будут опубликованы как единый стандарт.
Аналогично форматам UTF-16 и UTF-32 в стандарте Юникода, стандарт ISO/IEC 10646 также имеет две основные формы кодирования символов: UCS-2 (2 байта на символ, аналогично UTF-16) и UCS-4 (4 байта на символ, аналогично UTF-32). UCS значит универсальный многооктетный (многобайтовый) кодированный набор символов (англ. universal multiple-octet coded character set). UCS-2 можно считать подмножеством UTF-16 (UTF-16 без суррогатных пар), а UCS-4 является синонимом для UTF-32.
Отличия стандартов Юникод и ISO/IEC 10646:
· небольшие различия в терминологии;
· ISO/IEC 10646 не включает разделы, необходимые для полноценной реализации поддержки Юникода:
· нет данных о двоичном кодировании символов;
· нет описания алгоритмов сравнения (англ. collation) и отрисовки (англ. rendering) символов;
· нет перечня свойств символов (например, нет перечня свойств, необходимых для реализации поддержки двунаправленного (англ. bi-directional) письма).
Способы представления
Юникод имеет несколько форм представления (англ. Unicode transformation format, UTF): UTF-8, UTF-16 (UTF-16BE, UTF-16LE) и UTF-32 (UTF-32BE, UTF-32LE). Была разработана также форма представления UTF-7 для передачи по семибитным каналам, но из-за несовместимости с ASCII она не получила распространения и не включена в стандарт. 1 апреля 2005 года были предложены две шуточные формы представления: UTF-9 и UTF-18 (RFC 4042).
В Microsoft Windows NT и основанных на ней системах Windows 2000 и Windows XP в основном используется форма UTF-16LE. В UNIX-подобных операционных системах GNU/Linux, BSD и Mac OS X принята форма UTF-8 для файлов и UTF-32 или UTF-8 для обработки символов в оперативной памяти.
Punycode — другая форма кодирования последовательностей Unicode-символов в так называемые ACE-последовательности, которые состоят только из алфавитно-цифровых символов, как это разрешено в доменных именах.
UTF-8
Основная статья: UTF-8
UTF-8 — представление Юникода, обеспечивающее наилучшую совместимость со старыми системами, использовавшими 8-битные символы. Текст, состоящий только из символов с номером меньше 128, при записи в UTF-8 превращается в обычный текст ASCII. И наоборот, в тексте UTF-8 любой байт со значением меньше 128 изображает символ ASCII с тем же кодом. Остальные символы Юникода изображаются последовательностями длиной от 2 до 6 байт (на деле, только до 4 байт, поскольку в Юникоде нет символов с кодом больше 10FFFF, и вводить их в будущем не планируется), в которых первый байт всегда имеет вид 11xxxxxx, а остальные — 10xxxxxx. В UTF-8 не используются суррогатные пары, 4 байтов достаточно для записи любого символа юникода.
Формат UTF-8 был изобретён 2 сентября 1992 года Кеном Томпсоном и Робом Пайком и реализован в Plan 9[36]. Сейчас стандарт UTF-8 официально закреплён в документах RFC 3629 и ISO/IEC 10646 Annex D.
Символы UTF-8 получаются из Unicode следующим образом:
Unicode UTF-8:
0x00000000 — 0x0000007F: 0xxxxxxx
0x00000080 — 0x000007FF: 110xxxxx 10xxxxxx
0x00000800 — 0x0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx
0x00010000 — 0x001FFFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
Теоретически возможны, но не включены в стандарт также:
0x00200000 — 0x03FFFFFF: 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
0x04000000 — 0x7FFFFFFF: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
Несмотря на то, что UTF-8 позволяет указать один и тот же символ несколькими способами, только наиболее короткий из них правильный. Остальные формы должны отвергаться по соображениям безопасности.
Порядок байтов
В потоке данных UTF-16 младший байт может записываться либо перед старшим (англ. UTF-16 little-endian), либо после старшего (англ. UTF-16 big-endian). Аналогично существует два варианта четырёхбайтной кодировки — UTF-32LE и UTF-32BE.
Для определения формата представления Юникода в начало текстового файла записывается сигнатура — символ U+FEFF (неразрывный пробел с нулевой шириной), также именуемый маркером последовательности байтов (англ. byte order mark (BOM)). Это позволяет различать UTF-16LE и UTF-16BE, поскольку символа U+FFFE не существует. Также этот способ иногда применяется для обозначения формата UTF-8, хотя к этому формату и неприменимо понятие порядка байтов. Файлы, следующие этому соглашению, начинаются с таких последовательностей байтов:
UTF-8
EF BB BF
UTF-16BE
FE FF
UTF-16LE
FF FE
UTF-32BE
00 00 FE FF
UTF-32LE
FF FE 00 00
К сожалению, этот способ не позволяет надёжно различать UTF-16LE и UTF-32LE, поскольку символ U+0000 допускается Юникодом (хотя реальные тексты редко начинаются с него).
Файлы в кодировках UTF-16 и UTF-32, не содержащие BOM, должны иметь порядок байтов big-endian (unicode.org).
