我读到在文本文件的开头添加 UTF-8 字节顺序标记(3 个字符(会使它成为 UTF-8 文件，但我也读过 unicode 建议不要对 UTF-8 使用 BOM。
我正在用PHP生成文件，并且要求文件为UTF-8。我已将 UTF-8 BOM 添加到文件的开头，但我从解析文件的公司收到了有关文件开头的垃圾字符的反馈，这让我要求将文件设为 UTF-8。
如果我在记事本中打开文件，它不会显示 BOM，如果我另存为，它会显示 UTF-8 作为默认选项。
在 Textpad32 中打开文件会在文件开头显示 3 个字符。
那么是什么使文件成为 UTF-8？
文本是 UTF-8，因为它作为 UTF-8 有效，并且作者决定它是。
作者如何将该决定传达给消费者是一个不同的问题，它涉及约定、猜测以及带内或带外信令的各种方案，如 HTTP 或 HTML 字符集、BOM(增强猜测(、一些信封/嵌入格式、其他数据流、文件命名等等。
该文件不需要任何明确的指示符来表明它是 UTF-8，现代文本编辑器应该从上下文中检测 UTF-8 编码，因为 UTF-8 序列非常不同。
此外，正如您亲身经历的那样，PHP 不喜欢 BOM 标头，这是一件愚蠢的事情，经常会弄乱脚本输出并产生比它解决的问题更多的问题。
HTML有它自己的方法来声明文件的编码，你可以在HTML本身中做到这一点：
<head>
<meta charset="UTF-8">
</head>
或者在 HTTP 标头中声明编码，此处使用 PHP：
header('Content-Type: text/html; charset=utf-8');
现代浏览器还将假定 UTF-8 作为默认编码，以防未指定任何编码。毕竟，这是网络的标准。
UTF-8 是一种特殊的编码。 所有 7 位 ASCII 文件也是有效的 UTF-8，它也可以对每个 Unicode 字符进行编码。
您经常会得到在没有 BOM 的情况下另存为 UTF-8 的建议。 实际上，传统编码(如代码页 1252、Big5 或 Shift-JIS(中的文件不太可能恰好看起来像有效的 UTF-8，除非它是一个故意不明确的测试用例。 许多程序(如 Web 浏览器(在实践中都擅长确定文件何时为 UTF-8。 最新的软件使用 UTF-8 作为其首选文本编码，除非它被迫默认为其他编码以与上个世纪兼容。 (例如，LaTeX 在 2018 年 4 月将其默认源编码更改为 UTF-8，LuaLaTeX 和 XeLaTeX 引擎多年来一直在这样做。
有一些文档类型具有特殊要求。 例如，网页的默认编码理论上是 Windows 1252，尽管现实世界中的浏览器会采取最佳猜测。 Web 上的当前最佳实践是另存为 UTF-8，不带 BOM。 相反，您编写文档的<head>，<meta http-equiv="Content-Type" content="text/html; charset=utf-8">或<meta charset="utf-8"/>这会明确告知用户代理字符编码是什么。
另一方面，某些旧版本的软件在看到 BOM 时会中断，或者只有在有 BOM 时才能识别 UTF-8。 Microsoft in the 'aughts 对此特别内疚，它的软件不想破坏任何过去可以工作的文件，所以，直到今天，我使用 BOM 将我的 C 源文件保存为 UTF-8。 这是唯一适用于我使用的每个编译器的格式：如果您不给它 BOM 或正确的命令行标志，即使是最新版本的 MSVC 也可能猜错，而 Clang 仅支持 UTF-8，并且没有读取任何其他编码的文件的选项。 我曾经被迫使用的一些旧版本的 MSVC 根本无法理解 UTF-8，除非 BOM 存在，并且不提供任何覆盖其自动检测的方法。