MySQL对字符集的支持及对乱码出现原因【转】

MySQL 4.1后对字符集支持的高度灵活性着实给包括我在内的许多人带来了不小的麻烦。百度和Google中搜索MySQL 乱码结果都在20万页以上。。。显然，其灵活性的代价就是复杂性。

关于字符集需要明确以下几点：
一种字符集（character set或charset ）对应若干种字符集校正（character set collation），其中只有一种是默认的。而不同的字符集不可能对应同一种字符集校正。
字符集校正是一组规则，用于对对应字符集中的字符进行排序、分辨大小写，音调等等，与字符集的具体编码方法是没有关系的，可以说乱码与字符集校正的关系最多是间接的。

在数据存储层面上的字符集及字符集校正设置由高层至底层分四个层次：服务器，数据库，表，字段。设置方法有多种，而且每个层次都可以设置独立的字符集和其校正。存储于各层中的数据究竟是何字符集，使用什么字符集校正又有以下规则：
设置的优先级由下至上依次降低，如设置了字段的字符集为“utf8”和其校正为“utf8_general_ci”，那么不论其高层的表等如何设置，存储其中的数据都是“utf8”的，以“utf8_general_ci”为其字符集校正。
如某层没有设置，即依照其高一层的设置；所有都未设置按默认设置。
如果只设置了字符集，字符集校正自动依照其对应的默认值被系统设置。如只设某个表的字符集为“utf8”，那其校正会被自动设置为“utf8_general_ci”；反之，只设置了字符集校正，字符集自动被按其对应的字符集设置。
在与客户端连接层面上牵涉到另外三种字符集和字符集校正，这是客户端发送请求时可以更改的：
character_set_client ，这是用户告诉MySQL查询是用的什么字符集。
character_set_connection ，MySQL接受到用户查询后，按照character_set_client将其转化为character_set_connection设定的字符集。
character_set_results ， MySQL将存储的数据转换成character_set_results中设定的字符集发送给用户。
中文世界中使用较多的字符集有UTF8，GB2312，GBK，BIG5等。由于东方文字有很多全角字符，当转换为对应字母文字的字符集时，没有对应编码的全角字符必然显示为乱码，反之则不一定有。
以UTF8为例，首先假设数据库字段设置的字符集是UTF8，则中文乱码出现的原因可能有以下几个：
查询数据库时，character_set_client被设置或默认其他字符集。
提交数据至数据库时，提交数据为UTF8，而character_set_client ，character_set_connection 设置或被默认设为其他字符集，则存入数据库的数据即为乱码。再查询出的必然是乱码。
不用去管字符集校正。
若字段的字符集不是UTF8，不论如何设置，查询、更新数据字段都应显示出或多或少的乱码。
我总结了一下，东方字符集转西方字符集，东方字符全部乱码；西方字符集转东方字符集可能有少量无码；东方字符集互转，可能有部分误码。
所以出现乱码应首先明确使用何种字符集，然后做如下检查：
依次检查MySQL由底层字段到高层系统合层字符集。如有误，导出数据后设置正确后再按正确的字符集导出。
检查character_set_client是否被配置正确。
检查character_set_client ，character_set_connection 是否被配置正确。

程序里使用set names gb2312 之后，从数据库里读出来的，就是GB2312编码了。

数据库只是用UTF8存储