Объединение и дублирование символов

Один и тот же символ может иметь несколько форм; в Юникод эти формы входят одной кодовой позицией:

· если это сложилось исторически. Например, у арабских букв есть четыре формы: обособленная, в начале, в середине и в конце^[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) в соответствии с таблицами декомпозиции.

Примеры:

U+00C5

→

U+0041

U+030A

ṩ

U+1E69

→

U+0073

U+0323

U+0307

ḍ̇
U+1E0B	U+0323

→

U+0064

U+0323

U+0307

q̣̇
U+0071	U+0307	U+0323

→

U+0071

U+0323

U+0307

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 удаляется.

Пример:

U+006F

U+0302

→

U+00F4

NFKD

NFKD, англ. n ormalization f orm KD, форма нормализации KD — совместимая декомпозиция — алгоритм, согласно которому последовательно выполняются каноническая декомпозиция и замены символов текста по таблицам совместимой декомпозиции. Таблицы совместимой декомпозиции предусматривают замену на почти эквивалентные символов^[35]:

· похожих на буквы (ℍ и ℌ);

· обведённых кружками (①);

· с изменёнными размерами (ｶ и カ);

· повёрнутых (︷ и {);

· степеней (⁹ и ₉);

· дробей (¼);

· других (™).

Примеры:

ℍ

U+210d

→

U+0048

①

U+2460

→

U+0031

ｶ

U+FF76

→

カ

U+30AB

︷

U+FE37

→

{

U+007B

⁹

U+2079

→

U+0039

U+00BC

→

	⁄
U+0031	U+2044	U+0034

™

U+2122

→

T	M
U+0054	U+004D

NFKC

NFKC, англ. n ormalization f orm KC, форма нормализации KC — алгоритм, согласно которому последовательно выполняются совместимая декомпозиция (алгоритм NFKD) и каноническая композиция (алгоритм NFC).

Примеры [править | править вики-текст]

Исходный текст

NFD

NFC

NFKD

NFKC

ﬁ

U+FB01

ﬁ

U+FB01

ﬁ

U+FB01

f	i
U+0066	U+0069

f	i
U+0066	U+0069

	⁵
U+0032	U+2075

	⁵
U+0032	U+2075

	⁵
U+0032	U+2075


U+0032	U+0035


U+0032	U+0035

ẛ̣
U+1E9B	U+0323

ſ	̣	̇
U+017F	U+0323	U+0307

ẛ	̣
U+1E9B	U+0323

s	̣	̇
U+0073	U+0323	U+0307

ṩ

U+1E69

U+0439

и	̆
U+0438	U+0306

U+0439

и	̆
U+0438	U+0306

U+0439

U+0451

е	̈
U+0435	U+0308

U+0451

е	̈
U+0435	U+0308

U+0451

U+0410

が

U+304C

か	゙
U+304B	U+3099

が

U+304C

か	゙
U+304B	U+3099

が

U+304C

Ⅷ

U+2167

Ⅷ

U+2167

Ⅷ

U+2167

V	I	I	I
U+0056	U+0049	U+0049	U+0049

V	I	I	I
U+0056	U+0049	U+0049	U+0049

U+00E7

c	̧
U+0063	U+0327

U+00E7

c	̧
U+0063	U+0327

U+00E7

Двунаправленное письмо

Стандарт Юникод поддерживает письменности языков как с направлением написания слева направо (англ. 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).