一直以来都在研究mambo系统的设计，不过我用的是英文版，主要是看看它的系统体系，英文版的要精简一些的阿。今日准备用manbo将公司网站改版，下载并安装了mambo 4.5.2的黄金中文版，才发现后台居然是乱码，本着自己动手丰衣足食的理念，开始了漫长的Bug寻找之旅…………历经5个小时漫长的抓虫之旅，终大功告成。特发本人之处女贴以飨诸位曼友（本人一直在潜水，呵呵）。并将其中历程一并写出，作抛砖引玉尔。

测试环境：
本人喜新厌旧（非人方面），所用环境如下：
apache 2.0.53
php 5.0.3
mysql 5.0.4 Beta Nt
Window XP
Zend Studio

各项配置如下：
    Apache:
        AddDefaultCharset GB2312
    php5:
        extension=php_mbstring.dll
    mysql 5
        MySQL 字符集: UTF-8 Unicode (utf8)
        数据库整理: latin1-general-ci

论坛速度感觉很慢阿？很影响形象吗，Mambo是个好东东，但不如意的地方也不少啊。：）继续继续，呵。

安装：
    下载黄金版的mambo 4.5.2，正常安装。~~安装时居然也报错？是SQL建表语句错误：
SQL=Invalid default value for 'rating_sum':
- - - - - - - - - -
# Table structure for table `mos_content_rating`

