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

PHP
php 远程图片保存到本地的函数类
php 破解防盗链图片函数
快速开发一个PHP扩展图文教程
PHP6 mysql连接方式说明
php 进度条实现代码
php discuz 主题表和回帖表的设计
php 无限级缓存的类的扩展
php adodb操作mysql数据库
php FPDF类库应用实现代码
sourcesafe管理phpproj文件的补充说明(downmoon)
AspNetAjaxPager,Asp.Net通用无刷新Ajax分页控件,支持多样式多数据绑定
php一句话cmdshell新型 (非一句话木马)
php 木马的分析(加密破解)
PHP 数组入门教程小结
php 方便水印和缩略图的图形类
PHP加速 eAccelerator配置和使用指南
PHP 组件化编程技巧
IIS6+PHP5+MySQL5+Zend Optimizer+phpMyAdmin安装配置图文教程 2009年
两个强悍的php 图像处理类1
PHP 数据库 常见问题小结

PHP 中的 MySQL 4.1的编码问题


出处:互联网   整理: 软晨网(RuanChen.com)   发布: 2009-11-03   浏览: 48 ::
收藏到网摘: 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 不加转换的直接把这些