用于 UTF16-LE 和 UTF-32LE 的字节顺序标记之间似乎存在歧义。特别是，考虑一个包含以下 8 个字节的文件：
FF FE 00 00 00 00 00 00
如何判断此文件是否包含：
此处描述了 Unicode BOM：http: //unicode.org/faq/utf_bom.html#bom4但没有讨论这种歧义。我错过了什么吗？
顾名思义，BOM 只告诉您字节顺序，而不是编码。您必须首先知道编码是什么，然后您可以使用 BOM 来确定最低或最高有效字节是多字节序列的第一个。
BOM 的一个幸运副作用是，如果您不知道编码，有时也可以使用它来猜测编码，但这不是它的设计目的，它不能替代发送正确的编码信息。
这是明确的。 FF FE用于 UTF-16LE，FF FE 00 00表示 UTF-32LE。没有理由认为这FF FE 00 00可能是 UTF-16LE，因为 UTF 是为文本设计的，用户不应该在他们的文本中使用 NUL 字符。毕竟，您最后一次打开十六进制编辑器并将几个字节的 00 插入文本文档是什么时候？^_^
我遇到过和爱德华一样的问题。我同意达斯汀的观点，通常不会在文本文件中使用空字符。
但是我创建了一个包含所有 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 little endian 编码的文件的第一个字符，因为它会使 utf-16le 和 utf-32le BOM 不明确。
为了解决我的问题，我将交换第一个和第二个字符。:-)