UTF-8(7)

ИМЯ
UTF-8 - ASCII-совместимая многобайтовая юникодная кодировка

ОПИСАНИЕ
Набор символов Unicode 3.0 занимает 16-битное кодовое пространство. Наиболее распространённая юникодная кодировка, известная как UCS-2, содержит последовательности 16-битных слов. Закодированные таким образом строки могут состоять из частей 16-битных символов например, '\0' или '/', которые имеют специальное значение в именах файлов и других параметрах функций библиотеки языка Си. Кроме того, большинство утилит UNIX предназначено для обработки ASCII-файлов и не может воспринимать 16-битные слова как символы. По этим причинам UCS-2 является неподходящей кодировкой Юникода для имён файлов, текстовых файлов, переменных окружения и т.д. Набор ISO Universal Character Set (UCS), расширенный набор Юникода, занимает более 31-битного кодового пространства, а используемая для него кодировка UCS-4 (последовательность 32-битных слов) имеет те же недостатки, что и описанные выше.

Кодировка UTF-8 для представления Юникода и UCS лишена этих недостатков и поэтому в UNIX-подобных операционных системах используется наиболее часто.

  Свойства
Кодировка UTF-8 обладает следующими полезными свойствами:

*   UCS-символы с кодами от 0x00000000 до 0x0000007f (стандартный набор US-ASCII) кодируются как байты с кодами от 0x00 до 0x7f (для совместимости с кодовой таблицей ASCII). Это означает, что файлы и строки, содержащие только 7-битные ASCII-символы, будут иметь одинаковое представление как в ASCII так и в UTF-8.

*   Все UCS-символы с кодами больше чем 0x7f кодируются как многобайтовые последовательности, содержащие только байты в диапазоне от 0x80 до 0xfd, так что ASCII-байты не могут оказаться частью другого символа и, как следствие, не будет проблем с использованием '\0' или '/'.

*   Сохраняется лексикографический порядок сортировки строк как в кодировке UCS-4.

*   При помощи UTF-8 могут быть закодированы все 2^31 значения UCS.

*   В кодировке UTF-8 никогда не используются байты с кодами 0xc0, 0xc1, 0xfe и 0xff.

*   Первый байт многобайтовой последовательности, представляющей один не ASCII UCS-символ, всегда находится в диапазоне от 0xc2 до 0xfd и указывает на длину многобайтовой последовательности. Все последующие байты в многобайтовой последовательности находятся в диапазоне от 0x80 до 0xbf. Это позволяет облегчить ресинхронизацию, устраняет необходимость учитывать состояние кодировки (statelessness) и делает кодировку независимой от пропущенных байтов.

*   Символы UCS, закодированные в UTF-8, могут занимать до шести байтов, однако в стандарте Юникода не определены символы выше 0x10ffff, поэтому в UTF-8 юникодные символы могут иметь максимальный размер 4 байта.

  Кодирование
Приведённые ниже последовательности байтов используются для отображения символа. Конкретная последовательность зависит от номера символа в кодировке UCS:

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

Позиции битов, обозначенные как xxx, заполняются соответствующими битами из кода символа в двоичном виде, наиболее значимый бит первый (прямой порядок байт).Используется самая короткая из возможных многобайтовых последовательностей, которые могут представить код символа.

Значения кодов UCS 0xd00–0xdfff (суррогаты UTF-16), а также 0xfffe и 0xffff (не символьные значения UCS), не должны появляться в потоках UTF-8. Согласно RFC 3629 точки выше U+10FFFF не должны использоваться, что ограничивает символы четырьмя байтами.

  Пример
Символ Юникода с кодом 0xa9 = 1010 1001 (знак авторского права) кодируется в UTF-8 как

    11000010 10101001 = 0xc2 0xa9

а символ с кодом 0x2260 = 0010 0010 0110 0000 (знак неравенства) кодируется так:

    11100010 10001001 10100000 = 0xe2 0x89 0xa0

  Замечания к применению
Например, с помощью

    export LANG=en_GB.UTF-8

пользователи должны выбрать локаль UTF-8 для включения поддержки UTF-8 в приложениях.

Программы, в которых учитывается используемая пользователем кодировка, должны всегда устанавливать локаль с помощью

    setlocale(LC_CTYPE, "")

и затем проверять выражением

    strcmp(nl_langinfo(CODESET), "UTF-8") == 0

что локаль UTF-8 выбрана и во всех стандартных текстовых потоках ввода и вывода, на терминалах, в содержимом простых текстовых файлов, именах файлов и переменных окружения будет использоваться кодировка UTF-8.

Программисты, привыкшие к однобайтовым кодировкам, таким как, US-ASCII или ISO 8859, должны учесть, что два предположения, действовавших ранее, в локалях UTF-8 не работают. Первое: один байт теперь не обязательно соответствует одному символу. Второе: современные эмуляторы терминала в режиме UTF-8 также поддерживают китайские, японские и корейские символы двойной ширины (double-width characters), а также комбинированные символы без пробелов, и вывод одного символа необязательно смещает курсор на одну позицию, как это было в ASCII. Для подсчёта количества символов и позиций курсора нужно использовать библиотечные функции, такие как mbsrtowcs(3) и wcswidth(3).

Стандартной ESC-последовательностью для переключения из схемы кодировки ISO 2022 (используется в терминалах VT100) в UTF-8 является ESC % G ("\x1b%G"). Соответственно, обратной последовательностью для переключения из UTF-8 в ISO 2022 будет ESC % @ ("\x1b%@"). Остальные последовательности ISO 2022 (такие, как переключение в наборы G0 и G1) в режиме UTF-8 не работают.

  Безопасность
Стандарты Юникода и UCS требуют, чтобы генераторы UTF-8 использовали самую короткую возможную форму представления символов, то есть создание двухбайтной последовательности с первым байтом, равным 0xc0, запрещено. В стандарте Unicode 3.1 это правило расширено и запрещает программам воспринимать не самую короткую форму при вводе. Это сделано из соображений безопасности: если вводимые пользователем символы проверяются системой безопасности на возможные нарушения, то программам остаётся проверить только ASCII версии символов «/../», «;» или NUL, так как для этих символов может быть очень много не ASCII способов представления при не самом коротком кодировании в UTF-8.

  Стандарты
ISO/IEC 10646-1:2000, Unicode 3.1, RFC 3629, Plan 9.

СМОТРИТЕ ТАКЖЕ
locale(1), nl_langinfo(3), setlocale(3), charsets(7), unicode(7)