utf-8(7) - Russkiy

GNU

2019-03-06

Aliases: utf8(7), utf8(7), utf8(7), utf8(7), utf8(7), utf8(7), utf8(7), utf8(7), utf8(7), utf8(7), utf8(7), utf8(7), utf8(7), utf8(7)

man-pages-ru

Russian man pages from the Linux Documentation Project

manpages

Manual pages about using a GNU/Linux system

man-pages

Linux kernel and C library user-space interface documentation

ИМЯ

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

ОПИСАНИЕ

Набор символов Unicode 3.0 занимает 16-битное кодовое пространство. Наиболее распространённая юникодная кодировка, известная как UCS-2, содержит последовательности 16-битных слов. Закодированные таким образом строки могут состоять из частей 16-битных символов например, \(aq\0\(aq или \(aq/\(aq, которые имеют специальное значение в именах файлов и других параметрах функций библиотеки языка Си. Кроме того, большинство утилит 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-байты не могут оказаться частью другого символа и, как следствие, не будет проблем с использованием \(aq\0\(aq или \(aq/\(aq.
*	Сохраняется лексикографический порядок сортировки строк как в кодировке 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.