业务形式:本司专业提供深圳外贸网站建设,外贸网站建设,深圳网站建设,ZenCart模板
环球商务国际 版权所有 ©2005-2014 35EBS.All rights reserved.
粤ICP备05007577号
Processed in 0.015171 second(s) , 38 queries
前面说过因为 程序页面页头声明编码与当前文件编码不一至导致的乱码解决方法
也提到过因为程序声明编码与 数据库
编码不一至导致的乱码解决方法
这里再说说最后这两种情况导致的 Zen Cart 乱码,
如果说 前面两篇文章 是因为技术性原因造成的乱码
哪么这里提到的两种原因
基本就属于是 典型的 操作粗心大意而导致的乱码
第一种情况 当在编辑处理UTF8 编码 的 PHP 文档时 在保存的时候
当前使用的编辑器默认配置的是保存包含 BOM
信息的UTF8 文档
因此而造成乱码
对于因这种原因造成的乱码 只需要重新打开这个文件 再另存为 同名文件覆盖
在保存的时候 在下面的编码选择框中 选择 保存为不包含
BOM信息的UTF8 文档 即可
这种操作方法 如果只是个别文件 相对数量较少时 可以采用
如果是全站成千上万个文件, 而又不确定具体哪个文件被自己保存为 包含BOM 信息的UTF8文档时,
哪么 下面提供的小工具 就派上用场了
展开下列代码框 将其内代码复制保存或 点击 Code.php下载到本地
上传到当前网站程序下 任意路径下
然后通过 浏览器 直接访问本文件
即可快速批量清除全站包含BOM信息的UTF8文档
从而解决乱码问题
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 |
<?php /** * * @ 使用方法: * @ 重命名本文件 文件名中不要包含有中文和特殊字符 * @ 把命名后的文件上传到网站程序安装的根目录下 * @ 浏览器 地址栏输入 http://你的域名/文件名.php * * @ 功用: * @ 清除全站UTF8编码格式的PHP文件中的 BOM信息 以免出现乱码问题 * * @ By KIRA * @ QQ: 6171718 * @ Email: kira@kpa7.net * @ http://zcbk.org/ * */ ?> <?php //remove the utf-8 boms //by magicbug at gmail dot com if (isset($_GET['dir'])){ //config the basedir $basedir=$_GET['dir']; }else{ $basedir = '.'; } $auto = 1; checkdir($basedir); function checkdir($basedir){ if ($dh = opendir($basedir)) { while (($file = readdir($dh)) !== false) { if ($file != '.' && $file != '..'){ if (!is_dir($basedir."/".$file)) { echo "filename: $basedir/$file "; echo checkBOM("$basedir/$file")." <br>"; }else{ $dirname = $basedir."/".$file; checkdir($dirname); } } } closedir($dh); } } function checkBOM ($filename) { global $auto; $contents = file_get_contents($filename); $charset[1] = substr($contents, 0, 1); $charset[2] = substr($contents, 1, 1); $charset[3] = substr($contents, 2, 1); if (ord($charset[1]) == 239 && ord($charset[2]) == 187 && ord($charset[3]) == 191) { if ($auto == 1) { $rest = substr($contents, 3); rewrite ($filename, $rest); return ("<font color=red>BOM found, automatically removed.</font>"); } else { return ("<font color=red>BOM found.</font>"); } } else return ("BOM Not Found."); } function rewrite ($filename, $data) { $filenum = fopen($filename, "w"); flock($filenum, LOCK_EX); fwrite($filenum, $data); fclose($filenum); } ?> |
第二种情况 也是典型的粗心大意造成的乱码
比如 本来是 当前网站程序声明的编码为 ISO 8859-1 而自己在编辑修改文档时 画蛇添足 特意保存为
UTF8编码文档
或者 本来声明是 UTF8编码 结果在编辑修改文件时 看都不看 直接保存成编辑器默认的 ANSI
对于因为这类粗心大意造成的乱码
只需要重新将文件 保存为对应的编码文档 即可
如果自己不记得了 哪么可以去网上找个批量转码工具来将整个程序文件批量重新转码 来解决
这里 给个
转码小工具的 传送门
http://www.onlinedown.net/soft/46844.htm
顺带再提一个 可能出现的 不太严重的乱码现像
即使用了 PHP输出字符截断功能 时 最后一个字符 变成小方块或小黑点儿
等乱码,
目前在英文数字字符上 貌似还没听说过 但在 汉字字符截断处理上 可能就会碰上这种问题,
解决方法我个人的建议就是截断数值尽量设置为 偶数
还有无其他更完美的方法, 还有待进一步的收集整理
基本上 目前 造成 Zen Cart 乱码的各种原因总结就到此为止了
本来打算一篇文章说完的事儿 结果浪费了三篇篇幅才码完!
最后, 来作个总结吧
想要 Zen Cart 不乱码 记住两个一定 和一个注意 一个不要
两个一定为
一定要保持页面页头声明编码与程序文件和输出内容编码的一至性或声明编码与文件内容编码相兼容
一定要保持程序的配置 声明编码 与 数据库 编码的 一至性 或 与数据库编码相兼容
注意 保存文件时的默认编码
切记不要用记事本来编辑处理UTF8编码的PHP文档 哪怕是简单的打开与关闭
小常识传送门:
什么是 BOM:
http://zh.wikipedia.org/wiki/%E4%BD%8D%E5%85%83%E7%B5%84%E9%A0%86%E5%BA%8F%E8%A8%98%E8%99%9F
再啰嗦一次:
为什么不能使用 Windows 系统下的记事本 来编辑处理 UTF8 编码 的 PHP文档
我们都知道,计算机使用编码系统来表示不同的字符集。比如最为基本的 ASCII 编码,共包括127个常用字符,可用于处理英语以及其他西欧语言。我们国家则采用
gb2312, gbk, 以及后来 gb18030 等编码系统来处理汉字。其他国家也都分别制定了相应的编码系统,来表示他们自己的文字。所有的这些编码系统,统称为
ANSI 编码。也就是说,在简体中文系统下,ANSI 编码代表简体中文 gb2312 编码;在日本操作系统下,ANSI 编码则代表其常用的编码。
这样,各个国家使用不同的文字,也就有不同的编码系统,不便交流弊病就诞生了。假如你在国内使用 gb2312 编码的系统,发了一封情意绵绵的 email
发给了远在美国留学的女友,如果她所使用的电脑没有 gb2312 编码系统的话,她所看到的将只是一篇乱码。
因此,为了解决全世界各种语言的编码问题,人们提出了 UNICODE 编码,支持全世界 650
多种语言。这样,全世界的计算机上都将安装上这一套编码系统,可以方便地支持不同语言进行书面交流。UTF 8 编码是 UNICODE 编码的一个分支;除了 UTF8
之外,UNICODE 还有 UTF 16, UTF 32 等各种不同的编码方式。
UTF 8 编码比较简单,因为它是用单字节作为编码单元;但是对于 UTF 16 和 UTF 32
而言,则分别使用双字节和四字节作为编码单元,这就涉及到一个编码顺序的问题。例如收到一个“奎”的Unicode编码是594E,“乙”的Unicode编码是4E59。那么对于
UTF 16 编码系统而言,4E59 究竟是“奎”还是“乙”?这就需要 BOM (Byte Order Mark)来标记字节顺序。
对于 UTF 8 而言,它只有一个字节,显然不必要使用 BOM 来标记字节顺序。但是 BOM 可以用来表明,这是一个 UTF 8
编码的文件。Windows 系统的记事本就喜欢在 UTF 8 文件里面添加一个 BOM 标记。但是,对于包括记事本在内的绝大多数编辑器而言,不管你是 UTF8
with BOM 还是 UTF8 no BOM 编码,都可以正常打开。
看起来晴空万里,但远处却飘来一朵乌云。如果所有的事情都像上面这样一帆风顺的话,那么也就没有必要絮絮叨叨说这么多了。问题的关键在于,WordPress
所使用的动态语言,PHP,在设计的时候没有考虑 UTF8 编码的问题。因此如果是 UTF 8 no BOM 的文件,它可以正常识别;但是如果遇到一个 UTF 8
with BOM 的文件,也就无法识别在文件开头的 BOM 标志。
日常应用中, 当我们将一个文件 保存成了 UTF8 no BOM 格式, 这种格式本身并没有任何问题。但问题在于,大部分网友使用的编辑器,可能都是
Windows 操作系统所自带的记事本程序(Notepad.exe),而这个程序所支持的编码格式只有 ANSI, UTF8, Unicode 和 Unicode
big endian 四种。因此,当用户修改为 youfile.php 文件,另存为 youfile.php 文件的时候,原本的 UTF8 no BOM
格式,就是自动保存为 UTF8 ( with BOM )格式。记事本给文件自动添加 BOM (字节顺序标志),因此 youfile.php 第一行就多出了一个
php 无法识别的标志,因此也就带来了上述的困扰。也就是这些莫名的问题根源所在, 所以, 对于UTF8编码格式的PHP文件, 不要用记事本去编辑他,
哪怕是简单的打开再关闭 !!!