✖


Jump to content

UTF-8

(Перенаправлено с WTF-8 )
UTF-8
Стандартный Стандарт Юникод
Классификация Формат преобразования Unicode , расширенный ASCII , кодировка переменной длины
Расширяет ASCII
Преобразует/кодирует ISO/IEC 10646 ( Юникод )
Предшественник UTF-1

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

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

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

UTF-8 results in fewer internationalization issues[7][8] than any alternative text encoding, and it has been implemented in all modern operating systems, including Microsoft Windows, and standards such as JSON, where, as is increasingly the case, it is the only allowed form of Unicode.

UTF-8 is the dominant encoding for the World Wide Web (and internet technologies), accounting for 98.2% of all web pages, 99.1% of the top 100,000 pages, and up to 100% for many languages, as of 2024.[9] Virtually all countries and languages have 95% or more use of UTF-8 encodings on the web.

Naming

[edit]

The official name for the encoding is UTF-8, the spelling used in all Unicode Consortium documents. Most standards officially list it in upper case as well, but all that do are also case-insensitive and utf-8 is often used in code.[citation needed]

Some other spellings may also be accepted by standards, e.g. web standards (which include CSS, HTML, XML, and HTTP headers) explicitly allow utf8 (and disallow "unicode") and many aliases for encodings.[10] Spellings with a space e.g. "UTF 8" should not be used. The official Internet Assigned Numbers Authority also lists csUTF8 as the only alias,[11] which is rarely used.

In Windows, UTF-8 is codepage 65001[12] (i.e. CP_UTF8 in source code).

In MySQL, UTF-8 is called utf8mb4[13] (with utf8mb3, and its alias utf8, being a subset encoding for characters in the Basic Multilingual Plane[14]).

In HP PCL, the Symbol-ID for UTF-8 is 18N.[15]

In Oracle Database (since version 9.0), AL32UTF8[16] means UTF-8. See also CESU-8 for an almost synonym with UTF-8 that rarely should be used.

UTF-8-BOM and UTF-8-NOBOM are sometimes used for text files which contain or do not contain a byte-order mark (BOM), respectively.[citation needed] In Japan especially, UTF-8 encoding without a BOM is sometimes called UTF-8N.[17][18]

Encoding

[edit]

UTF-8 encodes code points in one to four bytes, depending on the value of the code point. In the following table, the x characters are replaced by the bits of the code point:

Code point ↔ UTF-8 conversion
First code pointLast code pointByte 1Byte 2Byte 3Byte 4
U+0000U+007F0xxxxxxx
U+0080U+07FF110xxxxx10xxxxxx
U+0800U+FFFF1110xxxx10xxxxxx10xxxxxx
U+010000[b]U+10FFFF11110xxx10xxxxxx10xxxxxx10xxxxxx

The first 128 code points (ASCII) need 1 byte. The next 1,920 code points need two bytes to encode, which covers the remainder of almost all Latin-script alphabets, and also IPA extensions, Greek, Cyrillic, Coptic, Armenian, Hebrew, Arabic, Syriac, Thaana and N'Ko alphabets, as well as Combining Diacritical Marks. Three bytes are needed for the remaining 61,440 codepoints of the Basic Multilingual Plane (BMP), including most Chinese, Japanese and Korean characters. Four bytes are needed for the 1,048,576 codepoints in the other planes of Unicode, which include emoji (pictographic symbols), less common CJK characters, various historic scripts, and mathematical symbols.

A whole graphic character can take more than 4 bytes, because it is made of more than one code point. For instance, a national flag character takes 8 bytes since it is "constructed from a pair of Unicode scalar values" both from outside the BMP.[19][c]

Examples

[edit]
In the following examples, red, green, and blue digits indicate how bits from the code point are distributed among the UTF-8 bytes. Additional bits added by the UTF-8 encoding process are shown in black.
  1. The Unicode code point for the euro sign € is U+20AC.
  2. As this code point lies between U+0800 and U+FFFF, this will take three bytes to encode.
  3. Hexadecimal 20AC is binary 0010 0000 1010 1100. The two leading zeros are added because a three-byte encoding needs exactly sixteen bits from the code point.
  4. Because the encoding will be three bytes long, its leading byte starts with three 1s, then a 0 (1110...)
  5. The four most significant bits of the code point are stored in the remaining low order four bits of this byte (11100010), leaving 12 bits of the code point yet to be encoded (...0000 1010 1100).
  6. All continuation bytes contain exactly six bits from the code point. So the next six bits of the code point are stored in the low order six bits of the next byte, and 10 is stored in the high order two bits to mark it as a continuation byte (so 10000010).
  7. Finally the last six bits of the code point are stored in the low order six bits of the final byte, and again 10 is stored in the high order two bits (10101100).

The three bytes 11100010 10000010 10101100 can be more concisely written in hexadecimal, as E2 82 AC.

The following table summarizes this conversion, as well as others with different lengths in UTF-8.

UTF-8 encoding process
CharacterBinary code pointBinary UTF-8Hex UTF-8
$U+0024010 01000010010024
£U+00A3000 1010 001111000010 10100011C2 A3
ИU+0418100 0001 100011010000 10011000D0 98
ह (Devanagari letter HA)U+09390000 1001 0011 100111100000 10100100 10111001E0 A4 B9
€U+20AC0010 0000 1010 110011100010 10000010 10101100E2 82 AC
한U+D55C1101 0101 0101 110011101101 10010101 10011100ED 95 9C
𐍈U+103480 0001 0000 0011 0100 100011110000 10010000 10001101 10001000F0 90 8D 88
Suppl Private Use Area BU+1096B31 0000 1001 0110 1011 001111110100 10001001 10011010 10110011F4 89 9A B3

The Vietnamese phrase Mình nói tiếng Việt (𨉟呐㗂越, "I speak Vietnamese") is encoded as follows:

