最近使用notepad++ 转换 文件的编码格式时,发现有两种UTF-8 格式
UTF-8
UTF-8 WITHOUT BOM --注释 推荐这种格式
上网查询得到如下 解释
Unicode规范中有一个BOM的概念。BOM——Byte Order Mark,就是字节序标记
在UCS编码中有一个叫做"ZERO WIDTH NO-BREAKSPACE"的字符,它的编码是FEFF。而FFFE在UCS中是不存在的字符,所以不应该出现在实际传输中。UCS规范建议我们在传输 字节流前,先传输字符"ZERO WIDTH NO-BREAKSPACE"。这样如果接收者收到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来标记文本文件的编码方式的。
另外unicode网站的FAQ-BOM 详细介绍了BOM。官方的自然权威,不过是英文的,看起来比较费劲。
UTF- 8编码的文件中,BOM占三个字节。如果用记事本把一个文本文件另存为UTF-8编码方式的话,用UE打开这个文件,切换到十六进制编辑状态就可以看到开 头的FFFE了。这是个标识UTF-8编码文件的好办法,软件通过BOM来识别这个文件是否是UTF-8编码,很多软件还要求读入的文件必须带BOM。可 是,还是有很多软件不能识别BOM。我在研究Firefox的时候就知道,在Firefox早期的版本里,扩展是不能有BOM的,不过 Firefox1.5以后的版本已经开始支持BOM了。现在又发现,PHP也不支持BOM。
PHP在设计时就没有考虑BOM的问题,也就是说他不 会忽略UTF-8编码的文件开头BOM的那三个字符。由于必须在<?或者<?php后面的代码才会作为PHP代码执行,所以这三个字符将会直 接输出。如果插件的文件有这个问题,将会导致在后台页面里激活或者不激活插件后显示白屏,如果是模版文件有这个问题,将会导致这三个字符直接输出,造成页 面上方有一个小空行。国外的英文插件和模版一般都是用的ASCII码的编码方式,不会有BOM,只有国内的插件和模版会由于作者的不知情造成问题。还有, 大家修改模版的时候,由于输出页面使用UTF-8编码,那么修改模版的时候如果有加入中文字符的话,必须把文件转成UTF-8编码才能正常显示,这个时候 如果所使用的编辑器自动加上了BOM的话,将会造成在页面上输出这三个字符,显示效果就要看浏览器了,一般是一个空行或是一个乱码。
在Bo-Blog的wiki 看 到,同样使用PHP的Bo-Blog也一样受到BOM的困扰。其中有提到另一个麻烦:“受COOKIE送出机制的限制,在这些文件开头已经有BOM的文件 中,COOKIE无法送出(因为在COOKIE送出前PHP已经送出了文件头),所以登入和登出功能失效。一切依赖COOKIE、SESSION实现的功 能全部无效。”这个应该就是Wordpress后台出现空白页面的原因了,因为任何一个被执行的文件包含了BOM,这三个字符都将被送出,导致依赖 cookies和session的功能失效。
解决的办法嘛,如果只包含英文字符(或者说ASCII编码内的字符),就把文件存成ASCII码方式 吧。用UE等编辑器的话,点文件->转换->UTF-8转ASCII,或者在另存为里选择ASCII编码。如果是DOS格式的行尾符,可以用 记事本打开,点另存为,选ASCII编码。如果包含中文字符的话,可以用UE的另存为功能,选择
UTF-8 无BOM”即可。