转载时请标明文章原始出处和作者信息, 作者: lostsnow.
http://www.lsproc.com/blog/mysql_encode_error_in_wordpress/

在MySQL4.1下，中文的WP就会产生种种的乱码问题。

一个程序（ PHP，CGI 等）与MySQL建立连接后，这个程序发送给MySQL的数据采用的是什么字符集，MySQL 是无从得知的。所以解决乱码问题的根本就是我们在程序中告诉MySQL采用的编码是什么，简单的就是在程序中加入这样的一个语句：

SET NAMES 'utf8';

这个语句的效果等同于同时设定了

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

为什么这么做？

我们安装MySQL4.1时按照默认配置，那么default-character-set= utf8。在MySQL Command Line Client下查看到的查看系统的字符集和排序方式的设定为：

Continue reading →

-- EOF --

转载时请标明文章原始出处和作者信息, 作者: lostsnow.
http://www.lsproc.com/blog/mysql-encode-wordpress/

下面要写的是一篇非常无聊的东西，充斥了大量各式各样的编码、转换、客户端、服务器端、连接……呃，我自己都不愿意去看它，但想一想，写下来还是有点意义的，原因有四：

1. MySQL 4.1 对多语言的支持有了很大变化 (这导致了问题的出现)；
2. 尽管大部分的地方 (包括个人使用和主机提供商)，MySQL 3 仍然占主导地位；但 MySQL 4.1 是 MySQL 官方推荐的数据库，已经有主机提供商开始提供并将会越来越多；
3. 许多 PHP 程序以 MySQL 作为默认的数据库管理软件，但它们一般不区分 MySQL 4.1 与 4.1 以下版本的区别，笼统地称“MySQL 3.xx.xx 以上版本”就满足安装需求了；
4. 因为 latin1 在许多地方 (下边会详细描述具体是哪些地方) 作为默认的字符集，成功的蒙蔽了许多 PHP 程序的开发者和用户，掩盖了在中文等语言环境下会出现的问题；

简单的说，MySQL 自身的变化和使用 MySQL 的 PHP 程序对此忽略，导致了问题的出现和复杂化，而由于大部分用户使用的是英文，使这种问题不被重视。这里提到的 PHP 程序，主要就 WordPress 而言。
MySQL 4.1 字符集支持的原理

MySQL 4.1 对于字符集的指定可以细化到一台机器上安装的 MySQL，其中的一个数据库，其中的一张表，其中的一栏，应该用什么字符集。但是，传统的 Web 程序在创建数据库和数据表时并没有使用那么复杂的配置，它们用的是默认的配置，那么，默认的配置从何而来呢？

1. 编译 MySQL 时，指定了一个默认的字符集，这个字符集是 latin1；
2. 安装 MySQL 时，可以在配置文件 (my.ini) 中指定一个默认的的字符集，如果没指定，这个值继承自编译时指定的；
3. 启动 mysqld 时，可以在命令行参数中指定一个默认的的字符集，如果没指定，这个值继承自配置文件中的；
4. 此时 character_set_server 被设定为这个默认的字符集；
5. 当创建一个新的数据库时，除非明确指定，这个数据库的字符集被缺省设定为 character_set_server；
6. 当选定了一个数据库时，character_set_database 被设定为这个数据库默认的字符集；
7. 在这个数据库里创建一张表时，表默认的字符集被设定为 character_set_database，也就是这个数据库默认的字符集；
8. 当在表内设置一栏时，除非明确指定，否则此栏缺省的字符集就是表默认的字符集；
9. 这个字符集就是数据库中实际存储数据采用的字符集，mysqldump 出来的内容就是这个字符集下的；

简单的总结一下，如果什么地方都不修改，那么所有的数据库的所有表的所有栏位的都用 latin1 存储，不过我们如果安装 MySQL，一般都会选择多语言支持，也就是说，安装程序会自动在配置文件中把 default_character_set 设置为 UTF-8，这保证了缺省情况下，所有的数据库的所有表的所有栏位的都用 UTF-8 存储。

Continue reading →

-- EOF --