UTF-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 приводит к меньшему количеству проблем с интернационализацией [7] [8] чем любая альтернативная кодировка текста, и она реализована во всех современных операционных системах , включая Microsoft Windows , и таких стандартах, как JSON , где, как это становится все чаще, это единственная разрешенная форма Unicode .

UTF-8 является доминирующей кодировкой во Всемирной паутине (и интернет-технологиях), на которую по состоянию на 2024 год будет приходиться 98,2% всех веб-страниц, 99,1% из 100 000 лучших страниц и до 100% для многих языков. . [9] Практически во всех странах и языках 95% или более используют кодировку UTF-8 в Интернете.

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

Официальное название кодировки — UTF-8 , это написание используется во всех документах Консорциума Unicode. В большинстве стандартов он также официально указан в верхнем регистре, но все они также нечувствительны к регистру и utf-8 часто используется в коде. [ нужна ссылка ]

Некоторые другие варианты написания также могут быть приняты стандартами, например веб-стандарты (которые включают CSS , HTML , XML и заголовки HTTP ) явно разрешают utf8 (и запрещают «unicode») и многие псевдонимы для кодировок. [10] Написание с пробелом, например «UTF 8», не должно использоваться. Официальный орган по присвоению номеров в Интернете также указывает csUTF8 как единственный псевдоним. [11] который используется редко.

В Windows UTF-8 — это кодовая страница. 65001[12] (т.е. CP_UTF8 в исходном коде).

В MySQL UTF-8 называется utf8mb4[13] (с utf8mb3и его псевдоним utf8, являющийся подмножеством кодировки символов в базовой многоязычной плоскости. [14] ). В HP PCL идентификатор символа для UTF-8 равен 18N. [15]

В базе данных Oracle (начиная с версии 9.0) AL32UTF8[16] означает UTF-8. См. также CESU-8 , почти синоним UTF-8, который следует использовать редко.

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

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

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

Кодовая точка ↔ преобразование UTF-8
Первая кодовая точка Последняя кодовая точка Байт 1 Байт 2 Байт 3 Байт 4
U+00 0 0 U + 00 7 Ф 0 ххх хххх
U+0 0 8 0 U+0 7 Ж Ж 110 ххх хх 10 хх хххх
И+ 0 8 0 0 U+ Ж Ж Ж Ж 1110 хххх 10 хххх хх 10 хх хххх
И+ 0 1 0 0 0 0 [б] U+ 1 0 Ф Ф Ф Ф 11110 х хх 10 хх хххх 10 хххх хх 10 хх хххх

Первые 128 кодовых точек (ASCII) занимают 1 байт. Для кодирования следующих 1920 кодовых точек требуется два байта, что охватывает остальную часть почти всех алфавитов латинского алфавита , а также расширений IPA , греческого , кириллического , коптского , армянского , иврита , арабского , сирийского алфавитов , алфавитов таана и нко , как а также Объединение диакритических знаков . Три байта необходимы для остальных 61 440 кодовых точек базовой многоязычной плоскости (BMP), включая большинство китайских, японских и корейских символов . Четыре байта необходимы для 1 048 576 кодовых точек в других плоскостях Unicode , которые включают в себя эмодзи (пиктографические символы), менее распространенные символы CJK , различные исторические сценарии и математические символы .

Целый графический символ может занимать более 4 байт, поскольку состоит из более чем одной кодовой точки. Например, символ национального флага занимает 8 байтов, поскольку он «составлен из пары скалярных значений Юникода» как за пределами BMP. [19] [с]

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

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

Три байта 1110 0010 10 000010 10 101100 можно более кратко записать в шестнадцатеричном виде , как Е2 82 АС .

В следующей таблице приведены это преобразование, а также другие преобразования разной длины в UTF-8.

Процесс кодирования UTF-8
Характер Двоичная кодовая точка Двоичный UTF-8 Шестнадцатеричный UTF-8
$ U + 0024 010 0100 0 0100100 24
£ U + 00A3 000 10 10 0011 110 00010 10 100011 С2 А3
И U + 0418 100 00 01 1000 110 10000 10 011000 Д0 98
ह (буква деванагари HA) U + 0939 0000 1001 00 11 1001 1110 0000 10 100100 10 111001 Е0 А4 Б9
€ U + 20AC 0010 0000 10 10 1100 1110 0010 10 000010 10 101100 Е2 82 АС
один U + D55C 1101 0101 01 01 1100 1110 1101 10 010101 10 011100 ЭД 95 9С
𐍈 U + 10348 0 00 01 0000 0011 01 00 1000 11110 000 10 010000 10 001101 10 001000 Ф0 90 8Д 88
Дополнительная зона частного использования B U + 1096B3 1 00 00 1001 0110 10 11 0011 11110 100 10 001001 10 011010 10 110011 Ф4 89 9А Б3

