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:
Позиции битов, обозначенные как xxx, заполняются соответствующими битами из кода символа в двоичном виде, наиболее значимый бит первый (прямой порядок байт).Используется самая короткая из возможных многобайтовых последовательностей, которые могут представить код символа.
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 |
Значения кодов 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.
СМОТРИТЕ ТАКЖЕ
REFERENCED BY
unicode_start(1), unicode_stop(1), setfont(8), locale(5), armscii-8(7), ascii(7), charsets(7), cp1251(7), cp1252(7), iso_8859-1(7), iso_8859-10(7), iso_8859-11(7), iso_8859-13(7), iso_8859-14(7), iso_8859-15(7), iso_8859-16(7), iso_8859-2(7), iso_8859-3(7), iso_8859-4(7), iso_8859-5(7), iso_8859-6(7), iso_8859-7(7), iso_8859-8(7), iso_8859-9(7), koi8-r(7), koi8-u(7), locale(7), unicode(7), uri(7), catdvi(1), man-pages(7)