WordPress 与 UTF-8 的 BOM 问题

简介:

我们都知道,在 WordPress 中编辑模板或改动相应的函数文件时,如果使用了中文字符,那么保存时应选择“UTF-8”格式。
    不过,笔者之前使用 UltraEdit 编辑时总出问题,上传改动后的函数或插件文件后屡屡发现很多基于 COOKIE 或 SESSION 的功能变得不正常,甚至不能进入管理面板。

  自己找到的笨办法便是使用 WordPress 自带的编辑器,虽然麻烦了些,但总算能够趋于正常。

  近日在网上搜索到一篇文章,对这个情况如何解决解释得很详细:

    简单地说,这类问题的原因在于,在将文件保存为 UTF-8 格式时,编辑器默认在文件开始位置添加了二个字节的 BOM(Byte Order Mark),内容为“FFFE”,但 PHP 设计之初并没有考虑 BOM,因此,便会将文件开头这三个 BOM 字符直接输出。这是造成上述问题的根本原因。
    解决方法也很简单,即在使用 UltraEdit 保存 UTF-8 格式文件时,选择“UTF-8 no BOM”,而不是单纯的“UTF-8”。

    ——————————————————-
    WordPress 主题编码导致页面正常,而源文件是乱码

    我的 Blog 是用 WordPress 实现的。前几天发现,在打开文章,使用 IE 或 Firefox 查看源文件时,里面的中文全部成了乱码,以为是 UTW 引起的。换上了新主题 My Simplism,禁用了 UTW,启用 Simple Tags,问题依旧。后来搜索了一圈,找到 WordPress 中文论坛上的一个帖子。

    原来,页面正常而源文件乱码的根源出自主题的字符编码集。原版的编码集用的是 ANSI,我修改之后,添加了中文,于是发生了该现象。

    解决方法也简单,按该帖子所述,找个文本编辑器,将主题的 php 文件另存为 UTF-8 编码即可。这样的文本编辑器太多了,我自己常用的就有Edit Plus、UltraeEdit、EmEditor、Notepad++ 等等。推荐 EmEditor,因为可以直接在“另存为”对话框中控制是否添加 BOM。

    原帖子:

    重新用16进制编辑器把主题文件存成UTF-8不带签名(BOM)的格式:不用复制-粘贴,就用编辑器打开,然后另存一次,覆盖原来的就可以了。

    ——————————————————-
    网眼还发现一个比较简便的办法:

    虽然在中文Windows下,浏览器打开“源文件”,看到的是乱码(用记事本打开的),但是保存一下(用 ANSI 编码),再用 UltraEdit 打开保存的文件,看到的就是正常的文字,汉字也正常。










本文转自网眼51CTO博客,原文链接:http://blog.51cto.com/itwatch/286449,如需转载请自行联系原作者

相关文章
|
Java Android开发
eclipse中默认编码设置为UTF-8
eclipse中默认编码设置为UTF-8
119 0
|
JavaScript 前端开发 Go
BOM 总结介绍
BOM 总结介绍
156 0
BOM 总结介绍
|
Web App开发
Chrome 技巧篇-浏览器网页设置编码,解决网页乱码问题,最新版charset插件获取,UTF-8编码设置
Chrome 技巧篇-浏览器网页设置编码,解决网页乱码问题,最新版charset插件获取,UTF-8编码设置
864 0
Chrome 技巧篇-浏览器网页设置编码,解决网页乱码问题,最新版charset插件获取,UTF-8编码设置
|
JavaScript C++
VS2017使用utf-8+BOM的编码格式
VS2017使用utf-8+BOM的编码格式
389 0
VS2017使用utf-8+BOM的编码格式
|
JavaScript C# Windows
C#保存文件为无BOM的utf8格式
如图所示,发现用C#的 File.WriteAllLines 方法,无论怎么设置,最终生成的文件都是 PC utf8,也就是CRLF,用SVN进行提交的时候,显示左侧为utf8,右侧为utf8 BOM文件,甚是蛋疼。
2153 0
|
Web App开发
|
Java Android开发 数据格式