(◕‿◕) SYMBL

UAX 44. Unicode Character Database

Это вольный пересказ оригинального документа, находящегося по адресу http://www.unicode.org/reports/tr44/tr44-16.html.
UAX 44 является частью технических приложений.

Здесь описывается База Данных Юникода (Unicode Character Database), в дальнейшем UCD.

Обратите внимание: этот документ не является исчерпывающим описанием того, как обрабатывать символы и интерпретировать их свойства. Его следует использовать совместно со стандартом Юникода и другими приложениями, в том числе файлами, хранящимися в самой UCD.

1. Введение

Стандарт Юникода, это нечто большее чем простая кодировка. Он также содержит большое количество семантических данных, которые необходимы для правильной работы совместимых с Юникодом реализаций. Основной тип этих данных — свойства (properties) символов.

Все эти данные собраны в базе данных UCD, которая является набором файлов, содержащих кодовые позиции символов и соответствующие им характеристики.

Этот документ описывает UCD и предоставляет путеводитель по связанным с ней документам. Дополнительная информация содержится в стандарте Unicode и его приложениях.

Последняя версия UCD находится здесь: http://www.unicode.org/Public/UCD/latest/.

2. Описание

UCD — неотъемлемая часть Стандарта Юникода.

UCD описывает свойства символов и другую информацию, которая требуется для реализаций алгоритмов обработки Юникод-текста, таких, как алгоритм двунаправленного вывода, нормализации и других. Спецификация каждого алгоритма, описанного в Стандарте или в приложении к нему, указывает какие файлы UCD требуются для его правильной работы.

2.1. Простые и производные свойства

Свойства могут быть простыми (simple) или производными (derived).

Значение простого свойства не зависит от других свойств. Оно такое, каким явно определено.

Значение производного свойства может быть вычислено из набора других свойств по определённым правилам. Эти правила могут быть достаточно сложными, а также включать в себя списки исключений для конкретных символов. Этот тип свойств введен в целях упрощения алгоритмов. Приложениям не рекомендуется самостоятельно вычислять значения производных свойств на основе простых. В целях исключения конфликтов следует брать значения этих свойств из UCD как есть. Если при вычислении какого-либо производного свойства, результат получается отличным от указанного в UCD, верным считается вариант UCD.

Кроме того, есть определённый подтип простых свойств — contributory. Эти свойства, в принципе, могут быть вычислены по некоторым правилам, но в целях стабильности они введены явно, как простые свойства.

2.2. Значения по умолчанию

Свойства символов имеют значения по умолчанию.

Значения по умолчанию принимают свойства неназначенных (unassigned) кодовых позиций. Или, в некоторых случаях, эти значения указываются для диапазонов кодов. Кроме того, например, бинарные свойства (см. ниже) всегда имеют значение по умолчанию «N».

Подробности см. в разделе 3.5 Стандарта.

2.3. Стабильность

Также, как и весь стандарт Юникода, каждая версия UCD с момента публикации является абсолютно стабильной и никогда не меняется. Каждая версия доступна на сайте Юникода по своему уникальному адресу. Все ошибки, обнаруженные в текущей версии UCD, помечаются и могут быть исправлены в последующих версиях UCD.

2.3.1. Изменение свойств между релизами

Изменение свойств символов может потребоваться по следующим причинам:

При добавлении новых символов в стандарт.
При добавлении в стандарт новых свойств символов.
Изменение уже существующего свойства у уже существующего символа.

Хотя Юникод всеми силами пытается сохранить стабильность свойст, в некоторых случаях может потребоваться их изменение. Например, в случае редких или древних языков, может так случиться, что на момент их добавления некоторые характеристики символов могут быть неизвестны. В дальнейшем, при получении новой информации, значения свойств могут быть скорректированы.

2.3.2. Устаревшие свойства

В некоторых случаях свойство может быть признано устаревшим (obsolete). Например, ISO_Comment раньше использовалось для связи с кодировкой ISO/IEC 10646. С версии 5.2.0 это свойство стало устаревшим и его значение теперь всегда пустая строка.

Устаревшие свойства никогда не будут удалены из UCD.

2.3.3. Нерекомендуемые

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

Такие свойства также никогда не будут удалены из UCD.

