Один и тот же символ может иметь несколько форм; в Юникод эти формы входят одной кодовой позицией:
- если это сложилось исторически. Например, у арабских букв есть четыре формы: обособленная, в начале, в середине и в конце[34];
- либо если в одном языке принята одна форма, а в другом — другая. Болгарская кириллица отличается от русской, а китайские иероглифы — от японских.
С другой стороны, если исторически в шрифтах были две разных кодовых позиции, они остаются разными и в Юникоде. Строчная греческая сигма имеет две формы, и у них разные позиции. Буква расширенной латиницы A (A с кружком) и знакангстрема A, греческая буква ? и обозначение приставки «микро-» µ — разные символы.
Конечно же, похожие символы в неродственных письменностях ставятся в разные кодовые позиции. Например, буква А в латинице, кириллице, греческом и чероки — разные символы.
Крайне редко один и тот же символ ставится в две разные кодовые позиции для упрощения обработки текста. Математический штрих и такой же штрих для индикации мягкости звуков — разные символы, второй считается буквой.
Модифицирующие символы
Представление символа «Й» (U+0419) в виде базового символа «И» (U+0418) и модифицирующего символа « ?» (U+0306)
Графические символы в Юникоде подразделяются на протяжённые и непротяжённые (бесширинные). Непротяжённые символы при отображении не занимают места в строке. К ним относятся, в частности, знаки ударения и прочие диакритические знаки. Как протяжённые, так и непротяжённые символы имеют собственные коды. Протяжённые символы иначе называются базовыми (англ. base characters), а непротяжённые — модифицирующими (англ. combining characters); причём последние не могут встречаться самостоятельно. Например, символ «a» может быть представлен как последовательность базового символа «a» (U+0061) и модифицирующего символа « ?» (U+0301) или как монолитный символ «a» (U+00E1).
Особый тип модифицирующих символов — селекторы варианта начертания (англ. variation selectors). Они действуют только на те символы, для которых такие варианты определены. В версии 5.0 варианты начертания определены для ряда математических символов, для символов традиционного монгольского алфавита и для символов монгольского квадратного письма.
Алгоритмы нормализации
Поскольку одни и те же символы можно представить различными кодами, сравнение строк байт за байтом становится невозможным. Алгоритмы нормализации (англ. normalization forms) решают эту проблему, выполняя приведение текста к определённому стандартному виду. Приведение осуществляется путём замены символов на эквивалентные с использованием таблиц и правил. «Декомпозицией» называется замена (разложение) одного символа на несколько составляющих символов, а «композицией», наоборот, — замена (соединение) нескольких составляющих символов на один символ.
В стандарте Юникода определены 4 алгоритма нормализации текста: NFD, NFC, NFKD и NFKC.
NFD
NFD, англ. normalization form D («D» от англ. decomposition), форма нормализации D — каноническая декомпозиция — алгоритм, согласно которому выполняется рекурсивная замена монолитных символов (англ. precomposed characters) на несколько составных (англ. composite characters) в соответствии с таблицами декомпозиции.
Примеры:
| A |
| U+00C5 |
| ? |
| U+1E69 |
| ?? | |
| U+1E0B | U+0323 |
| q?? | ||
| U+0071 | U+0307 | U+0323 |
NFC
NFC, англ. normalization form C («C» от англ. composition), форма нормализации C — алгоритм, согласно которому последовательно выполняются каноническая декомпозиция и каноническая композиция. Сначала каноническая декомпозиция (алгоритм NFD) приводит текст к форме D. Затем каноническая композиция — операция, обратная NFD, обрабатывает текст от начала к концу с учётом следующих правил:
- символ S считается начальным, если имеет класс модификации равный нулю согласно таблице символов Юникода;
- в любой последовательности символов, начинающейся с символа S, символ C блокируется от S, только если между S и C есть какой-либо символ B, который либо является начальным, либо имеет одинаковый или больший класс модификации, чем C. Это правило распространяется только на строки, прошедшие каноническую декомпозицию;
- символ считается первичным композитом, если имеет каноническую декомпозицию в таблице символов Юникода (или каноническую декомпозицию для хангыля и он не входит в список исключений);
- символ X может быть первично совмещён с символом Y, если и только если существует первичный композит Z, канонически эквивалентный последовательности ;
- если очередной символ C не блокируется последним встреченным начальным базовым символом L и он может быть успешно первично совмещён с ним, то L заменяется на композит L-C, а C удаляется.
Пример:
| o |
| U+006F |
NFKD
NFKD, англ. normalization form KD, форма нормализации KD — совместимая декомпозиция — алгоритм, согласно которому последовательно выполняются каноническая декомпозиция и замены символов текста по таблицам совместимой декомпозиции. Таблицы совместимой декомпозиции предусматривают замену на почти эквивалентные символов[35]:
- похожих на буквы (? и ?);
- обведённых кружками (?);
- с изменёнными размерами (ｶ и カ);
- повёрнутых (︷ и {);
- степеней (? и ?);
- дробей (¼);
- других (™).
Примеры:
| ? |
| U+210d |
| ? |
| U+2460 |
| ｶ |
| U+FF76 |
| ︷ |
| U+FE37 |
| ? |
| U+2079 |
| ¼ |
| U+00BC |
| ™ |
| U+2122 |
NFKC
NFKC, англ. normalization form KC, форма нормализации KC — алгоритм, согласно которому последовательно выполняются совместимая декомпозиция (алгоритм NFKD) и каноническая композиция (алгоритм NFC).
Примеры[править | править вики-текст]
| Исходный текст | NFD | NFC | NFKD | NFKC |
| fi |
| U+FB01 |
Двунаправленное письмо
Стандарт Юникод поддерживает письменности языков как с направлением написания слева направо (англ. 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).