Из Википедии, бесплатной энциклопедии
  (Перенаправлено из BYTE ORDER MARK )
Перейти к навигации Перейти к поиску

Метка порядка байтов ( BOM ) является частным использование специального Unicode символа, U + FEFF BYTE ORDER MARK , появление которого в качестве числа магического в начале текстового потока может сигнализировать несколько вещей к программе чтения текста: [1 ]

  • Порядок байтов, или порядок байтов , текстового потока в случаях 16-битного и 32-битного кодирования;
  • Тот факт, что кодировка текстового потока - Unicode, с высокой степенью достоверности;
  • Какая кодировка символов Unicode используется.

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

Юникод может быть закодирован в единицах 8-битных, 16-битных или 32-битных целых чисел. Для 16- и 32-битных представлений компьютер, получающий текст из произвольных источников, должен знать, в каком порядке байтов закодированы целые числа. Спецификация кодируется по той же схеме, что и остальная часть документа, и становится несимвольным Unicode кодовая точка, если его байты поменяны местами. Следовательно, процесс, обращающийся к тексту, может исследовать эти первые несколько байтов для определения порядка байтов, не требуя какого-либо контракта или метаданных вне самого текстового потока. Как правило, принимающий компьютер меняет байты в соответствии с порядком байтов, если это необходимо, и ему больше не требуется спецификация для обработки.

Последовательность байтов спецификации различается в зависимости от кодировки Unicode (включая те, которые выходят за рамки стандарта Unicode, такие как UTF-7 , см. Таблицу ниже ), и ни одна из последовательностей, вероятно, не появится в начале текстовых потоков, хранящихся в других кодировках. Следовательно, размещение закодированной спецификации в начале текстового потока может указывать на то, что текст является Unicode, и определять используемую схему кодирования. Такое использование символа спецификации называется «подписью Unicode». [2]

Использование [ править ]

Если символ спецификации появляется в середине потока данных, Unicode говорит, что его следует интерпретировать как « неразрывный пробел нулевой ширины » (запрещает разрыв строки между глифами слов). В Unicode 3.2 это использование не рекомендуется в пользу символа « Word Joiner », U + 2060. [1] Это позволяет использовать U + FEFF только в качестве спецификации.

UTF-8 [ править ]

UTF-8 , представление спецификации является ( шестнадцатеричное ) последовательность байтов 0xEF,0xBB,0xBF.

Стандарт Unicode разрешает спецификацию в UTF-8 , [3], но не требует и не рекомендует ее использование. [4] Порядок байтов не имеет значения в UTF-8, [5] поэтому его единственное использование в UTF-8 - это сигнализировать в начале, что текстовый поток закодирован в UTF-8 или что он был преобразован в UTF-8. из потока, содержащего необязательную спецификацию. Стандарт также не рекомендует удалять спецификацию, когда она есть, чтобы при циклическом переключении между кодировками информация не терялась, и чтобы код, который на нее полагается, продолжал работать. [6] [7] IETF рекомендует, чтобы, если протокол либо (а) всегда использует UTF-8, либо (б) имеет другой способ указать, какая кодировка используется, то «СЛЕДУЕТ запретить использование U + FEFF как подпись."[8]

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

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

Компиляторы и интерпретаторы Microsoft [9] , а также многие части программного обеспечения в Microsoft Windows, такие как Блокнот, рассматривают BOM как необходимое магическое число, а не используют эвристику. Эти инструменты добавляют спецификацию при сохранении текста как UTF-8 и не могут интерпретировать UTF-8, если только спецификация не присутствует или файл не содержит только ASCII. Windows PowerShell (до 5.1) добавит спецификацию при сохранении XML-документов UTF-8. Однако PowerShell Core 6 добавил переключатель -Encoding в некоторые командлеты, называемые utf8NoBOM, чтобы документ можно было сохранить без спецификации. Google Docs также добавляет спецификацию при преобразовании документа в простой текстовый файл для загрузки.

UTF-16 [ править ]

В UTF-16 BOM ( U+FEFF) может быть помещен в качестве первого символа файла или потока символов, чтобы указать порядок байтов (порядок байтов) всех 16-битных единиц кода файла или потока. Если будет сделана попытка прочитать этот поток с неправильным порядком байтов, байты будут переставлены местами, таким образом доставляется символ U+FFFE, который определяется Unicode как «несимвол», который никогда не должен появляться в тексте.

  • Если 16-битные блоки представлены в порядке обратного байта, спецификация будет отображаться в последовательности байтов как0xFE 0xFF
  • Если в 16-битных единицах используется прямой порядок байтов , спецификация будет отображаться в последовательности байтов как0xFF 0xFE

Ни одна из этих последовательностей не является допустимой UTF-8, поэтому их наличие указывает на то, что файл не закодирован в UTF-8.

Для зарегистрированных в IANA кодировок UTF-16BE и UTF-16LE отметку порядка байтов использовать не следует, поскольку имена этих наборов символов уже определяют порядок байтов. Если встречается где-нибудь в таком текстовом потоке, U + FEFF следует интерпретировать как «неразрывный пробел нулевой ширины».

Если нет спецификации, можно угадать, является ли текст UTF-16 и его порядок байтов, путем поиска символов ASCII (т. Е. Байта 0, смежного с байтом в диапазоне 0x20-0x7E, также 0x0A и 0x0D для CR и LF). Большое число (т.е. намного большее, чем случайный шанс) в одном и том же порядке является очень хорошим индикатором UTF-16, а то, находится ли 0 в четных или нечетных байтах, указывает порядок байтов. Однако это может привести как к ложным срабатываниям, так и к ложноотрицательным результатам.

