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


当前回答

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

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

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

#!/bin/bash

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

其他回答

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

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

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

将BOM放在UTF-8编码的文件中至少有三个问题。

不包含文本的文件不再为空,因为它们始终包含BOM。 在UTF-8的ASCII子集中保存文本的文件本身不再是ASCII,因为BOM不是ASCII,这使得一些现有工具无法使用,用户可能不可能替换这些遗留工具。 不可能将几个文件连接在一起,因为现在每个文件开头都有一个BOM。

而且,正如其他人所提到的,使用BOM来检测某些东西是否是UTF-8是既不够也没有必要的:

这是不够的,因为任意字节序列可能恰好以构成BOM的确切序列开始。 这是不必要的,因为你可以像读取UTF-8一样读取字节;如果成功,根据定义,它是有效的UTF-8。

UTF-8与BOM更好地识别。我得出这个结论很不容易。我正在从事一个项目,其中一个结果是一个CSV文件,包括Unicode字符。

如果CSV文件保存时没有BOM, Excel会认为它是ANSI并显示胡言乱语。一旦你在前面添加了“EF BB BF”(例如,通过使用UTF-8记事本重新保存它;或notepad++与UTF-8与BOM), Excel打开它很好。

RFC 3629: "UTF-8,一种ISO 10646的转换格式",2003年11月建议将BOM字符前置到Unicode文本文件中 在https://www.rfc-editor.org/rfc/rfc3629(这最后的信息可以在:http://www.herongyang.com/Unicode/Notepad-Byte-Order-Mark-BOM-FEFF-EFBBBF.html)

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

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