Список таких свойств:

Свойство        С версии  Почему 
Grapheme_Link   5.0.0     дублировало ccc=9
Hypen           6.0.0     вытеснено Line_Break
ISO_Comment     6.0.0     нет необходимости
Expands_On_NFC  6.0.0     лучше использовать вычисления для каждого из UTF
Expands_On_NFD  6.0.0     аналогично
Expands_On_NFKC 6.0.0     аналогично
Expands_On_NFKD 6.0.0     аналогично
FC_NFKC_Closure 6.0.0     вытеснено NFKC_Casefold

2.3.4. Стабилизированные свойства

Ещё один вариант для устаревшего свойства — быть объявленным стабилизированным (stabilized). Это значит, что значения этого свойства заморожены на тот момент, когда оно было признано стабилизированным. Оно не будет распространятся на новые символы, которые будут введены в следующих версиях.

Свойства    С версии
Hypen       4.0.0
ISO_Comment 6.0.0

3. Документация

Основное описание UCD находится здесь, но дополнительная информация также может содержаться в других частях стандарта, а также в файлах внутри UCD.

3.1. Свойства символов в Стандарте

Формальное определение, связанных с символами свойств содержится в Стандарте, раздел 3.5 (Свойства). Понимание приведённого там определения и терминологии важно для правильного использование свойств.

Также обратите внимание на главу 4, особенно на раздел 4.1.

3.2. Модель свойств

Для подробностей см. UTR #23. Этот документ является информативным, но за время его существования многие его части были перенесены в нормативные документы, в частности в главу 3 Стандарта.

Также там обсуждается связь строковых функций со свойствами символов.

3.3. NamesList.html

NamesList.html описывает формат файла NamesList.txt в формальных терминах BNF. Этот файл используется для форматированного отображения списков символов и их названий.

3.4 StandardizedVariants.html

StandardizedVariants.html описывает стандартизированные варианты. StandardizedVariants.txt же делает тоже самое, но уже формально.

3.5 Unihan и UAX #38

UAX #38 описывает структуру базы данных Unihan, которая содержит свойства CJK (Китай-Япония-Корея) иероглифов.

3.6 U-Source иероглифы и UAX #45

UAX #45 описывает формат файла USourceData.txt, который содержит информацию о U-Source иероглифах.

3.7 Комментарии в файлах

В дополнении к этой спецификации, сами файлы данных могут содержать комментарии в которых описывается их структура.

3.8 Устаревшие файлы документации

UCD.html раньше был основным файлом документации для UCD. С версии 5.2.0 его содержимое включено в текущий документ.

Содержимое Unihan.html с версии 5.1.0 включено в UAX #38.

Старые версии (до 4.0.0) содержали несколько небольших файлов (UnicodeCharacterDatabase.html, PropList.html, DerivedProperties.html). Впоследствии они были включены в UCD.html.

4. Файлы UCD

Основа UCD — файлы данных. Здесь описываются их форматы и структура каталога.

4.1. Структура каталога

Каждая версия UCD хранится в своём пронумерованном каталоге в директории Public сайта unicode.org. Структура и содержимое конкретных версий после публикации не меняется, они всегда доступны по неизменному адресу. Например, база для версии 8.0.0 доступна по адресу http://www.unicode.org/Public/8.0.0/.

Последняя версия также доступна по адресу http://www.unicode.org/Public/UCD/latest/.

4.1.1 UCD файлы

Сами UCD файлы находятся в подкаталоге ucd (внутри нумерованного каталога, соответствующего версии стандарта).

Имена файлов не изменяются от версии к версии.

Файлы, содержащие значения производных (derived) свойств, находятся в подкаталоге extracted.

В подкаталоге auxiliary находятся вспомогательные файлы, связанные с UAX29 и UAX14, а также данные для тестирования, описанных там алгоритмов.

4.1.2 XML-файлы

XML-версия базы хранится в каталоге ucdxml на одном уровне с каталогом ucd.

4.1.3 Таблицы

Таблицы символов хранятся в едином большом PDF-файле и каталоге charts на одном уровне с каталогом ucd.

4.1.4 Предварительные файлы

