UTF-8整理

1. BOM: Byte Order Mark

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

2. 影响：

    IE里面会发现页面里多了一行空白，而且排除是CSS的原因。
    firefox的firebug插件里看DOM树，会发现HTML多了一行空白，但是在页面样式里面没有影响。

  在Firefox早期的版本里，扩展是不能有BOM的，不过Firefox 1.5以后的版本已经开始支持BOM了。

  PHP也不支持BOM。PHP在设计时就没有考虑BOM的问题，也就是说他不会忽略UTF-8编码的文件开头BOM的那三个字符。

  bom的另一个麻烦：“受COOKIE送出机制的限制，在这些文件开头已经有BOM的文件中，COOKIE无法送出（因为在COOKIE送出前PHP已经送出了文件头），所以登入和登出功能失效。一切依赖COOKIE、SESSION实现的功能全部无效。”

utf8时的BOM是：EF BB BF，占三个字节。

其实UTF-8 的BOM对UFT-8没有作用,是为了支援UTF-16,UTF-32才加上的BOM,BOM签名的意思就是告诉编辑器当前文件采用何种编码,方便编辑器识别,但是BOM虽然在编辑器中不显示,但是会产生输出,就像多了一个空行。

BOM对于utf-8来说是多余的东西。

utf-16才需要加bom。因为它是按unicode顺序编码，在BMP范围内是二字节，需要识别是大或小字节序。

Unicode（UTF-16）以小尾（little-endian）顺序存放的BOM是0xFF、0xFE，以大尾（big-endian）顺序存放的BOM是0xFE、0xFF，这两个字节要先于文本写入。UTF-8文本不存在大小尾问题，但微软为UTF-8文本文件默认加上了0xEF、0xBB、0xBF的BOM。

倘若使用UltraEdit将UTF-8文本的BOM剔除，保存后的文件用记事本打开仍然是正常的。也就是说，Windows支持无BOM的UTF-8文本。上面的两个小把戏中的文本的离奇表现都是因为被识别为无BOM的UTF-8文本。Windows对文本编码识别的优先度是：依据BOM>依据UTF-8字符串检测算法>ANSI。

“涓狽”的GBK编码是0xE4B8 0xAA4E，保存为文件再打开时，E4B8AA是“个”的UTF-8编码，4E是“N”的ASCII码，整个字符串通过了检测函数，自然被认为是UTF-8字符串而不是GBK字符串了。

第一个小把戏中，删除空格前整个字符串没有通过检测函数，因此被当成GBK编码；删除空格后，通过了检测函数，因此被当成UTF-8编码。

那到底你想要的是GBK编码呢还是UTF-8编码呢？如果你想要GBK编码方式，“涓狽”这种情况，很遗憾，无论你怎样保存，系统还是会当成UTF-8。虽然这种概率很低，但并不是不存在。当然你将“涓狽”以UTF-8+BOM方式保存，就绝对不会出错了。

选择有BOM的UTF-8还是无BOM的UTF-8，要看场合。Windows默认有BOM，因此编写程序一定要支持BOM，检查前3个字节就行，非常简单。编写的程序保存UTF-8文本，也应当加上BOM，这不是多余，在一些情况下，UTF-8是能被当作多字节编码理解的。php的include文件，如果是UTF-8编码，不能加BOM。余的wordpress后台一直有问题，登录也不正常，原因在于修改某插件的一些代码加入中文字符后保存为UTF-8编码多了BOM。删掉php文件的BOM后就正常了。