Использование меток порядка байтов
Текстовые файлы Юникода могут быть закодированы в нескольких форматах, включая UTF-8, UTF-16 и UTF-32. Каждый из этих форматов можно префиксировать с помощью метки порядка байтов (BOM), которая указывает порядок байтов, используемый при написании текста. Доступные метки порядка байтов перечислены в следующей таблице. Для UTF-8 знак порядка байтов необязателен, так как байты могут находиться только в одном порядке. Для UTF-16 и UTF-32 требуется метка порядка байтов, так как эти форматы чувствительны к упорядочению байтов.
Примечание.
Знак порядка байтов не является символом элемента управления, который выбирает порядок байтов текста.
| Метка порядка байтов | Description |
|---|---|
| EF BB BF | UTF-8 |
| FF FE | UTF-16, маленький эндиан |
| FE FF | UTF-16, большой эндиан |
| FF FE 00 00 | UTF-32, маленький эндиан |
| 00 00 FE FF | UTF-32, big-endian |
Примечание.
Устаревшие продукты Майкрософт либо используют Windows-1252 или UCS-2 (фиксированное с UTF-16), маленький байтовый порядок байтов для Юникода. Для новых приложений рекомендуется использовать UTF-8.
В идеале все тексты Юникода соответствуют только одному набору правил упорядочения байтов. Однако это невозможно, так как микропроцессоры отличаются в размещении наименее значимых байтов. Процессоры Intel и MIPS сначала позиционируют наименьшую значительную байтовую позицию, в то время как процессоры Motorola (и все файлы Юникода с обратным байтами) позиционируют его последним. При использовании только одного набора правил порядка байтов пользователи одного типа микропроцессора вынуждены переключать порядок байтов каждый раз, когда обычный текстовый файл считывается или записывается в другой операционной системе, даже если файл никогда не передается в другую операционную систему на основе другого микропроцессора.
Предпочтительное место для указания порядка байтов находится в заголовке файла, но текстовые файлы не имеют заголовков. Поэтому Юникод определил символ (U+FEFF) и нехарактер (U+FFFE) в качестве меток порядка байтов. Они являются зеркальными изображениями байтов друг друга.
Так как последовательность U+FEFF является чрезвычайно редкой в начале обычного текстового файла, отличного от Юникода, она может служить неявным маркером или подписью для идентификации файла в виде файла Юникода. Приложения, которые считывают как файлы Юникода, так и текстовые файлы, отличные от Юникода, должны использовать наличие этой последовательности в качестве индикатора того, что файл, скорее всего, является файлом Юникода. Сравните этот метод с использованием маркера EOF MS-DOS для завершения текстовых файлов.
Когда приложение находит U+FEFF в начале текстового файла, он обычно обрабатывает файл в виде файла Юникода, хотя он может выполнять дальнейшие эвристические проверки для проверки. Такая проверка может быть столь же простой, как тестирование, чтобы узнать, является ли вариация в байтах низкого порядка гораздо выше, чем вариант в байтах высокого порядка. Например, если текст ASCII преобразуется в текст Юникода, каждый второй байт равен 0. Кроме того, проверка символов обратной линии и каретки (U+000A и U+000D) и даже или нечетного размера файла может обеспечить сильный индикатор характера файла.
Когда приложение находит U+FFFE в начале текстового файла, оно интерпретирует его, чтобы означать, что файл является файлом с обратным байтом Юникода. Приложение может переключить порядок байтов или предупредить пользователя об ошибке.
Так как символ порядка байтов Юникода не найден на кодовой странице, он исчезает, если данные преобразуются в ANSI. В отличие от других символов Юникода, он не заменяется символом по умолчанию при преобразовании. Если знак порядка байтов найден в середине файла, он не интерпретируется как символ Юникода и не влияет на выходные данные текста.
Примечание.
Значение Юникода U+FFFF является незаконным в файлах обычного текста и не может быть передано между приложениями. Он зарезервирован для частного использования приложения.
См. также