До официального релиза какой-либо версии Юникода, предварительные файлы этого релиза хранятся в таком же каталоге, соответствующим будущей версии. Также там могут хранится временные файлы, а имена файлов могут включать в себя номера внутренних версий, например, PropList-5.2.0d13.txt.

4.1.5 Отличия в более ранних версиях

В более ранних версиях, структура каталога могла отличаться.

4.2. Соглашения о форматах файлов.

UCD-файлы используют описанный здесь формат (если не указано иное).

4.2.1. Поля данных

Каждая строка данных содержит поля, разделённые точкой с запятой. Поля нумеруются с нуля.
Первое поле (0) каждой строки содержит код символа или диапазон. Остальные поля связываются с этим кодом.
Крайние пробельные символы в строке не имеют значения. Но для совместимости лучше их не допускать.
Файлы данных Unihan имеют отдельный формат, используя вместо точки запятой символ табуляции. См. UAX38.

4.2.2. Кодовые позиции и последовательности

Кодовая позиция обозначается 16-ричным числом от 4 до 6 цифр. Префикс «U+» не используется везде, за исключением Unihan.
Если поле содержит последовательность кодовых позиций, они отделяются пробелом.

4.2.3. Диапазоны

Диапазон указывается как «X..Y».
Каждая кодовая позиция в диапазоне получает указанные для него значения свойств: 0000..007F; Basic Latin (для примера, Blocks.txt)
Для обратной совместимости, в UnicodeData.txt указывается первый и последний символ в следующем формате:

4E00;<CJK Ideograph, First>;Lo;0;L;;;;;N;;;;;
9FD5;<CJK Ideograph, Last>;Lo;0;L;;;;;N;;;;;

4.2.4. Комментарии

