隐形的 UTF-8 BOM 可能导致样式错乱
2009-06-13 14:13
162 查看
utf-8 是一种在web应用中经常使用的一种 unicode 字符的编码方式,使用 utf-8 的好处在于它是一种变长的编码方式,对于 ANSII 码编码长度为1个字节,这样的话在传输大量 ASCII 字符集的网页时,可以大量节约网络带宽。
使用 utf-8 编码来编写网页的时候, 往往会因为 bom (Byte Order Mark) 的问题,导致网页中经常出现一些不明的空行或者乱码字符。 这些都是因为 utf-8 编码方式对于 bom 不是强制的。因此 utf-8 编码在保存文件的时候,会出现不同的处理方式。比如有的浏览器(FireFox)可以自动过滤掉所有 utf-8 bom , 有的 (IE) 只能过滤掉一次 bom (为什么是一次? 当你出现 Include 多次文件时就会碰上这个问题了)。
使用editplus或其他编辑器删除掉文件中的BOM签名,重新刷新页面,样式正常了。
在这里找到一段关于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来标记文本文件的编码方式的。
...
UTF-8编码的文件中,BOM占三个字节。如果用记事本把一个文本文件另存为UTF-8编码方式的话,用UE打开这个文件,切换到十六进制编辑状态就可以看到开头的FFFE了。这是个标识UTF-8编码文件的好办法,软件通过BOM来识别这个文件是否是UTF-8编码,很多软件还要求读入的文件必须带BOM。可是,还是有很多软件不能识别BOM。我在研究Firefox的时候就知道,在Firefox早期的版本里,扩展是不能有BOM的,不过Firefox 1.5以后的版本已经开始支持BOM了。现在又发现,PHP也不支持BOM。
PHP在设计时就没有考虑BOM的问题,也就是说他不会忽略UTF-8编码的文件开头BOM的那三个字符。由于必须在<?或者<?php后面的代码才会作为PHP代码执行,所以这三个字符将会直接输出。如果插件的文件有这个问题,将会导致在后台页面里激活或者不激活插件后显示白屏,如果是模版文件有这个问题,将会导致这三个字符直接输出,造成页面上方有一个小空行。国外的英文插件和模版一般都是用的ASCII码的编码方式,不会有BOM,只有国内的插件和模版会由于作者的不知情造成问题。还有,大家修改模版的时候,由于输出页面使用UTF-8编码,那么修改模版的时候如果有加入中文字符的话,必须把文件转成UTF-8编码才能正常显示,这个时候如果所使用的编辑器自动加上了BOM的话,将会造成在页面上输出这三个字符,显示效果就要看浏览器了,一般是一个空行或是一个乱码。
使用 utf-8 编码来编写网页的时候, 往往会因为 bom (Byte Order Mark) 的问题,导致网页中经常出现一些不明的空行或者乱码字符。 这些都是因为 utf-8 编码方式对于 bom 不是强制的。因此 utf-8 编码在保存文件的时候,会出现不同的处理方式。比如有的浏览器(FireFox)可以自动过滤掉所有 utf-8 bom , 有的 (IE) 只能过滤掉一次 bom (为什么是一次? 当你出现 Include 多次文件时就会碰上这个问题了)。
使用editplus或其他编辑器删除掉文件中的BOM签名,重新刷新页面,样式正常了。
在这里找到一段关于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来标记文本文件的编码方式的。
...
UTF-8编码的文件中,BOM占三个字节。如果用记事本把一个文本文件另存为UTF-8编码方式的话,用UE打开这个文件,切换到十六进制编辑状态就可以看到开头的FFFE了。这是个标识UTF-8编码文件的好办法,软件通过BOM来识别这个文件是否是UTF-8编码,很多软件还要求读入的文件必须带BOM。可是,还是有很多软件不能识别BOM。我在研究Firefox的时候就知道,在Firefox早期的版本里,扩展是不能有BOM的,不过Firefox 1.5以后的版本已经开始支持BOM了。现在又发现,PHP也不支持BOM。
PHP在设计时就没有考虑BOM的问题,也就是说他不会忽略UTF-8编码的文件开头BOM的那三个字符。由于必须在<?或者<?php后面的代码才会作为PHP代码执行,所以这三个字符将会直接输出。如果插件的文件有这个问题,将会导致在后台页面里激活或者不激活插件后显示白屏,如果是模版文件有这个问题,将会导致这三个字符直接输出,造成页面上方有一个小空行。国外的英文插件和模版一般都是用的ASCII码的编码方式,不会有BOM,只有国内的插件和模版会由于作者的不知情造成问题。还有,大家修改模版的时候,由于输出页面使用UTF-8编码,那么修改模版的时候如果有加入中文字符的话,必须把文件转成UTF-8编码才能正常显示,这个时候如果所使用的编辑器自动加上了BOM的话,将会造成在页面上输出这三个字符,显示效果就要看浏览器了,一般是一个空行或是一个乱码。
相关文章推荐
- UTF-8 BOM 可能导致样式错乱的解决方法
- UTF-8 BOM可能导致样式错乱的解决方法
- php中隐形字符65279(utf-8的BOM头)问题和fwrite写入文件bom头导致的乱码问题解决
- php中隐形字符65279(utf-8的BOM头)问题和fwrite写入文件bom头导致的乱码问题解决
- 关于jsp中bom头导致页面样式错乱(Safari)
- BOM的来源是不可能出现的字符,GB2312双字节高位都是1,Unicode理论的根本缺陷导致UTF8的诞生
- IE6不完全兼容UTF-8导致“ 銆€銆€ ”样式乱码
- UTF-8 BOM导致的无法正常模拟Http请求
- UltraEdit编辑文件编码为utf-8容易带有BOM导致的错误解决
- div间的小红点,可能是BOM头,利用ultraedit另存为UTF-8无BOM即可
- UTF-8 BOM导致验证码不显示
- 【less.js扫雷系列一】--less和CSS同时时使用时,可能出现的样式优先级变化导致样式覆盖问题
- 把gbk的编码按utf-8来解码,可能导致的不可恢复的错误
- 后台弹出消息框不会导致样式错乱的2种方法
- 递归删除utf8文件的bom头(该bom头可能导致php产生意外输出)
- 递归删除utf8文件的bom头(该bom头可能导致php产生意外输出)
- iOS导航控制器使用interactivePopGestureRecognizer导致导航栏标题可能层次错乱的问题解决
- 开发小坑--百度地图Marker和bootsharp样式冲突导致显示错乱
- 关于Android切换系统字体大小和字体样式导致App崩溃或者界面错乱的问题
- 浏览器缓存之Last-Modified导致第一次样式错乱