Войти
| Standard | Стандарт Unicode |
|---|---|
| Классификация | Формат преобразования Unicode, расширенный ASCII, кодирование размеров ширины |
| Расширяет | US-ASCII |
| Преобразует / кодирует | ISO 10646 (Unicode ) |
| , которому предшествует | UTF-1 |
| |
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 г..
Использование основных кодировок в Интернете с 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 заменяются битами кодовой точки.
| Количество байтов | Первая кодовая точка | Последняя кодовая точка | Байт 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, различные исторические сценарии, математические символы и эмодзи (пиктографические символы).
Рассмотрим кодировку знака евро, €:
Три байта 1110 0010 1000 0010 1010 1100 можно более кратко записать в шестнадцатеричном формате, как E2 82 AC.
Представлена приведенная сводка этого преобразования с разной длиной в 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_) и объясняется далее в легенде ниже.
| _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 | <. 003C | =. 003D | >. 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 путь, и этот пример отражен в имени и вводном тексте его замены. Приведенная ниже таблица основана на текстовом описании в приложении.
| Число. байтов | Первая. кодовая точка | Последняя. кодовая точка | Байт 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) и большая часть текста этого предложения были позже сохранены в окончательной спецификации.
| Number. байтов | Первая. кодовая точка | Последняя. кодовая точка | Байт 1 | Байт 2 | Байт 3 | Байт 4 | Байт 5 |
|---|---|---|---|---|---|---|---|
| 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.
| Число. байтов | Первая. кодовая точка | Последняя. кодовая точка | Байт 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 в различных документах стандартов:
Они заменяют определения, приведенные в следующих устаревших работах:
Все они одинаковы по своей общей механике, с основными различиями в таких вопросах, как д опустимый диапазон кода. точечные значения и безопасная обработка недопустимого ввода.
Вот некоторые из важных особенностей этой кодировки:
Следующие реализации показывают небольшие отличия от спецификации UTF-8. Они несовместимы со спецификацией UTF-8 и могут отклоняться от приложениями UTF-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 набор символов использует UTF8CESU-8. кодировка и устарела. Набор символов AL32UTF8использует кодировку UTF-8 и является предпочтительным.
ЦЕСУ-8 запрещено использовать в документах HTML5.
В 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 (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 (формат шаткого преобразования, 8-бит) разрешены непарные суррогатные половинки (от U + D800 до U + DFFF). Это необходимо для хранения возможно недопустимого UTF-16, например, имен файлов Windows. Многие системы, которые работают с UTF-8, работают таким образом, не считая его другим кодировкой, поскольку это проще.
(Термин «WTF-8» также использовался в шутливом смысле для обозначения , ошибочно дважды в кодировке UTF-8 иногда подразумевается, что кодируются только CP1252 байты)
Версия 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.
