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