UTF8 与 UTF8 +BOM 区别

一个带标签，一个没有标签。
BOM是Byte Order Mark（定义字节顺序），由于在网络传输中分两种顺序：大头和小头。

因为兼容性，带BOM的utf-8在一些browser中显示为乱码。

网上搜索了关于Byte Order Mark的信息：
在UCS 编码中有一个叫作"ZERO WIDTH NO-BREAK SPACE"的字符，它的编码是FEFF。而FFFE在UCS中是不存在的字符，因此不该该出如今实际传输中。UCS规范建

议咱们在传输字节流前，先传输字符"ZERO WIDTH NO-BREAK SPACE"。这样若是接收者收到FEFF，就代表这个字节流是Big-Endian的；若是收到FFFE，就代表这

个字节流是Little- Endian的。所以字符"ZERO WIDTH NO-BREAK SPACE"又被称做BOM。
UTF-8不须要BOM来代表字节顺序，但能够用BOM来代表编码方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8编码是EF BB BF。因此若是接收者收到以EF BB BF

开头的字节流，就知道这是UTF-8编码了。
Windows就是使用BOM来标记文本文件的编码方式的。

带BOM的UTF-8，全部PHP没法识别，直接将EF BB BF输出，在charset="utf-8"的页面中是空白，在GB2312的页面中的输出的就是稀有汉字：锘匡豢

 

怎么转化为 UTF-8，无bom格式 ？？
用 UltarEdit   能够转化的
直接用UE打开你的文件,而后在文件选项里面有一个转化的选项
里面选ascii转化为 uft-8 就能够了

【UTF8 + BOM产生问题与小结】
写python脚本的时候发现这样一个问题：从xls文件导出到txt时，没法直接转换为int型数据，输出查看发现和文件编码方式产生的附加信息有关用一个简单的

文件举例

90905

90907

90908

90909

90939

90940

90946

90959

90961

90965

当文件分别用ascii，utf8，utf8+bom做为编码格式时，显示输出结果以下：

使用ascii编码的输出：

['90905\r\n', '90907\r\n', '90908\r\n', '90909\r\n', '90939\r\n', '90940\r\n', '90946\r\n', '90959\r\n', '90961\r\n', '90965']

使用utf8编码的输出：

['90905\r\n', '90907\r\n', '90908\r\n', '90909\r\n', '90939\r\n', '90940\r\n', '90946\r\n', '90959\r\n', '90961\r\n', '90965']

使用bom编码的输出：

['\xef\xbb\xbf90905\r\n', '90907\r\n', '90908\r\n', '90909\r\n', '90939\r\n', '90940\r\n', '90946\r\n', '90959\r\n', '90961\r\n', '90965']