CharacterMình nói tiếng Việt
Code point4DEC6E68206EF3692074691EBF6E672056691EC774
Hex UTF-8C3ACC3B3E1BABFE1BB87
Character𨉟呐㗂越
Code point2825F545035C28D8A
Hex UTF-8F0A8899FE59190E39782E8B68A

Codepage layout

[edit]

The following table summarizes usage of UTF-8 code units (individual bytes or octets) in a code page format. The upper half is for bytes used only in single-byte codes, so it looks like a normal code page; the lower half is for continuation bytes and leading bytes and is explained further in the legend below.

UTF-8
0123456789ABCDEF
0xNULSOHSTXETXEOTENQACKBELBSHTLFVTFFCRSOSI
1xDLEDC1DC2DC3DC4NAKSYNETBCANEMSUBESCFSGSRSUS
2x SP !"#$%&'()*+,-./
3x0123456789:;<=>?
4x@ABCDEFGHIJKLMNO
5xPQRSTUVWXYZ[\]^_
6x`abcdefghijklmno
7xpqrstuvwxyz{|}~DEL
8x+0+1+2+3+4+5+6+7+8+9+A+B+C+D+E+F
9x+10+11+12+13+14+15+16+17+18+19+1A+1B+1C+1D+1E+1F
Ax+20+21+22+23+24+25+26+27+28+29+2A+2B+2C+2D+2E+2F
Bx+30+31+32+33+34+35+36+37+38+39+3A+3B+3C+3D+3E+3F
Cx2222222222222222
Dx2222222222222222
Ex3333333333333333
Форекс 4 4 4 4 4 4 4 4 5 5 5 5 6 6
  7-битные (однобайтовые) кодовые точки. За ними не должен следовать байт продолжения. [20]
  Байты продолжения. [21] В ячейке показано шестнадцатеричное значение добавляемых ими 6 бит. [д]
  За ведущими байтами последовательности из нескольких байтов должно следовать ровно N -1 байтов продолжения. [22] В подсказке отображается диапазон кодовых точек и блоки Юникода, закодированные последовательностями, начинающимися с этого байта.
  Ведущие байты, в которых не все расположения байтов продолжения действительны. Е0 и F0 может начать слишком длинную кодировку. F4 может начинать кодовые точки больше U+10FFFF. ED может начинать кодовые точки в диапазоне U+D800–U+DFFF, которые являются недопустимыми UTF-16 суррогатными половинками . [23]
  Не используйте действительную последовательность UTF-8. С0 и C1 можно было использовать только для «слишком длинного» кодирования 1-байтового символа. [24] F5, чтобы FD — это ведущие байты последовательностей длиной 4 байта или более, которые могут кодировать только кодовые точки, превышающие U + 10FFFF. [23] FE и FF никогда не придавали никакого значения. [25]

Слишком длинные кодировки

[ редактировать ]

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

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

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

[ редактировать ]

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

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

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

«... рассматривать любую неправильно сформированную последовательность кодовых единиц как состояние ошибки. Это гарантирует, что она не будет ни интерпретировать, ни выдавать неправильно сформированную последовательность кодовых единиц».

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

Некоторые реализации декодеров выдают исключения при ошибках. [29] Недостаток этого подхода заключается в том, что он может превратить ошибки, которые в противном случае были бы безобидными (например, ошибку «нет такого файла»), в отказ в обслуживании . Например, ранние версии Python 3.0 завершали работу немедленно, если переменные командной строки или среды содержали недопустимый код UTF-8. [30]

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

Эти рекомендации не часто выполняются. Обычно каждый байт считается ошибкой, и в этом случае E1,A0,C0 — три ошибки (каждая длиной 1 байт). Это означает, что существует всего 128 различных ошибок, и их также часто заменяют 128 разными символами, чтобы сделать декодирование «без потерь». [32]

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

[ редактировать ]

Если знак порядка байтов Юникода (BOM, U+FEFF, технически Символ U+FEFF ZERO WIDTH NO-BREAK SPACE ) находится в начале файла UTF-8, первые три байта будут 0xEF , 0xBB , 0xBF .

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

Принятие

[ редактировать ]
См. Также: Популярность кодировок текста.
Заявлен набор символов для 10 миллионов самых популярных веб-сайтов с 2010 года.
Использование основных кодировок в Интернете в 2001–2012 гг., зафиксировано Google. [35] при этом UTF-8 обогнал все остальные в 2008 году и более 60% сети в 2012 году (с тех пор приближается к 100%). UTF-8 — единственная кодировка Unicode, указанная там (явно), а остальные предоставляют только подмножества Unicode. Фигура, состоящая только из ASCII, включает все веб-страницы, содержащие только символы ASCII, независимо от объявленного заголовка.

UTF-8 является самой распространенной кодировкой во Всемирной паутине с 2008 года. [36] По состоянию на май 2024 г. , UTF-8 используется на 98,2% опрошенных веб-сайтов. [9] [г] Хотя на многих страницах для отображения контента используются только символы ASCII, очень немногие веб-сайты теперь заявляют, что их кодировка — только ASCII, а не UTF-8. [37] Более 50 % отслеживаемых языков на 100 % используют UTF-8.

Многие стандарты поддерживают только UTF-8, например, это требуется для обмена JSON (без метки порядка байтов (BOM)). [38] UTF-8 также является рекомендацией WHATWG для спецификаций HTML и DOM и гласит: «Кодировка UTF-8 является наиболее подходящей кодировкой для обмена Unicode ». [8] Консорциум Интернет-почты рекомендует, чтобы все программы электронной почты могли отображать и создавать почту с использованием UTF-8. [39] [40] Консорциум Всемирной паутины рекомендует UTF-8 в качестве кодировки по умолчанию в XML и HTML (а не только использование UTF-8, а также объявление его в метаданных), «даже если все символы находятся в диапазоне ASCII… Использование отличных от UTF Кодировки -8 могут иметь неожиданные результаты». [41]

Многие программы имеют возможность чтения/записи UTF-8. Однако пользователю может потребоваться изменить параметры обычных настроек или может потребоваться спецификация (метка порядка байтов) в качестве первого символа для чтения файла. Примеры программного обеспечения, поддерживающего UTF-8, включают Microsoft Word , [42] [43] [44] Microsoft Excel (2016 и более поздние версии), [45] [46] Google Drive , LibreOffice и большинство баз данных.

устаревшие однобайтовые кодировки (и несколько многобайтовых CJK Однако для локальных текстовых файлов использование UTF-8 менее распространено, поскольку продолжают использоваться ). Основной причиной этого являются устаревшие текстовые редакторы, которые отказываются читать UTF-8, если первые байты файла не кодируют метку порядка байтов (BOM). [47]

Некоторое программное обеспечение может читать и записывать только UTF-8 (или, по крайней мере, не требует спецификации). [48] Блокнот Windows во всех поддерживаемых на данный момент версиях Windows по умолчанию пишет в UTF-8 без спецификации (отличие от устаревшего/неподдерживаемого Windows 7 Блокнота ), что приводит его в соответствие с большинством других текстовых редакторов. [49] Некоторые системные файлы в Windows 11 требуют UTF-8. [50] без необходимости спецификации, и почти все файлы в macOS и Linux должны быть в формате UTF-8 без спецификации. [ нужна ссылка ] Java 18 по умолчанию читает и записывает файлы в формате UTF-8, [51] а в более старых версиях (например, версиях LTS ) только NIO для этого был изменен API. Многие другие языки программирования по умолчанию используют UTF-8 для ввода-вывода , включая Ruby 3.0. [52] [53] и Р 4.2.2. [54] Все текущие версии Python поддерживают UTF-8 для ввода-вывода, даже в Windows (где это разрешено). open() функция [55] ), и существуют планы сделать ввод-вывод UTF-8 стандартным в Python 3.15 на всех платформах. [56] [57] C++23 использует UTF-8 как единственный переносимый формат файлов исходного кода (на удивление, раньше его не было). [58]

Использование UTF-8 в памяти намного ниже, чем в других областях, UTF-16 вместо него часто используется . Это происходит особенно в Windows, но также и в JavaScript , Python, [час] Qt и многие другие кроссплатформенные программные библиотеки. совместимость с Windows API Основной причиной этого является ; изначально этот выбор был сделан из-за убеждения, что прямая индексация BMP улучшит скорость. Перевод из/на внешний текст в формате UTF-8 замедляет работу программного обеспечения и, что более важно, приводит к ошибкам, когда разные фрагменты кода не выполняют одинаковый перевод.

Обратная совместимость является серьезным препятствием для изменения кода на использование UTF-8 вместо 16-битной кодировки, но это происходит. Строковый примитив по умолчанию в Go , [59] Юлия , Раст , Свифт 5 , [я] и ПиПи [61] во всех случаях внутренне использует UTF-8. Python 3.3 внутренне использует UTF-8 для расширений API Python C. [Дж] [63] а иногда и для строк [62] [64] а в будущей версии Python планируется по умолчанию хранить строки в формате UTF-8. [к] [66] Современные версии Microsoft Visual Studio внутренне используют UTF-8. [67] В SQL Server 2019 от Microsoft добавлена ​​поддержка UTF-8, и ее использование приводит к увеличению скорости на 35% и «почти на 50% снижению требований к памяти». [л]

Все поддерживаемые в настоящее время версии Windows в той или иной степени поддерживают UTF-8 (включая Xbox ); [7] частичная поддержка существует, по крайней мере, с Windows XP . По состоянию на май 2019 г. Microsoft изменила свою предыдущую позицию, рекомендуя только UTF-16; появилась возможность устанавливать UTF-8 в качестве «кодовой страницы» для Windows API; и Microsoft рекомендует программистам использовать UTF-8, [м] и даже заявляет, что «UTF-16 [...] — это уникальное бремя, которое Windows возлагает на код, предназначенный для нескольких платформ». [н]

История

[ редактировать ]
См. Также: Универсальный набор кодированных символов § История

Международная организация по стандартизации (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
U+0000 U + 009F 00–9F
U + 00A0 U + 00FF А0 А0–ФФ
U + 0100 U + 4015 A1–F5 21–7Е, А0–ФФ
U + 4016 U + 38E2D F6–ФБ 21–7Е, А0–ФФ 21–7Е, А0–ФФ
U + 38E2E U + 7FFFFFFFF ФК–ФФ 21–7Е, А0–ФФ 21–7Е, А0–ФФ 21–7Е, А0–ФФ 21–7Е, А0–ФФ

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

ФСС-UTF

[ редактировать ]
Предложение FSS-UTF (1992 г.)
Первая кодовая точка Последняя кодовая точка Байт 1 Байт 2 Байт 3 Байт 4 Байт 5
U+0000 U + 007F 0ххххххх
U + 0080 U + 207F 10xxxxxx 1ххххххх
U + 2080 U + 8207F 110ххххх 1ххххххх 1ххххххх
U+82080 U + 208207F 1110хххх 1ххххххх 1ххххххх 1ххххххх
U+2082080 U + 7FFFFFFFF 11110xxx 1ххххххх 1ххххххх 1ххххххх 1ххххххх

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

ФСС-UTF (1992 г.) / UTF-8 (1993 г.) [2]
Первая кодовая точка Последняя кодовая точка Байт 1 Байт 2 Байт 3 Байт 4 Байт 5 Байт 6
U+0000 U + 007F 0ххххххх
U + 0080 U + 07FF 110ххххх 10xxxxxx
U + 0800 U+FFFF 1110хххх 10xxxxxx 10xxxxxx
U+10000 U + 1FFFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
U+200000 U + 3FFFFFF 111110хх 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
U+4000000 U + 7FFFFFFFF 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

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

В ноябре 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 г.)
  • ИСО/МЭК 10646:2014 §9.1 (2014 г.) [74]
  • Стандарт Юникод, версия 15.0.0 (2022 г.) [75]

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

  • Стандарт 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 г.)
  • Стандартное приложение Unicode № 27: Unicode 3.1 (2001 г.) [76]
  • Стандарт Юникод, версия 5.0 (2006 г.) [77]
  • Стандарт Юникод, версия 6.0 (2010 г.) [78]

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

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

[ редактировать ]
См. также: Сравнение кодировок Unicode.

Некоторые из важных особенностей этого кодирования заключаются в следующем:

  • Обратная совместимость. Обратная совместимость с ASCII и огромное количество программного обеспечения, предназначенного для обработки текста в кодировке ASCII, были основной движущей силой разработки UTF-8. В UTF-8 отдельные байты со значениями в диапазоне от 0 до 127 напрямую сопоставляются с кодовыми точками Юникода в диапазоне 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: несколько байтов не могут появиться; байт с установленным старшим битом не может быть одиноким; а дальнейшие требования означают, что крайне маловероятно, чтобы читаемый текст в любом расширенном ASCII был допустимым UTF-8. Частично популярность UTF-8 объясняется тем, что она также обеспечивает для них форму обратной совместимости. Процессор UTF-8, который ошибочно получает на входе расширенный ASCII, может, таким образом, «автоматически обнаружить» это с очень высокой надежностью. Поток UTF-8 может просто содержать ошибки, в результате чего схема автоматического обнаружения выдает ложные срабатывания; но автоматическое обнаружение оказывается успешным в подавляющем большинстве случаев, особенно с более длинными текстами, и широко используется. Он также работает для «отката» или замены 8-битных байтов с использованием соответствующей кодовой точки для устаревшей кодировки при обнаружении ошибок в UTF-8, что позволяет выполнить восстановление, даже если UTF-8 и устаревшая кодировка объединены в одном файле. .
  • Код префикса : первый байт указывает количество байтов в последовательности. Чтение из потока позволяет мгновенно декодировать каждую отдельную полностью полученную последовательность без необходимости предварительного ожидания первого байта следующей последовательности или индикации конца потока. Длина многобайтовых последовательностей легко определяется людьми, поскольку это просто количество старших единиц в ведущем байте. Неправильный символ не будет декодирован, если поток закончится в середине последовательности.
  • Самосинхронизация : ведущие байты и байты продолжения не имеют общих значений (байты продолжения начинаются с битов 10, а отдельные байты начинаются с 0 и более ведущие байты начинаются с 11 ). Это означает, что при поиске случайно не будет найдена последовательность одного символа, начинающаяся с середины другого символа. Это также означает, что начало символа можно найти из случайной позиции, скопировав не более 3 байтов для поиска ведущего байта. Неправильный символ не будет декодирован, если поток начнется в середине последовательности, а более короткая последовательность никогда не появится внутри более длинной.
  • Порядок сортировки: выбранные значения ведущих байтов означают, что список строк UTF-8 можно отсортировать в порядке кодовых точек путем сортировки соответствующих последовательностей байтов.

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

[ редактировать ]
  • UTF-8 может кодировать любой символ Юникода , что позволяет избежать необходимости определять и устанавливать « кодовую страницу » или иным образом указывать, какой набор символов используется, и позволяет выводить данные в нескольких сценариях одновременно. Во многих сценариях использовалось более одной однобайтовой кодировки, поэтому даже знание сценария было недостаточным для его правильного отображения.
  • Байты 0xFE и 0xFF не отображаются, поэтому действительный поток UTF-8 никогда не соответствует метке порядка байтов UTF-16 (BOM) и, следовательно, его нельзя спутать. Отсутствие 0xFF (0377) также устраняет необходимость экранирования этого байта в Telnet (и FTP-соединении).
  • Текст в кодировке UTF-8 больше, чем специализированные однобайтовые кодировки, за исключением простых символов ASCII. В случае сценариев, в которых используются 8-битные наборы символов с нелатинскими символами, закодированными в верхней половине (например, большинство кодовых страниц кириллицы и греческого алфавита ), символы в UTF-8 будут иметь двойной размер. В некоторых алфавитах, таких как тайский и деванагари (который используется в различных языках Южной Азии), размер символов увеличивается в три раза. Есть даже примеры, когда один байт превращается в составной символ в Юникоде и, таким образом, в шесть раз больше в 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-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, например, с помощью метки порядка байтов (BOM).
    • Если в UTF-16 отсутствует нечетное количество байтов, вся остальная часть строки будет бессмысленным текстом. Любые байты, отсутствующие в UTF-8, по-прежнему позволят точно восстановить текст, начиная со следующего символа после пропущенных байтов.

Производные

[ редактировать ]

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

ЦЭСУ-8

[ редактировать ]
Основная статья: ЦЭСУ-8

Технический отчет Unicode № 26 [79] присваивает имя CESU-8 нестандартному варианту UTF-8, в котором символы Юникода в дополнительных плоскостях кодируются с использованием шести байтов, а не четырех байтов, требуемых 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 базе UTF8 Набор символов использует кодировку CESU-8 и устарел. AL32UTF8 В наборе символов используется кодировка UTF-8, соответствующая стандартам, и это является предпочтительным. [80] [81]

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

MySQL utf8mb3

[ редактировать ]

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

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

[ редактировать ]

Модифицированная UTF-8 (MUTF-8) возникла на языке программирования Java . В модифицированной UTF-8 нулевой символ (U+0000) использует двухбайтовую удлиненную кодировку. 110 00000 10 000000 (шестнадцатеричный С0 80 ), вместо 00000000 (шестнадцатеричный 00 ). [85] Модифицированные строки UTF-8 никогда не содержат фактических нулевых байтов, но могут содержать все кодовые точки Unicode, включая U+0000, [86] что позволяет обрабатывать такие строки (с добавленным нулевым байтом) традиционными строковыми функциями с нулевым завершением . Все известные реализации модифицированного UTF-8 также обрабатывают суррогатные пары, как в CESU-8 .

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

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

WTF-8

[ редактировать ]

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

Термин «WTF-8» также использовался в шутку для обозначения ошибочно дважды закодированного UTF-8. [94] [95] иногда подразумевается, что CP1252 . закодированы только байты [96]

ПЭП 383

[ редактировать ]

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

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

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

См. также

[ редактировать ]

Примечания

[ редактировать ]
  1. ^ 17 самолетов умножить на 2 16 кодовые точки на плоскость, минус 2 11 технически недействительные суррогаты .
  2. ^ Битов данных достаточно для кодирования до 0x1F FFFF , но текущий RFC 3629 §3 ограничивает кодировку UTF-8 кодовой точкой U+ 10 FFFF , чтобы предотвратить распространение кодировок, превышающих 20-битный предел UTF-16. Устаревший RFC 2279 допускал кодировку UTF-8 до кодовой точки U+ 7FF FFFF , допуская закодированное значение длиной до 27 бит. По этой причине, хотя первый байт многобайтовой кодовой последовательности UTF-8 ограничен значениями из F0 до F4 , поскольку не было строгой необходимости обновлять старое программное обеспечение для декодирования, чтобы оно правильно функционировало с кодировками, соответствующими новым ограничениям, некоторое старое программное обеспечение, которое не обеспечивает соблюдение этих ограничений, остается в использовании.
  3. ^ Некоторые сложные символы эмодзи могут занимать даже больше: смайлик флага трансгендера (🏳️‍⚧️), который состоит из последовательности из 5 кодовых точек U+1F3F3 U+FE0F U+200D U+26A7 U+FE0F, требует для кодирования шестнадцати байтов. , в то время как для флага Шотландии (🏴 Football Football) требуется в общей сложности 28 байтов для последовательности из 7 кодовых точек U+1F3F4 U+E0067 U+E0062 U+E0073 U+E0063 U+E0074 U+E007F .
  4. ^ Например, ячейка 9D говорит +1D. Шестнадцатеричное число 9D в двоичном формате равно 10011101 , и поскольку 2 старших бита ( 10 ) зарезервированы для маркировки этого байта как продолжения, остальные 6 бит ( 011101 ) имеют шестнадцатеричное значение 1D.
  5. ^ «Этот PEP предлагает изменить кодировку файловой системы по умолчанию в Windows на utf-8 и изменить все функции файловой системы для использования API-интерфейсов Unicode для путей файловой системы. [...] может правильно обрабатывать все символы, используемые в путях (в POSIX с помощью surrogateescape умение обращаться; в Windows, потому что str отображает нативное представление). В Windows байты не могут обойти все символы, используемые в путях». [28]
  6. ^
    один байт  128 = 128  
    два байта  ( 16 + 5 ) × 64 = 1 344  
    три байта  5 × 64 × 64 = + 20 480  
     21 952 общий

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

  7. ^ Опрос W3Techs.com [9] основано на кодировке, объявленной в ответе сервера, см. https://w3techs.com/forum/topic/22994.
  8. ^ Python использует ряд кодировок для того, что он называет «Юникод», однако ни одна из этих кодировок не является UTF-8. Python 2 и ранняя версия 3 использовали UTF-16 в Windows и UTF-32 в Unix. В более поздних реализациях Python 3 используются три кодировки фиксированной длины: ISO-8859-1 , UCS-2 и UTF-32, в зависимости от необходимой максимальной кодовой точки.
  9. ^ Переход на UTF-8 реализует одну из долгосрочных целей строки — обеспечить высокопроизводительную обработку, [...] а также закладывает основу для предоставления ещё более производительных API в будущем. [60]
  10. ^ Поскольку взаимодействие с другими библиотеками часто требует какого-то внутреннего представления, спецификация выбирает UTF-8 в качестве рекомендуемого способа представления строк коду C. [...] Указатели data и utf8 указывают на одну и ту же память, если в строке используются только символы ASCII (использования только Latin-1 недостаточно). [...] Рекомендуемый способ создания объекта Unicode — использовать функцию PyUnicode_New [...] Для доступа к представлению UTF-8 предоставляется новая функция PyUnicode_AsUTF8. [62]
  11. ^ Пока мы не отбросим устаревший объект Unicode, очень сложно попробовать другие реализации Unicode, например реализацию на основе UTF-8 в PyPy. [65]
  12. ^ Например, изменение существующего типа данных столбца с NCHAR(10) на CHAR(10) с использованием параметров сортировки с поддержкой UTF-8 приводит к сокращению требований к памяти почти на 50%. [...] В диапазоне ASCII при интенсивном вводе-выводе чтения/записи в UTF-8 мы измерили среднее улучшение производительности на 35% по сравнению с UTF-16 с использованием кластерных таблиц с некластеризованным индексом в строковом столбце, и улучшение производительности в среднем на 11 % по сравнению с UTF-16 при использовании кучи. [68]
  13. ^ Начиная с версии Windows 1903 (обновление от мая 2019 г.), вы можете использовать свойство ActiveCodePage в appxmanifest для упакованных приложений или манифест Fusion для неупакованных приложений, чтобы заставить процесс использовать UTF-8 в качестве кодовой страницы процесса. [...] CP_ACP приравнивается к CP_UTF8 только при работе в Windows версии 1903 (обновление от мая 2019 г.) или более поздней версии, а описанному выше свойству ActiveCodePage присвоено значение UTF-8. В противном случае он учитывает кодовую страницу устаревшей системы. Мы рекомендуем использовать CP_UTF8 явно. [69]
  14. ^ «Работая в UTF-8, вы можете обеспечить максимальную совместимость [...] Windows изначально работает в UTF-16 (или WCHAR), что требует преобразования кодовых страниц с использованием MultiByteToWideChar и WideCharToMultiByte. Это уникальное бремя, которое возлагает на себя Windows. код, предназначенный для нескольких платформ. [...] Microsoft Game Development Kit (GDK) и Windows в целом продвигаются вперед к поддержке UTF-8, чтобы устранить это уникальное бремя Windows по нацеливанию кода или взаимообмену с несколькими платформами и Интернетом. Кроме того, это приводит к меньшему количеству проблем с интернационализацией в приложениях и играх и уменьшает матрицу тестов, необходимую для правильной работы». [7]

Ссылки

[ редактировать ]
  1. ^ «Глава 2. Общая структура» . Стандарт Unicode (изд. 6.0). Маунтин-Вью, Калифорния, США: Консорциум Unicode . ISBN  978-1-936213-01-6 .
  2. ^ Jump up to: а б Пайк, Роб (30 апреля 2003 г.). «История UTF-8» .
  3. ^ Пайк, Роб; Томпсон, Кен (1993). «Hello World или Καλημέρα κόσμε или こんにちは 世界» (PDF) . Материалы зимней конференции USENIX 1993 года .
  4. ^ «Безопасная файловая система UCS — формат преобразования (FSS-UTF) — предварительная спецификация X/Open» (PDF) . unicode.org .
  5. ^ «Материалы зимней конференции USENIX 1993 г.» . usenix.org .
  6. ^ Jump up to: а б Альвестранд, Харальд Т. (январь 1998 г.). Политика IETF в отношении наборов символов и языков . IETF . дои : 10.17487/RFC2277 . BCP 18. RFC 2277 .
  7. ^ Jump up to: а б с «Поддержка UTF-8 в Microsoft GDK» . Learn.microsoft.com . Комплект разработки игр Microsoft (GDK) . Проверено 05 марта 2023 г.
  8. ^ Jump up to: а б «Стандарт кодирования» . кодирование.spec.whatwg.org . Проверено 15 апреля 2020 г.
  9. ^ Jump up to: а б с «Обзор использования кодировок символов с разбивкой по рейтингу» . W3Techs . Проверено 22 мая 2024 г.
  10. ^ «Стандарт кодирования § 4.2. Имена и метки» . ЧТОРГ . Проверено 29 апреля 2018 г.
  11. ^ «Наборы символов» . Управление по присвоению номеров в Интернете . 23 января 2013 г. Проверено 8 февраля 2013 г.
  12. ^ Ливиу (07 февраля 2014 г.). «Кодовая страница UTF-8 65001 в Windows 7 — часть I» . Проверено 30 января 2018 г. Раньше под XP (и, непроверенно, но, вероятно, и под Vista) циклы for просто не работали, пока была активна кодовая страница 65001.
  13. ^ «MySQL :: Справочное руководство MySQL 8.0 :: 10.9.1 Набор символов utf8mb4 (4-байтовая кодировка Unicode UTF-8)» . Справочное руководство MySQL 8.0 . Корпорация Оракл . Проверено 14 марта 2023 г.
  14. ^ Jump up to: а б «MySQL :: Справочное руководство MySQL 8.0 :: 10.9.2 Набор символов utf8mb3 (3-байтовая кодировка Unicode UTF-8)» . Справочное руководство MySQL 8.0 . Корпорация Оракл . Проверено 24 февраля 2023 г.
  15. ^ «Наборы символов HP PCL | Блог о поддержке языка управления принтером (PCL и PXL)» . 19 февраля 2015 г. Архивировано из оригинала 19 февраля 2015 г. Проверено 30 января 2018 г.
  16. ^ «Руководство по поддержке глобализации баз данных» . docs.oracle.com . Проверено 16 марта 2023 г.
  17. ^ «БОМ» . Суйкавики (на японском языке). Архивировано из оригинала 17 января 2009 г.
  18. ^ Дэвис, Марк . «Формы Юникода» . ИБМ . Архивировано из оригинала 6 мая 2005 г. Проверено 18 сентября 2013 г.
  19. ^ "Нить" . Разработчик Apple . Проверено 15 марта 2021 г.
  20. ^ «Глава 3» (PDF) , Стандарт Юникод , стр. 54
  21. ^ «Глава 3» (PDF) , Стандарт Юникод , стр. 55
  22. ^ «Глава 3» (PDF) , Стандарт Юникод , стр. 55
  23. ^ Jump up to: а б с Йерго, Ф. (ноябрь 2003 г.). UTF-8, формат преобразования ISO 10646 . IETF . дои : 10.17487/RFC3629 . СТД 63. RFC 3629 . Проверено 20 августа 2020 г.
  24. ^ «Глава 3» (PDF) , Стандарт Юникод , стр. 54
  25. ^ «Глава 3» (PDF) , Стандарт Юникод , стр. 55
  26. ^ Марин, Марвин (17 октября 2000 г.). Анализ уязвимостей UNICODE для Windows NT . Обход папок веб-сервера. Институт SANS (Отчет). Часто задаваемые вопросы по вредоносному ПО. MS00-078. Архивировано из оригинала 27 августа 2014 г.
  27. ^ «CVE-2008-2938» . Национальная база данных уязвимостей (nvd.nist.gov) . США Национальный институт стандартов и технологий . 2008.
  28. ^ «Изменить кодировку файловой системы Windows на UTF-8» . Python.org . ПЭП 529 . Проверено 10 мая 2022 г.
  29. ^ «Ввод данных» . docs.oracle.com . Платформа Java SE 8) . Проверено 24 марта 2021 г.
  30. ^ «Недекодируемые байты в интерфейсах системных символов» . python.org . 22 апреля 2009 г. Проверено 13 августа 2014 г.
  31. ^ Юникод 6.0.0 . unicode.org (отчет). Октябрь 2010.
  32. ^ Jump up to: а б с фон Лёвис, Мартин (22 апреля 2009 г.). «Недекодируемые байты в интерфейсах системных символов» . Фонд программного обеспечения Python . ПЭП 383.
  33. ^ «Глава 2» (PDF) , Стандарт Unicode — версия 15.0.0 , стр. 39
  34. ^ «Часто задаваемые вопросы по UTF-8 и Unicode для Unix/Linux» .
  35. ^ Дэвис, Марк (3 февраля 2012 г.). «Юникод используется более чем в 60 процентах Интернета» . Официальный блог Google . Архивировано из оригинала 9 августа 2018 г. Проверено 24 июля 2020 г.
  36. ^ Дэвис, Марк (5 мая 2008 г.). «Переход на Юникод 5.1» . Официальный блог Google . Проверено 13 марта 2023 г.
  37. ^ «Статистика использования и доля рынка ASCII для веб-сайтов» . W3Techs . Январь 2024 года . Проверено 1 января 2024 г.
  38. ^ Брей, Тим (декабрь 2017 г.). Брей, Тим (ред.). Формат обмена данными нотации объектов JavaScript (JSON) . IETF. дои : 10.17487/RFC8259 . РФК 8259 . Проверено 16 февраля 2018 г.
  39. ^ «Использование международных символов в интернет-почте» . Консорциум Интернет-почты. 1 августа 1998 г. Архивировано из оригинала 26 октября 2007 г. Проверено 8 ноября 2007 г.
  40. ^ «Стандарт кодирования» . кодирование.spec.whatwg.org . Проверено 15 ноября 2018 г.
  41. ^ «Указание кодировки символов документа» . HTML 5.2 (Отчет). Консорциум Всемирной паутины . 14 декабря 2017 года . Проверено 3 июня 2018 г.
  42. ^ «Выбирать кодировку текста при открытии и сохранении файлов» . Служба поддержки Microsoft (support.microsoft.com) . Проверено 1 ноября 2021 г.
  43. ^ «UTF-8 — кодировка символов Microsoft Word. DOC и DOCX файлы?" . Переполнение стека . Проверено 01 ноября 2021 г. .
  44. ^ «Экспорт UTF-8 .txt файл из Word » . support.3playmedia.com .
  45. ^ "Являются XLSX файлы в кодировке UTF-8 по определению?» . Stack Overflow . Excel . Проверено 01.11.2021 .
  46. ^ Абхинав, Анкит; Сюй, Джазлин (13 апреля 2020 г.). «Как открыть UTF-8 CSV файл в Excel без неправильного преобразования символов японского и китайского языков для Mac и Windows?» . Сообщество поддержки Microsoft . Проверено 1 ноября 2021 г ..
  47. ^ «Как мне заставить Блокнот сохранять текст в формате UTF-8 без спецификации?» . Переполнение стека . Проверено 24 марта 2021 г.
  48. ^ Галлоуэй, Мэтт (октябрь 2012 г.). «Кодировка символов для разработчиков iOS; или UTF-8, что теперь?» . www.galloway.me.uk . Проверено 02 января 2021 г. ... на самом деле вы обычно просто предполагаете UTF-8, поскольку это, безусловно, самая распространенная кодировка.
  49. ^ «Блокнот Windows 10 получает улучшенную поддержку кодировки UTF-8» . Мигающий компьютер . Проверено 24 марта 2021 г. Microsoft теперь по умолчанию сохраняет новые текстовые файлы в формате UTF-8 без спецификации, как показано ниже.
  50. ^ » Windows 11 «Настройка меню «Пуск » . docs.microsoft.com . Проверено 29 июня 2021 г. Убедитесь, что ваш LayoutModification.json использует кодировку UTF-8.
  51. ^ «UTF-8 по умолчанию» . openjdk.java.net . JEP 400 . Проверено 30 марта 2022 г.
  52. ^ «Установите по умолчанию для Encoding.default_external значение UTF-8 в Windows» . Система отслеживания проблем Ruby (bugs.ruby-lang.org) . Рубиновый мастер. Функция № 16604 . Проверено 1 августа 2022 г.
  53. ^ «Функция № 12650: используйте кодировку UTF-8 для ENV в Windows» . Система отслеживания проблем Ruby (bugs.ruby-lang.org) . Рубиновый мастер . Проверено 1 августа 2022 г.
  54. ^ «Новые возможности в R 4.2.0» . R-блоггеры (r-bloggers.com) . Блог Jumping Rivers. 01.04.2022 . Проверено 1 августа 2022 г.
  55. ^ «добавить новый режим UTF-8» . peps.python.org . ПЭП 540 . Проверено 23 сентября 2022 г.
  56. ^ «Сделать режим UTF-8 по умолчанию» . peps.python.org . ПЭП 686 . Проверено 26 июля 2023 г.
  57. ^ «Добавить опционально EncodingWarning" . Python.org . PEP 597 . Проверено 24 августа 2021 г.
  58. ^ Поддержка UTF-8 в качестве переносимой кодировки исходного файла (PDF) . open-std.org (Отчет). 2022. с2295р6.
  59. ^ «Представление исходного кода» . Спецификация языка программирования Go . golang.org (Отчет) . Проверено 10 февраля 2021 г.
  60. ^ Цай, Майкл Дж. (21 марта 2019 г.). «Строка UTF-8 в Swift 5» (сообщение в блоге) . Проверено 15 марта 2021 г.
  61. ^ «Выпущен PyPy v7.1; теперь для строк Unicode используется внутренняя UTF-8» . Маттип. Статусный блог PyPy . 24 марта 2019 г. Проверено 21 ноября 2020 г.
  62. ^ Jump up to: а б «Гибкое представление строк» . Python.org . ПЭП 393 . Проверено 18 мая 2022 г.
  63. ^ «Общие структуры объектов» . Документация Python . Проверено 29 мая 2024 г.
  64. ^ «Объекты и кодеки Unicode» . Документация Python . Проверено 19 августа 2023 г. Представление UTF-8 создается по требованию и кэшируется в объекте Unicode.
  65. ^ «PEP 623 – удалить wstr из Юникода» . Python.org . Проверено 21 ноября 2020 г.
  66. ^ Воутерс, Томас (11 июля 2023 г.). «Выпущена бета-версия Python 3.12.0 4» . Python Insider (pythoninsider.blogspot.com) (запись в блоге) . Проверено 26 июля 2023 г. Устаревший wstr и wstr_length члены реализации объектов Юникода на языке C были удалены согласно PEP 623.
  67. ^ "validate-charset (проверка совместимости символов)" . docs.microsoft.com . Проверено 19 июля 2021 г. Visual Studio использует UTF-8 в качестве внутренней кодировки символов во время преобразования между исходным набором символов и набором символов выполнения.
  68. ^ «Представляем поддержку UTF-8 для SQL Server» . techcommunity.microsoft.com . 2019-07-02 . Проверено 24 августа 2021 г.
  69. ^ «Используйте кодовую страницу Windows UTF-8 — приложения UWP» . docs.microsoft.com . Проверено 6 июня 2020 г.
  70. ^ «Приложение F. Формат преобразования FSS-UTF / Safe UCS для файловой системы» (PDF) . Стандарт Юникод 1.1 . Архивировано (PDF) из оригинала 7 июня 2016 г. Проверено 7 июня 2016 г.
  71. ^ Уистлер, Кеннет (12 июня 2001 г.). «FSS-UTF, UTF-2, UTF-8 и UTF-16» . Архивировано из оригинала 7 июня 2016 г. Проверено 7 июня 2006 г.
  72. ^ Jump up to: а б Пайк, Роб (30 апреля 2003 г.). «История UTF-8» . Проверено 7 сентября 2012 г.
  73. ^ Пайк, Роб (6 сентября 2012 г.). «UTF-8 вчера исполнилось 20 лет» . Проверено 7 сентября 2012 г.
  74. ^ ISO/IEC 10646:2014 §9.1 , 2014.
  75. ^ Стандарт Unicode, версия 15.0 §3.9 D92, §3.10 D95 , 2021 г.
  76. ^ Стандартное приложение Unicode № 27: Unicode 3.1 , 2001 г.
  77. ^ Стандарт Unicode, версия 5.0 §3.9–§3.10 гл. 3 , 2006.
  78. ^ Стандарт Unicode, версия 6.0 §3.9 D92, §3.10 D95 , 2010 г.
  79. ^ Макгоуэн, Рик (19 декабря 2011 г.). «Схема кодирования совместимости для UTF-16: 8-бит (CESU-8)» . Консорциум Юникод . Технический отчет Unicode № 26.
  80. ^ «Поддержка набора символов» . Документация по базе данных Oracle 19c, Справочник по языку SQL . Корпорация Оракл .
  81. ^ «Поддержка многоязычных баз данных с помощью Unicode § Поддержка стандарта Unicode в базе данных Oracle» . Руководство по поддержке глобализации баз данных . Корпорация Оракл .
  82. ^ «8.2.2.3. Кодировки символов» . Стандарт HTML 5.1 . W3C .
  83. ^ «8.2.2.3. Кодировки символов» . Стандарт HTML5 . W3C .
  84. ^ «12.2.3.3 Кодировки символов» . HTML Уровень жизни . ЧТОРГ .
  85. ^ «Документация Java SE для интерфейса java.io.DataInput, подраздел «Модифицированный UTF-8»» . Корпорация Оракл . 2015 . Проверено 16 октября 2015 г.
  86. ^ «Спецификация виртуальной машины Java, раздел 4.4.7: «Структура CONSTANT_Utf8_info» » . Корпорация Оракл . 2015 . Проверено 16 октября 2015 г.
  87. ^ «Спецификация сериализации объектов Java, глава 6: Протокол потока сериализации объектов, раздел 2: Элементы потока» . Корпорация Оракл . 2010 . Проверено 16 октября 2015 г.
  88. ^ «Спецификация собственного интерфейса Java, глава 3: Типы JNI и структуры данных, раздел: Модифицированные строки UTF-8» . Корпорация Оракл . 2015 . Проверено 16 октября 2015 г.
  89. ^ «Спецификация виртуальной машины Java, раздел 4.4.7: «Структура CONSTANT_Utf8_info» » . Корпорация Оракл . 2015 . Проверено 16 октября 2015 г.
  90. ^ «АРТ и Далвик» . Проект Android с открытым исходным кодом . Архивировано из оригинала 26 апреля 2013 г. Проверено 9 апреля 2013 г.
  91. ^ «UTF-8 побитно» . Вики Тклера . 28 февраля 2001 г. Проверено 3 сентября 2022 г.
  92. ^ Сапен, Саймон (11 марта 2016 г.) [25 сентября 2014 г.]. «Кодировка WTF-8» . Архивировано из оригинала 24 мая 2016 г. Проверено 24 мая 2016 г.
  93. ^ Сапен, Саймон (25 марта 2015 г.) [25 сентября 2014 г.]. «Кодировка WTF-8 § Мотивация» . Архивировано из оригинала 16 августа 2020 г. Проверено 26 августа 2020 г.
  94. ^ «WTF-8.com» . 18 мая 2006 г. Проверено 21 июня 2016 г.
  95. ^ Шпеер, Робин (21 мая 2015 г.). «ftfy (исправляет текст для вас) 4.0: меньше меняем и больше исправляем» . Архивировано из оригинала 30 мая 2015 г. Проверено 21 июня 2016 г.
  96. ^ «WTF-8, формат преобразования кодовой страницы 1252» . Архивировано из оригинала 13 октября 2016 г. Проверено 12 октября 2016 г.
  97. ^ «PEP 540 — добавление нового режима UTF-8» . Python.org . Проверено 24 марта 2021 г.
  98. ^ «RTFM optu8to16(3), optu8to16vis(3)» . www.mirbsd.org .
  99. ^ Jump up to: а б Дэвис, Марк ; Суиньяр, Мишель (2014). «3.7 Включение преобразования без потерь» . Вопросы безопасности Unicode . Технический отчет Unicode № 36.
[ редактировать ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=UTF-8&oldid=1237013480#WTF-8"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 2809f04e6e380666bb25b0c8446c2c76__1722091740
URL1:https://arc.ask3.ru/arc/aa/28/76/2809f04e6e380666bb25b0c8446c2c76.html
Заголовок, (Title) документа по адресу, URL1:
UTF-8 - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)