Utf 8 со спецификацией что это

UTF-8

UTF-8 (сокращение от Universal Character Set Transformation Format — 8 бит ) — это компьютерная кодировка символов, предназначенная для кодирования набора символов из «универсального репертуара кодированных символов», первоначально разработанного ISO в стандарте. International ISO / IEC 10646 , теперь полностью совместим со стандартом Unicode , оставаясь при этом совместимым со стандартом ASCII, ограниченным базовым английским языком, но широко используемым на протяжении десятилетий.

UTF-8 используется 82,2% веб-сайтов в декабрь 2014 , 87,6% в 2016 г., 90,5% в 2017 г., 93,1% в февраль 2019 и почти 95,2% в октябрь 2020 . По своей природе UTF-8 все чаще используется в Интернете и в системах, которые нуждаются в обмене информацией. Это также наиболее широко используемый код в GNU , Linux и совместимых системах для максимально простого управления текстами и их переводами во всех системах письма и всех алфавитах в мире.

Резюме

1 Ссылки на международный стандарт ISO / IEC 10646, а также стандарты Unicode и Интернет
2 Техническое описание

3 Описание

3.1 Примеры

3.2 Характеристики

3.2.1 Принцип и уникальность кодирования

4.1 Универсальность
4.2 Совместимость с US-ASCII
4.3 Совместимость
4.4 Эффективность
4.5 Возможность повторного использования
4.6 Надежность

5.1 Переменный размер
5.2 Эффективность
5.3 Недействительные последовательности
5.4 Нулевой символ
5.5 Представление в СУБД

6.1 Развитие использования
6.2 Последовательные ограничения
6.3 Поддержка

6.4 Нестандартные расширения

6.4.1 Пример варианта, используемого в Java

8.1 Статьи по теме

8.1.1 Специальные блоки символов Unicode, содержащие не символы

Связь с международным стандартом ISO / IEC 10646, а также стандартами Unicode и Интернет.

UTF-8 — это «формат преобразования», изначально разработанный для стандарта ISO / IEC 10646 , т.е. UTF-8 определяет кодировку для любой скалярной кодовой точки ( абстрактный символ или «несимвольный») из универсального набора символов ( UCS ). каталог. Этот каталог теперь является общим для стандарта ISO / IEC 10646 (начиная с его редакции 1) и для стандарта Unicode (начиная с его версии 1.1).

UTF-8 официально определен в стандарте ISO / IEC 10646 с момента его принятия в поправке, опубликованной в 1996 году. Он также был описан в стандарте Unicode и является частью этого стандарта с версии 3.0, опубликованной в 2000 году. В 1996 году был опубликован RFC 2044 (« UTF-8, формат преобразования ISO 10646 »), чтобы предоставить доступную спецификацию UTF-8 и начать ее стандартизацию в рамках Инженерной группы Интернета (IETF). Этот RFC был пересмотрен в 1998 году ( RFC 2279) и, наконец, в 2003 году ( RFC 3629), последняя версия сделала UTF-8 одним из стандартов Интернета (STD 63).

Техническое описание

Технически, это включает в себя кодирующее Unicode символов в виде последовательностей одного до четырех кодовых одного байта каждого. Стандарт Unicode определяет, среди прочего, набор (или каталог) символов. Каждый символ в этом наборе идентифицируется целым индексом, также называемым « кодовой точкой ». Например, символ «€» ( евро ) — это 8365- й символ каталога Unicode, его индекс или кодовая точка, следовательно, 8364 (0x20AC) (мы начинаем отсчет с 0).

Каталог Unicode может содержать более миллиона символов, что слишком велико для кодирования в виде одного байта (ограничено значениями от 0 до 255). Поэтому стандарт Unicode определяет стандартизованные методы кодирования и хранения этого индекса в виде последовательности байтов: UTF-8 является одним из них, наряду с UTF-16 , UTF-32 и их различными вариантами.

Основной характеристикой UTF-8 является то, что он обратно совместим со стандартом ASCII, то есть любой символ ASCII кодируется в UTF-8 в виде одного байта, идентичного коду ASCII. Например, «A» (верхний регистр A) имеет код ASCII 65 (0x41) и закодирован в UTF-8 байтом 65. Каждый символ, кодовая точка которого больше 127 (0x7F) (символ не-ASCII), является кодом от 2 до 4 байта . Символ «€» (евро) кодируется, например, 3 байтами : 226, 130 и 172 (0xE2, 0x82 и 0xAC).

Описание

Номер (скалярное значение) каждой кодовой точки в универсальном наборе символов (UCS) задается стандартом ISO / IEC 10646, который присваивает кодовую точку каждому действительному символу и разрешает их кодирование путем присвоения скалярного значения, идентичного кодовой точке. ; этот стандарт включен в стандарт Unicode (который использует тот же каталог, начиная с версии 1.1).

Все « кодовые точки » от U + 0000 до U + D7FF и от U + E000 до U + 10FFFF представимы в UTF-8 — даже те , отнесены к «не-символов» ( без символов ) и всех тех , кто еще не назначен — и только те. Единственные кодовые точки, действительные в пространстве UCS и которые не должны быть представлены в UTF-8, — это те, которые присвоены « полукодовым точкам » ( суррогаты на английском языке), потому что они не могут быть представлены каким-либо образом. Bijective в кодировке UTF-16 и сами по себе не являются символами: в отличие от других кодовых точек, полукоды не имеют определенного « скалярного значения ».

Точечный код, имеющий скалярное значение от 0 до 127 (кодовые точки U + 0000 U + 007F, назначенные символам набора, закодированного на 7 битах в ASCII), кодируется на одном байте, самый старший бит которого равен нулю.

Другие кодовые точки (назначенные или не назначенные символам), имеющие скалярное значение больше 127 (за исключением тех, которым назначены «полукоды», которые сами не являются символами), кодируются несколькими байтами, каждый из которых имеет свои собственные. наиболее значимый бит: наиболее значимые биты первого байта кодированной последовательности образуют последовательность из единиц длины, равную общему количеству байтов (не менее 2), используемых для всей последовательности, за которым следует 0, а требуемые последующие байты имеют их два старших бита установлены на 10.

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

Закодированные символы	Двоичное представление UTF-8	Первый действительный байт (шестнадцатеричный)	Имея в виду
U + 0000 — U + 007F	`0 ххххххх`	С 00 по 7 этаж	1 байт, кодирование 7 бит
U + 0080 до U + 07FF	`11 0 ххххх 10 XXXXXX`	C2 в DF	2 байта, кодирование 11 бит
U + 0800 в U + FFFF	`111 0 хххх 10 XXXXXX 10 XXXXXX`	E0 в EF	3 байта, кодирование 16 бит
От U + 10000 до U + 10FFFF	`1111 0 ххх 10 ххххх 10 ххххх 10 ххххх`	От F0 до F4	4 байта, кодирование 21 бит

Этот принцип можно расширить до восьми байтов для одной кодовой точки (для представления кодовых точек длиной до 42 бит), но текущая стандартизованная версия UTF-8 устанавливает ограничение до четырех.

Кодирование запрещает представление кодовых точек, зарезервированных для полукодов (которые не имеют определенного скалярного значения, чтобы сохранить совместимость с UTF-16, который также не позволяет их представлять). Однако он разрешает представление кодовых точек, присвоенных несимволам (даже если их присутствие запрещено в соответствующем тексте).

Примеры

Примеры кодировки UTF-8

Тип	Персонаж	Кодовая точка (шестнадцатеричная)	Скалярное значение		Кодировка UTF-8
Тип	Персонаж	Кодовая точка (шестнадцатеричная)	десятичный	двоичный	двоичный	шестнадцатеричный
Контроль	`[НЕТ]`	`U + 0000`	0	`0`	`0 0000000`	`00`
Контроль	`[НАС]`	`U + 001F`	31 год	`1111`	`0 0011111`	`1F`
Текст	`[SP]`	`U + 0020`	32	`100000`	`0 0100000`	`20`
	В	`U + 0041`	65	`100 0001`	`0 100 0001`	`41 год`
	~	`U + 007E`	126	`111 1110`	`0 1111110`	`7E`
Контроль	`[ПРИНАДЛЕЖАЩИЙ]`	`U + 007F`	127	`111 1111`	`0 1111111`	`7F`
	`[PAD]`	`U + 0080`	128	`000 1000 0000`	`110 000 10 10 000 000`	`C2 80`
	`[APC]`	`U + 009F`	159	`000 1001 1111`	`110 000 10 10 011 111`	`C2 9F`
Текст	`[NBSP]`	`U + 00A0`	160	`000 1010 0000`	`110 000 10 10 100 000`	`C2 A0`
	é	`U + 00E9`	233	`000 1110 1001`	`110 000 11 10 101 001`	`C3 A9`
	߿	`U + 07FF`	2047	`111 1111 1111`	`110 111 11 10 111 111`	`DF BF`
	ࠀ	`U + 0800`	2048	`1000 0000 0000`	`1110 0000 10 1000 00 10 000000`	`E0 A0 80`
	€	`U + 20AC`	8 364	`100000 10101100`	`1110 0010 10 0000 10 10 10 1100`	`E2 82 AC`
	퟿	`U + D7FF`	55 295	`1101 0111 1111 1111`	`1110 1101 10 0111 11 10 111111`	`ED 9F BF`
Половина кодета		`U + D800`	(ничего такого)		(кодирование запрещено)
Половина кодета		`U + DFFF`	(ничего такого)		(кодирование запрещено)
Частное использование	[]	`U + E000`	57 344	`1110 0000 0000 0000`	`1110 1110 10 0000 00 10 0000000`	`EE 80 80`
Частное использование	[]	`U + F8FF`	63 743	`1111 1000 1111 1111`	`1110 1111 10 1000 11 10 111111`	`EF A3 BF`
Текст	`U + F900`	63 744	`1111 1001 0000 0000`	`1110 1111 10 1001 00 10 000 000`	`EF A4 80`
Текст	﷏	`U + FDCF`	64 975	`1111 1101 1100 1111`	`1110 1111 10 1101 11 10 001111`	`EF B7 8F`
Не-персонажи		`U + FDD0`	64 976	`1111 1101 1101 0000`	`1110 1111 10 1101 11 10 010000`	`EF B7 90`
Не-персонажи		`U + FDEF`	65 007	`1111 1101 1110 1111`	`1110 1111 10 1101 11 10 101111`	`EF B7 AF`
Текст	ﷰ	`U + FDF0`	65 008	`1111 1101 1111 0000`	`1110 1111 10 1101 11 10 110000`	`EF B7 B0`
Текст	`U + FFFD`	65 533	`1111 1111 1111 1101`	`1110 1111 10 1111 11 10 111101`	`EF BF BD`
Не-персонажи		`U + FFFE`	65 534	`1111 1111 1111 1110`	`1110 1111 10 1111 11 10 111110`	`EF BF BE`
Не-персонажи		`U + FFFF`	65 535	`1111 1111 1111 1111`	`1110 1111 10 1111 11 10 111111`	`EF BF BF`
Текст	?	`U + 10,000`	65 536	`1 0000 0000 0000 0000`	`11 110 000 10 01 0000 10 0000 00 10 000000`	`F0 90 80 80`
	?	`U + 1D11E`	119 070	`1 1101 0001 0001 1110`	`11 110 000 10 01 1101 10 0001 00 10 011 110`	`F0 9D 84 9E`
	?	`U + 1FFFD`	131 069	`1 1111 1111 1111 1101`	`11110 000 10 01 1111 10 1111 11 10 111 101`	`F0 9F BF BD`
Не-персонажи		`U + 1FFFE`	131 070	`1 1111 1111 1111 1110`	`11110 000 10 01 1111 10 1111 11 10 111 110`	`F0 9F BF BE`
Не-персонажи		`U + 1FFFF`	131 071	`1 1111 1111 1111 1111`	`11 110 000 10 01 1111 10 1111 11 10 111111`	`F0 9F BF BF`
Текст	?	`U + 20,000`	131 072	`10 0000 0000 0000 0000`	`11 110 000 10 10 0000 10 0000 00 10 000000`	`F0 A0 80 80`
Текст	?	`U + 2FFFD`	196 605	`10 1111 1111 1111 1101`	`11110 000 10 10 1111 10 1111 11 10 111 101`	`F0 AF BF BD`
Не-персонажи		`U + 2FFFE`	196 606	`10 1111 1111 1111 1110`	`11110 000 10 10 1111 10 1111 11 10 111 110`	`F0 AF BF BE`
Не-персонажи		`U + 2FFFF`	196 607	`10 1111 1111 1111 1111`	`11 110 000 10 10 1111 10 1111 11 10 111111`	`F0 AF BF BF`
. другие планы зарезервированы .
Специальные	?	`U + E0000`	917 504	`1110 0000 0000 0000 0000`	`11110 011 10 10 0000 10 0000 00 10 000000`	`F3 A0 80 80`
Специальные	?	`U + EFFFD`	983 037	`1110 1111 1111 1111 1101`	`11110 011 10 10 1111 10 1111 11 10 111101`	`F3 AF BF BD`
Не-персонажи		`U + EFFFE`	983 038	`1110 1111 1111 1111 1110`	`11110 011 10 10 1111 10 1111 11 10 111110`	`F3 AF BF BE`
Не-персонажи		`U + EFFFF`	983 039	`1110 1111 1111 1111 1111`	`11110 011 10 10 1111 10 1111 11 10 111111`	`F3 AF BF BF`
Частное использование	[?]	`U + F0000`	983 040	`1111 0000 0000 0000 0000`	`11110 011 10 11 0000 10 0000 00 10 000000`	`F3 B0 80 80`
Частное использование	[ ]	`U + FFFFD`	1 048 573	`1111 1111 1111 1111 1101`	`11110 011 10 11 1111 10 1111 11 10 111101`	`F3 BF BF BD`
Не-персонажи		`U + FFFFE`	1 048 574	`1111 1111 1111 1111 1110`	`11110 011 10 11 1111 10 1111 11 10 111110`	`F3 BF BF BE`
Не-персонажи		`U + FFFFF`	1 048 575	`1111 1111 1111 1111 1111`	`11110 011 10 11 1111 10 1111 11 10 111111`	`F3 BF BF BF`
Частное использование	[?]	`U + 100 000`	1 048 576	`1 0000 0000 0000 0000 0000`	`11110 100 10 00 0000 10 0000 00 10 000000`	`F4 80 80 80`
Частное использование	[?]	`U + 10FFFD`	1,114,109	`1 0000 1111 1111 1111 1101`	`11110 100 10 00 1111 10 1111 11 10 111101`	`F4 8F BF BD`
Не-персонажи		`U + 10FFFE`	1,114,110	`1 0000 1111 1111 1111 1110`	`11110 100 10 00 1111 10 1111 11 10 111110`	`F4 8F BF BE`
Не-персонажи		`U + 10FFFF`	1,114,111	`1 0000 1111 1111 1111 1111`	`11110 100 10 00 1111 10 1111 11 10 111111`	`F4 8F BF BF`

Характеристики

В любой строке символов, закодированной в UTF-8, мы замечаем, что:

любой байт старшего значащего бита нуля обозначает единственную «кодовую точку», назначенную символу в каталоге US-ASCII и закодированную в этом единственном байте, со скалярным значением, идентичным значению кодовой точки, используемой в кодировке US -ASCII;
любой байт из наиболее значимых битов 11 является первым байтом уникальной последовательности, представляющей «кодовую точку» (назначенной символу или несимволу) и закодированной по нескольким байтам;
любой байт из наиболее значимых битов 10 является одним из следующих байтов единственной последовательности, представляющей «кодовую точку» (назначенной символу или несимволу) и закодированной в нескольких байтах;
любые байты могут принимать шестнадцатеричное значение между C0 и C1, а также между F5 и FF (наивысшая допустимая кодовая точка и присвоенная представимому символу U + 10FFFD; это символ частного использования, выделенный в 17- м действующем плане).

Самая большая точка действительного кода, назначаемого действительному символу, не являющемуся частным, — это U + EFFFD в 15- м плане (он еще не назначен, но может стать в будущем), но UTF-8 также может использоваться стандартным способом, для представления любого допустимого символа для личного использования (в одном из трех диапазонов от U + E000 до U + F8FF, от U + F0000 до U + FFFFD и от U + 100000 до U + 10FFFD).

Будьте или не не-символы или символы частного пользования будут приняты оставляются приложения или текст транспортных протоколов. Однако несимволы обычно не принимаются в текстах, строго соответствующих стандарту Unicode или стандарту ISO / IEC 10646 .

Некоторые приложения налагают дополнительные ограничения на кодовые точки, которые могут использоваться (например, стандарты HTML и XML запрещают в любом документе, соответствующем этим спецификациям, присутствие большинства управляющих символов между U + 0000 и U + 001F и между U + 0080 и U + 009F, вне вкладок U + 0009 считается пустой символ, а также запретить не-символы ).

Любая кодовая точка всегда представлена точно такой же двоичной последовательностью, независимо от ее относительного положения в тексте, и эти последовательности автосинхронизируются по неразделенной позиции значимых кодовых точек (здесь байты: мы всегда можем знать, начинается ли байт или нет эффективная двоичная последовательность); это кодирование, таким образом, позволяет использовать быстрые алгоритмы текстового поиска, такие как алгоритм Бойера-Мура .

