没有BOM的UTF-8没有BOM，这并不意味着它比有BOM的UTF-8更好，除非文件的消费者需要知道(或者从知道中受益)文件是否是UTF-8编码的。

BOM通常用于确定编码的字节序，这对于大多数用例来说是不需要的。

此外，对于那些不了解或不关心BOM的消费者来说，BOM可能是不必要的噪音/痛苦，并可能导致用户困惑。

从http://en.wikipedia.org/wiki/Byte-order_mark:

字节顺序标记(BOM)是一个Unicode 符号的符号 文本文件的字节顺序 或流。其编码点为U+FEFF。 BOM使用是可选的，如果使用， 应该出现在文本的开头吗 流。除了它的特殊用途 字节顺序指示器，即BOM 字符也可以指示哪一个 几种Unicode表示 文本是用。

总是在文件中使用BOM将确保它总是在支持UTF-8和BOM的编辑器中正确打开。

我对缺少BOM的真正问题如下。假设我们有一个文件，它包含:

abc

如果没有BOM，在大多数编辑器中它会作为ANSI打开。所以这个文件的另一个用户打开它，并添加一些本机字符，例如:

abg-αβγ

哎呀……现在文件仍然在ANSI中，你猜怎么着，“αβγ”不占用6个字节，而是3个字节。这不是UTF-8，这会在开发链的后面引起其他问题。

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: http://en.wikipedia.org/wiki/Byte-order_mark#cite_note-2

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

其他优秀的回答已经回答过了

UTF-8和BOM-ed的UTF-8之间没有官方的区别 一个BOM-ed的UTF-8字符串将以以下三个字节开始。Ef bb bf 如果存在这些字节，在从文件/流中提取字符串时必须忽略。

但是，作为附加信息，UTF-8的BOM可以很好地“嗅出”字符串是否以UTF-8编码……或者它可以是任何其他编码的合法字符串…

例如，数据[EF BB BF 41 42 43]可以是:

合法的ISO-8859-1字符串“ABC” 合法的UTF-8字符串“ABC”

因此，尽管通过查看第一个字节来识别文件内容的编码很酷，但您不应该依赖于此，如上面的示例所示

编码应该是已知的，而不是推测的。

UTF-8和没有BOM的UTF-8有什么不同?

简单回答:在UTF-8中，BOM编码为文件开头的字节EF BB BF。

长一点的回答:

最初，预计Unicode将以UTF-16/UCS-2编码。BOM是为这种编码形式设计的。当您有2字节的代码单元时，有必要指出这两个字节的顺序，这样做的一个常见惯例是在数据的开头包含字符U+FEFF作为“字节顺序标记”。字符U+FFFE是永久未分配的，因此可以使用它来检测错误的字节顺序。

不管平台字节顺序如何，UTF-8都具有相同的字节顺序，因此不需要字节顺序标记。然而，它可能出现在从UTF-16转换为UTF-8的数据中(作为字节序列EF BB FF)，或者作为表示数据为UTF-8的“签名”。

哪个更好?

没有。正如Martin Cote回答的那样，Unicode标准并不推荐这样做。它会导致非bom识别软件出现问题。

检测文件是否为UTF-8的更好方法是执行有效性检查。UTF-8对哪些字节序列是有效的有严格的规则，因此假阳性的概率可以忽略不计。如果一个字节序列看起来像UTF-8，那么它可能就是。

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

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

我从另一个角度看这个问题。我认为UTF-8与BOM更好，因为它提供了更多关于文件的信息。我只在遇到问题时才使用没有BOM的UTF-8。

我在我的页面上使用多种语言(甚至西里尔字母)很长一段时间，当文件保存时没有BOM，我重新打开它们用编辑器编辑(cherouvim也指出)，一些字符被损坏了。

请注意，当您尝试以UTF-8编码保存新创建的文件时，Windows的经典记事本会自动保存带有BOM的文件。

我个人保存带有BOM的服务器端脚本文件(.asp， .ini， .aspx)和没有BOM的.html文件。

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编码的信息时，可能不会遇到问题。例如，将HTML文档声明为UTF-8，您将在浏览器中显示文档主体中包含的所有内容。

但在Windows或Linux上，当我们有文本、CSV和XML文件时，情况就不同了。

例如，Windows或Linux中的文本文件，这是最简单的事情之一，它(通常)不是UTF-8。

保存为XML并声明为UTF-8:

<?xml version="1.0" encoding="UTF-8"?>

即使声明为UTF-8，它也不能正确显示(不能读取)。

我有一串包含法语字母的数据，需要将其保存为XML以进行联合。无需从一开始就创建UTF-8文件(更改IDE中的选项和“创建新文件”)或在文件开头添加BOM

$file="\xEF\xBB\xBF".$string;

我无法将法语字母保存在XML文件中。

将BOM放在UTF-8编码的文件中至少有三个问题。

不包含文本的文件不再为空，因为它们始终包含BOM。 在UTF-8的ASCII子集中保存文本的文件本身不再是ASCII，因为BOM不是ASCII，这使得一些现有工具无法使用，用户可能不可能替换这些遗留工具。 不可能将几个文件连接在一起，因为现在每个文件开头都有一个BOM。

而且，正如其他人所提到的，使用BOM来检测某些东西是否是UTF-8是既不够也没有必要的:

这是不够的，因为任意字节序列可能恰好以构成BOM的确切序列开始。 这是不必要的，因为你可以像读取UTF-8一样读取字节;如果成功，根据定义，它是有效的UTF-8。

