我用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是文本流开头的字节序列(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节特殊项中的“字节顺序标记”小节。

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

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

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

红点标记BitBucket差异视图

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

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

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