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


当前回答

以下是我使用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。

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

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

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

我个人保存带有BOM的服务器端脚本文件(.asp, .ini, .aspx)和没有BOM的.html文件。

如上所述,带有BOM的UTF-8可能会导致非BOM感知(或兼容)软件出现问题。我曾经用基于mozilla的KompoZer编辑UTF-8 + BOM编码的HTML文件,因为客户需要WYSIWYG程序。

保存时,布局总是会被破坏。我花了一些时间来解决这个问题。这些文件在Firefox中运行良好,但在Internet Explorer中显示了一个CSS怪癖,再次破坏了布局。在摆弄了几个小时链接的CSS文件后,我发现Internet Explorer不喜欢BOMfed HTML文件。我再也不会见你了。

还有,我刚在维基百科上找到了这个:

The shebang characters are represented by the same two bytes in extended ASCII encodings, including UTF-8, which is commonly used for scripts and other text files on current Unix-like systems. However, UTF-8 files may begin with the optional byte order mark (BOM); if the "exec" function specifically detects the bytes 0x23 0x21, then the presence of the BOM (0xEF 0xBB 0xBF) before the shebang will prevent the script interpreter from being executed. Some authorities recommend against using the byte order mark in POSIX (Unix-like) scripts,[15] for this reason and for wider interoperability and philosophical concerns

其他优秀的回答已经回答过了

UTF-8和BOM-ed的UTF-8之间没有官方的区别 一个BOM-ed的UTF-8字符串将以以下三个字节开始。Ef bb bf 如果存在这些字节,在从文件/流中提取字符串时必须忽略。

但是,作为附加信息,UTF-8的BOM可以很好地“嗅出”字符串是否以UTF-8编码……或者它可以是任何其他编码的合法字符串…

例如,数据[EF BB BF 41 42 43]可以是:

合法的ISO-8859-1字符串“ABC” 合法的UTF-8字符串“ABC”

因此,尽管通过查看第一个字节来识别文件内容的编码很酷,但您不应该依赖于此,如上面的示例所示

编码应该是已知的,而不是推测的。

只有当文件实际包含一些非ascii字符时,UTF-8和BOM才有用。如果包含了它,而没有任何ASCII,那么它可能会破坏旧的应用程序,否则将文件解释为纯ASCII。当遇到非ASCII字符时,这些应用程序肯定会失败,因此在我看来,只有当文件可以并且不应该再被解释为纯ASCII时,才应该添加BOM。

我想说清楚的是,我宁愿没有BOM。如果一些旧的垃圾没有它就坏了,那么就添加它,替换遗留应用程序是不可行的。

不要制作UTF-8的BOM之外的任何东西。