UTF-8的BOM之争

BOM的介绍

在github上写md文件的时候，发现生成本身blog时，报出一个错误是让使用UTF-8编码，而后在Notepad++上把文件转成UTF-8时，发现菜单中有"UTF-8无BOM编码格式"。

上网查了一下BOM的定义：byte order mark 这个是为UTF-16和UTF-32准备的，用于标记字节序(byte order)。

「UTF-8」和「带 BOM 的 UTF-8」的区别就是有没有 BOM。即文件开头有没有 U+FEFF。

BOM的爱恨情仇

知乎上有个比较好的文章，讲了BOM问题，下面直接引用了原文：

做者：陈甫鸼 连接：https://www.zhihu.com/question/20167122/answer/14199022 来源：知乎 著做权归做者全部。商业转载请联系做者得到受权，非商业转载请注明出处。

首先，BOM是啥。这个就不解释了，Wikipedia上很详细。http://en.wikipedia.org/wiki/Byte_order_mark。在网页上使用BOM是个错误。BOM设计出来不是用来支持HTML和XML的。要识别文本编码，HTML有charset属性，XML有encoding属性，不必拉BOM撑场面。虽然理论上BOM能够用来识别UTF-16编码的HTML页面，但实际工程上不多有人这么干。毕竟UTF-16这种编码连ASCII都双字节，实在不适用于作网页。其实说BOM是个坏习惯也不尽然。BOM也是Unicode标准的一部分，有它特定的适用范围。一般BOM是用来标示Unicode纯文本字节流的，用来提供一种方便的方法让文本处理程序识别读入的.txt文件是哪一个Unicode编码（UTF-8，UTF-16BE，UTF-16LE）。Windows相对对BOM处理比较好，是由于Windows把Unicode识别代码集成进了API里，主要是CreateFile()。打开文本文件时它会自动识别并剔除BOM。Windows用这个有历史缘由，由于它最初脱胎于多代码页的环境。而引入Unicode时Windows的设计者又但愿能在用户不注意的状况下同时兼容Unicode和非Unicode（Multiple byte）文本文件，就只能借助这种小trick了。相比之下，Linux这样的系统在多locale的环境中浸染的时间比较短，再加上社区自己也有足够的动力轻装前进（吐槽：微软对兼容性的要求确实是到了很是偏执的地步，任何一点破坏兼容性的作法都不容许，以致于不少时候是本身绑住本身的双手），因此干脆一步到位进入UTF-8。固然中间其实有一段过渡期，好比从最初全UTF-8的GTK+2.0发布到基本上全部GTK开发者都弃用多locale的GTK+1.2，我印象中至少经历了三到四年。BOM不受欢迎主要是在UNIX环境下，由于不少UNIX程序不鸟BOM。主要问题出在UNIX那个全部脚本语言通行的首行#!标示，这东西依赖于shell解析，而不少shell出于兼容的考虑不检测BOM，因此加进BOM时shell会把它解释为某个普通字符输入致使破坏#!标示，这就麻烦了。其实不少现代脚本语言，好比Python，其解释器自己都是能处理BOM的，可是shell卡在这里，没办法，只能躺着也中枪。提及来这也不能怪shell，由于BOM自己违反了一个UNIX设计的常见原则，就是文档中存在的数据必须可见。BOM不能做为可见字符被文本编辑器编辑，就这一条不少UNIX开发者就不满意。顺便说一句，即便脚本语言能处理BOM，随处使用BOM也不是推荐的办法。各个脚本语言对Unicode的处理都有本身的一套，Python的 # -- coding: utf-8 --，Perl的use utf8，都比BOM简单并且可靠。另外一个好消息是，即便是必须在Windows和UNIX之间切换的朋友也不会悲催。幸好在UNIX环境下咱们还有VIM这种神器，即便遇到BOM挡道，咱们也能够经过 set nobomb; set fileencoding=utf8; w 三条命令解决问题。最后回头想一想，彷佛也真就只有Windows坚持用BOM了。P.S.：本问题是本身的第150个回答。忽然发现本身回答得不多不多⋯⋯P.S. 2：忽然想起须要解释一下为何说VIM去除bomb的操做须要在UNIX下完成。由于VIM在Windows环境下有一个奇怪的bug，老是把UTF-16文件识别成二进制文件，而UNIX（Linux或者Mac均可以）下VIM则无问题。这个问题从VIM 6.8一直跟着我到VIM 7.3。目前尚不清楚这是VIM的bug仍是我本身那个.vimrc文件的bug。若有高手解答不胜感激。

@引用结束

总结

如下是一些经典语录：

• HTML有charset属性，XML有encoding属性，不必拉BOM撑场面
• UTF-16这种编码连ASCII都双字节，实在不适用于作网页
• 一般BOM是用来标示Unicode纯文本字节流的，让文本处理程序识别txt文件是哪一个Unicode编码（UTF-8，UTF-16BE，UTF-16LE）
• Windows相对对BOM处理比较好, 打开文本文件时它会自动识别并剔除BOM.
• Windows的设计者但愿能在用户不注意的状况下同时兼容Unicode和非Unicode（Multiple byte）文本文件.
• Linux一步到位进入UTF-8, 过渡期至少经历了三到四年.
• BOM不受欢迎主要是在UNIX环境下，由于不少UNIX程序不鸟BOM。由于BOM自己违反了一个UNIX设计的常见原则，就是文档中存在的数据必须可见。
• UNIX环境下咱们还有VIM这种神器，即便遇到BOM挡道，咱们也能够经过 set nobomb; set fileencoding=utf8; w 三条命令解决问题。
• 彷佛也真就只有Windows坚持用BOM了。
• UTF-8不须要BOM, 因此不含BOM的UTF-8才是标准形式.
• 微软在 UTF-8 中使用 BOM 是由于这样能够把 UTF-8 和 ASCII 等编码明确区分开
• UTF-8 的网页代码不该使用 BOM，不然经常会出错
• 写C++代码建议程序要在windows 和 mac 还有linux 上运行的话，源代码最好保存成utf-8 带bom的格式，这样比较通用一些。而用utf-16 不管大端仍是小端，g++ 都不认的。或者用utf-8 不带bom格式，而后代码不要出现非ascii 127之后的字符。
• 带用bom的utf-8也是符合国际标准的
• 微软在坚持使用bom上没有错，由于这是在为用户考虑的。也许给咱们这些写程序的带来了不便，可是，计算机最普遍的用户不是程序员。
• 带头的鹅和去头的鹅，有些编辑器比较傻会把去头的鹅认成鸭子
• 以UTF-8格式编码, 从notepad++ --> Mongodb里面复制东西的时候，莫名其妙多了很多的字节数。若是不安装notepad++，使用默认的记事本，那就更是个坑，默认有bom，你还没法选择。
• 就是由于这个bom，CSV导入mongodb时，第一个字段老是不正常，直接致使用第一个字段做为条件find时，出不告终果!
• utf8对ascii的兼容确实是它的好，可是这个优势在某些时候偏偏成了隐藏问题的缺点。所以bom大法好，加bom保平安.
• 为何windows的记事本要强行给utf8加bom的缘由——为了兼容旧系统的编码问题，unix阵营放弃带bom的utf8——为了让它们的上古程序能继续运行下去，这个各自有本身利益诉求的差别决定其实并不对错

---

参考：

• https://www.zhihu.com/question/20167122
• http://jimliu.net/2015/03/07/something-about-encoding-extra/