使用字节顺序标记
Unicode 文本文件可以采用多种格式进行编码，包括 UTF-8、UTF-16 和 UTF-32。 每个格式都可以以字节顺序标记 (BOM) 作为前缀，表示编写文本时使用的字节顺序。 下表中列出了可用的字节顺序标记。 对于 UTF-8，字节顺序标记是可选的，因为字节可能只有一个顺序。 对于 UTF-16 和 UTF-32，需要字节顺序标记，因为这些格式对字节排序很敏感。
注意
字节顺序标记不是选择文本字节顺序的控件字符。
| 字节顺序标记 | 说明 |
|---|---|
| EF BB BF | UTF-8 |
| FF FE | UTF-16，little endian |
| FE FF | UTF-16，big endian |
| FF FE 00 00 | UTF-32，little endian |
| 00 00 FE FF | UTF-32，big-endian |
注意
旧版 Microsoft 产品要么使用 Windows-1252 或 UCS-2（固定使用 UTF-16），little endian 字节顺序为“Unicode”。 对于新应用程序，建议使用 UTF-8。
理想情况下，所有 Unicode 文本仅遵循一组字节排序规则。 然而，这是不可能的，因为微处理器在最低有效字节的位置上有所不同。 Intel 和 MIPS 处理器最低有效字节放在第一位，而 Motorola 处理器（以及所有字节反转 Unicode 文件）将其放在最后。 由于只有一组字节排序规则，一种微处理器的用户在每次读取或写入纯文本文件时都被迫交换字节顺序，即使该文件从未传输到基于不同微处理器的另一个操作系统。
指定字节顺序的首选位置在文件标头中，但文本文件没有标头。 因此，Unicode 定义了一个字符 (U+FEFF) 和一个非字符 (U+FFFE) 作为字节顺序标记。 它们是彼此的镜像字节图像。
由于序列 U+FEFF 在常规非 Unicode 文本文件的开头极为罕见，因此它可以作为隐式标记或签名，将文件标识为 Unicode 文件。 读取 Unicode 和非 Unicode 文本文件的应用程序应使用此序列的存在作为该文件最有可能是 Unicode 文件的指示符。 将此技术与使用 MS-DOS EOF 标记终止文本文件进行比较。
当应用程序在文本文件的开头找到 U+FEFF 时，它通常会将文件作为 Unicode 文件进行处理，尽管它可以执行进一步的启发式检查以进行验证。 这种检查可以像测试一样简单，以确定低序字节的变体是否远高于高序字节的变体。 例如，如果 ASCII 文本转换为 Unicode 文本，则每秒字节数为 0。 此外，检查换行符和回车符（U+000A 和 U+000D），以及偶数或奇数文件大小可以很好地指示文件的性质。
当应用程序在文本文件的开头找到 U+FFFE 时，它会将其解释为该文件是一个字节反转的 Unicode 文件。 应用程序可以交换字节的顺序，也可以提醒用户发生了错误。
由于在任何代码页中找不到 Unicode 字节顺序标记字符，因此如果数据转换为 ANSI，它将消失。 与其他 Unicode 字符不同，它在转换时不会被默认字符替换。 如果在文件的中间找到字节顺序标记，则不会将其解释为 Unicode 字符，并且对文本输出没有影响。
注意
Unicode 值 U+FFFF 在纯文本文件中是非法的，无法在应用程序之间传递。 它保留供应用程序专用使用。
相关主题