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

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

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

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

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

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

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

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

当您希望显示以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文件中。