一个典型的环境典型的环境以我自己的电脑上安装的 MySQL 4.1 为例，我自己的电脑上安装着 apache 2，PHP 5 和 WordPress 1.5.1.3，MySQL 配置文件中指定了 default_character_set 为 utf8。于是问题出现了：
WordPress 按照默认情况安装，所以所有的表都用 UTF-8 存储数据；
WordPress 默认采用的浏览字符集是 UTF-8 (Options->Reading 中设置)，因此所有 WP 页面的 meta 中会说明 charset 是 utf-8；
所以浏览器会以 utf-8 方式显示所有的 WP 页面；这样一来 Write 的所有 Post，和 Comment 都会以 UTF-8 格式从浏览器发送给 Apache，再由 Apache 交给 PHP；
所以 WP 从所有的表单中得到的数据都是 utf-8 编码的；WP 不加转换的直接把这些数据发送给 MySQL；
MySQL 默认设置的 character_set_client 和 character_set_connection 都是 latin1，此时怪异的事情发生了，实际上是 utf-8 格式的数据，被“当作 latin1”转换成……居然还是转换成 latin1，然后再由这个 latin1 转换成 utf-8，这么两次转换，有一部分 utf-8 的字符就丢失了，变成 ??，最后输出的时候 character_set_results 默认是 latin1，也就输出为奇怪的东西了。
最神奇的还不是这个，如果 WordPress 中设置以 GB2312 格式阅读，那么 WP 发送给 MySQL 的 GB2312 编码的数据，被“当作 latin1”转换后，存进数据库的是一种奇怪的格式 (真的是奇怪的格式，mysqldump 出来就能发现，无论当作 utf-8 还是当作 gb2312 来读都是乱码)，但如果这种格式以 latin1 输出出来，居然又能变回 GB2312！
这会导致什么现象呢？WP 如果使用 MySQL 4.1 数据库，把编码改用 GB2312 就正常了，可惜，这种正常只是貌似正常。
如何解决问题如果你已经不耐烦了 (几乎是肯定的)，google 一下，会发现绝大部分的解答是，query 之前先执行一下：SET NAMES 'utf8'，没错，这是解决方案，但本文的目的是说明，这为什么是解决方案。
要保证结果正确，必须保证数据表采用的格式是正确的，也就是说，至少能够存放所有的汉字，那么只有两种选择，gbk 或者 utf-8，下面讨论 utf-8 的情况。
因为配置文件设置的 default_character_set 是 utf8，数据表默认采用的就是 utf-8 建立的。这也应该是所有采用 MySQL 4.1 的主机提供商应该采用的配置。所以要保证的只是客户端与 MySQL 交互之间指定编码的正确。
这只有两种可能，客户端以 gb2312 格式发送数据，或者以 utf-8 格式发送数据。
如果以 gb2312 格式发送:
都是可以的，都能够保证数据在编码转换中不出现丢失，也就是保证存储入数据库的是正确的内容。
怎么保证取出的是正确的内容呢？考虑到绝大部分客户端 (包括 WP)，发送数据的编码也就是它所希望收到数据的编码，所以:
可以保证取出给浏览器显示的格式就是 gb2312。
如果是第二种情况，客户端以 utf-8 格式发送 (WP 的默认情况)，可以采用下述配置:
WP 应该作什么修改还是那句话，客户端要发给数据库什么编码的数据，数据库是不可能确切知道的，只能让客户端自己说明白，所以，WP 是必须发送正确的 SET... 给 MySQL 的。怎么发送最合适呢？台湾的 pLog 同仁给出了一些建议：
首先，测试服务器是否 >= 4.1，编译时是否加入了 UTF-8 支持；是则继续
然后测试数据库以什么格式存储 ($dbEncoding)；
对于第二点，WP 的情况是不同的，按照上面的典型配置，只要用 WP，肯定数据库是用 UTF-8 存储的，所以要根据用户设置的以 GB2312 还是 UTF-8 浏览来判断 (bloginfo('charset'))，但这个值是要连接数据库以后才能得到的，所以效率最高的方式是连接数据库之后，根据这个配置设置一次 SET NAMES，而不必每次查询之前都设置一遍。
我的修改方式是这样的，在 wp_includes/wp-db.php 中增加:
1. MySQL 4.1 在文字上有很大改进，它有了 Character Set 与 Collation 的慨念。
2. 在 MySQL 4.0 ，一般的程式都会将文字以拉丁文 ( latin) 来储存，就算输入中文字，结果仍是放在以拉丁文设置的文字栏里头，这对 MySQL 4.0 与以 MySQL 4.0 为基楚的程式来说，并不会有问题。
3. 可是 MySQL 4.1 的系统编码是预设用 UTF-8 的，当要 restore MySQL 4.0 的 backup 档到 MySQL 4.1 时，乱码就出现了。原因在于 MySQL 4.1 将 latin 码转换过来，而后转换是并不完全完美的，这导致了出现少量文字出现乱码现象。
4. 要解决这乱码问题并不难。首先，在 MySQL 4.0 备份时，先将所有文字栏变成 binary 类型，然后进行正常备份。第二步，可在 MySQL 4.1 里将刚才的备份 restore。最后，将较早前所变更到 binay 类型的文字栏，再次复原到文字类型。这样中文编码的问题就应该可以完全解决。
5. 将文字栏变更到 binay 类型时，必需设定 binary 栏的长度大过或等于 (>=) 文字栏的长度，否则资料会失去。
6. 另外，经这样升级的 MySQL 数据库，在 MySQL 4.1 里将会正常工作，就算是怎样 backup 与 restore 都不会再有乱码问题。
作者: MySQL 发布日期: 2005-12-14
mysql4.1是比较烦人，支持多语言的细化设置，再加上phpmyadmin2.6也比较笨，默认就是改不动的utf8，怎么弄都乱码。
好了，废话少说，来一步步解决这个问题：
1.修改/etc/my.cnf文件，改成这样：
注意：就是加入了一句default-character-set=utf8。
2./etc/init.d/mysqld restart 重新启动mysql；
3.打开phpmyadmin，选择lang为"Chines simplifies(zh-utf-8)",选择"MySQL 连接校对"为"utf8_general_ci "点“显示 MySQL 的运行信息”--“变量”，可以看到：
从这里可以看到character全部变成utf8了。