CREATE TABLE `mos_content_rating` (
  `content_id` int(11) NOT NULL default '0',
  `rating_sum` int(11) unsigned NOT NULL default '',
  `rating_count` int(11) unsigned NOT NULL default '0',
  `lastip` varchar(50) NOT NULL default '',
  PRIMARY KEY  (`content_id`)
) TYPE=MyISAM
= = = = = = = = = =

    这个好办，很明显的问题吗，rating_sum` int(11)是整数型，怎么能富缺省值为空字符呢？找到安装表的SQL文件：mambo_dir/installation/sql/mambo.sql，把  `rating_sum` int(11) unsigned NOT NULL default '',的''改为0就行了。
更改完毕，重新安装，一切正常。Right,Let's Go.
这里将已盖好的文件上传，覆盖到mambo_dir/installation/sql下就行了

寻虫记 第一章 漫漫征途
安装完毕，直接进入后台，乍眼一看，一切正常。心中暗想，三年了，所有发票屡谢屡刮，莫非苍天开眼乎，按下购彩票心情不表，一路按去。
然奇迹未现，一路乱码纷现。唉，开始磨刀向臭虫也。
开始狂调apache语言设置，mysql字符集设置以及php的各种有关设置，甚至包括mbstring的函数替换选项等等各种组合，罢了，乱码依旧。
无奈，看来此Bug与系统配置无关也。命苦也命苦也，只得翻遍数万行代码中，数百文件。千怕万怕，就怕嫁错郎啊！无奈，追寻URL足迹一路寻去。先从解决Menu模块入手，administrator/index2.php  --〉administrator\components\com_menus\admin.menus.php--〉…………好多@#$@$，我找，我跟…………终于找到了臭虫发源地....XML文件。
大喜，午时，饭至。开饭了，且听下回分解。

寻虫记 第二章 我的征途是星辰大海
饭后，心想，本人一向以善为本，虽不曾彩票暴富，也不只独落阴沟把，于是搜本坛，Key='乱码'。果然纷纷攘攘，仁者见仁智者见智，英雄所见都差不多哩，其中多篇文章深有启发，然，最终确是需要重新编译php！这怎生得了，想我沁润php数月，也没干过这活啊，何况$%$#。
欲就此打住，却又于心不甘，上午已费两个时辰，岂能白白浪费？况且某某人曾经教导我们，万事皆有源也，通过改动源代码肯定能解决，妖还是妖他妈生得呢，还能找不到根乎。
而漫眼望去，源码似海，踌躇一阵，横下心来埋头苦看去也。
（吾深知赌博之害，未料今日也没能免俗，乌呼爱哉）[/i:7c1d9cc19a]

一下午时光飞逝，将XML存储文本编码从gb2312、gb18310、gbk到utf-8、unicode，又到windows-1251等十种编码方式及改变XML ENCODE数种方式循环测试，均告失败，除了其中出现几次乱码变?之外，未见成果，残念，彻底放弃简单方式，看来问题只能通过源代码入手，问题出在多字节的XML解析部分。一路根踪源码，良久………

寻虫记 第三章 曙光初现
一路源码跟去，直到Mambo使用的domit XML解析库。上网查阅，发现其有更新版本，Down&Recover，心中窃喜，如此岂不省事？然而事实再一次见证了投机倒把者的失败。继续源码研究中.............

埋头于domit，同时研究其所带文档，终于发现其核心解析代码中有一功能，可以使用php开源的解析器SAXY来代替系统内置的XML解析器函数，眼前一亮，最不济干脆手工更改源代码作多字节支持，嘿嘿，精神大振，上网搜索SAXY，又发现更新版本，继续窃喜，继续D&R，继续见证事实。

跟踪源码中..........终于，于mambo_dir/includes/mamboxml.php中发现其调用代码，尝试更改参数打开SAXY支持，而后再看管理后台，顿时幸福的成就感种满全身，所有参数栏完全正常，狂喜，但一路按去，发现只有参数栏恢复正常，而新建菜单和组件安装依然如故。无妨，尾巴都揪出来了，还摸不着瓜么，占占兴奋中，放松ing.....

其时已日落西山，携夫人会餐也。。。

寻虫记 第四章 大结局
至沸腾渔乡，被痛宰，两份小菜加一份炒米被要一百大洋，肉疼毕，刮票，如故。

至蜗居，继续。
改动数处，均无效，大怒，Find In All Files ,Key='xmlDoc->loadXML'搜出十几处，不尽愤怒，已经有了一个MamboXML的封装类，干嘛还有这么多地方直接调domit，真是#$%$^不言中。
想想要改十几处文件，不禁头发晕手发慌，如此苦力岂是我辈所为，一不做二不休，直接将domit文件中可选项改为必选项，将可选的'软'解析固定死，于是乎云开雾散，大放光明，所有选项均露出本色，大功告成也。：）

最终改动如下：
mambo\includes\domit\xml_domit_lite_parser.php
963行
原程序：
function parseXML($xmlText, $useSAXY = true, $preserveCDATA = true, $fireLoadEvent = false) {
在其后添加一行
$useSAXY =true;

仅此而已。

附件为改好的文件，遵文注使用

后记

终于告一段落，要说的是此种改法为懒惰人所为，而非正规方法也。
正常应搜索所有的parseXML()调用将$useSAXY 的调用参数改为一全局变量，放入配置文件，这样应能顾及兼容性与性能。

本人天性四体不勤，望有心人为之。
（其实这应该是Mambo开发小组干的事情，真是!@$#%无以言表）

收工！

赚钱好快啊，一不留神成百元户了，呵呵

作个记号，回来慢慢看　呵呵

非常精彩，堪称经典！

    

特奖励波币3000，以资鼓励！

老大真够慷慨的，就此谢过，呵呵。 :  :
一日之内由穷光蛋变成百元户，继而变为n千元户，真是嘴都合不上了啊 :    

非常感谢！

打补丁后rss仍然是乱码。

赞！

顶！顶得天昏地暗！！！
谢！谢得地久天长！！！

up

搞定后台乱码问题感谢！

常常会遇到的事情。

不过xml的转码用frontpage一次搞定即可，我在用的自己转的utf-8版没有象楼主这样折腾却能正常使用。楼主对于曼波文件本身不转码，应用新的模组时还是可能出现乱码——只是凭经验说，不知道实质。因为曼波文件转码前后大小都不一样，如不存在非英文字符ios-8859与utf-8编码文件大小应该一样。这就是隐患。Mambo.cn整站为utf-8编码，其它任何地方都不会出现乱码（SMF标题截取因为无法正确处理3字节而出现乱码，不属于现在讨论的问题），只有AKOcomment出现过，就是因为当时我为了省事没有对AKOcomment文件本身进行转码处理。用了好长一段时间后忍无可忍转了，乱码现象从此消失。去过我网站的朋友可能注意到过这一现象。

RSS乱码是因为黄金版没处理好feedcreator.class.php的编码。简单点就把这个文件里的什么utf-8什么iso-XXXXXXX统统改定gb2312（共同四处），改完之后应该就会正常（好久没弄了，加上我也没用过mambo4.5.2黄金版，不排除意外）。

有个问题，关于xml解析乱码，怎么我在虚拟主机上使用就没有此问题呢？难道是因为环境问题？

这都能写出文章...真牛的说
俺得加油了..不过真希望自己能看懂php的代码