UTF-8和UTF-8与BOM有什么不同?哪个更好?


当前回答

应该注意的是,对于某些文件,即使在Windows上也不能有BOM。例如SQL*plus或VBScript文件。如果这样的文件包含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节特殊项中的“字节顺序标记”小节。

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

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

BOM倾向于在某个地方爆炸(没有双关语)。当它突然出现时(例如,无法被浏览器、编辑器等识别),它会以奇怪的字符出现在文档的开头(例如,HTML文件、JSON响应、RSS等),并导致类似于最近奥巴马在Twitter上谈话时经历的编码问题那样的尴尬。

当它出现在难以调试的地方或当测试被忽略时,这是非常令人讨厌的。所以除非必须使用,否则最好避免使用。

这个问题已经有了无数个答案,其中许多答案都很好,但我想尝试并澄清何时应该使用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保存了一个自动热键文件,中文字符变得奇怪。

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

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

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