Unicode字节顺序标记(BOM)常见问题解答提供了一个简明的答案:

Q: How I should deal with BOMs? A: Here are some guidelines to follow: A particular protocol (e.g. Microsoft conventions for .txt files) may require use of the BOM on certain Unicode data streams, such as files. When you need to conform to such a protocol, use a BOM. Some protocols allow optional BOMs in the case of untagged text. In those cases, Where a text data stream is known to be plain text, but of unknown encoding, BOM can be used as a signature. If there is no BOM, the encoding could be anything. Where a text data stream is known to be plain Unicode text (but not which endian), then BOM can be used as a signature. If there is no BOM, the text should be interpreted as big-endian. Some byte oriented protocols expect ASCII characters at the beginning of a file. If UTF-8 is used with these protocols, use of the BOM as encoding form signature should be avoided. Where the precise type of the data stream is known (e.g. Unicode big-endian or Unicode little-endian), the BOM should not be used. In particular, whenever a data stream is declared to be UTF-16BE, UTF-16LE, UTF-32BE or UTF-32LE a BOM must not be used.

应该注意的是，对于某些文件，即使在Windows上也不能有BOM。例如SQL*plus或VBScript文件。如果这样的文件包含BOM，则在尝试执行它们时会出现错误。

问:UTF-8和没有BOM的UTF-8有什么不同?哪个更好?

以下是一些摘自维基百科关于字节顺序标记(BOM)的文章，我相信这些文章为这个问题提供了一个可靠的答案。

关于BOM和UTF-8的含义:

Unicode标准允许使用UTF-8格式的BOM，但不要求 或推荐使用。字节顺序在UTF-8中没有意义，因此 在UTF-8中唯一使用的是在文本流开始时发出信号 以UTF-8编码。

不使用BOM的参数:

不使用BOM的主要动机是向后兼容性 使用不支持unicode的软件…另一个不这样做的原因 使用BOM是为了鼓励UTF-8作为“默认”编码。

使用BOM的参数:

The argument for using a BOM is that without it, heuristic analysis is required to determine what character encoding a file is using. Historically such analysis, to distinguish various 8-bit encodings, is complicated, error-prone, and sometimes slow. A number of libraries are available to ease the task, such as Mozilla Universal Charset Detector and International Components for Unicode. Programmers mistakenly assume that detection of UTF-8 is equally difficult (it is not because of the vast majority of byte sequences are invalid UTF-8, while the encodings these libraries are trying to distinguish allow all possible byte sequences). Therefore not all Unicode-aware programs perform such an analysis and instead rely on the BOM. In particular, Microsoft compilers and interpreters, and many pieces of software on Microsoft Windows such as Notepad will not correctly read UTF-8 text unless it has only ASCII characters or it starts with the BOM, and will add a BOM to the start when saving text as UTF-8. Google Docs will add a BOM when a Microsoft Word document is downloaded as a plain text file.

有或没有BOM，哪个更好:

IETF建议，如果一个协议(a)总是使用UTF-8， 或者(b)有其他方式表明使用的是什么编码， 那么它“应该禁止使用U+FEFF作为签名。”

我的结论是:

仅在与软件应用程序的兼容性是绝对必要的情况下使用BOM。

还要注意，虽然引用的维基百科文章指出，许多Microsoft应用程序依赖BOM来正确检测UTF-8，但并非所有Microsoft应用程序都是如此。例如，正如@barlop所指出的，当使用带有UTF-8†的Windows命令提示符时，此类类型和更多的命令不期望出现BOM。如果存在BOM，它可能会像其他应用程序一样出现问题。

†chcp命令通过代码页65001提供对UTF-8(没有BOM)的支持。

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

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

只有当文件实际包含一些非ascii字符时，UTF-8和BOM才有用。如果包含了它，而没有任何ASCII，那么它可能会破坏旧的应用程序，否则将文件解释为纯ASCII。当遇到非ASCII字符时，这些应用程序肯定会失败，因此在我看来，只有当文件可以并且不应该再被解释为纯ASCII时，才应该添加BOM。

我想说清楚的是，我宁愿没有BOM。如果一些旧的垃圾没有它就坏了，那么就添加它，替换遗留应用程序是不可行的。

不要制作UTF-8的BOM之外的任何东西。

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节特殊项中的“字节顺序标记”小节。