如果你在HTML文件中使用UTF-8，如果你在同一页面上使用塞尔维亚西里尔语、塞尔维亚拉丁语、德语、匈牙利语或一些外来语言，那么使用UTF和BOM更好。

这是我(从事计算机和IT行业30年)的观点。

如上所述，带有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

一个实际的区别是，如果你为Mac OS X编写一个shell脚本，并将其保存为普通的UTF-8，你将得到响应:

#!/bin/bash: No such file or directory

在shebang行指定您希望使用哪个shell的响应中:

#!/bin/bash

如果你保存为UTF-8，没有BOM(说在BBEdit)，一切都会很好。

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

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

不要制作UTF-8的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)的支持。

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

这个问题已经有了无数个答案，其中许多答案都很好，但我想尝试并澄清何时应该使用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使用示例，但许多人并不了解它。

BOM中断脚本

Shell脚本，Perl脚本，Python脚本，Ruby脚本，Node.js脚本或任何其他需要由解释器运行的可执行文件-都以shebang行开始，看起来像这样:

#!/bin/sh
#!/usr/bin/python
#!/usr/local/bin/perl
#!/usr/bin/env node

它告诉系统在调用这样的脚本时需要运行哪个解释器。如果脚本是用UTF-8编码的，人们可能会在开头包含一个BOM。但实际上“#!”字符不仅仅是字符。它们实际上是一个神奇的数字，恰好由两个ASCII字符组成。如果您在这些字符之前放了一些东西(如BOM)，那么文件看起来就像有一个不同的魔法数字，这可能会导致问题。

参见维基百科，文章:Shebang，章节:魔法数字:

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 and 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,[14] for this reason and for wider interoperability and philosophical concerns. Additionally, a byte order mark is not necessary in UTF-8, as that encoding does not have endianness issues; it serves only to identify the encoding as UTF-8. [emphasis added]

BOM在JSON中是非法的

参见RFC 7159，章节8.1:

实现绝对不能在JSON文本的开头添加字节顺序标记。

BOM在JSON中是冗余的

它不仅在JSON中是非法的，而且也不需要确定字符编码，因为有更可靠的方法可以明确地确定任何JSON流中使用的字符编码和字节顺序(详细信息请参阅这个答案)。

BOM 会中断 JSON 解析器

它不仅在JSON中是非法的，而且不需要，它实际上破坏了所有使用RFC 4627中提出的方法来确定编码的软件:

确定JSON的编码和字节顺序，检查前四个字节为NUL字节:

00 00 00 xx - UTF-32BE
00 xx 00 xx - UTF-16BE
xx 00 00 00 - UTF-32LE
xx 00 xx 00 - UTF-16LE
xx xx xx xx - UTF-8

现在，如果文件以BOM开头，它将看起来像这样:

00 00 FE FF - UTF-32BE
FE FF 00 xx - UTF-16BE
FF FE 00 00 - UTF-32LE
FF FE xx 00 - UTF-16LE
EF BB BF xx - UTF-8

注意:

UTF-32BE不是以三个null开头的，所以它不会被识别 UTF-32LE第一个字节后面没有三个null，所以它不会被识别 UTF-16BE在前四个字节中只有一个NUL，所以它不会被识别 UTF-16LE在前四个字节中只有一个NUL，所以它不会被识别

根据实现的不同，所有这些都可能被错误地解释为UTF-8，然后被错误地解释或拒绝为无效的UTF-8，或者根本不被识别。

此外，如果实现像我推荐的那样测试有效的JSON，它甚至会拒绝确实编码为UTF-8的输入，因为它没有像RFC那样以< 128的ASCII字符开头。

其他数据格式

JSON格式的BOM是不需要的，是非法的，并且会破坏按照RFC正常工作的软件。当时不使用它应该是显而易见的，然而，总是有人坚持通过使用bom、注释、不同的引用规则或不同的数据类型来破坏JSON。当然，如果你需要，任何人都可以自由地使用像bom或其他东西——只是不要把它称为JSON。

对于JSON以外的其他数据格式，看看它到底是什么样子的。如果唯一的编码是UTF-*，并且第一个字符必须是小于128的ASCII字符，那么您已经拥有了确定数据编码和字节序所需的所有信息。即使将bom添加为可选特性，也只会使其更加复杂和容易出错。

BOM的其他用途

至于JSON或脚本之外的用途，我认为这里已经有了很好的答案。我想添加更详细的信息，特别是关于脚本和序列化，因为这是BOM字符导致实际问题的一个例子。

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.

以下是我使用Visual Studio、Sourcetree和Bitbucket拉请求的经验，这给了我一些问题:

因此，在审查拉取请求时，带有签名的BOM将在每个文件上包含一个红点字符(这可能非常烦人)。

如果你把鼠标停在上面，它会显示一个像“ufeff”这样的字符，但事实证明Sourcetree不显示这些类型的字节标记，所以它很可能会在你的拉请求中结束，这应该是可以的，因为这是Visual Studio 2017现在编码新文件的方式，所以也许Bitbucket应该忽略这个或让它以另一种方式显示，更多信息在这里:

红点标记BitBucket差异视图

我用utf-8保存了一个自动热键文件，中文字符变得奇怪。

使用utf-8 BOM，工作正常。

AutoHotkey不会自动识别UTF-8文件，除非它以字节顺序标记开始。

https://www.autohotkey.com/docs/FAQ.htm#nonascii