原来utf8+bom不能直接转换int的缘由在这里，它在文件头插入了一个表示文件编码的信息\xef\xbb\xbf，那么UTF-8(无BOM）和UTF－8这两个有什么区别呢？

BOM是什么呢？

什么是BOM？
BOM: Byte Order Mark
UTF-8 BOM又叫UTF-8 签名,其实UTF-8 的BOM对UFT-8没有做用,是为了支持UTF-16,UTF-32才加上的

BOM,BOM签名的意思就是告诉编辑器当前文件采用何种编码,方便编辑器识别,可是BOM虽然在编辑器中不显示,可是会产生输出,就像多了一个空行。

Byte Order Marks are special characters at the beginning of a Unicode file to indicate whether it is big or little endian, in other words

does the high or low order byte come first. These codes also tell whether the encoding is 8, 16 or 32 bit. You can recognise Unicode files by their starting byte order marks, and by the way Unicode-16 files are half zeroes and Unicode-32 files are three-quarters zeros. Unicode Endian Markers

Byte-order mark Description
EF BB BF UTF-8
FF FE UTF-16 aka UCS-2, little endian
FE FF UTF-16 aka UCS-2, big endian
00 00 FF FE UTF-32 aka UCS-4, little endian.
00 00 FE FF UTF-32 aka UCS-4, big-endian.

UTF的字节序和BOM
UTF- 8以字节为编码单元，没有字节序的问题。UTF-16以两个字节为编码单元，在解释一个UTF-16文本前，首先要弄清楚每一个编码单元的字节序。例如收到 一个“奎”的Unicode编码是594E，“乙”的Unicode编码是4E59。若是咱们收到UTF-16字节流“594E”，那么这是“奎”仍是 “乙”？

Unicode规范中推荐的标记字节顺序的方法是BOM。BOM不是“Bill Of Material”的BOM表，而是Byte Order Mark。BOM是一个有点小聪明的想法：

在 UCS编码中有一个叫作"ZERO WIDTH NO-BREAK SPACE"的字符，它的编码是FEFF。而FFFE在UCS中是不存在的字符，因此不该该出如今实际传输中。UCS规范建议咱们在传输字节流前，先传输 字符"ZERO WIDTH NO-BREAK SPACE"。

这样若是接收者收到FEFF，就代表这个字节流是Big-Endian的；若是收到FFFE，就代表这个字节流是Little-Endian的。所以字符"ZERO WIDTH NO-BREAK SPACE"又被称做BOM。

UTF-8不须要BOM来代表字节顺序，但能够用BOM来代表编码方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8编码是EF BB BF。因此若是接收者收到以EF BB BF开头的字节流，就知道这是UTF-8编码了。

Windows就是使用BOM来标记文本文件的编码方式的。

原来BOM是在文件的开始加了几个字节做为标记。有了这个标记，一些协议和系统才能识别。

ok,说了这么多背景，那么如何解决这个问题呢？

如何使用BOM头
BOM头的删除
对UTF-16, Python将BOM解码为空字串。然而对UTF-8, BOM被解码为一个字符，如例：

>>> codecs.BOM_UTF16.decode( "utf16" )  u''  >>> codecs.BOM_UTF8.decode( "utf8" )  u'\ufeff'简单的作法是在文件读入时使用

import codecs

f = codecs.open(sys.argv[1],'r', 'utf_8_sig')便可，具体能够参见[http://docs.python.org/library/codecs.html#module-

encodings.utf_8_sig|http://docs.python.org/library/codecs.html#module-encodings.utf_8_sig]

或者：

u.lstrip( unicode( codecs.BOM_UTF8, "utf8" ) )BOM头的添加
out = file( "someFile", "w" )
out.write( codecs.BOM_UTF8 )
out.write( unicodeString.encode( "utf-8" ) )
out.close()out = file( "someFile", "w" )out.write( codecs.BOM_UTF8 )out.write( unicodeString.encode( "utf-8" ) )out.close()详细的过程解释可

以参见[http://mindprod.com/jgloss/encoding.html|http://mindprod.com/jgloss/encoding.html]

参考资料：

[http://blog.sina.com.cn/s/blog_3e9d2b350100as0b.html|http://blog.sina.com.cn/s/blog_3e9d2b350100as0b.html]

[http://4nail.iteye.com/blog/840612|http://4nail.iteye.com/blog/840612]

【UTF8和UTF8 + BOM 网页代码通常使用哪一个？】

首先，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.： 为何说VIM去除bomb的操做须要在UNIX下完成。由于VIM在Windows环境下有一个奇怪的bug，老是把UTF-16文件识别成二进制文 件，而UNIX（Linux或者Mac均可以）下VIM则无问题。这个问题从VIM 6.8一直跟着我到VIM 7.3。目前尚不清楚这是VIM的bug仍是我本身那个.vimrc文件的bug。

【谈谈Unicode编码，简要解释UCS、UTF、BMP、BOM等名词】
这是一篇程序员写给程序员的趣味读物。所谓趣味是指能够比较轻松地了解一些原来不清楚的概念，增进知识，相似于打RPG游戏的升级。整理这篇文章的动机是两个问题：

问题一：
使用Windows记事本的“另存为”，能够在GBK、Unicode、Unicode big endian和UTF-8这几种编码方式间相互转换。一样是txt文件，Windows是怎样识别编码方式的呢？

我 很早前就发现Unicode、Unicode big endian和UTF-8编码的txt文件的开头会多出几个字节，分别是FF、FE（Unicode）,FE、FF（Unicode big endian）,EF、BB、BF（UTF-8）。但这些标记是基于什么标准呢？

问题二：
最近在网上看到一个 ConvertUTF.c，实现了UTF-3二、UTF-16和UTF-8这三种编码方式的相互转换。对于Unicode(UCS2)、GBK、UTF- 8这些编码方式，我原来就了解。但这个程序让我有些糊涂，想不起来UTF-16和UCS2有什么关系。
查了查相关资料，总算将这些问题弄清楚了，顺带也了解了一些Unicode的细节。写成一篇文章，送给有过相似疑问的朋友。本文在写做时尽可能作到通俗易懂，但要求读者知道什么是字节，什么是十六进制。

0、big endian和little endian
big endian和little endian是CPU处理多字节数的不一样方式。例如“汉”字的Unicode编码是6C49。那么写到文件里时，到底是将6C写在前面，仍是将49写在前 面？若是将6C写在前面，就是big endian。仍是将49写在前面，就是little endian。

“endian”这个词出自《格列佛游记》。小人国的内战就源于吃鸡蛋时是究竟从大头(Big-Endian)敲开仍是从小头(Little-Endian)敲开，由此曾发生过六次叛乱，其中一个皇帝送了命，另外一个丢了王位。

咱们通常将endian翻译成“字节序”，将big endian和little endian称做“大尾”和“小尾”。

一、字符编码、内码，顺带介绍汉字编码
字符必须编码后才能被计算机处理。计算机使用的缺省编码方式就是计算机的内码。早期的计算机使用7位的ASCII编码，为了处理汉字，程序员设计了用于简体中文的GB2312和用于繁体中文的big5。

GB2312(1980年)一共收录了7445个字符，包括6763个汉字和682个其它符号。汉字区的内码范围高字节从B0-F7，低字节从A1-FE，占用的码位是72*94=6768。其中有5个空位是D7FA-D7FE。

GB2312支持的汉字太少。1995年的汉字扩展规范GBK1.0收录了21886个符号，它分为汉字区和图形符号区。汉字区包括21003个字符。2000年的GB18030是取代

GBK1.0的正式国家标准。该标准收录了27484个汉字，同时还收录了藏文、蒙文、维吾尔文等主要的少数民族文字。如今的PC平台必须支持GB18030，对嵌入式产品暂不做要求。因此手机、MP3通常只支持GB2312。

从 ASCII、GB23十二、GBK到GB18030，这些编码方法是向下兼容的，即同一个字符在这些方案中老是有相同的编码，后面的标准支持更多的字符。 在这些编码中，英文和中文能够统一地处理。区分中文编码的方法是高字节的最高位不为0。按照程序员的称呼，GB23十二、GBK到GB18030都属于双 字节字符集 (DBCS)。

有的中文Windows的缺省内码仍是GBK，能够经过GB18030升级包升级到GB18030。不过GB18030相对GBK增长的字符，普通人是很难用到的，一般咱们仍是用GBK指代中文Windows内码。

这里还有一些细节：

GB2312的原文仍是区位码，从区位码到内码，须要在高字节和低字节上分别加上A0。

在DBCS中，GB内码的存储格式始终是big endian，即高位在前。

GB2312的两个字节的最高位都是1。但符合这个条件的码位只有128*128=16384个。因此GBK和GB18030的低字节最高位均可能不是1。不过这不影响DBCS字符流的

解析：在读取DBCS字符流时，只要遇到高位为1的字节，就能够将下两个字节做为一个双字节编码，而不用管低字节的高位是什么。

二、 Unicode、UCS和UTF 前面提到从ASCII、GB23十二、GBK到GB18030的编码方法是向下兼容的。而Unicode只与ASCII兼容（更准确地说，是与ISO- 8859-1兼容），与GB码不兼容。例如“汉”字的Unicode编码是6C49，而GB码是BABA。

Unicode也是一种字 符编码方法，不过它是由国际组织设计，能够容纳全世界全部语言文字的编码方案。Unicode的学名是"Universal Multiple-Octet Coded Character Set"，简称为UCS。UCS能够看做是"Unicode Character Set"的缩写。

根据维基百科全书(http://zh.wikipedia.org/wiki/)的记载：历史上存在两个试图独立 设计Unicode的组织，即国际标准化组织（ISO）和一个软件制造商的协会（unicode.org）。ISO开发了ISO 10646项目，Unicode协会开发了Unicode项目。

在1991年先后，双方都认识到世界不须要两个不兼容的字符集。因而它们开始合并双方的工做成果，并为创立一个单一编码表而协同工做。从Unicode2.0开始，Unicode项目采用了与ISO 10646-1相同的字库和字码。

目前两个项目仍都存在，并独立地公布各自的标准。Unicode协会如今的最新版本是2005年的Unicode 4.1.0。ISO的最新标准是10646-3:2003。

UCS规定了怎么用多个字节表示各类文字。怎样传输这些编码，是由UTF(UCS Transformation Format)规范规定的，常见的UTF规范包括UTF-八、UTF-七、UTF-16。

IETF 的RFC2781和RFC3629以RFC的一向风格，清晰、明快又不失严谨地描述了UTF-16和UTF-8的编码方法。我老是记不得IETF是 Internet Engineering Task Force的缩写。但IETF负责维护的RFC是Internet上一切规范的基础。

三、UCS-二、UCS-四、BMP UCS有两种格式：UCS-2和UCS-4。顾名思义，UCS-2就是用两个字节编码，UCS-4就是用4个字节（实际上只用了31位，最高位必须为0）编码。下面让咱们作一些简单的数学游戏：

UCS-2有2^16=65536个码位，UCS-4有2^31=2147483648个码位。

UCS- 4根据最高位为0的最高字节分红2^7=128个group。每一个group再根据次高字节分为256个plane。每一个plane根据第3个字节分为 256行 (rows)，每行包含256个cells。固然同一行的cells只是最后一个字节不一样，其他都相同。

group 0的plane 0被称做Basic Multilingual Plane, 即BMP。或者说UCS-4中，高两个字节为0的码位被称做BMP。

将UCS-4的BMP去掉前面的两个零字节就获得了UCS-2。在UCS-2的两个字节前加上两个零字节，就获得了UCS-4的BMP。而目前的UCS-4规范中尚未任何字符被分配在BMP以外。

四、UTF编码

UTF-8就是以8位为单元对UCS进行编码。从UCS-2到UTF-8的编码方式以下：

UCS-2编码(16进制) UTF-8 字节流(二进制)
0000 - 007F 0xxxxxxx
0080 - 07FF 110xxxxx 10xxxxxx
0800 - FFFF 1110xxxx 10xxxxxx 10xxxxxx

例 如“汉”字的Unicode编码是6C49。6C49在0800-FFFF之间，因此确定要用3字节模板了：1110xxxx 10xxxxxx 10xxxxxx。将6C49写成二进制是：0110 110001 001001， 用这个比特流依次代替模板中的x，获得：11100110 10110001 10001001，即E6 B1 89。

读者能够用记事本测试一下咱们的编码是否正确。

UTF- 16以16位为单元对UCS进行编码。对于小于0x10000的UCS码，UTF-16编码就等于UCS码对应的16位无符号整数。对于不小于 0x10000的UCS码，定义了一个算法。不过因为实际使用的UCS2，或者UCS4的BMP必然小于0x10000，因此就目前而言，能够认为 UTF-16和UCS-2基本相同。但UCS-2只是一个编码方案，UTF-16却要用于实际的传输，因此就不得不考虑字节序的问题。

五、UTF的字节序和BOM
UTF- 8以字节为编码单元，没有字节序的问题。UTF-16以两个字节为编码单元，在解释一个UTF-16文本前，首先要弄清楚每一个编码单元的字节序。例如收到 一个“奎”的Unicode编码是594E，“乙”的Unicode编码是4E59。若是咱们收到UTF-16字节流“594E”，那么这是“奎”仍是 “乙”？

Unicode规范中推荐的标记字节顺序的方法是BOM。BOM不是“Bill Of Material”的BOM表，而是Byte Order Mark。BOM是一个有点小聪明的想法：

在 UCS编码中有一个叫作"ZERO WIDTH NO-BREAK SPACE"的字符，它的编码是FEFF。而FFFE在UCS中是不存在的字符，因此不该该出如今实际传输中。UCS规范建议咱们在传输字节流前，先传输 字符"ZERO WIDTH NO-BREAK SPACE"。 这样若是接收者收到FEFF，就代表这个字节流是Big-Endian的；若是收到FFFE，就代表这个字节流是Little-Endian的。所以字 符"ZERO WIDTH NO-BREAK SPACE"又被称做BOM。

UTF-8不须要BOM来代表字节顺序，但能够用BOM 来代表编码方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8编码是EF BB BF（读者能够用咱们前面介绍的编码方法验证一下）。因此若是接收者收到以EF BB BF开头的字节流，就知道这是UTF-8编码了。

Windows就是使用BOM来标记文本文件的编码方式的。

六、进一步的参考资料
本文主要参考的资料是 "Short overview of ISO-IEC 10646 and Unicode" (http://www.nada.kth.se/i18n/ucs/unicode-iso10646-oview.html)。

两篇看上去不错的资料：

"Understanding Unicode A general introduction to the Unicode Standard" (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter04a) "Character set encoding basics Understanding character set encodings and legacy encodings" (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter03) 网上应该有UTF-八、UCS-二、GBK相互转换的软件包，包括使用Windows API和不使用Windows API的版本。