搬移虚拟主机的过程中，在 MySQL 4.1.12 上出了严重的编码问题，导致所有中
文数据在数据库中均不正常。直到今天重新设定数据库的编码，然后在
Discuz（大概是 2.5 版）中加入一行代码，才得以正常显示。
论坛的数据导出成 SQL 了，在 phpMyAdmin 里导入到数据库。有点麻烦的是，整
个 SQL 有接近 1.5M，一次执行有问题，于是分成若干份一个一个导入。导入完
成后，各个表的条数是对的。但进论坛一看，却全是乱码，英文字母还正常，汉
字就全显示成问号了。试着在 Discuz 里输入中文，在 Discuz 显示正常，但在
数据库里却显示成四个拉丁形式的字符。
上网查资料，又下载新版的 phpMyAdmin 2.9.0.2，再试了都不行。
（phpMyAdmin 在执行某些 SQL 的时候有 bug）在老兵团里讨论过后，总算知道
大概可行的办法就是在创建表的时候指定字符集。今天把所有的表都删了，然后
在 SQL 里的每条 CREATE TABLE 后面都加上字符集的指定：DEFAULT CHARACTER
SET utf8 COLLATE utf8_general_ci，这样创建的表都是用 utf-8 表示的了。
再次导入所有数据后，在 phpMyAdmin 里显示的汉字终于正常了。但是在
Discuz 里显示的还是问号。崩溃。不得以，重新删除所有表，再设置字符集为
gbk 以及 gbk_chinese_ci，然而 Discuz 还是不能正常显示。
（注：可用 SHOW CHARACTER SET; 查看 MySQL 支持的字符集。MySQL 除了字符
集，还有一种 collation。collation 用于字符串的比较。）
中间又做了一些修改，如
ALTER DATABASE forum DEFAULT CHARACTER SET gbk
DEFAULT COLLATE gbk_chinese_ci;
来修改数据库的特性。然而还是没有效果。但是此时的问题显然更可以出在
Discuz 那端，因为在 phpMyAdmin 里，数据一切正常。
在 Discuz 的源代码里查找有关 charset 的代码，结果没有发现有用的。不过在
网上查到说是在 /include/db_mysql.php 里修改的，但我对照源代码却没有发现。
在试了 config.php 里那个强制编码的变量后，也没有效果。
无赖之下，下载了一个 Discuz 4.1，上传上去根本对不上号，数据库结构完全不
对。不过耍了个小聪明，想是否可以用 Discuz 4.1 的文件替换掉一小部分呢？
于是比较新旧的 db_mysql.php（4.1 里是 db_mysql.class.php）的内容，发现
4.1 版的在连接数据库的时候，针对 MySQL 4.1 以上的版本多了一个 SET
NAMES 语句的调用。正好这个 SET NAMES 是设置有关字符集的命令。于是
把这句修改一下，在旧文件对应位置加入 mysql_query("SET NAMES 'gbk'");。
上传之后，发现一切正常了！哭啊！
与 SET NAMES 相关的内容可在 MySQL 5.1 的中文在线帮助里看到，
http://dev.mysql.com/doc/refman/5.1/zh/charset.html。主要是这个命令是
一次性的，所以要在连接之后马上调用。
function connect($dbhost, $dbuser, $dbpw, $dbname, $pconnect = 0) {
if($pconnect) {
if(!@mysql_pconnect($dbhost, $dbuser, $dbpw)) {
$this->halt('Can not connect to MySQL server');
}
} else {
if(!@mysql_connect($dbhost, $dbuser, $dbpw)) {
$this->halt('Can not connect to MySQL server');
}
}
mysql_query("SET NAMES 'gbk'"); # <=== 这里加入
mysql_select_db($dbname);
}
终于可以灌水了。
主要是 MySQL 默认是 UTF-8 编码，但却有部分设置为 latin1，结果默认的不正
常。Discuz 也太老，不支持设定字符集。
阅读(2879) | 评论(3) | 转发(0) |