Вьетнамская Я фраза « говорю по-вьетнамски» ( 𨉟呐㗂越 , «Я говорю по-вьетнамски») кодируется следующим образом:

Характер М я н час н от я т я неликвидный н г V я Эх т
Кодовая точка 4D ЕС 6Е 68 20 6Е F3 69 20 74 69 1EBF 6Е 67 20 56 69 1EC7 74
Шестнадцатеричный UTF-8 С3 переменного тока С3 Б3 Е1 НЕТ лучший друг Е1 ББ 87
Характер 𨉟 На 㗂 крест
Кодовая точка 2825F 5450 35С2 8Д8А
Шестнадцатеричный UTF-8 Ф0 А8 89 9F Е5 91 90 Е3 97 82 Е8 Б6 8А

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

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

UTF-8
0 1 2 3 4 5 6 7 8 9 А Б С Д И Ф
0x НУЛЕВОЙ СОХ СТХ И Т. Д ОТ ENQ ПОДТВЕРЖДЕНИЕ БЕЛ БС ХТ НЧ ВТ ФФ ЧР ТАК И
1x В СООТВЕТСТВИИ С DC1 DC2 DC3 DC4 ХОТЕТЬ СИН ЭТБ МОЖЕТ В СУБ ЭКУ ФС GS РС НАС
2x  СП  ! " # $ % & ' ( ) * + , - . /
3x 0 1 2 3 4 5 6 7 8 9 : ; < = > ?
4x @ А Б С Д И Ф Г ЧАС я Дж К л М Н ТО
5x П вопрос Р С Т В V В Х И С [ \ ] ^ _
6x ` а б с д и ж г час я дж к л м н тот
7x п д р с т в v В х и С { | } ~ ПРИНАДЛЕЖАЩИЙ
8x +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +А +Б +С +Д +Э +Ф
9x +10 +11 +12 +13 +14 +15 +16 +17 +18 +19 +1А +1Б +1С +1Д +1Е +1F
Топор +20 +21 +22 +23 +24 +25 +26 +27 +28 +29 +2А +2Б +2С +2D +2Е +2F
Бх +30 +31 +32 +33 +34 +35 +36 +37 +38 +39 +3А +3Б +3С +3D +3Е +3F
Сх 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
Дх 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
Бывший 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
Форекс 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. ↑ Перейти обратно: Перейти обратно: а б Пайк, Роб (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. ↑ Перейти обратно: Перейти обратно: а б Альвестранд, Харальд Т. (январь 1998 г.). Политика IETF в отношении наборов символов и языков . IETF . дои : 10.17487/RFC2277 . BCP 18. RFC 2277 .
  7. ↑ Перейти обратно: Перейти обратно: а б с «Поддержка UTF-8 в Microsoft GDK» . Learn.microsoft.com . Комплект разработки игр Microsoft (GDK) . Проверено 05 марта 2023 г.
  8. ↑ Перейти обратно: Перейти обратно: а б «Стандарт кодирования» . кодирование.spec.whatwg.org . Проверено 15 апреля 2020 г.
  9. ↑ Перейти обратно: Перейти обратно: а б с «Обзор использования кодировок символов с разбивкой по рейтингу» . 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. ↑ Перейти обратно: Перейти обратно: а б «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. ↑ Перейти обратно: Перейти обратно: а б с Йерго, Ф. (ноябрь 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. ↑ Перейти обратно: Перейти обратно: а б с фон Лёвис, Мартин (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 . Проверено 11.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. ↑ Перейти обратно: Перейти обратно: а б «Гибкое представление строк» . 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. ↑ Перейти обратно: Перейти обратно: а б Пайк, Роб (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. ↑ Перейти обратно: Перейти обратно: а б Дэвис, Марк ; Суиньяр, Мишель (2014). «3.7 Включение преобразования без потерь» . Вопросы безопасности Unicode . Технический отчет Unicode № 36.

Внешние ссылки [ править ]

Retrieved from "https://en.wikipedia.org/w/index.php?title=UTF-8&oldid=1226464974"