Это не всегда происходит с контекстными кодировками (которые обычно используют сжатие данных , например, SCSU, определенный в дополнительном техническом примечании к стандарту UTS # 6, дополняющем стандарт Unicode) и которые могут потребовать полного чтения текста с самого начала. на более чем одной переменной состояния (или которые включают дополнительные коды избыточности); в лучшем случае некоторые из этих кодировок могут потребовать использования сложных алгоритмов ресинхронизации, часто основанных на эвристике, которая может дать сбой или привести к ложным интерпретациям, если текст не читается с самого начала (например, BOCU -1).

Принцип и уникальность кодирования

В приведенной выше таблице мы видим, что символ «€» находится в кодовой точке U + 20AC, либо в десятичном виде 8364, либо в двоичном формате: 100 000 10101100.

Это последнее число состоит из значащих двоичных цифр, поэтому для кодирования символа «€» необходимо не менее 14 бит . Представленный выше стандарт фактически требует трех байтов для представления этих символов. ⌈ бревно 2 ⁡ 8364 ⌉ знак равно 14 8364 \ rceil = 14>

При наличии четырех байтов можно было бы разместить в соответствии с этим стандартом до 21 бита , в частности, представить символ «€» как 00000 00 100000 10101100, добавив к нему 7 ведущих нулей . Однако стандарт требует, чтобы программа, декодирующая UTF-8, не могла принимать излишне длинные байтовые строки, как в этом примере, по соображениям безопасности (избегайте использования слишком терпимых тестов подстроки). Таким образом, «€» будет закодировано: 11100010 10000010 10101100, но кодирование 11110000 10000010 10000010 10101100, выведенное из представления «€» на 21 бите , хотя и недвусмысленно, использоваться не должно.

Такая форма, которая длиннее, чем необходимо, в английском языке называется overlong . Такие формы (изначально разрешенные в старых спецификациях до того, как они были последовательно стандартизированы первоначальным RFC, опубликованным X / Open Consortium , а затем параллельно стандартом ISO 10646 и стандартом Unicode) запрещены и должны рассматриваться как недействительные.

Типы байтов, допустимые последовательности и декодирование

Кодирование является прогнозирующим и всегда позволяет найти позицию первого байта последовательности, представляющей кодовую точку, по значению любого байта и по чтению ограниченного числа соседних байтов в двух направлениях чтения (это всегда будет самим байтом или первым подходящим байтом в одном из 1-3 соседних байтов ).

Любой байт продолжения в допустимой последовательности UTF-8 может принимать только шестнадцатеричные значения от 80 до BF;

он может существовать только после начала байта последовательности (представляющего кодовую точку), который будет последним, закодированным в одном из предыдущих от 1 до 3 байтов, и который также не является байтом продолжения;
следующая кодовая точка, если таковая имеется, может начинаться только в пределах следующих 1-3 байтов .

за первым шестнадцатеричным байтом от 00 до 7F последовательности не следует ни один байт продолжения;
за первым шестнадцатеричным байтом от C2 до DF последовательности всегда следует один байт продолжения (каждый с шестнадцатеричным значением от 80 до BF);

за первым шестнадцатеричным байтом от E0 до EF последовательности всегда следуют два байта продолжения (каждый с шестнадцатеричным значением от 80 до BF);

однако, если первый байт последовательности принимает шестнадцатеричное значение E0, первый байт продолжения ограничивается шестнадцатеричным значением между A0 и BF;
однако, если первый байт последовательности принимает шестнадцатеричное значение ED, первый байт продолжения ограничивается шестнадцатеричным значением между 80 и 9F;

однако, если первый байт последовательности принимает шестнадцатеричное значение F0, первый байт продолжения ограничивается шестнадцатеричным значением от 90 до BF;
однако, если первый байт последовательности принимает шестнадцатеричное значение F4, первый байт продолжения ограничивается шестнадцатеричным значением от 80 до 8F.

Запрещенные последовательности

Кодовые точки всегда представлены самой короткой последовательностью байтов:

следовательно, ни одна последовательность байтов не содержит начальных байтов шестнадцатеричного значения C0 или C1 в допустимом тексте в кодировке UTF-8;
аналогично, никакая последовательность, начинающаяся с начального байта E0, не может иметь первый байт продолжения с шестнадцатеричным значением от 80 до 9F.

следовательно, первый байт продолжения последовательности, который начинается с шестнадцатеричного байта ED, не может принимать какие-либо шестнадцатеричные значения от A0 до BF;
с другой стороны, эти последовательности, запрещенные в UTF-8, разрешены в преобразовании CESU-8 (не рекомендуется, что ни в коем случае не следует путать с UTF-8, потому что CESU-8 использует эти последовательности для кодирования символов дополнительных плоскости в 2 последовательности по 3 байта каждая вместо одной последовательности из 4 байтов в UTF-8).

следовательно, первый байт продолжения последовательности, который начинается с шестнадцатеричного байта F4, не может принимать какие-либо шестнадцатеричные значения от 90 до BF;
и ни одна последовательность байтов не содержит начальных байтов шестнадцатеричного значения от F5 до FF.

Такие последовательности называются плохо сформированными . (См. Ссылку выше, особенно вторую таблицу в пункте о соответствии стандарта D36 или статье о Unicode ).

С другой стороны, зарезервированные кодовые точки (еще не присвоенные символам) авторизованы (даже если интерпретация символов может оставаться неоднозначной): приложения должны решить, являются ли эти символы приемлемыми или нет, зная, что те же самые приложения, вероятно, будут продолжать использоваться, даже если эти позиции были назначены в стандартах Unicode и ISO 10646 новым, полностью допустимым символам.

Аналогичным образом, другие кодовые точки, постоянно назначенные другим « несимволам », запрещены в текстах, соответствующих ISO / IEC 10646 или стандарту Unicode : например, от U + x FFFE до U + x FFFF (где x означает шестнадцатеричный номер плана от От 0 до 10). Но они остаются кодируемыми и декодируемыми как таковые в UTF-8 ( не-символы доступны для приложений , которые могут использовать их во внутренних API — интерфейсах, например , в качестве промежуточных кодов , необходимых для выполнения определенных процессов.).

Ограничение пространства представления только кодовыми точками, меньшими или равными U + 10FFFF (не включая кодовые точки, присвоенные полукодовым точкам ), применялось не всегда:

Так было не всегда в стандарте ISO / IEC 10646, который изначально предусматривал возможность кодирования очень большого количества возможных плоскостей (UCS-4 допускал кодирование до 31 бита ), так что Консорциум Unicode (с момента слияния общего репертуара в версии 1.1) все еще использовала только базовый многоязычный план и еще не рассматривала возможность охвата такого количества сценариев, как сегодня;

Введение Unicode кодировки UTF-16 в стандартное приложение (когда было признано, что быстро потребуется более 65536 символов) потребовало предварительного выделения ISO / IEC 10646 блока кодовых точек для «полукодов», которые были первоначально рассматриваемый ISO / IEC 10646 как специальные символы (уступка Unicode, когда UCS-4 был создан как линейное пространство кодирования, где все кодовые точки имели скалярное значение), в то время как Unicode по-прежнему использовал только подпространство UCS-2, а не полное пространство UCS-4;

Чтобы избежать проблем совместимости с другими (не-Unicode) приложениями, основанными на UCS-2, первая версия UTF-8 была опубликована ISO в 1998 году, в которой было упомянуто, что эти элементы половинного кода, следовательно, не имеют определенного скалярного значения и что нет кодовые точки, присвоенные «полукодовым точкам» в двух последовательно выделенных блоках, должны были быть закодированы в UTF-8;

Действительно, после двадцати лет усилий по определению UCS для всех скриптов в мире были установлены более строгие правила для ограничения кодируемых символов в соответствии с моделью, обеспечивающей обратную совместимость, но также и передовой практикой. Практически все современные сценарии в мире были закодированы, и доступны надежные порядковые оценки количества символов, необходимых для поддержки других сценариев, а также требований к кодированию для новых символов;
Очень сильный первоначальный рост распределения в UCS (или символов, которые еще предстоит закодировать) значительно замедлился, и в конце 2011 года использовались только 6 из 17 планов (но только два имели значительную скорость заполнения: многоязычный базовый план , практически полный, и дополнительный идеографический уровень; именно на дополнительном многоязычном уровне сосредоточено большинство других старых шрифтов, которые еще предстоит закодировать, или новых наборов символов и знаков технической нотации);
Скорость роста выделений в UCS для стандарта ISO / IEC 10646 не позволяет рассматривать его насыщение до истечения срока, который выходит далеко за пределы жизненного цикла международных стандартов (и тем более промышленных стандартов, таких как Unicode). В этом слишком далеком будущем вполне возможно, что UTF-16 устарел на очень долгое время или что новый стандарт кодификации появился и был массово развернут (и что инструменты автоматического преобразования также будут стандартизированы и развернуты. ). Ничто еще не оправдывает сохранение возможного расширения, не связанного с непосредственной потребностью в функциональной совместимости текущих норм и стандартов или предусмотренных будущих стандартов;
Рассматриваются только один или два других плана для синографических сочинений, древних клинописей или иероглифических писаний и, возможно, еще один план для коллекций символов и пиктограмм, необходимых для взаимодействия определенных современных приложений (например, смайликов сообщений и интерактивных услуг. или символы, необходимые для международных обозначений или стандартов безопасности);
Дополнительные «группы» частного использования в конце UCS-4, а также дополнительные «планы» частного использования в UCS-4 в конце группы 0, которые рассматривались ISO с момента начала ее работы по стандартизации , были оставлены, чтобы оставить среди 17 первых снимков первой группы только последние два снимка для личного использования (в дополнение к блоку частного использования от U + E000 до U + F8FF, уже выделенному в основном многоязычном плане), который достаточно для всех приложений;
Это было предметом пересмотра 2003 года RFC, опубликованного техническим комитетом ISO, определяющего кодировку UTF-8 для ISO / IEC 10646, и одновременно обновления стандартного приложения. Стандарт Unicode (стандартное приложение, которое с тех пор было включено в сам стандарт);
После этих обновлений 2003 года кодировка UCS-4, определенная стандартом ISO / IEC 10646, на практике стала эквивалентной UTF-32 (определенной в стандарте Unicode, который добавляет дополнительные свойства, но без разницы в кодировке). И последний RFC, опубликованный ISO и одобренный IETF в 2003 году, теперь также содержит нормативную ссылку на определение UTF-8, опубликованное совместно со стандартом Unicode (или в нем).

Преимущества

Универсальность

Эта кодировка позволяет представлять тысячи символов универсального каталога, общего для стандарта ISO / IEC 10646 и стандарта Unicode (по крайней мере, начиная с его версии 1.1.1).

Совместимость с US-ASCII

Текст в US-ASCII кодируется идентично в UTF-8 (когда спецификация не используется).

Совместимость

Поскольку символ разделен на последовательность байтов (а не на многобайтовые слова), нет проблем с порядком следования байтов ( endianness English).

Эта проблема возникает с кодировками UTF-16 и UTF-32, например, если они не используются с маркером упорядочивания (называемым BOM для метки порядка байтов ), закодированным в начале файла с помощью символа U + FEFF, который был ранее предназначен для другого использования (ZWNBSP для неразрывного пробела нулевой ширины , функция агглютинации слов, отображаемых без разделения пробелов или переносов, которые символ WJ заполняет сегодня для соединения слов ). Напротив, производные кодировки UTF-16BE, UTF-16LE, UTF-32BE и UTF-32LE разработаны с точным планированием, которое не требует использования какой-либо спецификации;
По различным причинам совместимости (в частности, с помощью процессов перекодирования), тем не менее, было принято, что спецификация (U + FEFF), не являющаяся абсолютно необходимой, по-прежнему может быть закодирована в заголовке файла UTF-8 (их интерпретация остается такой же, как у символ ZWNBSP, даже если многие протоколы предпочли игнорировать и молчаливо фильтровать этот символ, поскольку он используется только для этого использования и его старая функция, когда она остается необходимой для интерпретации самого текста, теперь передается другому явно закодированному персонаж).

Эффективность

Для большинства языков латинского алфавита, файлов цифровых данных или исходных кодов программ или многих текстовых протоколов связи (таких как FTP , HTTP или MIME ), которые используют символы широко (или иногда только частично) US-ASCII, UTF-8 требует меньше байтов, чем UTF-16 или UTF-32 .

Возможность повторного использования

Многие методы компьютерного программирования , которые допустимы с единообразными однобайтовыми символами, остаются действительными с UTF-8, включая:

способ найти конец символьной строкиC , потому что любой двоичный байт 00000000, найденный в кодированной символьной строке UTF-8, всегда является нулевым символом (однако тогда невозможно представить сам NUL-символ как член символьной строки , если только информация о фактической длине закодированного текста не сохраняется или не транспортируется за ее пределами, и в этом случае этот байт будет интерпретироваться как таковой в строках, закодированных в UTF-8);
способ поиска подстроки такой же.

Надежность

Это самосинхронизирующаяся кодировка (читая один байт, мы узнаем, является ли он первым символом или нет).

Можно из любой позиции в кодированном тексте вернуться к первому байту последовательности, прочитав очень небольшое количество предыдущих байтов, то есть максимум 3 байта , или легко найти начало следующей последовательности, опять же, пропуская максимум 3 байта );
последовательность, описывающая один символ, никогда не появляется в более длинной последовательности, описывающей другой символ (как в случае с Shift-JIS );
не существует «escape-кода», который изменяет интерпретацию (как символов) остальной части последовательности байтов.

Недостатки

Переменный размер

Кодовые точки представлены в UTF-8 последовательностями байтов разного размера (как и в UTF-16), что усложняет некоторые операции со строками кодовых точек: вычисление количества кодовых точек; позиционирование на заданном расстоянии (выраженном в количестве кодовых точек) в текстовом файле и вообще любая операция, требующая доступа к кодовой точке позиции N в цепочке.

Переменный размер символов строки не позволяет использовать эффективные алгоритмы сравнения строк, такие как алгоритм Кнута-Морриса-Пратта , и, следовательно, сильно наказывает массовую обработку данных, как при эксплуатации баз данных. Однако эта проблема больше связана с аспектами стандартизации, чем с кодированием.

Эффективность

Для языков, использующих много символов за пределами US-ASCII , UTF-8 занимает значительно больше места. Например, общие идеограммы, используемые в текстах на азиатских языках, таких как китайский или японский (например, кандзи ), используют 3 байта в UTF-8 по сравнению с 2 байтами в UTF-16.

В общем, записи, в которых используется много кодовых точек со значением, равным или превышающим U + 0800, занимают больше памяти, чем если бы они были закодированы с помощью UTF-16 (UTF-32 будет более эффективным только для текстов, в которых в основном используются записи. старый или редко закодированный вне базового многоязычного плана, то есть из U + 10000, но он также может оказаться полезным локально в определенных процессах для упрощения алгоритмов, потому что символы там всегда имеют фиксированный размер, преобразование ввода или вывода данные из или в UTF-8 или UTF-16 являются тривиальными).

Недействительные последовательности

Благодаря своей системе кодирования, возможно, было возможно представить код по-разному в UTF-8, что могло создать проблему безопасности: плохо написанная программа может принимать определенное количество представлений UTF-8, которые обычно недействительны в соответствии с RFC 3629. и в спецификациях (теперь эквивалентных друг другу), опубликованных ISO 10646 и Unicode; но это было не так в соответствии с исходной спецификацией, которая позволяла преобразовывать их как один символ.

Таким образом, программное обеспечение, обнаруживающее определенные символьные строки (например, для предотвращения SQL-инъекций ), может не выполнить свою задачу (это уже не тот случай, если проверяется соответствие кодировки строгому и стандартизованному определению UTF-8. все).

Давайте возьмем пример из реального случая атаки вируса на HTTP-серверы в Интернете в 2001 году ( (en) Crypto-Gram: 15 июля 2000 г. Microsoft IIS и PWS Extended Unicode Directory Traversal Vulnerability Microsoft IIS 4.0 / 5.0 Web Directory Traversal Vulnerability ) . Обнаруживаемая последовательность может быть представлена «/../» в ASCII ( а тем более в UTF-8) байтами « 2F 2E 2E 2F » в шестнадцатеричной системе счисления . Однако неправильный способ кодирования этой строки в UTF-8 будет » 2F C0 AE 2E 2F «, также называемый сверхдлинной формой . Если программное обеспечение не написано так, чтобы отклонить эту цепочку, например, преобразовав ее в каноническую форму , открывается потенциальное нарушение безопасности. Эта атака называется обходом каталога .

Программное обеспечение, принимающее текст в кодировке UTF-8, было защищено, чтобы систематически отклонять эти длинные формы, потому что они не соответствуют стандарту: либо весь текст отклоняется; но иногда недопустимые последовательности заменяются символом подстановки (обычно U + FFFD, если приложение принимает и обрабатывает этот символ нормально; иногда вопросительный знак или управляющий символ подстановки SUB U + 001A в ASCII, что может вызвать другие проблемы совместимости); реже эти запрещенные последовательности удаляются молча (что очень мало рекомендуется).

Нулевой символ

UTF-8 может представлять только нулевой управляющий символ (U + 0000) с одним нулевым байтом, что создает проблемы совместимости с обработкой строк, которые не кодируют отдельно их эффективную длину, потому что этот нулевой байт не представляет тогда ни символа, а конец строки (очень распространенный случай в языках C или C ++ и в API операционных систем). Если нулевой символ должен быть сохранен в тексте в таких системах, необходимо будет прибегнуть к системе экранирования, специфичной для этого языка или системы, перед кодированием в UTF-8 текста, преобразованного таким образом. На практике ни один действительный текст не должен содержать этот символ. Другое решение — использовать одну из последовательностей, запрещенных в стандартной кодировке UTF-8, чтобы закодировать символ этой последовательностью; но закодированный таким образом текст не будет соответствовать стандартной кодировке UTF-8, даже если измененная таким образом кодировка останется соответствующим универсальным форматом преобразования (который, однако, не следует обозначать как «UTF-8»). См. Раздел ниже о нестандартных вариантах на основе UTF-8.

Представление в СУБД

Использование UTF8, как и любой другой кодировки с переменным шагом, в базе данных создает множество проблем с производительностью.

Действительно, для символьных строк, содержащих одинаковое количество букв (например, CHAR (8)), количество байтов может быть различным (в частности, из-за диакритических символов: акценты, лигатуры . ), используемые алгоритмы должны, для по большей части необходимо выполнить выравнивание до начала работы, что влечет за собой значительные дополнительные затраты на обработку.

Например, СУБД MySQL / MariaDB решила представлять символы строк, представленных как UTF8, систематически используя 3 байта на символ. Последствия таковы: утроение объема данных и деление на три потенциальной длины индексных ключей по сравнению с кодировкой ASCII, а также увеличение времени выполнения для сравнений, сортировок, группирования или дедупликации. Строка, наконец, возвращается в форме UTF8 после очистки ненужных байтов.

