UTF-16LE 与 UTF32-LE 的 Unicode BOM

Question

用于 UTF16-LE 和 UTF-32LE 的字节顺序标记之间似乎存在歧义。特别是，考虑一个包含以下 8 个字节的文件：

FF FE 00 00 00 00 00 00

我如何判断该文件是否包含：

1. UTF16-LE BOM (FF FE) 后跟 3 个空字符；或者
2. UTF32-LE BOM (FF FE 00 00) 后跟一个空字符？

Unicode BOM 描述如下： http://unicode.org/faq/utf_bom.html#bom4 但没有讨论这种歧义。我错过了什么吗？

Answer 1

顾名思义，BOM 只告诉您 字节顺序, ，而不是编码。您必须首先知道编码是什么，然后可以使用 BOM 来确定多字节序列中最低有效字节还是最高有效字节在前。

BOM 的一个幸运的副作用是，如果您不知道编码，有时也可以使用它来猜测编码，但这不是它的设计目的，并且它不能替代发送正确的编码信息。

Answer 2

这是明确的。 FF FE 适用于 UTF-16LE，并且 FF FE 00 00 表示 UTF-32LE。没有理由认为 FF FE 00 00 可能是 UTF-16LE，因为 UTF 是为文本设计的，用户不应在文本中使用 NUL 字符。毕竟，您上次打开十六进制编辑器并将几个字节的 00 插入文本文档是什么时候？^_^

Answer 3

我也经历过和爱德华一样的问题。我同意达斯汀的观点，通常不会在文本文件中使用空字符。

但是我创建了一个包含所有 unicode 字符的文件。我首先使用utf-32le编码，然后使用utf-32be编码，utf-16le和utf-16be编码以及utf-8编码。

当尝试将文件重新编码为 utf-8 时，我想将结果与现有的 utf-8 文件进行比较。因为我的文件中 BOM 之后的第一个字符是空字符，所以我无法成功检测到带有 utf-16le BOM 的文件，它显示为 utf-32le BOM，因为字节的显示与 Edward 所描述的完全一样。BOM FFFE 后的第一个字符是 0000，但 BOM 检测发现了 BOM FFFE0000，因此检测到了 utf-32le 而不是 utf-16le，因此我的第一个 0000 字符被盗并作为 BOM 的一部分。

因此，永远不要使用空字符作为使用 utf-16 小尾数法编码的文件的第一个字符，因为它会使 utf-16le 和 utf-32le BOM 不明确。

为了解决我的问题，我将交换第一个和第二个字符。:-)