[讨论]MySQL运维----"诡异"的字符集问题（获奖名单已公布-2012-8-23）

ning_lianjie

回复 70# CTUOS
如果在第三方客户端上面也需要设置gbk的话,是不是建表的字符集是gbk的,或者列字符集是gbk,
可以执行

1. SHOW CREATE TABLE table_name\G

复制代码

命令,查看一下

   

ning_lianjie

有兄弟问及LOAD DATA INFILE乱码的问题.引用<高性能MySQL>中的语言

LOAD DATA INFILE按照当前character_set_database的设置接收数据.
...
导入的最佳方式:use 相应库,然后执行set names ...,最后加载数据

yueyuezhaozhao

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

ning_lianjie

回复 73# yueyuezhaozhao

=.=!!
   

tkchks

关于如何修改latin1编码为utf8编码：
这个与版本有关。这里例举的是mysql5.5版本解决方案：

添加以下行到my.cnf [mysqld]下面：

collation-server=utf8_unicode_ci
ini-connect='SET NAMES utf8'
character_set_server=utf8
具体可以参考这篇文章： http://phpcode8.com/lamp/mysql-l ... de-latin1-utf8.html
http://stackoverflow.com/questio ... t-to-utf8-in-my-cnf

macaw_w

个人理解
character_set_client     是客户端过来的字符集，程序可以指定，就好比电话里告诉你来了个印度人，你见面发现是个美国人，所以这个首先不能指定错了  
character_set_connection 上面的client 要转化成 connection ，然后再转化成下面的server才能进库，所以connection是个中间状态
character_set_database    这个没用过
character_set_filesystem  这个没用过
character_set_results    数据库计算完了要返回值，就把刚才server库里面的字符集，转成结果result，回给客户端
character_set_server     这个就是建库用的默认值
character_set_system     这个没用过，是元数据的值吧

这几个值设错了有时候也没事，因为如果client过来认错了，先将错就错，然后result返回去就ok了
但项目中一般为了国际化，就都写utf8，程序员过来也都制定好utf8就没问题了

ning_lianjie

回复 75# tkchks

collation-server=utf8_unicode_ci 
排序规则建议默认,如果指定的话,有一次忘记,就会出乱子.

ini-connect='SET NAMES utf8'
对于super权限的用户是无效的.
   

ning_lianjie

回复 76# macaw_w

character_set_database：当前选中数据库的默认字符集.
这个值是随着库的字符集而改变的.例如:
a库的字符集是latin1,当前在a库中,执行show variables like 'char%';你会发现这个值是latin1;
b库的字符集是utf8,当前在b库中,执行show variables like 'char%'; 你会发现这个值是utf8.
   

wenxin1234114

一般连接的时候编码和服务器库中的表字段一致就不会乱码。就是请求的时候和被请求的要一致。

ning_lianjie

回复 79# wenxin1234114

在初学的时候,很多都不了解如何保持一致...