Другие СУБД, такие как Microsoft SQL Server, решили сжать поддержку UTF8, вставив дополнительные символы в 2-байтовой кодировке, основанной на UNICODE, используя пробелы, оставленные пустыми по спецификации. Дополнительные усилия для перевода в UTF8 заключаются только в перекодировании символов, закодированных в 2 байта, и расширении символов, закодированных в 3 байта.

История

UTF-8 был изобретен Кеннет Томпсон во время ужина с Rob Pike вокруг Сентябрь 1992 г. . Тогда он назывался FSS-UTF и сразу же был использован в операционной системе Plan 9, над которой они работали. Одно ограничение, которое необходимо разрешить, заключалось в кодировании символов NULL и ‘/’, как в ASCII, и в том, что ни один из байтов, кодирующих другой символ, не имеет такого же кода. Таким образом, операционные системы UNIX могут продолжать поиск этих двух символов в строке без адаптации программного обеспечения.

FSS-UTF был предметом предварительного стандарта X / Open 1993 года, который был предложен ISO. Последний принял его как часть стандарта ISO / IEC 10646 под названием сначала UTF-2, затем, наконец, UTF-8.

Эволюция использования

График, показывающий, что использование UTF-8 (светло-синий) превышает другие основные кодировки текстовых символов в Интернете. К 2010 году распространенность UTF-8 составляла около 50%. Эта распространенность оценивается по тексту, а не по метке, содержащейся в заголовке, и был выбран простейший набор символов. Поэтому текст ASCII с заголовком UTF-8 или ISO-8859-1 идентифицируется как ASCII. В августе 2016 года заявленное использование UTF-8 составило 87,4%.

Статистика основана на выборке из 10 миллионов веб-сайтов по версии Alexa. Сумма не достигает 100%, потому что некоторые серверы используют более одной технологии.

Последовательные ограничения

Первоначальная кодировка FSS-UTF была предназначена для замены многобайтовой кодировки UTF-1, первоначально предложенной ISO 10646. Эта изначально разрешающая кодировка позволяла несколько двоичных представлений для одного и того же символа (это было запрещено в стандартизированной версии в RFC, опубликованном X / Открытый консорциум, одобренный Кеннетом Томпсоном).

Кроме того , оно может (в предварительном варианте не сохраняется) кодирует все символы, код которого состоит до 32 бит , определяя восьмой тип байта (в последовательностях , содержащих до 6 байт ), в то вместо 7 типов из байты, наконец, сохраняются для кодирования (в последовательностях, также содержащих до 6 байтов ) только кодовые точки длиной до 31 бита в начальной версии UTF-8 (опубликованной Консорциумом X / Open под названием FSS-UTF, затем предложенной технический комитет ISO 10646 как предложение «UTF-2», тогда все еще конкурирующий с предложением «UTF-1», пока предложение UTF-2 не будет сохранено и не примет имя UTF-8, уже сохраненное и используемое в X / Open и План 9).

Это UTF-8 кодировка дополнительно ограничена , когда Unicode и ISO 10646 согласились выделить символы только в первых 17 самолетах, чтобы сохранить совместимость с UTF-16 до бесконечности (без изменения его), с помощью не ограничивающих последовательности до тех пор «до 4 байт только и с использованием только первых 5 из 7 типов байтов (что потребовало определения недопустимых новых значений байтов и определенных последовательностей байтов, независимо от того, действительны они по отдельности).

Поддерживается

IETF теперь требует UTF-8 поддерживается по умолчанию (а не просто поддерживается расширение) на всех новых коммуникационных протоколов в сети Интернет (опубликовано в RFC пронумерованы) , который обмена текст (самые старые протоколы, однако, не были изменены сделать эту поддержку обязательной, но только расширенной, если это возможно, для поддержки ее факультативно, если это вызывает несовместимость или вводит новые риски безопасности: это имеет место с протоколами Интернет, широко используемыми как DNS , HTTP , FTP , Telnet и HTML в его начальных версиях тогда еще не стандартизирован W3C и ISO).

Это стало важным, особенно в основном программном обеспечении для веб-коммуникаций и современных операционных системах:

Веб-браузеры : поддержка UTF-8 стала широко распространяться с 1998 года .

Старые веб-браузеры, не поддерживающие UTF-8, по-прежнему правильно отображают первые 127 символов ASCII;
Netscape Navigator поддерживает UTF-8 с версии 4 ( июнь 1997 г. );
Microsoft Internet Explorer поддерживает UTF-8 с версии 4 ( октябрь 1997 г. ) для Microsoft Windows и Mac OS ( январь 1998 г. );
Браузеры, основанные на движке рендеринга Gecko (1998), поддерживают UTF-8: Mozilla , Mozilla Firefox , SeaMonkey и т. Д.
Opera поддерживает UTF-8 с версии 6 ( ноябрь 2001 г. );
Konqueror поддерживает UTF-8;
Safari на Macintosh и Windows поддерживает UTF-8;
OmniWeb на Macintosh поддерживает UTF-8;
Google Chrome поддерживает UTF-8.

Файлы и имена файлов: все более и более распространены в файловых системах GNU / Linux и Unix, но не очень хорошо поддерживаются в более старых версиях Windows (до Windows 2000 и Windows XP, которые теперь могут поддерживать их без проблем, так как теперь поддержка UTF-8 полностью интегрирован в систему, в дополнение к UTF-16, присутствующему с ранних версий Windows NT и системному API Win32). Обратите внимание, что историческая файловая система MS-DOS и Windows FAT была расширена с Windows NT 4 и Windows XP для поддержки UTF-16 (для лучшей совместимости с NTFS), а не UTF-8 (но это преобразование эквивалентно и прозрачно для приложений) с некоторыми ограничениями на допустимые или эквивалентные символы (такие исключения или ограничения также существуют для всех файловых систем GNU / Linux, Unix, Mac OS X и других систем, включая системные файлы, распространяемые через Интернет, такие как HTTP / WebDAV).

Почтовый клиент : все используемое сегодня программное обеспечение электронной почты поддерживает UTF-8.

Apple Mail ;
Thunderbird ;
Почта Windows ;
Microsoft Outlook ;
Lotus Notes ;
Novell GroupWise ;
и т.п.

Нестандартные расширения

Однако варианты UTF-8 (основанные на возможностях кодирования исходной неограниченной версии) продолжали использоваться (особенно в реализации сериализации строк Java), чтобы разрешить кодирование в виде многобайтового escape-кода некоторых зарезервированных символов ASCII, обычно кодируемых в одном байт (например, нулевой символ).

Кроме того, некоторые системы используют неограниченные строки: например, Java (и другие языки, включая библиотеки обработки строк в C, PHP, Perl и т. Д.) Представляют символы с единицами кодирования на 16 бит (что позволяет хранить строки с использованием UTF. -16 кодирование, но без ограничений действительности, налагаемых UTF-16 относительно запрещенных значений и пар в порядке «полукодов» или суррогатов ); в этом случае единицы кодирования обрабатываются как двоичные значения, и их необходимо сериализовать индивидуально (независимо от их возможной интерпретации как символы или как полуточки кода). В этом случае каждая 16-битная единица кодирования , представляющая «символ» (без ограничений), сериализуется в виде последовательностей, содержащих до 3 байтов каждая, и некоторые байты, запрещенные реализацией (например, нулевые символы или дробная черта ‘ / ‘в файловой системе или другие однобайтовые символы в других протоколах) кодируются как двухбайтовые управляющие последовательности, ни одна из которых не равна нулю, просто с использованием принципа кодирования первой спецификации FSS-UTF (перед той, которая сохраняется в X / Open Consortium в его первоначальном RFC, где эти побеги были специально запрещены и остались таковыми).

До принятия предложения UTF-2, сохраненного для UTF-8, существовал также вариант UTF-1, в котором несколько кодировок было невозможно, но требовалось более сложное кодирование / декодирование для учета положения каждого байта. И использование ряд «магических» значений.

Эти варианты не следует называть «UTF-8».

Однако один из этих нестандартных вариантов был предметом более поздней стандартизации (в качестве альтернативы UTF-16 и с использованием пар «полукодов», каждый из которых закодирован по 3 байта, то есть всего 6 байтов вместо 4. с UTF-8): см. CESU-8 .

Пример варианта, используемого в Java

