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

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

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

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

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

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

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

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

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

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

我个人保存带有BOM的服务器端脚本文件(.asp， .ini， .aspx)和没有BOM的.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节特殊项中的“字节顺序标记”小节。

从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，这会在开发链的后面引起其他问题。

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.