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