MySQL 4.1 字符集支持的原理

2016-01-29 14:59 16 1 收藏

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

【 tulaoshi.com - MySQL 】

摘于:  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 程序在创建数据库和数据表时并没有使用那么复杂的配置,它们用的是默认的配置,那么,默认的配置从何而来呢?

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

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

(本文来源于图老师网站,更多请访问http://www.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 格

来源:http://www.tulaoshi.com/n/20160129/1494918.html

延伸阅读
我们遵循的标准是,数据库,表,字段和页面或文本的编码要统一起来 很多mysql数据库工具(除了phpmyadmin,我偶尔用,功能强速度慢)都不支持创建时指定数据库编码,当然可以改my.ini来解决这个问题,但是需要重新启动mysql,不过用下面的语句会更有效 GBK: create database test2 DEFAULT CHARACTER SET gbk COLLATE gbk_chinese_ci; UTF8: C...
标签: Web开发
1、在建库时,catproc一定要运行,否则用rman时会出现如下字符集的错误: RMAN-00554: initialization of internal recovery manager package failed RMAN-04005: error from target database: ORA-06553: PLS-213: package STANDARD noe RMAN-04015: error setting target database character set to ZHS16CGB231280 如果建库时没有问题,那...
改变redhat的系统语言/字符集 改变redhat的系统语言/字符集修改 /etc/sysconfig/i18n 文件,如 LANG="en_US",xwindow会显示英文界面, LANG="zh_CN.GB18030",xwindow会显示中文界面。 还有一种方法 cp /etc/sysconfig/i18n $HOME/.i18n 修改 $HOME/.i18n 文件,如 LANG="en_US",xwindow会显示英文界面, LANG...
以mysql-noinstall-5.0.22-win32为例,解压缩后会看到mysql-5.0.22-win32文件夹下面,有五个ini格式的文件,把my-medium.ini文件拷贝一份,改名为my.ini,打开my.ini文件,在[client]、[mysqld]下面加上default-character-set=gb2312,其含义就是把gb2312设置为数据库的默认字符集。设置完毕后需要重新启动myqsl服务。 同理,可以把其他字符集...
在国内外大中型数据库管理系统中,把 ORACLE 作为数据库管理平台的用户比较多。 ORACLE 不论是数据库管理能力还是安全性都是无可非议的,但是,它在汉字信息的显示方面着实给中国用户带来不少麻烦,笔者多年从事 ORACLE 数据库管理,经常收到周围用户和外地用户反映有关 ORACLE 数据库汉字显示问题的求援信,主要现象是把汉字显示为...

经验教程

591

收藏

17
微博分享 QQ分享 QQ空间 手机页面 收藏网站 回到头部