张微波的BLOG

MySQL为解决并控制不同层次的不同字符编码问题，在4.1 以上版本对字符集的支持细化到四个层次：服务器(server)、数据库(database) 、数据表(table)和连接(connection) 。MySQL通过以下三个方面来控制各个层次的字符编码：MySQL 字符集(Character set)、MySQL连接校对 (Collation，整理)以及站点编码。

编译 MySQL 时，指定了一个默认的字符集，这个字符集是 latin1；

安装 MySQL 时，可以在配置文件 (my.ini) 中指定一个默认的字符集，如果没指定，这个值继承自编译时指定的；

启动 mysqld 时，可以在命令行参数中指定一个默认的字符集，如果没指定，这个值继承自配置文件中的；此时 character_set_server 被设定为这个默认的字符集；

当创建一个新的数据库时，除非明确指定，这个数据库的字符集被缺省设定为 character_set_server ；

当选定了一个数据库时，character_set_database 被设定为这个数据库默认的字符集；

在这个数据库里创建一张表时，表默认的字符集被设定为 character_set_database ，也就是这个数据库默认的字符集；

当在表内设置一栏时，除非明确指定，否则此栏缺省的字符集就是表默认的字符集；

这个字符集就是数据库中实际存储数据采用的字符集，mysqldump 出来的内容就是这个字符集下的；

简单的总结一下，如果什么地方都不修改，那么所有的数据库的所有表的所有栏位的都用 latin1 存储。

当一个程序与 MySQL 建立连接后，这个程序发送给 MySQL 的数据采用的是什么字符集？MySQL 无从得知 (它最多只能猜测)，所以 MySQL 4.1 要求客户端必须指定这个字符集，也就是 character_set_client， MySQL 的怪异之处在于，得到的这个字符集并不立即转换为存储在数据库中的那个字符集，而是先转换为 character_set_connection 变量指定的一个字符集；这个 connection 层究竟有什么用我不大明白，但转换为 character_set_connection 的这个字符集之后，还要转换为数据库默认的字符集，也就是说要经过两次转换；当这个数据被输出时，又要由数据库默认的字符集转换为 character_set_results 指定的字符集。

http://isdq.com/image/1.jpg

在PhpMyAdmin看到的 MT数据库的编码变量。

会话值

全局值

character set client

utf8

latin1

character set connection

utf8

latin1

character set database

latin1

latin1

character set results

utf8

latin1

character set server

latin1

latin1

character set system

utf8

latin1

collation connection

utf8_general_ci

latin1_swedish_ci

collation database

latin1_swedish_ci

latin1_swedish_ci

collation server

latin1_swedish_ci

latin1_swedish_ci

MT 默认采用的浏览字符集是 UTF-8 ，所以 MT 从所有的表单中得到的数据都是 utf-8 编码的，都不加转换的直接把这些数据发送给 MySQL（ MT 的 character set client 和 character set connection 都是 utf8）。

但由上表所示，MySQL 默认设置的 character_set_client 和 character_set_connection 都是 latin1，此时怪异的事情发生了，实际上是 utf-8 格式的数据，被"当作 latin1"转换成……居然还是转换成 latin1，然后还要转换成 latin1 （ character set database ）存入数据库，最后按照 latin1 的编码进行储存。（实际的存储数据，character set results）

但这几次转换 （主要是把 utf8 当作latin1转换成 latin1的过程）就造成了乱码。（利用Mysql CC和 phpmyadmin等可以看到是乱码，mysqldump 出来无论当作 utf-8 还是当作 latiin1 来读也都是乱码）。但是这种格式最后按照 character_set_results 默认是 utf8输出的时候，居然又能变回 utf8，而且也不是乱码了。也就是 MT 用 utf8 显示为正常的原因。(这个和 WP 采用 GB2312 编码时的情况差不多。）

在WP中，解决方案是，query 之前先执行一下：SET NAMES 'utf8'。

要保证结果正确，必须保证数据表采用的格式是正确的，也就是说，至少能够存放所有的汉字。

因为配置文件设置的 default_character_set 是 utf8，数据表默认采用的就是 utf-8 建立的。这也应该是所有采用 MySQL 4.1 的主机提供商应该采用的配置。所以我们要保证的只是客户端与 MySQL 交互之间指定编码的正确。

客户端以 utf-8 格式发送 (WP 的默认情况)，可以采用下述配置:

SET character_set_client='utf8'
SET character_set_connection='utf8'
SET character_set_results='utf8'

这个配置就等价于 SET NAMES 'utf8'。

所以对 WP 修改方式是这样的，在 wp_includes/wp- db.php 中增加:

function set_charset($charset)
{
// check mysql version first.
$serverVersion = mysql_get_server_info($this->dbh);
$version = explode('.', $serverVersion);
if ($version[0] dbh);
if (mysql_num_rows($result) dbh);
}

在 wp-settings.php 的 require (ABSPATH . WPINC . '/vars.php'); 后增加:

$wpdb->set_charset(get_bloginfo('charset'));

但是我的问题是，对 MT 系统来说，相同原理的方案应该是修改那里的设置或者代码呢？？？

--
Joey Shi
http://iSdq.com

看来我还没遇到你的问题，你对编码的研究显然比我要深入多，不过谢谢你的文章，看来我也得注意一下，目前我的mysql还是3.xx不知道是不是也有这样的问题，由于我一般不轻易升级数据库，暂时还不清楚你的问题。
密切关注这个问题，这个问题确实挺严重的

3.xx的mysql还没有这个问题
n多人也是升级到4.1x后产生了乱码问题
似乎根本不可能在mysql下配置好SET NAMES 'utf8'
难道只能在程序下操作么？
php的WP知道了
但是对于MT，实在不知道怎么修改啊～～～