Например, API-интерфейсы интеграции виртуальных машин Java (для JNI, Java Native Interface или для сериализации предварительно скомпилированных классов), которые позволяют обмениваться неограниченными строками Java в форме последовательностей байтов (для манипулирования ими, использования или создания с помощью собственного кода или для хранения в виде собственного файла, закодированного в строках байтов), имеют суффикс «UTFChars» или «UTF», но эта специфичная для Java кодировка не является UTF-8 (в документации Sun это называется модифицированный UTF , но некоторые старые документы JNI по-прежнему неправильно называют эту кодировку UTF-8 , что привело к некоторым аномалиям поведения некоторых собственных библиотек JNI, особенно с системными API (более старые собственные платформы, которые изначально не поддерживают кодировки символов более 8 бит ), потому что:

нулевой символ, присутствующий как таковой в строке Java, кодируется как два ненулевых байта (и ни один нулевой байт, используемый для обозначения конца последовательности);
полукодовые точки (в английских суррогатах , назначенных между U + D000 и U + D7FF) могут быть закодированы свободно в любом порядке, как и кодовые точки, обычно запрещенные для кодирования символов (например, U + FFFF или U + FFFE) : проверка достоверности не требуется;
более длинные байтовые последовательности (более 4 байтов для представления символов за пределами базовой многоязычной плоскости), нормализованные и действительные в UTF-8, не распознаются виртуальной машиной в ее модифицированных API на основе UTF (что вызывает исключения во время преобразования, запрошенного собственным кодом 8-битную строку в строку Java, управляемую виртуальной машиной): затем необходимо перекодировать символы вне базовой плоскости (и закодированные в 4 байтах в UTF-8) в виде двух последовательностей по три байта в модифицированном UTF — по одному на каждый суррогат (как в кодировке CESU-8 ) и соответствие Java строкам Unicode должно проверяться и управляться исключениями;
Строки Java (системного класса String) и числовой тип char также используются для хранения (в компактной, немодифицируемой и совместно используемой форме) любых двоичных данных (не только текста), а также ими можно манипулировать в других кодировках, кроме UTF-16 (единственное ограничение состоит в том, что отдельные единицы кодирования не должны превышать 16 бит и должны иметь положительное значение, причем самый старший бит не оценивается как знаковый бит).

приложения, написанные на чистой Java (без собственного кода) и требующие реализации ограничений кодирования для соответствия Unicode для текста, должны явно запрашивать его и использовать один из предоставленных фильтров кодирования (для UTF-8, а также для UTF-16), или создавать и использовать классы на основе класса String и числового типа char;
действительный текст UTF-8 (и манипулируемый в машинном коде в строках без нулевых символов) требует предварительной обработки, прежде чем он может быть передан в JVM через JNI; в частности, любая последовательность, закодированная в 4 байта (для символа вне базовой плоскости), должна быть транскодирована в две последовательности по 3 байта ;
строки, полученные из JVM через интерфейсы UTF JNI, требуют предварительной обработки проверки действительности или фильтрации в машинном коде, прежде чем их можно будет использовать в качестве действительного текста UTF-8 (необходимо обнаруживать вхождения нулевого символа, закодированного в два байта, и, если это символ приемлем для собственного кода, перекодируйте его в один байт; собственный код должен проверить правильность пары суррогатов , каждый из которых закодирован по 3 байта , и отфильтровать их, если эти последовательности не отклоняются как недопустимые, затем перекодировать любые допустимая пара суррогатов только в одну 4-байтовую последовательность, а не в две 3-байтовые последовательности ).

Эти процессы могут быть неэффективными для взаимодействия с большими объемами текста, поскольку они требуют выделения дополнительных буферов памяти для последующего взаимодействия в машинном коде с системными или сетевыми интерфейсами, которые принимают только стандартный UTF-8.

Однако JNI также предоставляет более эффективный двоичный API, позволяющий использовать UTF-16 напрямую, способный напрямую взаимодействовать с сетевыми протоколами и системными интерфейсами (например, Windows API), которые поддерживают UTF-16, без необходимости выделения дополнительной памяти для транскодирования (только соответствие проверка может быть необходима, в основном для проверки в закодированном тексте правильного сочетания полукода или суррогата , которым Java (как и другие языки программирования) позволяет манипулировать без ограничения действительности в своих собственных символьных строках, не предназначенных для хранения только текстов соответствует UCS). Этот двоичный API поддерживается во всех системах, в которые была перенесена Java, даже в тех, чья операционная система не предлагает текстовый API Unicode (поддержка может осуществляться в собственном приложении хоста или с помощью стандартных библиотек, поставляемых с JVM или другими независимыми собственными библиотеки.

Примечания и ссылки

↑https://www.unicode.org/L2/Historical/wg20-n193-fss-utf.pdf .
↑«Использование кодировок символов для веб-сайтов» , на W3Techs (см. 18 декабря 2014 г. ).
↑ a и b«Использование кодировок символов для веб-сайтов» на сайте W3Techs (по состоянию на 13 сентября 2016 г.).
↑ (in) « Статистика использования кодировок символов для веб-сайтов, декабрь 2017 г.» на сайте w3techs.com (по состоянию на 28 декабря 2017 г. )
↑« Обзор использования кодировок символов с разбивкой по рейтингу» на сайте w3techs.com (по состоянию на 15 февраля 2019 г. ) .
↑ (в) Запрос на комментарии п O 2044 .
↑ (в) Запрос на комментарии п O 2279 .
↑ а и б (о) Запрос комментариев п уплотнительных 3629 .
↑ Однако на этой странице, прослеживающей историю кодирования UTF-8 до 1996 года, говорится: « Символы в кодировкеUTF-8 теоретически могут иметь длину до шести байтов », тем самым ссылаясь на набор возможных значений (более двух миллиардов, кодируется максимум 31 битом) в первоначальной (ныне устаревшей) редакции ISO / IEC 10646, ср. раздел Последовательные ограничения .
↑ (in) Часто задаваемые вопросы по UTF-8 и Unicode : «По соображениям безопасности программа, которая декодирует символы в UTF-8, не должна принимать последовательности UTF-8, которые длиннее, чем необходимо для кодирования этих символов. Это может привести к злоупотреблению проверкой подстроки, которая будет проверять только самые короткие кодировки. » .
↑История создания UTF-8 — Роб Пайк .
↑Файловая система Safe UCS Transformation Format (FSS-UTF) .
↑ (в) Марк Дэвис , » Unicode приближается к 50% в сети » , официальный блог Google , Google , 28 января 2010 г. (по состоянию на 5 декабря 2010 г. ) .
↑ (in) Эрик ван дер Поэль , « Рост UTF-8 в Интернете (ответ) » в блоге W3C, W3C, 8 мая 2008 г. (по состоянию на 6 августа 2015 г. ) .
↑ w3techs.com/faq.
↑https://w3techs.com/technologies/history_overview/character_encoding/ms/y .
↑http://java.sun.com/docs/books/jni/html/types.html#58973 .

Смотрите также

Статьи по Теме

UTF-16 , UTF-32 , CESU-8
Юникод , ISO / IEC 10646
ISO / IEC 646
ИСО / МЭК 8859 , ИСО / МЭК 8859-1
Парсинг

Специальные блоки символов Unicode, содержащие не символы

Таблица символов Юникода — ползона с высоким косвенным указанием
Таблица символов Юникода — нижняя половина косвенного обращения
Таблица символов Unicode — образует арабское Представление ( 2 е часть)
Таблица символов Unicode — для области: специальные символы , дополнительная многоязычная плоскость , дополнительная идеографическая плоскость , плоскость 3 , уровень 4 , уровень пять , уровень шесть , плоскость 7 , плоскость 8 , плоскость 9 , карта 10 , карта 11 , карта 12 , план 13 , дополнительная специализированная планировка , дополнительная зона А для частного пользования , дополнительная зона В для частного пользования

Внешние ссылки

(ru) Форма преобразования UTF-8, UTF-16, UTF-32
(ru) Conformité — Перевод стандарта Unicode на французский язык [PDF]
(о) Консорциум Unicode , Unicode , стандарт, версия 6.0.0 , Mountain View (Калифорния, США), февраль 2011 ( ISBN978-1-936213-01-6 , онлайн-презентация , читать онлайн ) , гл. 3 («Соответствие») , стр. 88–100 .

(ru) RFC 3629 — UTF-8, формат преобразования ISO 10646 , ноябрь 2003 г. (стандарт, полностью совместим с Unicode):

(ru) RFC 2279 — UTF-8, формат преобразования ISO 10646 , Январь 1998 (старая ревизия, устаревшая);
(ru) RFC 2044 — UTF-8, формат преобразования Unicode и ISO 10646 , Октябрь 1996 (первоначальная версия одобрена IETF, устарела);
(еп) Оригинальная статья на UTF-8 , по Роб Пайк и Кен Томпсон (познавательного, устаревшее) [PDF] .

NFC (предварительно составленная, рекомендуемая форма)
NFD (разложенный)
NFKC ( составлен для совместимости)
NFKD (с разбивкой для совместимости)

ISO 15924
Сломанный
планирование УЦА
Двунаправленный текст
Спецификация

UTF-8 — UTF-8

UTF-8 — это ширины кодировка символов, используемая для электронного обмена данных. Определено стандартом Unicode, является производным от формата преобразования Unicode (или универсального кодового набора символов) — 8-бит.

UTF-8 может кодировать все 1 112 064 действующих символов кодовых точек в Unicode с использованием от одной до четырех однобайтных (8-битных) кодовых единиц. которые имеют тенденцию к распространению чаще, кодируются с использованием меньшего количества байтов. Он разработан для обратной совместимости с ASCII : f Первые 128 символов Unicode, которые взаимно однозначно соответствуют ASCII, кодируются с использованием одного байта с тем же двоичным числом, что и ASCII, так что действительный текст ASCII также является действительным Unicode в кодировке UTF-8. Бывают байты ASCII не встречаются при кодировании кодовых точек, отличных от ASCII, в UTF-8, UTF-8 можно безопасно использовать в большинстве языков программирования и документов, которые интерпретируют символы ASCII особым образом, например «/» (косая черта ) в именах файлов, «\» (обратная косая черта ) в escape-последовательностях и «%» в printf.

UTF-8 был разработан как улучшенная альтернатива UTF-1, предлагаемую кодировку вариантов с частичной совместимостью с ASCII, в которой отсутствуют некоторые функции, включая самосинхронизацию и полностью совместимую с ASCII обработкой символов, как косая черта. Кен Томпсон и Роб Пайк выполнить первую работу для операционной системы План 9 в сентябре 1992 года. Это привело к ее принятию в X / Open в качестве спецификации для FSS-UTF, которая сначала была представлена на USENIX в январе 1993 г. и принята Инженерная группа Интернета (IETF) в RFC. 2277 (BCP 18) для будущих стандартов, заменяя однобайтовые наборы символов, такие как Latin-1, в старых RFC.

UTF-8 на сегодняшний день является наиболее распространенной кодировкой для World Wide Web, составляющая более 95% всех веб-страниц и до 100% для некоторых языков по состоянию на 2020 г..

1 Принятие

2 Кодирование

2.1 Примеры
2.2 Схема кодовой страницы
2.3 Слишком длинные кодировки
2.4 Недопустимые последовательность и обработка ошибок
2.5 Метка порядка байтов

6.1 Однобайтный
6.2 Другие многобайтовые
6.3 UTF-16

7.1 CESU -8
7.2 MySQL utf8mb3
7.3 Модифицированный UTF-8
7.4 WTF-8
7.5 PEP 383

Принятие

Использование основных кодировок в Интернете с 2001 по 2012 год, как было зарегистрировано Google, при UTF-8 обогнал все остальные в 2008 году и более 60% Интернета в 2012 году. ASCII -только цифра включает все веб-страницы, которые содержат только символы ASCII независимо от объявленного заголовка.

UTF-8 является рекомендацией для m WHATWG для HTML и DOM спецификация, а Консорциум электронной почты рекомендует, чтобы все программы электронной почты могли создавать и создавать почту с использованием UTF-8.

Google сообщил, что в 2008 году UTF-8 (помеченный как «Unicode») стала наиболее распространенной кодировкой для файлов HTML.

С 2009 года UTF-8 была самой распространенной кодировкой для Всемирная паутина. Консорциум World Wide Web рекомендует UTF-8 в кодировках по умолчанию в XML и HTML (а не только с использованием UTF-8, но и с указанием его в метаданных), «даже если все символы находятся в диапазоне ASCII. Использование кодировок, отличных от UTF-8, может привести к неожиданным результатам ». Многие другие стандарты только UTF-8, например open JSON exchange требует этого.

По состоянию на октябрь 2020 года на UTF-8 приходится в среднем 95,5% всех веб-страниц и 97% из 1000 самых популярных веб-страниц. (При этом учитывается, что ASCII является допустимым UTF-8.) Некоторые используют использование UTF-8 на 100,0% в сети, например пенджаби, тагалог, лаосский, маратхи, каннада, курдский, Пушту, яванский, гренландский (калааллисут ) и иранские языки и жестовые языки.

В регионах, где UTF-8 используется вместе с другой кодировкой, обычно последняя более эффективен для связанного языка. Китайский стандарт GB 2312 и с его расширением GBK (оба интерпретируются веб-браузерами как GB 18030, с поддержкой те же буквы, что и UTF-8) в совокупности 14,5% имеют доли в Китае и 0,5% во всем мире. Big5 — еще одна популярная китайская кодировка, доля которой во всем мире составляет 0,1%. Однобайтный Windows-1251 вдвое эффективноенее кириллицы и используется на 10,6% российских веб-сайтов. Например. Кодировки на греческом и иврите также вдвое эффективнее, но все же на этих языках более 95% используется UTF-8. EUC-KR более эффективен для корейского текста и используется для 17,3% южнокорейских веб-сайтов. Shift JIS и EUC-JP занимают 10,5% доли на японских веб-сайтах (более популярный Shift JIS имеет мировую долю 0,2%). За исключением GB 18030 и UTF-16, эти кодировки были разработаны для определенных языков и не все символы Unicode. По состоянию на сентябрь 2020 года бретонский язык имеет самый низкий уровень использования UTF-8 в Интернете из всех отслеживаемых языков, с использованием 79,4%.

Международные компоненты для Unicode (ICU) исторически использовались UTF-16 и по-прежнему работает только для Java; в то время как для C / C ++ UTF-8 теперь поддерживается как «Кодировка по умолчанию», включая правильную обработку «недопустимого UTF-8».

Использование UTF-8 для локальных текстовых файлов меньше, устаревшие однобайтовые кодировки остаются в использовании. В свою очередь, это связано с тем, что редакторы не будут отображать или записывать UTF-8, если первый символ в файле не является первой меткой байтов, что делает невозможным использование UTF-8 другим программным без перезаписи, чтобы игнорировать отметьте порядок байтов на входе и его на выходе. Файлы UTF-16 также распространены в Windows, но не где-либо еще. Внутреннее использование программного обеспечения еще меньше, с использованием UCS-2 и UTF-32, особенно в Windows, но также Python, JavaScript, Qt и многих других программных библиотек. Это связано с закрытием, что прямое индексирование кодовых точек более важно, чем 8-битная совместимость. UTF-16 также используется из-за совместимости с UCS-2, хотя он не имеет прямого индексирования. Microsoft теперь рекомендует UTF-8 для программ Windows, хотя раньше они делали упор на «Unicode» (то есть UTF-16) Win32 API, это может означать, что внутреннее использование UTF-8 будет расширяться в будущем.

Кодирование

значение в 2003 году кодовое пространство Unicode было ограничено 21-битными значениями, UTF-8 определен для кодирования кодовых точек от одного до четырех байтов, в зависимости от количества значащих битов в числовом кодовой точки. В следующей программе через структуру кодировки. Символы x заменяются битами кодовой точки.

Структура байтовых последовательностей UTF-8

Количество байтов	Первая кодовая точка	Последняя кодовая точка	Байт 1	Байт 2	Байт 3	Байт 4
1	U + 0000	U + 007F	0xxxxxxx
2	U + 0080	U + 07FF	110xxxxx	10xxxxxx
3	U + 0800	U + FFFF	1110xxxx	10xxxxxx	10xxxxxx
4	U + 10000	U + 10FFFF	11110xxx	10xxxxxx	10xxxxxx	10xxxxxx

Первые 128 символов (US-ASCII) занимают один байт. Следующим 1920 символам требуется два байта для кодирования, что покрывает остаток почти всех алфавитов латинского алфавита, а также греческого, кириллица, коптского, армянский, иврит, арабский, сирийский, Thaana и N’Ko алфавиты, а также комбинированные диакритические знаки. Три байта необходимы для символов в остальной части многоязычной плоскости, которая содержит практически все широко используемые символы, включая большинство китайских, японских и корейских символов. Четыре байта необходимы для символов в других плоскостях Unicode, которые включают менее распространенные символы CJK, различные исторические сценарии, математические символы и эмодзи (пиктографические символы).

Примеры

Кодовая точка Unicode для «€» — U + 20AC.
Эта кодовая точка находится между U + 0800 и U + FFFF, для кодирования три байта.
Шестнадцатеричный кодирования 20AC — двоичный 0010 0000 1010 1100. Два ведущих нуля добавляются для трехбайтового кодирования требуется ровно шестнадцать битов от кодовой точки.
кодирование будет иметь длину три байта, его ведущий байт начинается с трех, затем с 0 (1110. )
Четыре старших бита кодовой точки сохраняются в оставшихся четырех младших битах этого байта (1110 0010), оставляя 12 битов кодовой точки, которую еще предстоит закодировать (. 0000 1010 1100).
Все байты продолжения содержат ровно шесть битов от кодовой точки. Таким образом, следующие шесть бит кодовой точки сохраняются в шести младших битах следующего байта, а 10 сохраняются в двух старших битах, чтобы пометить его как байт продолжения (поэтому 1000 0010).
Наконец, последние шесть бит кодовой точки сохраняются в шести младших битах последнего байта, и снова 10 сохраняет в двух старших битах (1010 1100).

Три байта 1110 0010 1000 0010 1010 1100 можно более кратко записать в шестнадцатеричном формате, как E2 82 AC.

Представлена приведенная сводка этого преобразования с разной длиной в UTF-8. Цвета показывают, как биты из кодовой точки распределяются между байтами UTF-8. Дополнительные биты, добавленные в процессе кодирования UTF-8, показаны черным.

Представление символов UTF-8

Символ		Кодовая точка		UTF-8
Символ		Восьмеричный	Двоичный	Двоичный	Восьмеричное	Шестнадцатеричное
$	U + 0024	044	010 0100	00100100	044	24
¢	U + 00A2	0242	000 1010 0010	11000010 10100010	302 242	C2 A2
ह	U + 0939	004471	0000 1001 0011 1001	11100000 10100100 10111001	340 244 271	E0 A4 B9
€	U + 20AC	020254	0010 0000 1010 1100	11100010 10000010 10101100	342202254	E2 82 AC
한	U + D55C	152534	1101 0101 0101 1100	11101101 10010101 10011100	355225 234	ED 95 9C
��	U + 10348	0201510	0 0001 0000 0011 0100 1000	11110000 10010000 10001101 10001000	360 220 215 210	F0 90 8D 88

Использование UTF-8 шести битов на байт для представления фактических кодируемых символов означает, что восьмеричная нотация (которая использует 3-битную г руппы) может помочь в сравнении последовательностей UTF-8 с e другой.

Макет кодовой страницы

В следующей таблице обобщено использование модулей кода UTF-8 (отдельные байты или октеты) в формате кодовой страницы. Верхняя половина (от 0_ до 7_) предназначена для байтов, используется только в однобайтовых кодах, поэтому она выглядит как обычная кодовая страница; нижняя половина предназначена для байтов продолжения (от 8_ до B_) и ведущих байтов (от C_ до F_) и объясняется далее в легенде ниже.

UTF-8

_0	_1	_2	_3	_4	_5	_6	_7	_8	_9	_A	_B	_C	_D	_E	_F
0_	NUL. 0000	SOH. 0001	STX. 0002	ETX. 0003	EOT. 0004	ENQ. 0005	ACK. 0006	BEL. 0007	BS. 0008	HT. 0009	LF. 000A	VT. 000B	FF. 000C	CR. 000D	SO. 000E	SI. 000F
1_	DLE. 0010	DC1. 0011	DC2. 0012	DC3. 0013	DC4. 0014	NAK. 0015	SYN. 0016	ETB. 0017	CAN. 0018	EM. 0019	SUB. 001A	ESC. 001B	FS. 001C	GS. 001D	RS. 001E	US. 001F
2_	SP. 0020	!. 0021	«. 0022	#. 0023	$. 0024	%. 0025	. 0026	‘. 0027	(. 0028	). 0029	*. 002A	+. 002B	,. 002C	-. 002D	.. 002E	/. 002F
3_	0. 0030	1. 0031	2. 0032	3. 0033	4. 0034	5. 0035	6. 0036	7. 0037	8. 0038	9. 0039	:. 003A	;. 003B	. 003E	?. 003F
4_	@. 0040	A. 0041	B. 0042	C. 0043	D. 0044	E. 0045	F. 0046	G. 0047	H. 0048	I. 0049	J. 004A	K. 004B	L. 004C	M. 004D	N. 004E	O. 004F
5_	P. 0050	Q. 0051	R. 0052	S. 0053	T. 0054	U. 0055	V. 0056	W. 0057	X. 0058	Y. 0059	Z. 005A	[. 005B	\. 005C	]. 005D	^. 005E	_. 005F
6_	`. 0060	a. 0061	b. 0062	c. 0063	d. 0064	e. 0065	f. 0066	g. 0067	h. 0068	i. 0069	j. 006A	k. 006B	l. 006C	m. 006D	n. 006E	o. 006F
7_	p. 0070	q. 0071	r. 0072	s. 0073	t. 0074	u. 0075	v. 0076	w. 0077	x. 0078	y. 0079	z. 007A	<. 007B	\|. 007C	>. 007D	~. 007E	DEL. 007F
8_	•. +00	•. +01	•. +02	•. +03	•. +04	•. +05	•. +06	•. +07	•. +08	•. +09	•. + 0A	•. + 0B	•. + 0C	•. + 0D	•. + 0E	•. + 0F
9_	•. +10	•. +11	•. +12	•. +13	•. +14	•. +15	•. +16	•. +17	•. +18	•. + 19	•. + 1A	•. + 1B	•. + 1C	•. + 1D	•. + 1E	•. + 1F
A_	•. +20	•. +21	•. + 22	•. +23	•. +24	•. +25	•. +26	•. +27	•. +28	•. +29	•. + 2A	•. + 2B	•. + 2C	•. + 2D	•. + 2E	•. + 2F
B_	•. +30	•. +31	•. +32	•. +33	•. +34	•. +35	•. +36	•. +37	•. +38	•. +39	•. + 3A	•. + 3B	•. + 3C	•. + 3D	•. + 3E	•. + 3F
2. C_	2. 0000	2. 0040	Латинский. 0080	Латинский. 00C0	Латинский. 0100	Латинский. 0140	Латинский. 0180	Латинский. 01C0	Латинский. 0200	IPA. 0240	IPA. 0280	IPA. 02C0	акценты. 0300	акценты. 0340	греческий. 0380	Греческий. 03C0
2. D_	Кирилл. 0400	Кирилл. 0440	Кирилл. 0480	Кирилл. 04C0	Кирилл. 0500	Армени. 0540	Иврит. 0580	Иврит. 05C0	Арабский. 0600	Арабский. 0640	Арабский. 0680	Араб ский. 06C0	Сирийский. 0700	Арабский. 0740	Тхана. 0780	Н’Ко. 07C0
3. E_	Индийский. 0800	Разное. 1000	Символ. 2000	Кана …. 3000	CJK. 4000	CJK. 5000	CJK. 6000	CJK. 7000	CJK. 8000	CJK. 9000	азиатский. A000	хангыль. B000	Хангыль. C000	Хангыль. D000	PUA. E000	Формы. F000
4. F_	SMP…. 10000	��. 40000	��. 80000	SSP…. C0000	SPU…. 100000	4. 140000	4. 180000	4. 1C0000	5. 200000	5. 1000000	5. 2000000	5. 3000000	6. 4000000	6. 40000000

Синие ячейки предоставляют собой 7-битные (однобайтовые) следовать. За ними не должен следовать байт продолжения.

Оранжевые ячейки с большой точкой байтами продолжения. Шестнадцатеричное число, показанное после символа +, число 6 добавляемых битов.

Белые ячейки — это ведущие байты для выполнения из нескольких байтов, длина которой указана у левого края строки. В тексте показаны блоки Unicode, закодированные последовательности, начинающиеся с байта, шестнадцатеричная кодовая точка, показанная в ячейке, наименьшим числом символов, закодированным с использованием ведущего байта.

Красные ячейки никогда не должны появляться в допустимой последовательности UTF-8. Первые две красные ячейки (C0 и C1) могут быть только для 2-байтового кодирования 7-битного символа ASCII, который должен быть закодирован в 1 байт; как описано ниже, такие «слишком длинные» запрещены. Красные ячейки в строке F_ (от F5 до FD) указывают ведущие байты 4-байтовых или более длинных последовательностей, которые не могут быть действительными, потому что они могут кодировать кодовые точки, превышающие пределы U + 10FFFF Unicode (предел, полученный из максимальной кодовой точки, кодируемой в UTF-16 ). FE и FF не соответствуют ни одному разрешенному шаблону символов и поэтому являются допустимыми стартовыми байтами.

Некоторые из следующих, но не все, последовательных последовательностей, вводят некоторые из них. E0 и F0 может начинать кодирование с чрезмерной длиной, в этом случае отображается самая низкая кодовая точка с кодированием чрезмерного кодирования. F4 может запускать кодовые точки больше, чем U + 10FFFF, которые недопустимы. ЭД может начать кодирование кодовой точки в диапазоне U + D800 — U + DFFF; они недействительны, так как они зарезервированы для UTF-16 суррогатных половин.

Сверхдлинные кодировки

В принципе, можно было бы увеличить количество байтов в кодировке, добавив кодовую точку с ведущими 0 с. Чтобы закодировать пример в четырех байтах вместо трех, он может быть дополнен ведущими нулями, пока он не станет длиной 21 бит — 000 000010 000010 101100, и закодирован как 11110000 10000010 10000010 10101100 (или F0 82 82 AC в шестнадцатеричном формате). Это слишком длинным кодированием.

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

Недопустимые придерживаться и обработка ошибок

Не все придерживаться допустимы для UTF-8. Декодер UTF-8 должен быть подготовлен к:

недопустимым байтам
неожиданному байту продолжения
байту непродолжения до конца символа
завершение строки до конца символа (что может произойти при простом усечении строки)
чрезмерно длинное кодирование
последовательность, которая декодируется до недопустимой кодовой точки

Многие из первых UTF-8 декодеры будут их декодировать, игнорируя неправильные биты и принимая слишком длинные результаты. Тщательно созданный недопустимый код UTF-8 может заставить их либо пропускать, либо создавать символы ASCII, такие как NUL, косую черту или кавычки. Недействительный код UTF-8 использовался для обхода проверок безопасности в популярных продуктах, включая веб-сервер Microsoft IIS и контейнер сервлетов Apache Tomcat. RFC 3629 гласит: «Реализации алгоритма декодирования ДОЛЖНЫ защищать от декодирования недопустимых последовательностей». Стандарт Unicode требует, чтобы декодеры «. обрабатывали любую некорректно сформированную последовательность кодовых единиц как состояние ошибки. Это гарантирует, что они не будут интерпретировать и генерировать неверно сформированную последовательность кодовых единиц».

Начиная с RFC 3629 (ноябрь 2003 г.), верхняя и нижняя суррогатные половины используются UTF-16 (от U + D800 до U + DFFF), а кодовые точки не кодируемые UTF-16 (после U + 10FFFF) не являются допустимыми значениями Unicode, и их кодировка UTF-8 должна рассматриваться как недопустимая последовательность байтов. Отсутствие декодирования непарных суррогатных половин делает невозможным сохранение недопустимого UTF-16 (например, имен файлов Windows или UTF-16, который был разделен между суррогатами) как UTF-8.

Некоторые реализации декодеров выдают исключения при ошибках. У этого есть недостаток, заключающийся в том, что он может превратить то, что в противном случае было бы безвредной ошибкой (например, ошибка «нет такого файла») в отказ в обслуживании. Например, ранние версии Python 3.0 будут немедленно завершаться, если командная строка или переменные среды содержали недопустимый UTF-8. Альтернативная практика — заменить ошибки символом замены. Начиная с Unicode 6 (октябрь 2010 г.), стандарт (глава 3) рекомендовал «наилучшую практику», при которой ошибка прекращается, как только встречается запрещенный байт. В этих декодерах E1, A0, C0 — это две ошибки (2 байта в первом). Это означает, что длина ошибки не превышает трех байтов и никогда не содержит начало действительного символа, и существует 21 952 различных возможных ошибки. Стандарт также рекомендует заменять каждую ошибку символом замены » » (U + FFFD).

Знак порядка байтов

Если знак порядка байтов UTF-16 знак порядка байтов (BOM) находится в начале файла UTF-8, первые три байта будут быть 0xEF, 0xBB, 0xBF.

Стандарт Unicode не требует и не рекомендует использовать BOM для UTF-8, но предупреждает, что он может встретиться в начале файла, перекодированного из другой кодировки. Хотя текст ASCII, закодированный с использованием UTF-8, обратно совместим с ASCII, это неверно, когда рекомендации стандарта Unicode игнорируются и добавляется спецификация. Тем не менее было и остается программное обеспечение, которое всегда вставляет спецификацию при записи UTF-8 и отказывается правильно интерпретировать UTF-8, если только первый символ не является спецификацией (или файл содержит только ASCII).

Именование

Официальный код Internet Assigned Numbers Authority (IANA) для кодировки — «UTF-8». Все буквы в верхнем регистре, а имя расставлено через дефис. Это написание используется во всех документах Консорциума Unicode, касающихся кодировки.

В качестве альтернативы имя «utf-8» может использоваться всеми стандартами, соответствующими списку IANA (который включает CSS, HTML, XML и заголовки HTTP ), поскольку в объявлении регистр не учитывается.

Другие описания, например, в которых дефис опускается или заменяется пробелом, например «utf8» или « UTF 8 «не признаются действующими стандартами как правильные. Несмотря на это, большинство агентов, таких как браузеры, могут их понять, и поэтому стандарты, предназначенные для описания существующей практики (например, HTML5), могут фактически потребовать их распознавания.

Неофициально, UTF-8-BOM и UTF-8-NOBOM иногда используются для обозначения текстовых файлов, которые соответственно содержат или не содержат метку порядка байтов (BOM). В частности, в Японии кодировка UTF-8 без спецификации иногда называется «UTF-8N».

Windows 7 и более поздние версии, то есть все поддерживаемые версии Windows, имеют кодовую страницу 65001, как синоним для UTF-8 (с лучшей поддержкой, чем в более старых версиях Windows), и у Microsoft есть сценарий для Windows 10, чтобы включить его по умолчанию для своей программы Microsoft Notepad.

в PCL, UTF-8 называется идентификатором символа «18N» (PCL поддерживает 183 кодировки символов, называемых наборами символов, которые потенциально могут быть сокращены до одной, 18N, то есть UTF-8).

История

Международная организация по стандартизации (ISO) в 1989 году решила составить универсальный многобайтовый набор символов. Проект стандарта ISO 10646 содержал необязательное приложение называется UTF-1, который обеспечивает кодировку потока байтов его 32-битных кодовых точек. Эта кодировка не была удовлетворительной с точки зрения производительности, среди других проблем, и самая большая проблема, вероятно, заключалась в том, что в ней не было четкого разделения между ASCII и не-ASCII: новые инструменты UTF-1 будут обратно совместимы с текстом в кодировке ASCII, но Текст в кодировке UTF-1 может сбить с толку существующий код, ожидающий ASCII (или расширенный ASCII ), поскольку он может содержать байты продолжения в диапазоне 0x21–0x7E, что означает что-то еще в ASCII, например, 0x2F для ‘/’, разделитель каталогов Unix путь, и этот пример отражен в имени и вводном тексте его замены. Приведенная ниже таблица основана на текстовом описании в приложении.

UTF-1

Число. байтов	Первая. кодовая точка	Последняя. кодовая точка	Байт 1	Байт 2	Байт 3	Байт 4	Байт 5
1	U + 0000	U + 009F	00–9F
2	U + 00A0	U + 00FF	A0	A0 – FF
2	U + 0100	U + 4015	A1 – F5	21–7E, A0 – FF
3	U + 4016	U + 38E2D	F6 – FB	21–7E, A0 – FF	21–7E, A0 – FF
5	U + 38E2E	U + 7FFFFFFF	FC – FF	21–7E, A0 – FF	21–7E, A0 – FF	21–7E, A0 – FF	21–7E, A0 – FF

В июле 1992 года комитет X / Open XoJIG искал лучшую кодировку. Дэйв Проссер из Unix System Laboratories представил предложение о более быстрой реализации и внес улучшение, заключающееся в том, что 7-битные символы ASCII будут представлять только себя; все многобайтовые последовательности будут включать только байты, в которых установлен старший бит. Имя File System Safe UCS Transformation Format (FSS-UTF) и большая часть текста этого предложения были позже сохранены в окончательной спецификации.

Предложение FSS-UTF (1992)

Number. байтов	Первая. кодовая точка	Последняя. кодовая точка	Байт 1	Байт 2	Байт 3	Байт 4
1	U + 0000	U + 007F	0xxxxxxx
2	U + 0080	U + 207F	10xxxxxx	1xxxxxxx
3	U + 2080	U + 8207F	110xxxxx	1xxxxxxx	1xxxxxxx
4	U + 82080	U + 208207F	1110xxxx	1xxxxxxx	1xxxxxxx	1xxxxxxx
5	U + 2082080	U + 7FFFFFFF	11110xxx	1xxxxxxx	1xxxxxxxx	776>1xxxxxxx

В августе 1992 года это предложение было распространено представителем IBM X / Open среди заинтересованных сторон. Модификация, внесенная Кеном Томпсоном из группы Plan 9 операционной системы в Bell Labs, сделала ее несколько менее эффективной по сравнению с предыдущим предложением. но, что очень важно, это позволило ему быть самосинхронизирующимся, позволяя читателю начинать с любого места и немедленно обнаруживать границы последовательности байтов. Он также отказался от использования предвзятости и вместо этого добавил правило, согласно которому допускается только кратчайшее кодирование; дополнительная потеря компактности относительно невелика, но теперь читатели должны искать недопустимые кодировки, чтобы избежать проблем с надежностью и особенно безопасностью. Дизайн Томпсона был обрисован 2 сентября 1992 года на салфетке в закусочной в Нью-Джерси вместе с Робом Пайком. В последующие дни Пайк и Томпсон внедрили его и обновили Plan 9, чтобы использовать его повсюду, а затем сообщили о своем успехе обратно в X / Open, которая приняла его как спецификацию для FSS-UTF.

FSS-UTF (1992) / UTF-8 (1993)

Число. байтов	Первая. кодовая точка	Последняя. кодовая точка	Байт 1	Байт 2	Байт 3	Байт 4	Байт 5	Байт 6
1	U + 0000	U + 007F	0xxxxxxx
2	U + 0080	U + 07FF	110xxxxx	10xxxxxx
3	U + 0800	U + FFFF	1110xxxx	10xxxxxx	10xxxxxx
4	U + 10000	U + 1FFFFF	11110xxx	10xxxxxx	10xxxxxx	10xxxxxx
5	U + 200000	U + 3FFFFFF	111110xx	10xxxxxx	10xxxxxx	10xxxxxx	10xxxxxx
6	U + 4000000	U + 7FFFFFFF	1111110x	10xxxxxx	10xxxxxx	10xxxxxx	10xxxxxx	10xxxxxx

UTF-8 был впервые официально представлен на конференции USENIX в Сан-Диего с января 25–29, 1993 г. Инженерная группа Интернета приняла UTF-8 в своей Политике в отношении наборов символов и языков в RFC 2277 (BCP 18) для будущего Интернета. стандарты работают, заменяя однобайтовые наборы символов, такие как Latin-1 в старых RFC.

В ноябре 2003 года UTF-8 был ограничен RFC 3629 для соответствия ограничениям кодировки символов UTF-16 : явное запрещение кодовых точек, соответствующих старшим и младшим суррогатным символам, удаляет более 3% трехбайтовых последовательностей и заканчивается на U + 10FFFF удалил более 48% четырехбайтовых последовательностей и всех пяти- и шестибайтовых последовательностей.

Стандарты

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

RFC 3629 / STD 63 (2003), который устанавливает UTF-8 в качестве стандарта Элемент интернет-протокола
RFC 5198 определяет UTF-8 NFC для сетевого обмена (2008)
ISO / IEC 10646: 2014 §9.1 (2014)
Стандарт Unicode, версия 11.0 (2018)

Они заменяют определения, приведенные в следующих устаревших работах:

Стандарт Unicode, версия 2.0, приложение A (1996)
ISO / IEC 10646- 1: 1993 Поправка 2 / Приложение R (1996)
RFC 2044 (1996)
RFC 2279 (1998)
Стандарт Unicode, версия 3.0, §2.3 (2000) плюс Исправление №1: Кратчайшая форма UTF-8 (2000)
Стандартное приложение № 27 Unicode: Unicode 3.1 (2001)
Стандарт Unicode, версия 5.0 (2006)
Стандарт Unicode, версия 6.0 (2010)

Все они одинаковы по своей общей механике, с основными различиями в таких вопросах, как д опустимый диапазон кода. точечные значения и безопасная обработка недопустимого ввода.

Сравнение с другими кодировками

Вот некоторые из важных особенностей этой кодировки:

Обратная совместимость: обратная совместимость с ASCII и огромное количество программного обеспечения, предназначенного для обработки кодировок ASCII текст был основной движущей силой дизайна UTF-8. В UTF-8 отдельные байты со значениями в диапазоне от 0 до 127 отображаются непосредственно в кодовые точки Unicode в диапазоне ASCII. Отдельные байты в этом диапазоне представляют символы, как и в ASCII. Более того, 7-битные байты (байты, где старший бит равен 0) никогда не появляются в многобайтовой последовательности, и никакая допустимая многобайтовая последовательность не декодируется в кодовую точку ASCII. Последовательность 7-битных байтов является допустимой как ASCII, так и допустимой UTF-8, и при любой интерпретации представляет одну и ту же последовательность символов. Следовательно, 7-битные байты в потоке UTF-8 представляют все и только символы ASCII в потоке. Таким образом, многие текстовые процессоры, синтаксические анализаторы, протоколы, форматы файлов, программы отображения текста и т. Д., Которые используют символы ASCII для форматирования и управления, будут продолжать работать, как задумано, обрабатывая поток байтов UTF-8 как последовательность отдельных байтовые символы, без декодирования многобайтовых последовательностей. Символы ASCII, на которых выполняется обработка, такие как знаки пунктуации, пробелы и управляющие символы, никогда не будут кодироваться как многобайтовые последовательности. Поэтому для таких процессоров безопасно просто игнорировать или передавать многобайтовые последовательности без их декодирования. Например, пробелы ASCII могут использоваться для токенизации потока UTF-8 в слова; Перевод строки ASCII может использоваться для разделения потока UTF-8 на строки; и символы ASCII NUL могут использоваться для разделения данных в кодировке UTF-8 на строки с завершающим нулем. Точно так же многие строки формата, используемые библиотечными функциями, такими как printf, будут правильно обрабатывать входные аргументы в кодировке UTF-8.
Откат и автоопределение: только небольшое подмножество возможных байтовых строк является допустимым UTF-8 string: the bytes C0, C1, and F5 through FF cannot appear, and bytes with the high bit set must be in pairs, and other requirements. It is extremely unlikely that a readable text in any extended ASCII is valid UTF-8. Part of the popularity of UTF-8 is due to it providing a form of backward compatibility for these as well. A UTF-8 processor which erroneously receives extended ASCII as input can thus «auto-detect» this with very high reliability. Fallback errors will be false negatives, and these will be rare. Moreover, in many applications, such as text display, the consequence of incorrect fallback is usually slight. A UTF-8 stream may simply contain errors, resulting in the auto-detection scheme producing false positives; but auto-detection is successful in the majority of cases, especially with longer texts, and is widely used. It also works to «fall back» or replace 8-bit bytes using the appropriate code-point for a legacy encoding only when errors in the UTF-8 are detected, allowing recovery even if UTF-8 and legacy encoding is concat записаны в том же файле.
Код префикса : первый байт указывает количество байтов в последовательности. Чтение из потока может мгновенно декодировать каждую отдельную полностью принятую последовательность без предварительного ожидания первого байта следующей последовательности или индикации конца потока. Длину многобайтовых последовательностей люди легко определяют, поскольку это просто количество старших единиц в ведущем байте. Некорректный символ не будет декодирован, если поток заканчивается в середине последовательности.
Самосинхронизация : ведущие байты и байты продолжения не имеют общих значений (байты продолжения начинаются с битов 10, а одиночные байты начинаются с 0, а более длинные ведущие байты начинаются с 11). Это означает, что поиск случайно не найдет последовательность для одного символа, начинающегося в середине другого символа. Это также означает, что начало символа может быть найдено из случайной позиции путем резервного копирования не более 3 байтов, чтобы найти ведущий байт. Некорректный символ не будет декодирован, если поток начинается с середины последовательности, а более короткая последовательность никогда не появится внутри более длинной.
Порядок сортировки: выбранные значения ведущих байтов означают, что список UTF- 8 строк можно отсортировать в порядке кодовых точек путем сортировки соответствующих последовательностей байтов.

Однобайтовый

UTF-8 может кодировать любой символ Unicode, избегая необходимости вычислять и устанавливать » кодовая страница «или иным образом указать, какой набор символов используется, и разрешить вывод в нескольких сценариях одновременно. Для многих скриптов использовалось более одной однобайтовой кодировки, поэтому даже зная, что скрипт не содержал достаточной информации для его правильного отображения.
Байты 0xFE и 0xFF не отображаются, поэтому допустимый UTF-8 stream никогда не соответствует метке порядка байтов UTF-16 и, следовательно, не может быть перепутан с ней. Отсутствие 0xFF (0377) также устраняет необходимость экранирования этого байта в Telnet (и управляющем соединении FTP).
Текст в кодировке UTF-8 больше, чем специализированные однобайтовые кодировки, за исключением для простых символов ASCII. В случае скриптов, которые использовали 8-битные наборы символов с нелатинскими символами, закодированными в верхней половине (например, большинство кодовых страниц кириллицы и греческого алфавита ), символы в UTF- 8 будет вдвое больше. Для некоторых сценариев, таких как тайский и деванагари (который используется в различных языках Южной Азии), символы будут утроены. Есть даже примеры, когда один байт превращается в составной символ в Unicode и, таким образом, в шесть раз больше в UTF-8. Это вызвало возражения в Индии и других странах.
В UTF-8 (или в любой другой кодировке с переменной длиной) можно разделить или обрезать строку в середине символа. Если две части не будут повторно добавлены позже перед интерпретацией как символы, это может привести к недопустимой последовательности как в конце предыдущего раздела, так и в начале следующего, а некоторые декодеры не сохранят эти байты и приведут к потере данных. Поскольку UTF-8 является самосинхронизирующимся, он никогда не будет вводить другой допустимый символ, а также довольно легко переместить точку усечения назад в начало символа.
Если все кодовые точки имеют одинаковый размер., легко измерить их фиксированное количество. Из-за эпохи документации ASCII, где «символ» используется как синоним «байта», это часто важно. Однако, измеряя позиции с использованием байтов вместо «символов», большинство алгоритмов можно легко и эффективно адаптировать для UTF-8. Поиск строки в длинной строке может, например, кофе побайтово; свойство самосинхронизации предотвращает ложные срабатывания.

Другой многобайтный

UTF-8 может кодировать любой символ Unicode. Файлы в разных сценариях могут быть правильно без выбора правильной кодовой страницы или шрифта. Например, китайский и арабский языки могут быть записаны в одном файле без специальной разметки или ручных настроек, указывающих кодировку.
UTF-8 — это самосинхронизирующийся : границы символов легко определить по сканированию для четко битовых комбинаций в любом направлении. Если байты потеряны из-за ошибки или повреждения , всегда можно найти следующий допустимый символ и продолжить обработку. Если необходимо указать соответствие указанному полю, можно легко найти предыдущий допустимый символ. Многие многобайтовые кодировки, такие как Shift JIS намного сложнее повторно синхронизировать. Это также означает, что ориентированные на байтыалгоритмы поиска строк разговор с UTF-8 (как символ — это то же самое, что и «состоящее из такого количества байтов»), оптимизированные версии поиска байтов могут быть намного быстрее благодаря аппаратной поддержке и таблицам поиска, которые содержат всего 256 записей. Однако самосинхронизация требует, чтобы биты были зарезервированы для этих маркеров в каждом байте, увеличивая размер.
Эффективно кодировать с использованием простых побитовых операций. UTF-8 не требует более медленных математических операций, таких как умножение или деление (отличие от Shift JIS, GB 2312 и других кодировок).
UTF-8 займет больше места, чем многобайтный кодировка, предназначенная для конкретного скрипта. Унаследованные восточноазиатские кодировки обычно использовали два байта на символ, но занимали три байта на символе в UTF-8.

UTF-16

Байтовые кодировки и UTF-8 представлены в байтовыми массивами, и часто ничего не нужно делать для функций при преобразовании исходного кода из байтовой кодировки в UTF-8. UTF-16 представленми 16-битных слов, и для преобразования в UTF-16 при сохранении совместимости с существующими программами на основе ASCII (например, как это было сделано с Windows) требуется каждый API и структура данных, которая принимает систему для дублирования, одна версия принимает байтовые строки, другая версия принимает UTF-16. Если обратная совместимость не требуется, необходимо изменить всю обработку строк.

Текст, закодированный в UTF-8, будет меньше, чем тот же текст, закодированный в UTF-16, если кодовых точек ниже U + 0080 будет больше, чем в диапазоне U + 0800..U + FFFF. Это верно для всех современных европейских языков.

Текст на (например) китайском, японском или деванагари будет занимать больше места в UTF-8, если этих символов больше, чем символов ASCII. Это вероятно, когда данные в основном состоят из чистой прозы, насколько используются данные пробелы, цифры и символы ASCII.
Большинство форматов RTF (включая HTML) содержат большую часть символов ASCII для форматирования, поэтому размер обычно будет значительно уменьшен по сравнению с UTF-16, даже если язык в основном использует символы длиной 3 байта в UTF-8.

Порядок этих двух байтов становится проблемой и должен быть указан в протоколе UTF-16, например, с байтом Метка порядка.
. байтов отсутствует в UTF-16, вся остальная часть строки будет бессмысленным текстом. Любые байты, отсутствующие байты, по-прежнему позволяют точно восстанавливать текст, начиная со следующего символа после отсутствующих байтов.

Производные

Следующие реализации показывают небольшие отличия от спецификации UTF-8. Они несовместимы со спецификацией UTF-8 и могут отклоняться от приложениями UTF-8.

CESU-8

Технический отчет Unicode № 26 присваивает имя CESU-8 нестандартному варианту UTF-8, в котором символы Unicode в дополнительных плоскостях кодируются с использованием шести байтов, а не четыре байта, требуемые UTF-8. Кодировка CESU-8 обрабатывает каждую половину четырехбайтовой суррогатной пары UTF-16 как двухбайтовый символ UCS-2, в результате чего получается два трехбайтовых символа UTF-8, которые вместе включают исходный дополнительный символ. Символы Юникода в многоязычной плоскости обычно так же, как обычно в UTF-8. Отчет был написан для подтверждения и формы существования данных, закодированных как CESU-8, несмотря на то, что Консорциум Unicode не одобряет его использование, отмечает, что использование CESU-8 является причиной сохранения UTF-16 двоичное сопоставление.

Кодирование CESU-8 может быть результатом преобразования данных UTF-16 с дополнительными символами в UTF-8 с использованием методов преобразования, которые принимают данные UCS-2, то есть они не осведомлены о четырехбайтовых дополнительных символах UTF-16. Это в первую очередь проблема систем, которые широко используют UTF-16 внутри, таких как Microsoft Windows.

. В Oracle Database набор символов использует UTF8 CESU-8. кодировка и устарела. Набор символов AL32UTF8 использует кодировку UTF-8 и является предпочтительным.

ЦЕСУ-8 запрещено использовать в документах HTML5.

MySQL utf8mb3

В MySQL набор символов utf8mb3 как данные в кодировке UTF-8 с тремя байтами на символ, что означает только Unicode поддерживаются символы в Basic Multilingual Plane. Символы Unicode в дополнительных плоскостях явно не поддерживаются. utf8mb3 устарел в пользу набора символов utf8mb4 , который использует совместимую со стандарми кодировку UTF-8. utf8 — это псевдоним для utf8mb3 , но обязанным, что он станет псевдонимом для utf8mb4 в будущей версии MySQL. Возможно, хотя и не поддерживает, хранить данные в кодировке CESU-8 в utf8mb3 , обрабатывая данные UTF-16 с дополнительными символами, как если бы они были UCS-2.

Модифицированный UTF-8

Модифицированный UTF-8 (MUTF-8) возник на языке программирования Java. В модифицированном UTF-8 нулевой символ (U + 0000) двухбайтовую сверхдлинную кодировку 11000000 10000000 (шестнадцатеричный C0 80) вместо 00000000 (шестнадцатеричный 00). Модифицированные строки UTF-8 не содержат никаких фактических нулевых байтов, но могут содержать все кодовые точки Unicode, включая U + 0000, что позволяет обрабатывать такие строки (с добавленным нулевым байтом) традиционными функциями строки с нулевым символом в конце. Все известные реализации модифицированного UTF-8 также обрабатывают суррогатные пары, как в CESU-8.

. При обычном использовании язык поддерживает стандартный UTF-8 при чтении и записи строк через InputStreamReader и OutputStreamWriter (если это набор символов по умолчанию для платформы или по запросу программы). Однако он использует модифицированный UTF-8 для сериализации объекта среди других приложений DataInput и DataOutput для Собственный интерфейс Java, а также для встраивания константных строк в файлы классов.

Формат dex, определенный Dalvik, также использует тот же измененный UTF-8 для представления строковых значений. Tcl также использует тот же модифицированный UTF-8, что и Java, для представления внутренних данных Unicode, но использует строгий CESU-8 для внешних данных.

WTF-8

В WTF-8 (формат шаткого преобразования, 8-бит) разрешены непарные суррогатные половинки (от U + D800 до U + DFFF). Это необходимо для хранения возможно недопустимого UTF-16, например, имен файлов Windows. Многие системы, которые работают с UTF-8, работают таким образом, не считая его другим кодировкой, поскольку это проще.

(Термин «WTF-8» также использовался в шутливом смысле для обозначения , ошибочно дважды в кодировке UTF-8 иногда подразумевается, что кодируются только CP1252 байты)

PEP 383

Версия 3 программы Язык Python обрабатывает каждый байт недопустимого байтового потока UTF-8 как ошибка; это дает 128 различных агентов ошибок. Были созданы новые расширения, позволяющие преобразовать любую последовательность байтов, которая, как обязана, является UTF-8, без потерь в UTF-16 или UTF-32, путем преобразования 128 байтов приводятся ошибки в зарезервированные кодовые точки и преобразование этих кодовых точек обратно в ошибки. байтов для вывода UTF-8. Наиболее распространенный подход — преобразовать коды в U + DC80. U + DCFF, которые являются низкими (замыкающими) суррогатными значениями и, следовательно, «недействительными» UTF-16, как используется Python PEP 383 (или « суррогатного спасения ») подход. Другая кодировка под названием MirBSD OPTU-8/16 преобразует их в U + EF80. U + EFFF в области частного использования. В любом подходе значение байта кодируется в младших восьми битах выходной кодовой точки.

Эти кодировки очень полезны, потому что они позволяют избежать необходимости иметь дело с «недопустимыми» байтовыми строками намного позже, если вообще позволяют, позволяют байтовым массивом «текст» и «данные» быть одним и тем же объектом. Если программа хочет использовать UTF-16, они должны использовать недопустимые файлы UTF-8; Поскольку API файловой системы Windows использует UTF-16, необходимость поддержки недопустимого UTF-8 здесь меньше.

Для того, чтобы кодирование было обратимым, стандартные кодировки UTF-8 кодовых точек, используемых для ошибочных байтов, считаться недействительным. Это делает кодирование несовместимым с WTF-8 или CESU-8 (хотя только для 128 кодовых точек). При перекодировании первых символов кода точек кода ошибок, которые преобразуются в допустимые символы UTF-8, который может вызвать неожиданные символы на выходе, хотя это не может создать символы ASCII, поэтому считается относительно безопасным. такие как межсайтовый скриптинг ) обычно полагаются на символы ASCII.

См. также

Альтернативный код
Кодировки символов в HTML
Сравнение почтовых клиентов # Возможности
Сравнение кодировок Unicode
Iconv
Specials (блок Unicode)
Unicode и электронная почта
Unicode и HTML
Процентная кодировка # Текущий стандарт
UTF-EBCDIC

Примечания

Ссылки

Внешние ссылки

Исходный документ UTF-8 (или pdf ) для Plan 9 от Bell Labs

Тестовые страницы UTF-8:

Андреас Прилоп
Йост Гипперт
Консорциум World Wide Web

UTF-8

UTF-8 — это кодировка символов переменной ширины, используемая для электронного общения. Имя, определенное стандартом Unicode, является производным от формата преобразования Unicode (или универсального кодированного набора символов ) — 8-битного . [1]

UTF-8 может кодировать все 1,112,064 [nb 1] допустимых кодовых точек символов в Unicode с использованием от одного до четырех однобайтовых (8-битных) кодовых единиц. Точки кода с более низкими числовыми значениями, которые, как правило, встречаются чаще, кодируются с использованием меньшего количества байтов. Он был разработан для обратной совместимости с ASCII.: первые 128 символов Unicode, которые взаимно однозначно соответствуют ASCII, кодируются с использованием одного байта с тем же двоичным значением, что и ASCII, так что действительный текст ASCII также является действительным Unicode в кодировке UTF-8. Поскольку байты ASCII не встречаются при кодировании кодовых точек, отличных от ASCII, в UTF-8, UTF-8 можно безопасно использовать в большинстве языков программирования и документов, которые интерпретируют определенные символы ASCII особым образом, например / ( косая черта ) в именах файлов, \ ( обратная косая черта ) в escape-последовательностях и % в printf .

UTF-8 был разработан как превосходная альтернатива UTF-1 , предложенной кодировке переменной ширины с частичной совместимостью с ASCII, в которой отсутствовали некоторые функции, включая самосинхронизацию и полностью совместимую с ASCII обработку символов, таких как косая черта. Кен Томпсон и Роб Пайк создали первую реализацию для операционной системы Plan 9 в сентябре 1992 года. [2] [3] Это привело к ее принятию X / Open в качестве спецификации для FSS-UTF , которая сначала будет официально представлена на USENIX. в январе 1993 года и впоследствии принят Инженерной группой Интернета(IETF) в RFC 2277 ( BCP 18 ) для будущих стандартов Интернета, заменяя однобайтовые наборы символов, такие как Latin-1, в старых RFC.

UTF-8 на сегодняшний день является наиболее распространенной кодировкой для Всемирной паутины , составляя 97% всех веб-страниц и до 100% для некоторых языков по состоянию на 2021 год [4].

1 Именование

2 Кодирование

2.1 Примеры
2.2 Восьмеричный
2.3 Макет кодовой страницы
2.4 Слишком длинные кодировки
2.5 Недействительные последовательности и обработка ошибок
2.6 Знак порядка байтов

4.1 FSS-UTF

6.1 однобайтный
6.2 Другой многобайтный
6.3 UTF-16

7.1 ЦЭСУ-8
7.2 MySQL utf8mb3
7.3 Модифицированный UTF-8
7.4 WTF-8
7.5 PEP 383

Именование [ править ]

Официальный код Internet Assigned Numbers Authority (IANA) для кодировки — «UTF-8». [5] Все буквы в верхнем регистре, а имя переносится. Это написание используется во всех документах Консорциума Unicode, касающихся кодировки.

В качестве альтернативы имя « utf-8 » может использоваться всеми стандартами, соответствующими списку IANA (который включает заголовки CSS , HTML , XML и HTTP ) [6], поскольку в объявлении регистр не учитывается. [5]

Другие варианты, такие как те, в которых дефис опускается или заменяется пробелом, например, « utf8 » или « UTF 8 », не считаются правильными в соответствии с действующими стандартами. [7] Несмотря на это, большинство веб-браузеров могут их понимать, и поэтому стандарты, предназначенные для описания существующей практики (например, HTML5), могут фактически требовать их признания. [8]

Неофициально UTF-8-BOM и UTF-8-NOBOM иногда используются для текстовых файлов, которые содержат или не содержат метку порядка байтов (BOM) соответственно. [ необходима цитата ] Особенно в Японии кодировку UTF-8 без спецификации иногда называют » UTF-8N «. [9] [10]

Windows 7 и более поздние версии, то есть все поддерживаемые версии Windows, имеют кодовую страницу 65001 , как синоним UTF-8 (с лучшей поддержкой, чем в более старых версиях Windows), [11] и Microsoft имеет сценарий для Windows 10 , чтобы включить его по умолчанию для его программа Microsoft Notepad . [12]

В PCL UTF-8 называется идентификатором символа «18N» (PCL поддерживает 183 кодировки символов, называемых наборами символов, которые потенциально могут быть сокращены до единицы 18N, то есть UTF-8). [13]

Кодировка [ править ]

Примеры [ править ]

Кодовая точка Unicode для «€» — U + 20AC.
Поскольку эта кодовая точка находится между U + 0800 и U + FFFF, для кодирования потребуется три байта.
Шестнадцатеричный 20AC является двоичным 0010 0000 10 10 1100 . Два ведущих нуля добавляются, потому что для трехбайтового кодирования требуется ровно шестнадцать битов от кодовой точки.
Поскольку кодировка будет иметь длину три байта, ее ведущий байт начинается с трех единиц, затем с 0 ( 1110 . )
Четыре старших бита кодовой точки хранятся в оставшихся четырех младших битах этого байта ( 1110 0010 ), оставляя 12 битов кодовой точки, которые еще предстоит закодировать ( . 0000 10 10 1100 ).
Все байты продолжения содержат ровно шесть битов от кодовой точки. Таким образом, следующие шесть бит кодовой точки сохраняются в шести младших битах следующего байта, а 10 сохраняется в двух старших битах, чтобы пометить его как байт продолжения (так 10 000010 ).
Наконец, последние шесть бит кодовой точки сохраняются в шести младших битах последнего байта, и снова 10 сохраняется в двух старших битах ( 10 10 1100 ).

Восьмеричный [ править ]

Макет кодовой страницы [ править ]

Слишком длинные кодировки [ править ]

Недействительные последовательности и обработка ошибок [ править ]

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

Многие из первых декодеров UTF-8 декодировали их, игнорируя неправильные биты и принимая слишком длинные результаты. Тщательно созданный недопустимый код UTF-8 может заставить их либо пропускать, либо создавать символы ASCII, такие как NUL, косую черту или кавычки. Недействительный код UTF-8 использовался для обхода проверок безопасности в популярных продуктах, включая веб-сервер Microsoft IIS [25] и контейнер сервлетов Apache Tomcat. [26] RFC 3629 гласит: «Реализации алгоритма декодирования ДОЛЖНЫ защищать от декодирования недопустимых последовательностей». [7] Стандарт Unicode требует, чтобы декодеры «. обрабатывали любую неверно сформированную последовательность кодовых единиц как состояние ошибки. Это гарантирует, что они не будут интерпретировать и генерировать неверно сформированную последовательность кодовых единиц».

Начиная с RFC 3629 (ноябрь 2003 г.), верхняя и нижняя суррогатные половины, используемые UTF-16 (от U + D800 до U + DFFF), и кодовые точки, не кодируемые UTF-16 (те, которые находятся после U + 10FFFF), не являются допустимыми значениями Unicode, и их кодировка UTF-8 должна рассматриваться как недопустимая последовательность байтов. Отсутствие декодирования непарных суррогатных половин делает невозможным сохранение недопустимого UTF-16 (например, имен файлов Windows или UTF-16, разделенного между суррогатами) как UTF-8. [ необходима цитата ]

Отметка порядка байтов [ править ]

Принятие [ править ]

Использование основных кодировок в Интернете с 2001 по 2012 год, как было зарегистрировано Google [32], при этом UTF-8 обогнал все остальные в 2008 году и более 60% веб-кодировок в 2012 году (с тех пор приближается к 100%). ASCII -только цифра включает в себя все веб — страницы , которые содержат только ASCII — символы, независимо от заявленного заголовка.

UTF-8 — это рекомендация WHATWG для спецификаций HTML и DOM [33], а Internet Mail Consortium рекомендует, чтобы все программы электронной почты могли отображать и создавать почту с использованием UTF-8. [34] [35] World Wide Web Consortium рекомендует UTF-8 в качестве кодировки по умолчанию в XML и HTML (а не только с использованием UTF-8, а также с указанием его в метаданных), «даже тогда , когда все символы в ASCII — диапазоне. . Использование кодировок, отличных от UTF-8, может привести к неожиданным результатам «. [36] Многие другие стандарты поддерживают только UTF-8, например, этого требует открытый обмен JSON . [37] Microsoft теперь рекомендует использовать UTF-8 для приложений, использующих Windows API , продолжая поддерживать устаревший интерфейс «Unicode» (то есть UTF-16). [38]

См. Также: Популярность кодировок текста

UTF-8 является наиболее распространенной кодировкой во всемирной паутине с 2008 года. [39] По состоянию на март 2021 [Обновить] года на UTF-8 приходится в среднем 96,6% всех веб-страниц; и 974 из 1000 самых популярных веб-страниц. [4] При этом учитывается, что ASCII является допустимым UTF-8. [40] Для локальных текстовых файлов Использование UTF-8 меньше, и многие из устаревших однобайтные (и КИХ многобайтовые) кодировок остаются в использовании. Основная причина — редакторы, которые не отображают и не записывают UTF-8, если первый символ в файле не является меткой порядка байтов , что делает невозможным использование UTF-8 другим программным обеспечением без перезаписи, чтобы игнорировать метку порядка байтов при вводе и добавить его на выходе. [41] [42] В последнее время произошли некоторые улучшения, Блокнот теперь по умолчанию записывает UTF-8 без спецификации. [43] Внутреннее использование программного обеспечения еще ниже, с использованием UCS-2 , UTF-16 и UTF-32 , особенно в Windows API, но также с помощью Python , [44] JavaScript , Qt и многих других межплатформенных программных библиотек. . Это связано с убеждением, что прямая индексация кодовых точек более важна, чем 8-битная совместимость [ необходима цитата ] (UTF-16 на самом деле не имеет прямой индексации, но совместим с устаревшей UCS-2, которая имела). В недавнем программном обеспечении внутреннее использование UTF-8 стало намного шире, поскольку это позволяет избежать накладных расходов на преобразование из / в UTF-8 при вводе-выводе и работу с ошибками кодирования UTF-8: строковый примитив по умолчанию, используемый в Go , [45 ] Julia , Rust , Swift 5 , [46] и PyPy [47] являются UTF-8.

История [ править ]

См. Также: Универсальный набор кодированных символов § История
Международная организация по стандартизации (ИСО) устанавливают , чтобы составить универсальный многобайтную набор символов в 1989 проект ИСО 10646 стандарт содержал не-требуемое приложение под названием UTF-1 , который обеспечил байтовый поток кодирование его 32-битных кодовых точек . Эта кодировка была неудовлетворительной с точки зрения производительности, среди других проблем, и самая большая проблема, вероятно, заключалась в том, что в ней не было четкого разделения между ASCII и не-ASCII: новые инструменты UTF-1 будут обратно совместимы с текстом в кодировке ASCII, но Текст в кодировке UTF-1 может запутать существующий код, ожидающий ASCII (или расширенный ASCII), потому что он может содержать байты продолжения в диапазоне 0x21–0x7E, которые означают что-то еще в ASCII, например, 0x2F для ‘/’, разделителя каталога пути Unix , и этот пример отражен в имени и вводном тексте его замены. Приведенная ниже таблица была составлена на основе текстового описания в приложении.

UTF-1

Количество байтов	Первая кодовая точка	Последняя кодовая точка	Байт 1	Байт 2	Байт 3	Байт 4	Байт 5
1	U + 0000	U + 009F	00–9F
2	U + 00A0	U + 00FF	A0	A0 – FF
2	U + 0100	U + 4015	A1 – F5	21–7E, A0 – FF
3	U + 4016	U + 38E2D	F6 – FB	21–7E, A0 – FF	21–7E, A0 – FF
5	U + 38E2E	U + 7FFFFFFF	FC – FF	21–7E, A0 – FF	21–7E, A0 – FF	21–7E, A0 – FF	21–7E, A0 – FF

В июле 1992 года комитет X / Open XoJIG искал лучшую кодировку. Дэйв Проссер из Unix System Laboratories представил предложение о более быстрой реализации и внесло улучшение, заключающееся в том, что 7-битные символы ASCII будут представлять только себя; все многобайтовые последовательности будут включать только байты, в которых установлен старший бит. Название File System Safe UCS Transformation Format (FSS-UTF) и большая часть текста этого предложения были позже сохранены в окончательной спецификации. [48] [49] [50] [51]

FSS-UTF [ править ]

Стандарты [ править ]

RFC 3629 / STD 63 (2003), который устанавливает UTF-8 в качестве стандартного элемента Интернет-протокола.
RFC 5198 определяет UTF-8 NFC для сетевого обмена (2008 г.)
ИСО / МЭК 10646: 2014 §9.1 (2014) [53]
Стандарт Unicode, версия 11.0 (2018) [54]

Они заменяют определения, данные в следующих устаревших работах:

Стандарт Unicode, версия 2.0 , приложение A (1996)
ИСО / МЭК 10646-1: 1993 Поправка 2 / Приложение R (1996)
RFC 2044 (1996)
RFC 2279 (1998)
Стандарт Unicode, версия 3.0 , §2.3 (2000) плюс исправление № 1: кратчайшая форма UTF-8 (2000)
Стандартное приложение Unicode № 27: Unicode 3.1 (2001) [55]
Стандарт Unicode, версия 5.0 (2006 г.) [56]
Стандарт Unicode, версия 6.0 (2010 г.) [57]

Все они одинаковы по своей общей механике, с основными различиями в таких вопросах, как допустимый диапазон значений кодовой точки и безопасная обработка недопустимого ввода.

Сравнение с другими кодировками [ править ]

См. Также: Сравнение кодировок Unicode

Вот некоторые из важных особенностей этой кодировки:

Обратная совместимость:Обратная совместимость с ASCII и огромное количество программного обеспечения, предназначенного для обработки текста в кодировке ASCII, были основной движущей силой дизайна UTF-8. В UTF-8 отдельные байты со значениями в диапазоне от 0 до 127 сопоставляются непосредственно с кодовыми точками Unicode в диапазоне ASCII. Отдельные байты в этом диапазоне представляют символы, как и в ASCII. Более того, 7-битные байты (байты, где самый старший бит равен 0) никогда не появляются в многобайтовой последовательности, и никакая допустимая многобайтовая последовательность не декодируется в кодовую точку ASCII. Последовательность 7-битных байтов является допустимой как ASCII, так и допустимой UTF-8, и при любой интерпретации представляет одну и ту же последовательность символов. Следовательно, 7-битные байты в потоке UTF-8 представляют все и только символы ASCII в потоке. Таким образом, многие текстовые процессоры, парсеры, протоколы, форматы файлов, программы отображения текста и т. Д.которые используют символы ASCII для целей форматирования и управления, будут продолжать работать так, как задумано, обрабатывая поток байтов UTF-8 как последовательность однобайтовых символов без декодирования многобайтовых последовательностей. Символы ASCII, на которых выполняется обработка, такие как знаки пунктуации, пробелы и управляющие символы, никогда не будут кодироваться как многобайтовые последовательности. Поэтому такие процессоры могут просто игнорировать или передавать многобайтовые последовательности без их декодирования. Например, пробелы ASCII могут использоваться дляа управляющие символы никогда не будут кодироваться как многобайтовые последовательности. Поэтому такие процессоры могут просто игнорировать или передавать многобайтовые последовательности без их декодирования. Например, пробелы ASCII могут использоваться дляа управляющие символы никогда не будут кодироваться как многобайтовые последовательности. Поэтому такие процессоры могут просто игнорировать или передавать многобайтовые последовательности без их декодирования. Например, пробелы ASCII могут использоваться дляпреобразовать поток UTF-8 в слова; Перевод строки ASCII может использоваться для разделения потока UTF-8 на строки; и символы ASCII NUL могут использоваться для разделения данных в кодировке UTF-8 на строки с завершающим нулем. Точно так же многие строки формата, используемые библиотечными функциями, такими как printf, будут правильно обрабатывать входные аргументы в кодировке UTF-8.
Откат и автоматическое обнаружение: только небольшое подмножество возможных байтовых строк является допустимой строкой UTF-8: байты от C0, C1 и F5 до FF не могут отображаться, а байты с установленным старшим битом должны быть парами, и другие требования . Крайне маловероятно, что читаемый текст в любом расширенном ASCII является допустимым UTF-8. Частично популярность UTF-8 связана с тем, что он также обеспечивает обратную совместимость для них. Таким образом, процессор UTF-8, который ошибочно принимает расширенный ASCII в качестве входных данных, может «автоматически определять» это с очень высокой надежностью. Откатные ошибки будут ложноотрицательными, и они будут редкими. Более того, во многих приложениях, таких как отображение текста, последствия неправильного отката обычно незначительны. [ оригинальное исследование? ] Поток UTF-8 может просто содержать ошибки, в результате чего схема автоматического обнаружения дает ложные срабатывания; но автоматическое определение в большинстве случаев оказывается успешным, особенно с более длинными текстами, и широко используется. Он также работает для «отката» или замены 8-битных байтов с использованием соответствующей кодовой точки для устаревшей кодировки только при обнаружении ошибок в UTF-8, что позволяет восстановление, даже если UTF-8 и устаревшая кодировка объединены в одном и том же файл.
Код префикса : первый байт указывает количество байтов в последовательности. Чтение из потока может мгновенно декодировать каждую отдельную полностью принятую последовательность без предварительного ожидания первого байта следующей последовательности или индикации конца потока. Длину многобайтовых последовательностей люди легко определяют, поскольку это просто количество старших единиц в ведущем байте. Некорректный символ не будет декодирован, если поток заканчивается на середине последовательности.
Самосинхронизация : ведущие байты и байты продолжения не имеют общих значений (байты продолжения начинаются с битов 10 , отдельные байты начинаются с 0, а более длинные ведущие байты начинаются с 11 ). Это означает, что поиск случайно не найдет последовательность для одного символа, начинающегося в середине другого символа. Это также означает, что начало символа может быть найдено из случайной позиции путем резервного копирования не более 3 байтов, чтобы найти ведущий байт. Некорректный символ не будет декодирован, если поток начинается в середине последовательности, а более короткая последовательность никогда не появится внутри более длинной.
Порядок сортировки: выбранные значения ведущих байтов означают, что список строк UTF-8 может быть отсортирован в порядке кодовых точек путем сортировки соответствующих последовательностей байтов.

Однобайтный [ править ]

UTF-8 может кодировать любой символ Unicode , избегая необходимости вычислять и устанавливать « кодовую страницу » или иным образом указывать, какой набор символов используется, и позволяя выводить в нескольких сценариях одновременно. Для многих сценариев использовалось более одной однобайтовой кодировки, поэтому даже знание сценария было недостаточной информацией для его правильного отображения.
Байты 0xFE и 0xFF не отображаются, поэтому допустимый поток UTF-8 никогда не соответствует метке порядка байтов UTF-16 и, следовательно, не может быть перепутан с ним. Отсутствие 0xFF (0377) также устраняет необходимость экранирования этого байта в Telnet (и управляющем соединении FTP).
Текст в кодировке UTF-8 больше специализированных однобайтовых кодировок, за исключением простых символов ASCII. В случае скриптов, которые использовали 8-битные наборы символов с нелатинскими символами, закодированными в верхней половине (например, большинство кодовых страниц кириллицы и греческого алфавита ), символы в UTF-8 будут вдвое больше. Для некоторых шрифтов, таких как тайский и деванагари (который используется в различных языках Южной Азии), размер символов утроится. Есть даже примеры, когда один байт превращается в составной символ в Unicode и, таким образом, в шесть раз больше в UTF-8. Это вызвало возражения в Индии и других странах.
В UTF-8 (или в любой другой кодировке переменной длины) можно разбить или усечь строку в середине символа. Если эти две части не будут повторно добавлены позже перед интерпретацией как символы, это может привести к недопустимой последовательности как в конце предыдущего раздела, так и в начале следующего, и некоторые декодеры не сохранят эти байты и приведут к потере данных. Поскольку UTF-8 является самосинхронизирующимся, он никогда не будет вводить другой допустимый символ, а также довольно легко переместить точку усечения назад к началу символа.
Если все кодовые точки имеют одинаковый размер, легко измерить их фиксированное количество. Из-за документации эпохи ASCII, где «символ» используется как синоним «байта», это часто считается важным. Однако, измеряя позиции строк с использованием байтов вместо «символов», большинство алгоритмов можно легко и эффективно адаптировать для UTF-8. Например, поиск строки в длинной строке может выполняться побайтово; свойство самосинхронизации предотвращает ложные срабатывания.

Другой многобайтный [ править ]

UTF-8 может кодировать любой символ Юникода . Файлы в разных скриптах могут отображаться правильно без необходимости выбора правильной кодовой страницы или шрифта. Например, китайский и арабский языки могут быть записаны в одном файле без специальной разметки или ручных настроек, указывающих кодировку.
UTF-8 является самосинхронизирующимся : границы символов легко идентифицируются путем сканирования четко определенных битовых шаблонов в любом направлении. Если байты потеряны из-за ошибки или повреждения , всегда можно найти следующий допустимый символ и возобновить обработку. Если необходимо сократить строку, чтобы она соответствовала указанному полю, можно легко найти предыдущий допустимый символ. Многие многобайтовые кодировки, такие как Shift JIS , гораздо сложнее повторно синхронизировать. Это также означает, что байтовые алгоритмы поиска по строкамможет использоваться с UTF-8 (поскольку символ — это то же самое, что и «слово», состоящее из такого количества байтов), оптимизированные версии поиска байтов могут быть намного быстрее благодаря аппаратной поддержке и таблицам поиска, которые содержат всего 256 записей. Однако самосинхронизация требует, чтобы биты были зарезервированы для этих маркеров в каждом байте, увеличивая размер.
Эффективно кодировать с помощью простых побитовых операций . UTF-8 не требует более медленных математических операций, таких как умножение или деление (в отличие от Shift JIS , GB 2312 и других кодировок).
UTF-8 займет больше места, чем многобайтовая кодировка, разработанная для конкретного скрипта. Унаследованные восточноазиатские кодировки обычно использовали два байта на символ, но в UTF-8 занимали три байта на символ.

UTF-16 [ править ]

Байтовые кодировки и UTF-8 представлены в программах байтовыми массивами, и часто ничего не нужно делать с функцией при преобразовании исходного кода из байтовой кодировки в UTF-8. UTF-16 представлен массивами 16-битных слов, и преобразование в UTF-16 при сохранении совместимости с существующими программами на основе ASCII (например, как это было сделано с Windows) требует, чтобы каждый API и структура данных, которая принимает строку для дублирования, одна версия принимает байтовые строки, а другая версия принимает UTF-16. Если обратная совместимость не требуется, необходимо изменить всю обработку строк.
Текст, закодированный в UTF-8, будет меньше, чем тот же текст, закодированный в UTF-16, если кодовых точек ниже U + 0080 больше, чем в диапазоне U + 0800..U + FFFF. Это верно для всех современных европейских языков. Это часто верно даже для таких языков, как китайский, из-за большого количества пробелов, новых строк, цифр и разметки HTML в типичных файлах.
Большая часть коммуникаций (например, HTML и IP) и хранилища (например, для Unix) была разработана для потока байтов . Строка UTF-16 должна использовать пару байтов для каждой единицы кода:
- Порядок этих двух байтов становится проблемой и должен быть указан в протоколе UTF-16, например, с пометкой порядка байтов .
- Если нечетное количество байтов отсутствует в UTF-16, вся остальная часть строки будет бессмысленным текстом. Любые байты, отсутствующие в UTF-8, по-прежнему позволяют точно восстановить текст, начиная со следующего символа после отсутствующих байтов.
Производные [ править ]

Следующие реализации показывают небольшие отличия от спецификации UTF-8. Они несовместимы со спецификацией UTF-8 и могут быть отклонены соответствующими приложениями UTF-8.

CESU-8 [ править ]

Основная статья: CESU-8

В техническом отчете Unicode № 26 [58] имя CESU-8 присваивается нестандартному варианту UTF-8, в котором символы Unicode в дополнительных плоскостях кодируются с использованием шести байтов, а не четырех байтов, требуемых UTF-8. Кодировка CESU-8 обрабатывает каждую половину четырехбайтовой суррогатной пары UTF-16 как двухбайтовый символ UCS-2, в результате чего получается два трехбайтовых символа UTF-8, которые вместе представляют исходный дополнительный символ. Символы Unicode в базовой многоязычной плоскости отображаются так же, как обычно в UTF-8. Отчет был написан для подтверждения и формализации существования данных, закодированных как CESU-8, несмотря на то, что Консорциум Unicode не поощряет его использование, и отмечает, что возможной преднамеренной причиной кодирования CESU-8 является сохранение двоичного сопоставления UTF-16.

Кодирование CESU-8 может быть результатом преобразования данных UTF-16 с дополнительными символами в UTF-8 с использованием методов преобразования, которые принимают данные UCS-2, что означает, что они не знают о четырехбайтовых дополнительных символах UTF-16. Это в первую очередь проблема операционных систем, которые широко используют UTF-16 для внутренних целей, таких как Microsoft Windows . [ необходима цитата ]

В Oracle Database для UTF8 набора символов используется кодировка CESU-8, и эта кодировка считается устаревшей. Набор AL32UTF8 символов использует совместимую со стандартами кодировку UTF-8 и является предпочтительной. [59] [60]

CESU-8 запрещено использовать в документах HTML5 . [61] [62] [63]

MySQL utf8mb3 [ править ]

В MySQL , то utf8mb3 набор символов определяется как UTF-8 закодированные данные с максимум три байта на символ, а это означает только Unicode символы в Basic Multilingual Plane (т.е. от UCS-2 ) поддерживаются. Символы Unicode в дополнительных плоскостях явно не поддерживаются. utf8mb3 устарел в пользу utf8mb4 набора символов, который использует совместимую со стандартами кодировку UTF-8. utf8 является псевдонимом для utf8mb3 , но предполагается, что он станет псевдонимом utf8mb4 в будущей версии MySQL. [64] Можно, хотя и не поддерживается, хранить данные в utf8mb3 кодировке CESU-8 , обрабатывая данные UTF-16 с дополнительными символами, как если бы они были UCS-2.

Измененный UTF-8 [ править ]

WTF-8 [ править ]

В этом разделе содержится список разной информации . Пожалуйста, переместите любую соответствующую информацию в другие разделы или статьи. ( Август 2020 г. )

PEP 383 [ править ]

Версия 3 языка программирования Python обрабатывает каждый байт недопустимого байтового потока UTF-8 как ошибку (см. Также изменения с новым режимом UTF-8 в Python 3.7 [77] ); это дает 128 различных возможных ошибок. Были созданы расширения, позволяющие преобразовывать любую последовательность байтов, которая, как предполагается, является UTF-8, в UTF-16 или UTF-32 без потерь путем преобразования 128 байтов возможных ошибок в зарезервированные кодовые точки и преобразования этих кодовых точек обратно в ошибки. байтов для вывода UTF-8. Наиболее распространенный подход — преобразовать коды в U + DC80 . U + DCFF, которые являются низкими (замыкающими) суррогатными значениями и, следовательно, «недействительными» UTF-16, как используется Python PEP 383 (или «surrogateescape»). подход. [78] Другая кодировка — MirBSD.OPTU-8/16 преобразует их в U + EF80 . U + EFFF в зоне частного использования . [79] В любом подходе значение байта кодируется в младших восьми битах выходной кодовой точки. Эти кодировки очень полезны, потому что они позволяют избежать необходимости иметь дело с «недопустимыми» байтовыми строками намного позже, если вообще позволяют, и позволяют байтовым массивам «текст» и «данные» быть одним и тем же объектом. Если программа хочет использовать UTF-16 внутри, они должны сохранять и использовать имена файлов, которые могут использовать недопустимый UTF-8; [80] поскольку API файловой системы Windows использует UTF-16, необходимость в поддержке недопустимого UTF-8 меньше. [78] Чтобы кодирование было обратимым, стандартные кодировки UTF-8 кодовых точек, используемых для ошибочных байтов, должны считаться недопустимыми. Это делает кодирование несовместимым с WTF-8 или CESU-8 (хотя только для 128 кодовых точек). При перекодировании необходимо быть осторожным с последовательностями точек кода ошибок, которые преобразуются обратно в допустимый UTF-8, который может использоваться вредоносным программным обеспечением для получения неожиданных символов на выходе, хотя это не может создавать символы ASCII, поэтому считается относительно безопасен, поскольку вредоносные последовательности (такие как межсайтовый скриптинг ) обычно используют символы ASCII. [80]

См. Также [ править ]
- Альтернативный код
- Кодировки символов в HTML
- Сравнение почтовых клиентов # Возможности
- Сравнение кодировок Unicode
  - ГБ 18030
  - UTF-EBCDIC
  Заметки [ править ]
  1. ^ 17 самолетов умножить на 2 16 кодовых точек на самолет минус 2 11 технически недействительных суррогатов .
  2. ^ Вы можете ожидать, что более крупные кодовые точки, чем U + 10FFFF, будут выражены , но в RFC3629 §3 UTF-8 ограничен, чтобы соответствовать ограничениям UTF-16. (Как указано в §12 , это изменено из RFC 2279. )
  Ссылки [ править ]
  1. ^ «Глава 2. Общая структура» . Стандарт Юникода (6.0 — ред.). Маунтин-Вью, Калифорния, США: Консорциум Unicode . ISBN 978-1-936213-01-6.
  2. ^ a b Пайк, Роб (30 апреля 2003 г.). «История UTF-8» .
  3. ^ Пайк, Роб; Томпсон, Кен (1993). «Hello World или αλημέρα κόσμε или こんにちは世界» (PDF) . Материалы Зимней 1993 USENIX конференции .
  4. ^ a b «Обзор использования кодировок символов с разбивкой по рейтингам» . w3techs.com . Проверено 24 марта 2021 .
  5. ^ a b «Наборы символов» . Управление по присвоению номеров в Интернете . 2013-01-23 . Проверено 8 февраля 2013 .
  6. ^ Дюрст, Мартин. «Установка параметра кодировки HTTP» . W3C . Проверено 8 февраля 2013 .
  7. ^ а б Йерго, Ф. (2003). UTF-8, формат преобразования ISO 10646 . Инженерная группа Интернета . DOI : 10,17487 / RFC3629 . RFC 3629 . Проверено 3 февраля 2015 .
  8. ^ «Стандарт кодирования § 4.2. Имена и метки» . WHATWG . Проверено 29 апреля 2018 .
  9. ^ «Спецификация» . суикавики (на японском) . Проверено 26 апреля 2013 .
  10. ^ Дэвис, Марк . «Формы Юникода» . IBM . Архивировано из оригинала на 2005-05-06 . Проверено 18 сентября 2013 .
  11. ↑ Ливиу (07.02.2014). «Кодовая страница UTF-8 65001 в Windows 7 — часть I» . Проверено 30 января 2018 .
  12. ^ «Сценарий Как установить кодировку по умолчанию в UTF-8 для блокнота с помощью PowerShell» . gallery.technet.microsoft.com . Проверено 30 января 2018 .
  13. ^ «Наборы символов HP PCL | Блог поддержки языка управления принтером (PCL и PXL)» . 2015-02-19. Архивировано из оригинала на 2015-02-19 . Проверено 30 января 2018 .
  14. ^ Аллен, Джули Д .; Андерсон, Дебора; Беккер, Джо; Кук, Ричард, ред. (2012). «Стандарт Unicode, версия 6.1». Маунтин-Вью, Калифорния: Консорциум Unicode.
  15. Цитировать журнал требует |journal= ( помощь )
  16. ^ «Документация разработчика Apple» . developer.apple.com . Проверено 15 марта 2021 .
  17. ^ «Это нормально, что» ��‍♂️ «.length == 7» . hsivonen.fi . Проверено 15 марта 2021 .
  18. объединяющий символ нулевой ширины в |title= позиции 24 ( справка )
  19. ^ «BinaryString (flink 1.9-SNAPSHOT API)» . ci.apache.org . Проверено 24 марта 2021 .
  20. ^ «Глава 3» (PDF) , Стандарт Unicode , стр. 54
  21. ^ «Глава 3» (PDF) , Стандарт Unicode , стр. 55
  22. ^ «Глава 3» (PDF) , Стандарт Unicode , стр. 55
  23. ^ «Глава 3» (PDF) , Стандарт Unicode , стр. 54
  24. ^ Yergeau, F. (ноябрь 2003). UTF-8, формат преобразования ISO 10646 . IETF . DOI : 10,17487 / RFC3629 . STD 63. RFC 3629 . Проверено 20 августа 2020 года .
  25. ^ «Глава 3» (PDF) , Стандарт Unicode , стр. 55
  26. ^ Yergeau, F. (ноябрь 2003). UTF-8, формат преобразования ISO 10646 . IETF . DOI : 10,17487 / RFC3629 . STD 63. RFC 3629 . Проверено 20 августа 2020 года .
  27. ^ Марин, Марвин (2000-10-17). «Обход папки веб-сервера MS00-078» .
  28. ^ «Резюме для CVE-2008-2938» . Национальная база данных уязвимостей .
  29. ^ «DataInput (Java Platform SE 8)» . docs.oracle.com . Проверено 24 марта 2021 .
  30. ^ «Нераз декодируемые байты в интерфейсах системных символов» . python.org . 2009-04-22 . Проверено 13 августа 2014 .
  31. ^ «Юникод 6.0.0» .
  32. ^ 128 1 байт, (16 + 5) × 64 2 байта и 5 × 64 × 64 3 байта. Их может быть немного меньше, если для каждого байта продолжения будут проводиться более точные проверки.
  33. ^ «Глава 2» (PDF) , Стандарт Unicode , стр. 30
  34. ^ Дэвис, Марк (2012-02-03). «Unicode более 60 процентов Интернета» . Официальный блог Google . Архивировано 9 августа 2018 года . Проверено 24 июля 2020 .
  35. ^ «Стандарт кодирования» . encoding.spec.whatwg.org . Проверено 15 апреля 2020 .
  36. ^ «Использование международных символов в интернет-почте» . Консорциум Интернет-почты. 1998-08-01. Архивировано из оригинала на 2007-10-26 . Проверено 8 ноября 2007 .
  37. ^ «Стандарт кодирования» . encoding.spec.whatwg.org . Проверено 15 ноября 2018 .
  38. ^ «Указание кодировки символов документа» . HTML5.2 . Консорциум World Wide Web . 14 декабря 2017 . Проверено 3 июня 2018 .
  39. ^ «Формат обмена данными JavaScript Object Notation (JSON)» . IETF. Декабрь 2017 . Проверено 16 февраля 2018 .
  40. ^ «Используйте кодовую страницу Windows UTF-8» . Приложения UWP . docs.microsoft.com . Проверено 6 июня 2020 .
  41. ^ Дэвис, Марк (2008-05-05). «Переход на Unicode 5.1» . Источник 2021-02-19 .
  42. ^ «Статистика использования и рыночная доля US-ASCII для веб-сайтов, август 2020 г.» . w3techs.com . Проверено 28 августа 2020 .
  43. ^ «Как я могу заставить Блокнот сохранять текст в UTF-8 без спецификации?» . Переполнение стека . Проверено 24 марта 2021 .
  44. ^ Галлоуэй, Мэтт. «Кодировка символов для разработчиков iOS. Или UTF-8, что теперь?» . www.galloway.me.uk . Проверено 2 января 2021 . на самом деле вы обычно просто предполагаете UTF-8, поскольку это самая распространенная кодировка.
  45. ^ «Блокнот Windows 10 получает лучшую поддержку кодировки UTF-8» . BleepingComputer . Проверено 24 марта 2021 . Microsoft теперь по умолчанию сохраняет новые текстовые файлы как UTF-8 без спецификации, как показано ниже.
  46. ^ «PEP 623 — Удалить wstr из Unicode» . Python.org . Проверено 21 ноября 2020 . Пока мы не откажемся от устаревшего объекта Unicode, очень сложно попробовать другую реализацию Unicode, такую как реализация на основе UTF-8 в PyPy.
  47. ^ «Спецификация языка программирования Go» . Проверено 10 февраля 2021 .
  48. ^ Цай, Майкл Дж. «Майкл Цай — Блог — Строка UTF-8 в Swift 5» . Проверено 15 марта 2021 .
  49. ^ Маттип (2019-03-24). «Блог статуса PyPy: выпущен PyPy v7.1; теперь внутренне используется utf-8 для строк Unicode» . Блог статуса PyPy . Проверено 21 ноября 2020 .
  50. ^ «Приложение F. FSS-UTF / Безопасный формат преобразования UCS файловой системы» (PDF) . Стандарт Unicode 1.1 . Архивировано (PDF) из оригинала 07.06.2016 . Проверено 7 июня 2016 .
  51. ^ Уистлер, Кеннет (2001-06-12). «FSS-UTF, UTF-2, UTF-8 и UTF-16» . Архивировано 07 июня 2016 года . Проверено 7 июня 2006 .
  52. ^ a b Пайк, Роб (30 апреля 2003 г.). «История UTF-8» . Проверено 7 сентября 2012 .
  53. ^ Пайк, Роб (2012-09-06). «UTF-8 вчера исполнилось 20 лет» . Проверено 7 сентября 2012 .
  54. ^ Alvestrand, Харальд (январь 1998). Политика IETF в отношении наборов символов и языков . DOI : 10,17487 / RFC2277 . ПП 18.
  55. ^ ISO / IEC 10646: 2014 §9.1 , 2014.
  56. ^ Стандарт Unicode, версия 11.0 §3.9 D92, §3.10 D95 , 2018.
  57. ^ Стандартное приложение Unicode # 27: Unicode 3.1 , 2001.
  58. ^ Стандарт Unicode, Версия 5.0 §3.9 – §3.10 гл. 3 , 2006.
  59. ^ Стандарт Unicode, версия 6.0 §3.9 D92, §3.10 D95 , 2010.
  60. ↑ Макгоуэн, Рик (19 декабря 2011 г.). «Схема кодирования совместимости для UTF-16: 8-бит (CESU-8)» . Консорциум Unicode . Технический отчет по Unicode № 26.
  61. ^ «Поддержка набора символов» . Документация по Oracle Database 19c, Справочник по языку SQL . Корпорация Oracle .
  62. ^ «Поддержка многоязычных баз данных с помощью Unicode § Поддержка стандарта Unicode в Oracle Database» . Руководство по поддержке глобализации баз данных . Корпорация Oracle .
  63. ^ «8.2.2.3. Кодировки символов» . Стандарт HTML 5.1 . W3C .
  64. ^ «8.2.2.3. Кодировки символов» . Стандарт HTML 5 . W3C .
  65. ^ «12.2.3.3 Кодировки символов» . Уровень жизни HTML . WHATWG .
  66. ^ «Набор символов utf8mb3 (3-байтовая кодировка Unicode UTF-8)» . Справочное руководство по MySQL 8.0 . Корпорация Oracle .
  67. ^ «Документация Java SE для интерфейса java.io.DataInput, подраздел по модифицированному UTF-8» . Корпорация Oracle . 2015 . Проверено 16 октября 2015 .
  68. ^ «Спецификация виртуальной машины Java, раздел 4.4.7:« Структура CONSTANT_Utf8_info » » . Корпорация Oracle . 2015 . Проверено 16 октября 2015 .
  69. ^ «Спецификация сериализации объектов Java, глава 6: Потоковый протокол сериализации объектов, раздел 2: Элементы потока» . Корпорация Oracle . 2010 . Проверено 16 октября 2015 .
  70. ^ «Спецификация собственного интерфейса Java, глава 3: Типы JNI и структуры данных, раздел: Измененные строки UTF-8» . Корпорация Oracle . 2015 . Проверено 16 октября 2015 .
  71. ^ «Спецификация виртуальной машины Java, раздел 4.4.7:« Структура CONSTANT_Utf8_info » » . Корпорация Oracle . 2015 . Проверено 16 октября 2015 .
  72. ^ «ИСКУССТВО и Дальвик» . Проект с открытым исходным кодом Android . Архивировано из оригинала на 2013-04-26 . Проверено 9 апреля 2013 .
  73. ^ «Tcler’s Wiki: UTF-8 бит за битом (Версия 6)» . 2009-04-25 . Проверено 22 мая 2009 .
  74. ^ Сапин, Саймон (2016-03-11) [2014-09-25]. «Кодировка WTF-8» . Архивировано 24 мая 2016 года . Проверено 24 мая 2016 .
  75. ^ Сапин, Саймон (2015-03-25) [2014-09-25]. «Кодировка WTF-8 § Мотивация» . Архивировано 24 мая 2016 года . Проверено 26 августа 2020 .
  76. ^ «WTF-8.com» . 2006-05-18 . Проверено 21 июня 2016 .
  77. ^ Спир, Робин (2015-05-21). «ftfy (исправляет текст за вас) 4.0: меньше менять и больше исправлять» . Архивировано из оригинала на 2015-05-30 . Проверено 21 июня 2016 .
  78. ^ «WTF-8, формат преобразования кодовой страницы 1252» . Архивировано из оригинала на 2016-10-13 . Проверено 12 октября 2016 .
  79. ^ «PEP 540 — Добавить новый режим UTF-8» . Python.org . Проверено 24 марта 2021 .
  80. ^ a b фон Левис, Мартин (2009-04-22). «Недекодируемые байты в интерфейсах системных символов» . Фонд программного обеспечения Python . PEP 383.
  81. ^ «RTFM optu8to16 (3), optu8to16vis (3)» . www.mirbsd.org .
  82. ^ а б Дэвис, Марк ; Suignard, Мишель (2014). «3.7 Включение преобразования без потерь» . Вопросы безопасности Unicode . Технический отчет по Unicode №36.
  Внешние ссылки [ править ]
  - Оригинальный документ UTF-8 ( или pdf ) для Plan 9 от Bell Labs
  - Тестовые страницы UTF-8:
    - Андреас Прилоп
    - Йост Гипперт
    - Консорциум World Wide Web
    - Консорциум Unicode
    - ISO / IEC 10646 (универсальный набор символов)
    - Версии
    - Блокировать
      - Список
      - Спецификация
      - Объединение Grapheme Joiner
      - Отметка слева направо / отметка справа налево
      - Мягкий дефис
      - Вариант формы
      - Соединитель слов
      - Соединитель нулевой ширины
      - Без стыковки с нулевой шириной
      - Пространство нулевой ширины
      UTF-8 vs UTF-8 без BOM — что когда использовать?
      
      Помогите, пожалуйста, разобраться:
      UTF-8 и UTF-8 без BOM — в чём разница в использовании? Что лучше использовать для сохранения файлов?
      
      Когда-то у меня сложилось впечатление, что UTF-8 универсальнее, лучше использовать эту кодировку — тогда я имел дело с HTML, CSS +/- JavaScript, но позднее — имея дело с PHP — получил опыт, говорящий, что UTF-8 без BOM предпочтительнее (были проблемы, как раз, из-за UTF-8)
      
      Так, как всё-таки быть? Что использовать?
      
      Мой опыт пока такой: для клиентской части — UTF-8 (либо нет разницы), для серверной — UTF-8 без BOM — всё так? Почему?
      - Вопрос задан более трёх лет назад
      - 59390 просмотров
      Комментировать
      Решения вопроса 2
      
      Сергей delphinpro @delphinpro
      frontend developer
      
      Различий никаких нет, кроме наличия/отсутствия маркера. Кодировка одна и та же — utf-8. По стандарту unicode маркер должен быть.
      
      Удалять маркер BOM при сохранении нужно только для PHP, который почему-то не умеет корректно обрабатывать нормальные unicode файлы.
      
      Ответ написан более трёх лет назад
      Нравится 6 1 комментарий
      («Нет смысла использовать строку без информации о её кодировке») —
      
      littleguga @littleguga
      Не стыдно не знать, а стыдно не интересоваться.
      
      Маркер последовательности байтов или метка порядка байтов (англ. Byte Order Mark (BOM)) — Юникод-символ, используемый для индикации порядка байтов текстового файла. Его кодовый символ U+FEFF. По спецификации, его использование не является обязательным, однако, если маркер последовательности байтов используется, то он должен быть установлен в начале текстового файла. Помимо своего конкретного использования в качестве указателя порядка байтов, символ может также указать, какой кодировкой Unicode закодирован текст.
      
      Кодировка Unicode может использовать 16-разрядные или 32-разрядные числа и приложение должно знать, как дальше с ними поступать. Поэтому потребность в маркере последовательности байтов возникает при обмене документами.
      
      Если сохраняете php файл — то без BOM, в остальном же разницы никакой не имеет.
      Похожие публикации:
      
      Sonic visualiser как пользоваться
      
      Synchronized java что это
      
      Для чего нужен scss
      
      Как запустить python от имени администратора

Utf 8 со спецификацией что это

UTF-8

Резюме

Связь с международным стандартом ISO / IEC 10646, а также стандартами Unicode и Интернет.

Техническое описание

Описание

Примеры

Характеристики

Принцип и уникальность кодирования

Типы байтов, допустимые последовательности и декодирование

Запрещенные последовательности

Преимущества

Универсальность

Совместимость с US-ASCII

Совместимость

Эффективность

Возможность повторного использования

Надежность

Недостатки

Переменный размер

Эффективность

Недействительные последовательности

Нулевой символ

Представление в СУБД

История

Эволюция использования

Последовательные ограничения

Поддерживается

Нестандартные расширения

Пример варианта, используемого в Java

Примечания и ссылки

Смотрите также

Статьи по Теме

Специальные блоки символов Unicode, содержащие не символы

Внешние ссылки

UTF-8 — UTF-8

Принятие

Кодирование

Примеры

Макет кодовой страницы

Сверхдлинные кодировки

Недопустимые придерживаться и обработка ошибок

Знак порядка байтов

Именование

История

Стандарты

Сравнение с другими кодировками

Однобайтовый

Другой многобайтный

UTF-16

Производные

CESU-8

MySQL utf8mb3

Модифицированный UTF-8

WTF-8

PEP 383

См. также

Примечания

Ссылки

Внешние ссылки

UTF-8

Именование [ править ]

Кодировка [ править ]

Примеры [ править ]

Восьмеричный [ править ]

Макет кодовой страницы [ править ]

Слишком длинные кодировки [ править ]

Недействительные последовательности и обработка ошибок [ править ]

Отметка порядка байтов [ править ]

Принятие [ править ]

История [ править ]

FSS-UTF [ править ]

Стандарты [ править ]

Сравнение с другими кодировками [ править ]

Однобайтный [ править ]

Другой многобайтный [ править ]

UTF-16 [ править ]

Производные [ править ]

CESU-8 [ править ]

MySQL utf8mb3 [ править ]