当前位置: 首页 > 图文教程 > 网络编程 > PHP > MySQL 4.1的编码问题

PHP
书评: PHP和ORACLE基础手册
最小化数据传输――在客户端存储数据
玩转虚拟域名◎+
DOMXML: Expat之外的另一选择
SQLite数据库安全
fckeditor用javascript创建
phplib7.2中文汉化版及调用示例
SQLite语法备忘录
将Oracle 10g内置的安全特性用于PHP
PHP5 & Web Services 系统架构图
解决PHP startup: Unable to load dynamic library的错误
PHP and Web Services
深入研究表单提交方式:GET/POST
php5中XML-RPC函数的使用
一 php与XML、XSLT、Mysql的结合运用,安装篇
二 php与XML、XSLT、Mysql的结合运用,代码篇
设计模式汇总
PHP5的异常处理机制
使用PHP5创建图形巧法(一)
使用PHP5创建图形巧妙方法(二)

PHP 中的 MySQL 4.1的编码问题


出处:互联网   整理: 软晨网(RuanChen.com)   发布: 2009-11-03   浏览: 134 ::
收藏到网摘: n/a

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

  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 指定的字符集。

一个典型的环境

典型的环境以我自己的电脑上安装的 MySQL 4.1 为例,我自己的电脑上安装着 Apache 2,PHP 5 和 WordPress 1.5.1.3,MySQL 配置文件中指定了 default_character_setutf8。于是问题出现了:

  1. WordPress 按照默认情况安装,所以所有的表都用 UTF-8 存储数据;
  2. WordPress 默认采用的浏览字符集是 UTF-8 (Options->Reading 中设置),因此所有 WP 页面的 meta 中会说明 charset 是 utf-8;
  3. 所以浏览器会以 utf-8 方式显示所有的 WP 页面;这样一来 Write 的所有 Post,和 Comment 都会以 UTF-8 格式从浏览器发送给 Apache,再由 Apache 交给 PHP;
  4. 所以 WP 从所有的表单中得到的数据都是 utf-8 编码的;WP 不加转换的直接把这些