首页 >> 网站建设 >> 网站源码中的经典乱码“锘”字的解决办法

网站源码中的经典乱码“锘”字的解决办法

    最近发现好些客户的站,特别是英文站,居然都在GOOGLE里显示有中文,真的是蛮奇怪了点。然后就猛找原因,连标点符号都用英文输入状态重新做了。结果发现源码里还是没有中文,但是GOOGLE快照里的页面一查看源码,最开始开出现一个“锘” 字。呵呵,有问题就GOOGLE,品界科技继续查找原因及解决方法。
    这几天看了看 Ajax 的基础知识,在练习一个简单的 请求和响应时,PHP 返回来的数据 在 IE 中开头总显示 一个 “锘” 字!上网 Baidu 了一下,发现这是由于 系统 处理 UTF-8 的方法不同而导致的。
 php 返回的 UTF-8 数据 开头自动加了 标志,是对于 UTF-8的标识。对于 javascript 来说,不会在意这个标识,依然当作数据来读,所以就会出现 这个经典的 “锘”乱码。
 解决办法:把相关的文件源码复制到 Dreamweaver 里然后再保存就可以了。或者用Ultraedit“另存为”UTF8-无BOM格式。
 如果使用 windows 记事本 保存的 UTF-8 格式。使用UltraEdit编辑器,打开高级>配置>Unicode/utf-8 检测,把自动检测UTF-8文件,自动检测没有BOM的Unicode文件等前面的勾全去掉,然后你再打开那个文件,就会发觉“锘 ”这个字符出现了。

    Unicode规范中有一个BOM的概念。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来标记文本文件的编码方式的。
    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的功能失效。

123

最新文章

热门资讯

网站建设网站优化

客户案例

工具软件