我的论坛更换服务器.论坛进行转移.顺便进行了升级.因为服务器用的mysql是4.1(原来安家空间是4.0),而4.1在编译 mysql 时,指定了一个默认的字符集,这个字符集是 utf8;就是这个utf8,因为不是很熟悉mysql,所以在升级的时候给我带来了相当大的麻烦.前后删除重建数据表不下20次. 在这里把我的一些经验之谈写出来,如果你也遇到我同样的情况,就可以少走一些弯路.
mysql4.0–>mysql4.1(默认字符集 utf8) discuz4.0–>discuz4.1
1.首先是论坛转移.
(1)先看看你的论坛的默认字符集是什么.进入你的phpmyadmin,里面有 mysql 连接校对 边上有一个下拉,点最上面的整理,页面会刷新,看看出来的是字符.如果是 utf8_swedish_ci ,说明默认的字符校对就是latin1了,你的情况就和我一样了.如果出来的是gbk_chinese_ci;那么你可以跳过此文.一知道了字符集的类型,就可以开始转移论坛了.
(2)首先新建一个discuz4.0,这时我们可以看到正常的文件.但是将备份的数据库导入后,会发现出来的全部是乱码,满篇都是??? 问题出在那里? 因为新建的discuz用的是 gbk_chinese_ci来和数据库进行连接校对的.新建的数据表的编码也是gbk_chinese_ci. 我们将备份数据导 ,因为备份数据是mysql4.0的,并没有连接校对字符集,所以mysql4.1会自动为倒入的备份数据添加一个默认的字符集,这个字符集是 utf8.如此一来,矛盾就出现了. 前台的编码访问模式是gbk_chinese_ci,而后台的编码模式却是utf8_swedish_ci.就像访问网页时,用utf-8去访问gb2312一样,自然而然的出现了错误.
解决方案:很明显,就是让前台用正确的编码访问模式去访问后台的编码.后台默认的编码是utf8_swedish_ci 我们让前台用utf8_swedish_ci 去访问就是了.打开文件include/db_mysql_class.php,大约在31~34行,有这样的一段代码.
if($this->version() > ‘4.1′ && in_array(strtolower($globals['charset']), array(’gbk’, ‘big5′, ‘utf-8′))) {
//attention: remove the following line if you want to use the default database character set.
mysql_query(”set names ‘”.str_replace(’-’, ”, $globals['charset']).”‘”);
}
在”mysql_query(”set names ‘”.str_replace(’-’, ”, $globals['charset']).”‘”);”它的意思是让程序用dz定义的字符集去访问mysql(gbk_chinese_ci),在前面加上””//”将这一行注释掉.程序就会用mysql的默认字符集(utf8_swedish_ci)去访问mysql里面的数据.保存好文件,在后台更新缓存和统计. wowo~ 页面显示正常了. [...]