Метка порядка байтов ( BOM ) — это особый вариант использования специального кода символов Юникода , U+FEFF ZERO WIDTH NO-BREAK SPACE , появление которого в качестве магического числа в начале текстового потока может сигнализировать о нескольких вещах при чтении программы . текст: [1]
Использование спецификации не является обязательным. Его наличие мешает использованию 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, это использование устарело в пользу . [1]U+2060 WORD JOINER
Имя этого кода в Юникоде 1.0 также BYTE ORDER MARK[3]
Представление спецификации 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 незначительно (например, изменение '\' на «¥»). По этим соображениям спецификация не является необходимой для обнаружения кодировки UTF-8.
Компиляторы Microsoft [11] и интерпретаторы, а также многие программы для Microsoft Windows , такие как Блокнот (до Windows 10 Build 1903 [12] ), рассматривают спецификацию как необходимое магическое число , а не используют эвристику. Эти инструменты добавляют спецификацию при сохранении текста в формате UTF-8 и не могут интерпретировать UTF-8, если спецификация не присутствует или файл не содержит только ASCII. Windows PowerShell (до 5.1) добавит спецификацию при сохранении XML-документов UTF-8. Однако в PowerShell Core 6 в некоторые командлеты добавлен -Encodingпереключатель под названием utf8NoBOM, позволяющий сохранять документ без спецификации. Google Docs также добавляет спецификацию при преобразовании документа в обычный текстовый файл для загрузки.
В UTF-16 спецификация ( U+FEFF) может быть помещена в качестве первых байтов файла или потока символов, чтобы указать порядок байтов (порядок байтов) всех 16-битных кодовых единиц файла или потока. Если будет предпринята попытка прочитать этот поток с неправильным порядком байтов, байты будут заменены, таким образом доставив символ U+FFFE, который определяется Unicode как « несимвол », который никогда не должен появляться в тексте.
FE FFFF FEДля зарегистрированных IANA кодировок UTF-16BE и UTF-16LE знак порядка байтов не следует использовать, поскольку имена этих наборов символов уже определяют порядок байтов. Если он встречается где-либо в таком текстовом потоке, U+FEFF следует интерпретировать как «неразрывный пробел нулевой ширины».
Если спецификации нет, можно угадать, соответствует ли текст 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-16 как байтовую кодировку, могут отображать искаженную путаницу символов, но символы ASCII будут распознаваемы, поскольку младший байт представления UTF-16 совпадает с кодом ASCII и, следовательно, будет отображаться так же. . Старший байт 0 может отображаться как пустое место, пробел, точка или какой-либо другой неизменный символ.
Хотя спецификацию можно использовать с UTF-32 , эта кодировка редко используется для передачи. В противном случае применяются те же правила, что и для UTF-16 .
Спецификация для UTF-32 с прямым порядком байтов представляет собой тот же шаблон, что и спецификация UTF-16 с прямым порядком байтов, за которым следует NUL-символ UTF-16. Это необычный пример того, что спецификация представляет собой один и тот же шаблон в двух разных кодировках. Программистам, использующим спецификацию для определения кодировки, придется решить, какой вариант UTF-32 или UTF-16 с первым символом NUL более вероятен.
В этой таблице показано, как спецификация представлена как последовательность байтов в различных кодировках и как эти последовательности могут отображаться в текстовом редакторе, который интерпретирует каждый байт как устаревшую кодировку ( Windows-1252 и нотация каретки для элементов управления C0 ):
38, 39, 2B, или 2F(ASCII 8, 9, +или /), в зависимости от следующего символа.U+FEFFпринадлежит кодовая точкаТаблица 2-4.
Семь схем кодирования Unicode
Использование спецификации не является обязательным и не рекомендуется для UTF-8, но может возникнуть в контекстах, где данные UTF-8 преобразуются из других форм кодировки, использующих спецификацию, или где спецификация используется в качестве подписи UTF-8.
Однако, поскольку исходный код C++ был закодирован как UTF-8 без спецификации (как это обычно бывает в Linux), компилятор Visual C++ ошибочно предположил, что исходный код был закодирован как Windows ANSI.