Для обозначения комментариев используется решётка (#, U+0023). Все символы, начиная с этого знака и до конца строки считаются комментариями.

Во многих файлах, комментарии имеют общий формат. Например, фрагмент Scripts.txt:

09B2          ; Bengali # Lo       BENGALI LETTER LA

Здесь для символа (код 09B2) в комментариях указано название и значение свойства General_Category.

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

4.2.5. Метки кодовых позиций

Суррагатные пары, символы для частного использования, управляющие коды, не-символы и нераспределённые кодовые позиции не имеют имён. Комментарии к этим кодовым позициям, вместо имени содержат метки, как показано ниже:

2065          ; Default_Ignorable_Code_Point # Cn       <reserved-2065>

В треугольных скобках указывается «тег» (см. ниже) и после «-» — код.

Тег           General_Category   Комментарий
reserved       Cn                 Noncharacter_Code_Point=F
noncharacter   Cn                 Noncharacter_Code_Point=T
control        CC
private-use    Co
surrogate      Cs

4.2.6. Множественные свойства в одном файле

Если файл содержит описание множественных свойств, второе поле содержит имя свойства, а третье его значение:

03D2  ; FC_NFKC; 03C5           # L&  GREEK UPSILON WITH HOOK SYMBOL
03D3  ; FC_NFKC; 03CD           # L&  GREEK UPSILON WITH ACUTE AND HOOK SYMBOL

4.2.7. Бинарные свойства

Для бинарных свойств, указание имени свойства означает его установку в True. Таким образом в файле указываются только свойства со значением «Y» (что означает True). Например, в PropList.txt:

1680       ; White_Space # Zs      OGHAM SPACE MARK
2000..200A ; White_Space # Zs [11] EN QUAD..HAIR SPACE

4.2.8. Множественные значения свойств

Если указываемое свойство может содержать несколько значений для одной кодовой позиции, эти значения указываются разделённым пробелами списком:

0640          ; Arab Mand Mani Phlp Syrc # Lm       ARABIC TATWEEL

В некоторых случаях (но не всегда) порядок внутри такого списка может иметь значение. В этом случае порядок документируется в том же файле.

4.2.9. Значения по умолчанию

Записи о значениях конкретных свойств для конкретных кодовых позиций могут быть опущены. В этом случае они принимаются равными значению по умолчанию.
Для строковых свойств, значение по умолчанию равняется кодовой позиции.
Для смешанных (miscellaneous) свойств, которые могут принимать строковое значение, значение по умолчанию — пустая строка.
Для любых бинарных свойств, значение по умолчанию — «N».
Для перечисляемых (enumerated) и списочных (catalog) свойств значения по умолчанию описывается в комментариях.

#  All code points not explicitly listed for Script
#  have the value Unknown (Zzzz).

Несколько перечиляемых свойств имеют множественные значения по умолчанию. В этом случае комментарии указывают диапазоны для каждого значения.
См. также ниже описание директивы @missing.
Из соображений совместимости, файл UnicodeData.txt не содержит информации о значениях по умолчанию. Вот они:

Свойство                  Значение по умолчанию
Age                            unassigned
Bidi_Class                    L, AL, R, BN, ET
Block                        No_Block
Canonical_Combining_Class    Not_Reordered (= 0)
Decomposition_Type            None
East_Asian_Width            Neutral (= N), Wide (= W)
General_Category            Cn
Line_Break                    Unknown (= XX), ID, PR
Numeric_Type                None
Numeric_Value                NaN
Script                        Unknown (= Zzzz)

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

BidiClass — комплексное значение. См. UAX #9.

East_Asian_Width принимает значение N (Neutral) для большинства кодовых позиций, но также принимает значение W (Wide) для нераспределённых (unassigned) позиций в блоках, связанных с CJK-иероглифами. См. UAX #11 и DerivedEastAsianWidth.txt.

Line_Break в большинстве случаев принимает значение Unknown. Для нераспределённых позиций в блоках CJK — значение ID. И значение PR для нераспределённых позиций блоке символов валют (Currency Symbols). См. UAX #14 и DerivedLineBreak.txt.

4.2.10. Директива @missing

Комментарий специального формата с ключевым словом «@missing» используется для определения значения по умолчанию некоего свойства для диапазона кодовых позиций, которые явно не определены в файле данных. Такие комментарии следуют определённму соглашению для того, чтобы быть машинно-читаемыми.

Такая строка начинается с символа начала комментария, «#», следующим за ним пробелом и ключевым словом «@missing». Затем двоеточие, пробел, диапазон и точка с запятой.

После чего строка обычно содержит список из одного или нескольких, разделённых точками с запятой, значениями по умолчанию. Например:

# @missing: 0000..10FFFF; Unknown

// @todo

4.2.11. Пустые поля

Файл UnicodeData.txt определяет для каждого символа значения многих свойств. Если какое-то из полей пустое, это означает, что соответствующее свойство принимает значение по умолчанию.

0022;QUOTATION MARK;Po;0;ON;;;;;N;;;;;

Отсюда следует, что у символа U+0022 поле Numeric_Value равняется NaN (не число), а Numeric_Type равно None.

В других файлах данных интерпретация пустых полей может отличаться. Например, DerivedNormalizationProps.txt:

00AA          ; NFKC_CF; 0061           # Lo       FEMININE ORDINAL INDICATOR
00AD          ; NFKC_CF;                # Cf       SOFT HYPHEN
00AF          ; NFKC_CF; 0020 0304      # Sk       MACRON

Свойство NFKC_Casefold символа U+00AD в этом случае равняется пустой строке. В то время как, строка для символа U+00AE не указана и для его свойства NFKC_Casefold используется значение по умолчанию.

4.2.12. Кодировка текста

Файлы данных используют UTF-8. Если не указано иное, то не-ASCII символы могут появляться только в комментариях.
Файлы Unihan используют UTF-8 в значениях полей.
Из соображений совместимости файл NamesList.txt кодировался в Latin-1 вплоть до версии 6.2. Теперь в нём используется UTF-8.
Тестовые файлы, вроде WordBreakTest.txt используют не-ASCII символы в качестве разделителей полей.

4.2.13. Переносы строк

Для переноса строк во всех файлах данных используется LF (не CRLF). При переносе на другие системы, эти символы могут быть автоматически изменены на те, что используются в данной системе. Убедитесь, что ваш редактор или парсер может корректно обрабатывать переносы строк, которые используются в вашей локальной копии файлов данных.

4.2.14. Другие соглашения

В некоторых файлах, начало тестовых сегментов указывается строкой, начинающейся со знака «@».

Например, NormalizationTest.txt:

@Part1 # Character by character test