UTF-8和UTF-8与BOM有什么不同?哪个更好?
当前回答
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.
其他回答
以下是我使用Visual Studio、Sourcetree和Bitbucket拉请求的经验,这给了我一些问题:
因此,在审查拉取请求时,带有签名的BOM将在每个文件上包含一个红点字符(这可能非常烦人)。
如果你把鼠标停在上面,它会显示一个像“ufeff”这样的字符,但事实证明Sourcetree不显示这些类型的字节标记,所以它很可能会在你的拉请求中结束,这应该是可以的,因为这是Visual Studio 2017现在编码新文件的方式,所以也许Bitbucket应该忽略这个或让它以另一种方式显示,更多信息在这里:
红点标记BitBucket差异视图
将BOM放在UTF-8编码的文件中至少有三个问题。
不包含文本的文件不再为空,因为它们始终包含BOM。 在UTF-8的ASCII子集中保存文本的文件本身不再是ASCII,因为BOM不是ASCII,这使得一些现有工具无法使用,用户可能不可能替换这些遗留工具。 不可能将几个文件连接在一起,因为现在每个文件开头都有一个BOM。
而且,正如其他人所提到的,使用BOM来检测某些东西是否是UTF-8是既不够也没有必要的:
这是不够的,因为任意字节序列可能恰好以构成BOM的确切序列开始。 这是不必要的,因为你可以像读取UTF-8一样读取字节;如果成功,根据定义,它是有效的UTF-8。
引用于维基百科页面底部BOM: http://en.wikipedia.org/wiki/Byte-order_mark#cite_note-2
对于UTF-8,使用BOM既不要求也不推荐,但在从使用BOM的其他编码形式转换UTF-8数据或将BOM用作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节特殊项中的“字节顺序标记”小节。
这个问题已经有了无数个答案,其中许多答案都很好,但我想尝试并澄清何时应该使用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编码。
推荐文章
- 用Python写入UTF-8文件
- c++中的_tmain()和main()有什么区别?
- HTML编码问题-显示“”字符而不是“ ”
- 将Unicode文本写入文本文件?
- PHP DOMDocument loadHTML没有正确编码UTF-8
- 我如何在JavaScript中使用unicode感知的正则表达式?
- 如何检查Python中的字符串是否是ASCII?
- 字符、码位、字形和字素之间的区别是什么?
- 如何将wstring转换为字符串?
- 什么是ANSI格式?
- 如何在Bash中回显4位Unicode字符?
- 如何使用vim更改文件的编码?
- 为什么这段反向写的代码打印“Hello World!”
- 重音字符的具体JavaScript正则表达式(变音符)
- UTF-8字节[]到字符串