Пункт D98 соответствия (раздел 3.10) стандарта Unicode гласит: «Схема кодирования UTF-16 может начинаться или не начинаться с спецификации. Однако, когда нет спецификации и в отсутствие протокола более высокого уровня, порядок байтов в схеме кодирования UTF-16 - обратный порядок байтов ". Вопрос о том, действует ли протокол более высокого уровня или нет, открыт для интерпретации. Файлы, локальные для компьютера, для которых собственный порядок байтов является прямым порядком байтов, например, можно утверждать, что они неявно закодированы как UTF-16LE. Поэтому презумпция прямого порядка байтов широко игнорируется. Стандарт кодирования W3C / WHATWG, используемый в HTML5, определяет, что контент с меткой «utf-16» или «utf-16le» должен интерпретироваться как little-endian «для работы с развернутым контентом». [10]Однако, если присутствует метка порядка байтов, то эта спецификация должна рассматриваться как «более авторитетная, чем что-либо еще». [11]

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

UTF-32 [ править ]

Хотя спецификацию можно использовать с UTF-32 , эта кодировка редко используется для передачи. В остальном применимы те же правила, что и для UTF-16 .

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

Метки порядка байтов по кодировке [ править ]

В этой таблице показано, как символ спецификации представлен как последовательность байтов в различных кодировках и как эти последовательности могут отображаться в текстовом редакторе, который интерпретирует каждый байт как устаревшую кодировку ( CP1252 и обозначение курсора для элементов управления C0 ):

  1. ^ a b c d e f g Это буквально не метка «порядка байтов», поскольку единица кода в этих кодировках составляет один байт и, следовательно, не может иметь байты в «неправильном» порядке. Тем не менее, спецификацию можно использовать для обозначения кодировки текста, который следует за ней. [5] [12]
  2. ^ Следуют38,39,3Aили3B(ASCII8,9,:или;),зависимости отчто следующий символ.
  3. ^ SCSU допускает другие кодировки U + FEFF, показанная форма является подписью, рекомендованной в UTR # 6. [13]

См. Также [ править ]

  • Знак слева направо

Ссылки [ править ]

  1. ^ a b «FAQ - UTF-8, UTF-16, UTF-32 & BOM» . Unicode.org . Проверено 28 января 2017 .
  2. ^ "Стандартная версия Unicode® 9.0" (PDF) . Консорциум Unicode .
  3. ^ «Стандарт Unicode 5.0, Глава 2: Общая структура» (PDF) . п. 36 . Проверено 29 марта 2009 . Таблица 2-4. Семь схем кодирования Unicode
  4. ^ «Стандарт Unicode 5.0, Глава 2: Общая структура» (PDF) . п. 36 . Проверено 30 ноября 2008 . Использование спецификации не требуется и не рекомендуется для UTF-8, но может встречаться в контекстах, где данные UTF-8 преобразуются из других форм кодирования, которые используют спецификацию, или где спецификация используется в качестве подписи UTF-8.
  5. ^ a b "Часто задаваемые вопросы - UTF-8, UTF-16, UTF-32 и спецификация: может ли поток данных UTF-8 содержать символ спецификации (в форме UTF-8)? Если да, то могу ли я предположить, что оставшийся UTF -8 байтов в порядке прямого байта? " . Unicode.org . Проверено 4 января 2009 .
  6. ^ «Re: pre-HTML5 и спецификация от Асмуса Фрейтага от 13 июля 2012 г. (Архив почтового списка Unicode)» . Unicode.org . Проверено 14 июля 2012 .
  7. ^ "Идентификатор ошибки: JDK-6378911 декодер UTF-8 обрабатывает метку порядка байтов изменена" . Bugs.sun.com . Проверено 28 января 2017 .
  8. ^ Yergeau, Francois (ноябрь 2003). UTF-8, формат преобразования ISO 10646 . IETF . DOI : 10,17487 / RFC3629 . RFC 3629 . Проверено 15 мая 2014 года .
  9. ^ Альф П. Штайнбах (2011). «Unicode, часть 1: подходы к вводу-выводу консоли Windows» . Проверено 24 марта 2012 года . Однако, поскольку исходный код C ++ был закодирован как UTF-8 без спецификации (как обычно в Linux), компилятор Visual C ++ ошибочно предположил, что исходный код был закодирован как Windows ANSI.
  10. ^ "UTF-16LE" . Стандарт кодирования . WHATWG.
  11. ^ "Декодировать" . Стандарт кодирования . WHATWG.
  12. ^ «RFC 3629 - UTF-8, формат преобразования ISO 10646» . Tools.ietf.org . 2003-11-08 . Проверено 28 января 2017 .
  13. ^ Маркус Шерер. «UTS # 6: Схема сжатия для Unicode» . Unicode.org . Проверено 28 января 2017 .

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

  • Вопросы и ответы по Unicode: UTF-8, UTF-16, UTF-32 и спецификация
  • Стандарт Unicode, глава 2.6 Схемы кодирования
  • Стандарт Unicode, глава 2.13 Специальные символы и несимволы , раздел Знак порядка байтов (BOM)
  • Стандарт Unicode, глава 16.8 Специальные возможности , раздел Знак порядка байтов (BOM): U + FEFF