Знак порядка байтов
Знак порядка байтов ( BOM ) — это особый вариант использования специального кода символов Юникода . U+FEFF ZERO WIDTH NO-BREAK SPACE , появление которого в виде магического числа в начале текстового потока может сигнализировать программе, читающей текст, о нескольких вещах: [1]
- порядок байтов или порядок байтов текстового потока в случаях 16- битной и 32-битной кодировки;
- тот факт, что текстовый поток кодируется в формате Unicode, обеспечивает высокий уровень достоверности;
- какая кодировка символов Unicode используется.
Использование спецификации не является обязательным. Его наличие мешает использованию UTF-8 программным обеспечением, которое не ожидает байтов, отличных от ASCII, в начале файла, но которое в противном случае могло бы обрабатывать текстовый поток.
Юникод может быть закодирован в виде 8-битных, 16-битных или 32-битных целых чисел. Для 16- и 32-битных представлений компьютер, получающий текст из произвольных источников, должен знать, в каком порядке байтов закодированы целые числа. Спецификация кодируется по той же схеме, что и остальная часть документа, и становится несимвольной кодовой точкой Юникода. если его байты поменяны местами. Следовательно, процесс доступа к тексту может проверить эти первые несколько байтов, чтобы определить порядок байтов, не требуя какого-либо контракта или метаданных за пределами самого текстового потока. Обычно принимающий компьютер при необходимости меняет местами байты на свой собственный порядок байтов и больше не нуждается в спецификации для обработки.
Последовательность байтов спецификации различается в зависимости от кодировки Unicode (в том числе за пределами стандарта Unicode, например UTF-7 , см. таблицу ниже ), и ни одна из последовательностей вряд ли появится в начале текстовых потоков, хранящихся в других кодировках. Таким образом, размещение закодированной спецификации в начале текстового потока может указать, что текст представляет собой Юникод, и определить используемую схему кодирования. Такое использование спецификации называется «подписью Unicode». [2]
Использование [ править ]
Спецификация — это просто код Unicode. U+FEFF ZERO WIDTH NO-BREAK SPACE, закодированный в текущей кодировке. Текстовый файл, начинающийся с байтов FE FF предполагает, что файл закодирован в UTF-16 с прямым порядком байтов.
Имя ZWNBSP следует использовать, если спецификация появляется в середине потока данных. Юникод говорит, что его следует интерпретировать как обычный код (а именно, соединение слов ), а не как спецификацию. Начиная с Unicode 3.2, это использование устарело в пользу U+2060 WORD JOINER. [1]
Имя этой кодовой точки в Юникоде 1.0 также BYTE ORDER MARK[3]
UTF-8 [ править ]
шестнадцатеричную ) Представление спецификации UTF-8 представляет собой ( последовательность байтов. EF BB BF.
Стандарт Unicode допускает спецификацию в UTF-8 . [4] но не требует и не рекомендует его использование. [5] UTF-8 всегда имеет одинаковый порядок байтов, [6] поэтому его единственное использование в UTF-8 - это сигнал в начале о том, что текстовый поток закодирован в UTF-8 или что он был преобразован в UTF-8 из потока, который содержал необязательную спецификацию. Стандарт также не рекомендует удалять спецификацию, если она существует, чтобы при циклическом переключении между кодировками не терялась информация и чтобы код, использующий ее, продолжал работать. [7] [8] IETF рекомендует, чтобы, если протокол (а) всегда использует UTF-8 или (б) имеет какой-либо другой способ указать, какая кодировка используется, то ему «СЛЕДУЕТ запретить использование U+FEFF в качестве подписи». [9] Примером несоблюдения этой рекомендации является протокол системного журнала IETF , который требует, чтобы текст был в формате UTF-8, а также требует спецификации. [10]
Отсутствие спецификации позволяет тексту быть обратно совместимым с программным обеспечением, разработанным для расширенного ASCII . Например, многие языки программирования допускают использование байтов, отличных от ASCII, в строковых литералах , но не в начале файла.
Спецификация не требуется для определения кодировки UTF-8. [ нужна ссылка ] UTF-8 — это разреженная кодировка: большая часть возможных комбинаций байтов не приводит к правильному тексту UTF-8. Двоичные данные и текст в любой другой кодировке, скорее всего, будут содержать последовательности байтов, недопустимые как UTF-8, поэтому наличие таких недопустимых последовательностей указывает на то, что файл не в формате UTF-8, а отсутствие недопустимых последовательностей является очень убедительным признаком того, что текст является недопустимым. UTF-8. Практически единственным исключением является текст, содержащий только байты диапазона ASCII, поскольку это может быть 7-битная кодировка, отличная от ASCII, но это маловероятно для любых современных данных, и даже тогда отличие от ASCII незначительно (например, изменение '\' на «¥»).
Microsoft Компиляторы [11] и интерпретаторы, а также многие программы для Microsoft Windows , такие как Блокнот (до Windows 10, сборка 1903). [12] ) рассматривайте спецификацию как обязательное магическое число , а не используйте эвристику. Эти инструменты добавляют спецификацию при сохранении текста в формате UTF-8 и не могут интерпретировать UTF-8, если спецификация не присутствует или файл не содержит только ASCII. Windows PowerShell (до 5.1) добавит спецификацию при сохранении XML-документов UTF-8. Однако в PowerShell Core 6 добавлен -Encoding включите некоторые командлеты под названием utf8NoBOM, чтобы документ можно было сохранить без спецификации. Google Docs также добавляет спецификацию при преобразовании документа в обычный текстовый файл для загрузки.
UTF-16 [ править ]
В UTF-16 спецификация ( U+FEFF) может быть помещен в качестве первых байтов файла или потока символов, чтобы указать порядок байтов (порядок байтов) всех 16-битных кодовых единиц файла или потока. Если будет предпринята попытка прочитать этот поток с неправильным порядком байтов, байты будут заменены, таким образом доставив символ. U+FFFE, который определяется Unicode как « несимвол », который никогда не должен появляться в тексте.
- Если 16-битные единицы представлены в порядке байтов с обратным порядком («UTF-16BE»), спецификация представляет собой ( шестнадцатеричную ) последовательность байтов.
FE FF - Если 16-битные устройства используют прямой порядок байтов («UTF-16LE»), спецификация представляет собой ( шестнадцатеричную ) последовательность байтов.
FF FE
Для зарегистрированных IANA кодировок UTF-16BE и UTF-16LE знак порядка байтов не должен использоваться, поскольку имена этих наборов символов уже определяют порядок байтов.
Если спецификации нет, можно угадать, соответствует ли текст UTF-16 и порядку его байтов, выполнив поиск символов ASCII (т. е. 0 байт, смежный с байтом в диапазоне 0x20-0x7E, а также 0x0A и 0x0D для CR и ЛФ). Большое число (т. е. намного большее, чем случайная вероятность) в том же порядке является очень хорошим показателем UTF-16, и то, находится ли 0 в четных или нечетных байтах, указывает на порядок байтов. Однако это может привести как к ложноположительным, так и к ложноотрицательным результатам.
В пункте D98 соответствия (раздел 3.10) стандарта Unicode говорится: «Схема кодирования UTF-16 может начинаться или не начинаться со спецификации. Однако при отсутствии спецификации и протокола более высокого уровня порядок байтов в схеме кодировки UTF-16 — обратный». Вопрос о том, действует ли протокол более высокого уровня или нет, остается открытым для интерпретации. Например, можно утверждать, что файлы, локальные для компьютера, для которых собственный порядок байтов имеет прямой порядок байтов, неявно закодированы как UTF-16LE. Таким образом, презумпция обратного порядка байтов широко игнорируется. Стандарт кодирования W3C / WHATWG , используемый в HTML5, определяет, что контент с пометкой «utf-16» или «utf-16le» должен интерпретироваться как с прямым порядком байтов «для работы с развернутым контентом». [13] Однако если присутствует отметка порядка байтов, то эта спецификация должна рассматриваться как «более авторитетная, чем что-либо еще». [14]
UTF-32 [ править ]
Хотя спецификацию можно использовать с UTF-32 , эта кодировка редко используется для передачи. те же правила, что и для UTF-16 В противном случае применяются .
Спецификация для UTF-32 с прямым порядком байтов — это тот же шаблон, что и спецификация UTF-16 с прямым порядком байтов, за которым следует NUL-символ UTF-16. Это необычный пример того, что спецификация представляет собой один и тот же шаблон в двух разных кодировках. Программистам, использующим спецификацию для определения кодировки, придется решить, какой вариант UTF-32 или UTF-16 с первым символом NUL более вероятен.
Метки порядка байтов при кодировании [ править ]
В этой таблице показано, как спецификация представлена как последовательность байтов в различных кодировках и как эти последовательности могут отображаться в текстовом редакторе, который интерпретирует каждый байт как устаревшую кодировку ( Windows-1252 и нотация каретки для элементов управления C0 ):
| Кодирование | Представление ( шестнадцатеричное ) | Представление ( десятичное ) | Байты интерпретируются как Windows-1252. |
|---|---|---|---|
| UTF-8 [а] | ЭФ ББ БФ | 239 187 191 | я" |
| UTF-16 ( БЭ ) | FE FF | 254 255 | þÿ |
| UTF-16 ( ЛЕ ) | ФФ ФЭ | 255 254 | ÿþ |
| UTF-32 (БЭ) | 00 00 ФЭ ФФ | 0 0 254 255 | ^@^@þÿ ( ^@ — это нулевой символ ) |
| UTF-32 (ЛЕ) | ФФ ФЭ 00 00 | 255 254 0 0 | ÿþ^@^@ ( ^@ — нулевой символ) |
| UTF-7 [а] | 2Б 2Ф 76 [б] [16] [17] | 43 47 118 | +/v |
| UTF-1 [а] | Ф7 64 4С | 247 100 76 | ÷dL |
| UTF-EBCDIC [а] | ДД 73 66 73 | 221 115 102 115 | YSFS |
| ЮКГУ [а] | 0E FE FF [с] | 14 254 255 | ^Нÿ ( ^N — символ «сдвига» ) |
| БУТЫЛКА-1 [а] | ФБ ЭЭ 28 | 251 238 40 | и ( |
| ГБ18030 [а] | 84 31 95 33 | 132 49 149 51 | „1•3 |
- ↑ Перейти обратно: Перейти обратно: а б с д и ж г Это не буквально знак «порядка байтов», поскольку единица кода в этих кодировках представляет собой один байт и, следовательно, не может иметь байты в «неправильном» порядке. Тем не менее, спецификация может использоваться для указания кодировки текста, следующего за ней. [6] [15]
- ^ Далее
38,39,2B, или2F(ASCII8,9,+или/), в зависимости от того, какой будет следующий символ. - ^ SCSU допускает другие кодировки U+FEFF, показанная форма является сигнатурой, рекомендованной в UTR #6. [18]
См. также [ править ]
- Метка слева направо
- Arab Presentation Forms-B , блок до какой кодовой точки
U+FEFFпринадлежит
Ссылки [ править ]
- ↑ Перейти обратно: Перейти обратно: а б «Часто задаваемые вопросы — UTF-8, UTF-16, UTF-32 и спецификация» . Юникод.орг . Проверено 28 января 2017 г.
- ^ «Стандарт Unicode® версии 9.0» (PDF) . Консорциум Юникод .
- ^ «Неразрывное пространство нулевой ширины (U+Feff)» .
- ^ «Стандарт Юникод 5.0, Глава 2: Общая структура» (PDF) . п. 36 . Проверено 29 марта 2009 г.
Таблица 2-4. Семь схем кодирования Unicode
- ^ «Стандарт Юникод 5.0, Глава 2: Общая структура» (PDF) . п. 36 . Проверено 30 ноября 2008 г.
Использование спецификации не является обязательным и не рекомендуется для UTF-8, но может возникнуть в контекстах, где данные UTF-8 преобразуются из других форм кодировки, использующих спецификацию, или где спецификация используется в качестве подписи UTF-8.
- ↑ Перейти обратно: Перейти обратно: а б «Часто задаваемые вопросы — UTF-8, UTF-16, UTF-32 и спецификация: может ли поток данных UTF-8 содержать символ спецификации (в форме UTF-8)? Если да, то могу ли я все еще предполагать оставшиеся байты UTF-8 находятся в порядке старшего байта?» . Юникод.орг . Проверено 4 января 2009 г.
- ^ «Re: pre-HTML5 и спецификация от Асмуса Фрейтага от 13 июля 2012 г. (Архив списка рассылки Unicode)» . Юникод.орг . Проверено 14 июля 2012 г.
- ^ «Идентификатор ошибки: JDK-6378911 Изменена обработка метки порядка байтов в декодере UTF-8» . Bugs.java.com . Проверено 14 октября 2021 г.
- ^ Жержо, Франсуа (ноябрь 2003 г.). UTF-8, формат преобразования ISO 10646 . IETF . дои : 10.17487/RFC3629 . РФК 3629 . Проверено 15 мая 2014 г.
- ^ Герхардс, Райнер (март 2009 г.). «МСГ» . Протокол системного журнала . IETF . сек. 6.4. дои : 10.17487/RFC5424 . РФК 5424 .
- ^ Альф П. Штайнбах (2011). «Юникод, часть 1: подходы к консольному вводу-выводу Windows» . Проверено 24 марта 2012 г.
Однако, поскольку исходный код C++ был закодирован как UTF-8 без спецификации (как это обычно бывает в Linux), компилятор Visual C++ ошибочно предположил, что исходный код был закодирован как Windows ANSI.
- ^ «Блокнот Windows 10 улучшает поддержку кодировки UTF-8» . Мигающий компьютер . Проверено 7 марта 2023 г.
- ^ «УТФ-16ЛЕ» . Стандарт кодирования . ЧТОРГ.
- ^ «Декодировать» . Стандарт кодирования . ЧТОРГ.
- ^ Жержо, Франсуа (8 ноября 2003 г.). «RFC 3629 — UTF-8, формат преобразования ISO 10646» . Ietf Datatracker . Проверено 28 января 2017 г.
- ^ Хонерманн, Том (2 января 2021 г.). «Уточнить рекомендации по использованию спецификации в качестве подписи кодировки UTF-8» (PDF) . Юникод .
- ^ «Документация SDL» .
- ^ Маркус Шерер. «UTS #6: Схема сжатия для Unicode» . Юникод.орг . Проверено 28 января 2017 г.
Внешние ссылки [ править ]
- Часто задаваемые вопросы по Unicode: UTF-8, UTF-16, UTF-32 и спецификация
- Стандарт Unicode, глава 2.6 Схемы кодирования
- Стандарт Unicode, глава 2.13 Специальные и несимволы , раздел Знак порядка байтов (BOM)
- Стандарт Unicode, глава 16.8 Специальные предложения , раздел Метка порядка байтов (BOM): U+FEFF
