- 论坛徽章:
- 1
|
[转载] Mysql4.1 & PhpMyAdmin 2.6.x的中文乱码问题的思考
MySQL4.1和4.0对于我们的影响主要是字符集的问题,以前装过一次,但是发现phpAdmin就无法正常显示中文了,当时没有时间就简单的退回到了4.0。
但现在不得不使用4.1了,不能用phpAdmin的确很难受,就花点时间看了一下mysql的文档:
4.1中,对于字符集非常灵活,可以为数据库、表、字段分别制定不同的字符集,这是静态的,此外,客户端链接时也可以选择不同的字符集,因此,上述几个环节都要设置正确才行。
对于phpMyAdmin,对于新建的数据库表,应该没有什么问题,一般可以选择用utf8作为数据库默认的字符集,在pma中可以正确的显示和录入中文。但是,当你用php读取那些pma创建的数据时,很可能会出现乱码,为什么?这是因为有些变量没有设置正确罢了,PMA在dbi接口中,连接数据库后会通过“set names”来设置正确的字符集,因此可以正常工作。这其中具体的细节可以参考mysql manual "Chapter 10. Character Set Support" 这部分,很清楚。
mysql如何检测并判断使用何种字符集,要注意以下几个变量(主要是涉及链接数据库部分):
character_set_server:这是设置服务器使用的字符集
character_set_client :这是设置客户端发送Query串使用的字符集
character_set_connection :这是设置服务器需要将收到的查询串转换成的字符集
character_set_results :这是设置服务器要将结果数据转换到的字符集,转换后才发送给客户端
因此,整个流程如下:
- client(如php程序)发送一个sql串
- 服务器收到串,将sql串从character_set_client 转换到character_set_connection,然后执行转换后的查询
- 服务器将结果数据转换到character_set_results字符集后发送回客户端
因此,如果上述过程有不匹配的地方,自然就出现乱码(因为如果没有设置上述变量,则取默认值,一般来说默认的是latin1,这是编译mysql的默认选项)。
PMA在对mysql4.0以下会使用内置的库(主要是通过Iconv)来实现字符集的转换,从而支持多语言版本,而对于4.1以上则完全交给Mysql。
其实只要上述变量设置好了,不管是PMA还是普通的PHP程序都可可以正确读取,只要把上述变量设定到/etc/my.cnf ,或者my.ini(windows) 中的[mysqld]下面就可以了(注意:设置的时候需要设置default-character-set,而不是上面的几个变量名)。
如果是租用主机,无法修改,则可以通过:
set names 或 SET CHARACTER SET 来动态设置上述值,这2个SQL略有差别:
SET NAMES 'x' 相当于:
mysql> SET character_set_client = x;
mysql> SET character_set_results = x;
mysql> SET character_set_connection = x;
而SET CHARACTER SET 则:
mysql> SET character_set_client = x;
mysql> SET character_set_results = x;
mysql> SET collation_connection = @@collation_database;
其实说了半天,问题主要还是出现在由4.0数据库迁移到4.1上的时候会有乱码,
因为4.0一般使用latin1,那么在import的时候如果设置不对,
从pma中就看到都是乱码了。我自己是将上述值都设置为gbk后将旧数据重新导入的,
然后在pma中可以选择utf8/gbk链接校对都可以正确显示中文的。
而原有PHP程序是不需要变动的(前提是在my.cnf中设置上述变量).
摘要:写了那么多,其实对于大多数的应用而言,迁移真的很简单,
windows:
只需要在mysql安装目录中的my.ini的[mysqld]设置:
default-character-set=gbk,然后导入你原先的4.0的数据就ok
Linux: /etc/my.cnf 中的[mysqld]设置default-character-set=gbk
如果你的网页使用的是utf-8,则,可以将gbk改为utf8,但是,由于我们原来mysqldump
出来的sql是latin1,所以导入的时候还是要用gbk,之后可以重新设置为utf8 |
|