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

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

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

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

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

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

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

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

#!/bin/bash

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

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

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

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

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

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

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