MySQL 4.1 字符集支持的原理

天却笑

天却笑

2016-01-29 14:59

MySQL 4.1 字符集支持的原理,MySQL 4.1 字符集支持的原理

摘于:  http://jjgod.3322.org/2005/07/31/a-mysql-41-story/

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

MySQL 4.1 对多语言的支持有了很大变化 (这导致了问题的出现); 
尽管大部分的地方 (包括个人使用和主机提供商),MySQL 3 仍然占主导地位;但 MySQL 4.1 是 MySQL 官方推荐的数据库,已经有主机提供商开始提供并将会越来越多; 
许多 PHP 程序以 MySQL 作为默认的数据库管理软件,但它们一般不区分 MySQL 4.1 与 4.1 以下版本的区别,笼统地称“MySQL 3.xx.xx 以上版本”就满足安装需求了; 
因为 latin1 在许多地方 (下边会详细描述具体是哪些地方) 作为默认的字符集,成功的蒙蔽了许多 PHP 程序的开发者和用户,掩盖了在中文等语言环境下会出现的问题; 
简单的说,MySQL 自身的变化和使用 MySQL 的 PHP 程序对此忽略,导致了问题的出现和复杂化,而由于大部分用户使用的是英文,使这种问题不被重视。这里提到的 PHP 程序,主要就 WordPress 而言。 

MySQL 4.1 字符集支持的原理
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 存储。

(本文来源于图老师网站,更多请访问https://m.tulaoshi.com/mysql/)

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

(本文来源于图老师网站,更多请访问https://m.tulaoshi.com/mysql/)

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

WordPress 按照默认情况安装,所以所有的表都用 UTF-8 存储数据; 
WordPress 默认采用的浏览字符集是 UTF-8 (Options-Reading 中设置),因此所有 WP 页面的 meta 中会说明 charset 是 utf-8; 
所以浏览器会以 utf-8 方式显示所有的 WP 页面;这样一来 Write 的所有 Post,和 Comment 都会以 UTF-8 格式从浏览器发送给 Apache,再由 Apache 交给 PHP; 
所以 WP 从所有的表单中得到的数据都是 utf-8 编码的;WP 不加转换的直接把这些数据发送给 MySQL; 
MySQL 默认设置的 character_set_client 和 character_set_connection 都是 latin1,此时怪异的事情发生了,实际上是 utf-8 格式的数据,被“当作 latin1”转换成……居然还是转换成 latin1,然后再由这个 latin1 转换成 utf-8,这么两次转换,有一部分 utf-8 的字符就丢失了,变成 ??,最后输出的时候 character_set_results 默认是 latin1,也就输出为奇怪的东西了。 
最神奇的还不是这个,如果 WordPress 中设置以 GB2312 格

展开更多 50%)
分享

猜你喜欢

MySQL 4.1 字符集支持的原理

MySQL mysql数据库
MySQL 4.1 字符集支持的原理

MySQL字符集

编程语言 网络编程
MySQL字符集

s8lol主宰符文怎么配

英雄联盟 网络游戏
s8lol主宰符文怎么配

小谈MySQL字符集

编程语言 网络编程
小谈MySQL字符集

mysql 字符集的系统变量说明

编程语言 网络编程
mysql 字符集的系统变量说明

lol偷钱流符文搭配推荐

英雄联盟 网络游戏
lol偷钱流符文搭配推荐

MySQL 存储过程的字符集问题

编程语言 网络编程
MySQL 存储过程的字符集问题

HTML 字符集

Web开发
HTML 字符集

lolAD刺客新符文搭配推荐

英雄联盟
lolAD刺客新符文搭配推荐

《曹操去哪了》武技修习攻略

《曹操去哪了》武技修习攻略

Access数据库技术(58)

Access数据库技术(58)
下拉加载更多内容 ↓