UTF-8与BOM更好地识别。我得出这个结论很不容易。我正在从事一个项目，其中一个结果是一个CSV文件，包括Unicode字符。

如果CSV文件保存时没有BOM, Excel会认为它是ANSI并显示胡言乱语。一旦你在前面添加了“EF BB BF”(例如，通过使用UTF-8记事本重新保存它;或notepad++与UTF-8与BOM)， Excel打开它很好。

RFC 3629: "UTF-8，一种ISO 10646的转换格式"，2003年11月建议将BOM字符前置到Unicode文本文件中 在https://www.rfc-editor.org/rfc/rfc3629(这最后的信息可以在:http://www.herongyang.com/Unicode/Notepad-Byte-Order-Mark-BOM-FEFF-EFBBBF.html)

UTF-8 BOM是文本流开头的字节序列(0xEF, 0xBB, 0xBF)，它允许读者更可靠地猜测文件是否以UTF-8编码。

通常，BOM用于表示编码的字节顺序，但由于字节顺序与UTF-8无关，因此BOM是不必要的。

根据Unicode标准，不建议使用UTF-8文件的BOM:

2.6编码方案 ．.． 对于UTF-8，既不要求也不建议使用BOM，但在将UTF-8数据从使用BOM的其他编码形式转换或将BOM用作UTF-8签名的上下文中可能会遇到这种情况。有关更多信息，请参阅第16.8节特殊项中的“字节顺序标记”小节。

如上所述，带有BOM的UTF-8可能会导致非BOM感知(或兼容)软件出现问题。我曾经用基于mozilla的KompoZer编辑UTF-8 + BOM编码的HTML文件，因为客户需要WYSIWYG程序。

保存时，布局总是会被破坏。我花了一些时间来解决这个问题。这些文件在Firefox中运行良好，但在Internet Explorer中显示了一个CSS怪癖，再次破坏了布局。在摆弄了几个小时链接的CSS文件后，我发现Internet Explorer不喜欢BOMfed HTML文件。我再也不会见你了。

还有，我刚在维基百科上找到了这个:

The shebang characters are represented by the same two bytes in extended ASCII encodings, including UTF-8, which is commonly used for scripts and other text files on current Unix-like systems. However, UTF-8 files may begin with the optional byte order mark (BOM); if the "exec" function specifically detects the bytes 0x23 0x21, then the presence of the BOM (0xEF 0xBB 0xBF) before the shebang will prevent the script interpreter from being executed. Some authorities recommend against using the byte order mark in POSIX (Unix-like) scripts,[15] for this reason and for wider interoperability and philosophical concerns

BOM倾向于在某个地方爆炸(没有双关语)。当它突然出现时(例如，无法被浏览器、编辑器等识别)，它会以奇怪的字符出现在文档的开头(例如，HTML文件、JSON响应、RSS等)，并导致类似于最近奥巴马在Twitter上谈话时经历的编码问题那样的尴尬。

当它出现在难以调试的地方或当测试被忽略时，这是非常令人讨厌的。所以除非必须使用，否则最好避免使用。

这个问题已经有了无数个答案，其中许多答案都很好，但我想尝试并澄清何时应该使用BOM，何时不应该使用BOM。

如前所述，任何使用UTF BOM(字节顺序标记)来确定字符串是否为UTF-8的方法都是有根据的猜测。如果有适当的元数据可用(如charset="utf-8")，那么您已经知道应该使用什么，但除此之外，您还需要进行测试并做出一些假设。这涉及到检查字符串来自的文件是否以十六进制字节码EF BB BF开头。

If a byte code corresponding to the UTF-8 BOM is found, the probability is high enough to assume it's UTF-8 and you can go from there. When forced to make this guess, however, additional error checking while reading would still be a good idea in case something comes up garbled. You should only assume a BOM is not UTF-8 (i.e. latin-1 or ANSI) if the input definitely shouldn't be UTF-8 based on its source. If there is no BOM, however, you can simply determine whether it's supposed to be UTF-8 by validating against the encoding.

为什么不推荐使用BOM ?

不支持unicode或兼容性较差的软件可能会假定它是latin-1或ANSI，并且不会从字符串中剥离BOM，这显然会导致问题。 这并不是真正需要的(只要检查内容是否兼容，并且在找不到兼容编码时总是使用UTF-8作为备用)

什么时候应该使用BOM编码?

如果您无法以任何其他方式(通过字符集标记或文件系统元)记录元数据，并且像使用BOM一样使用程序，则应该使用BOM进行编码。在Windows上尤其如此，没有BOM的任何东西通常都被认为使用了遗留代码页。BOM告诉Office等程序，是的，这个文件中的文本是Unicode;这是使用的编码。

归根结底，我唯一真正有问题的文件是CSV。根据程序的不同，它必须或必须没有BOM。例如，如果你在Windows上使用Excel 2007+，如果你想要顺利地打开它，而不必求助于导入数据，它必须用BOM编码。

引用于维基百科页面底部BOM: http://en.wikipedia.org/wiki/Byte-order_mark#cite_note-2

对于UTF-8，使用BOM既不要求也不推荐，但在从使用BOM的其他编码形式转换UTF-8数据或将BOM用作UTF-8签名的上下文中可能会遇到这种情况。