好友的BLOG http://techpad.net在IE下查看源代码时，中文显示全部为乱码。本以为是最近安装插件后导致的问题，但禁用所有的插件后问题依旧不能够解决。接下来解决问题过程中发现了很多有意思的东西，用Editplus把theme中相关php文件全部另存为UTF-8格式，上传后问题依旧。接着再次下载检查文件，发现编码又变回ANSI，检查上传文件发现Editplus根本就没有保存为UTF-8格式，由此得出结论，Editplus并非想象中那么可靠，过分信任某东西的后果是严重的。

网上下载了一个批量编码转换的小程序，使用后编码全部转换为UTF-8，但网页变得很不正常，表现为页面顶部增加一行空白，用备份的文件替换转换后的header.php,single.php后一切恢复。问题原因大概是批量转换工具将php文件中的空白字符变为一种浏览器可误读的字符，产生空白。

此次修改问题：IE下网页正常，源代码乱码

问题原因：风格php文件与网页编码不同

解决：将风格中php文件另存为UTF-8格式

获得经验：1.Google对于网页编码兼容性标准性强于百度


2.Editplus在另存文件选择格式处存在问题，有时不能按所选格式保存


3.批量转换编码的工具慎用，用前必须备份文件

=============问题深入

继续修改发现此问题的关键因素是UTF-8 BOM，对于WordPress，其中模板文件夹下function.php文件是关键，将此文件保存为带BOM的UTF-8文件，则用IE（更准确说是用notepad）查看文件源代码时可以正常显示；如果保存为不带BOM的UTF-8，IE（notepad）可以正常显示，而WordPress后台无法正常登录，Windows Live Write也无法连接。

此问题根本原因是PHP不支持BOM，同时NOTEPAD无法识别无BOM的UTF-8。

关于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的话，将会造成在页面上输出这三个字符，显示效果就要看浏览器了，一般是一个空行或是一个乱码。

继续阅读 »