MySQL 4.1 字符集支持的原理

dragon76

MySQL 4.1 字符集支持的原理
转自:
http://jjgod.3322.org/2005/07/31/a-mysql-41-story/
MySQL 4.1 对于字符集的指定可以细化到一台机器上安装的 MySQL，其中的一个数据库，其中的一张表，其中的一栏，应该用什么字符集。但是，传统的 Web 程序在创建数据库和数据表时并没有使用那么复杂的配置，它们用的是默认的配置，那么，默认的配置从何而来呢？

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

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

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

此时 character_set_server 被设定为这个默认的字符集；

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

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

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

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

这个字符集就是数据库中实际存储数据采用的字符集，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 指定的字符集。


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/12056/showart_68119.html