再谈MySQL升级出现乱码问题的解决

以前写过一篇关于MySQL升级到4.1出现乱码如何解决的帖子,他只是讲述了当你导入的数据都正常了,该怎么使用到MySQL4.1以后版本的多语言特征。但是如果在导入的过程中就遇到了字符集的问题,该怎么办呢?就是无论你怎么导入,怎么折腾字符集,都是乱码,但是你新插入的任何一条数据都没有问题,这就不是升级后调整字符集的问题了,而是在导出导入的工程中就需要考虑。

UP这两天估计被这个问题折腾的够呛,虽然事后找到的原因不是在于数据库,但是这里还是把升级的过程记录下来。今天up问我上次论坛如何升级和转换的,我就记得不太清楚了。

我自己试验成功的有两种方式
1)只需要把你原来版本的数据库文件考到到新的数据库目录下,什么都不用修改,这个时候输出应该是正常的,默认采用了latin1字符集。这大概只最简单的方式了,不过这种方式不太好的地方在于一旦将来要转换字符集,很是麻烦。

2)假设你要从MySQL4.0以下版本升级到MySQL4.1以上版本,并明确指定需要的字符集是gb2312,那么我的步骤是
a)在原来的数据库上导出你要的数据库,可以使用下面的命令:

$mysqldump -u username -p password databasename >xxx.sql
b)修改导出的sql文件,首先将导出的数据表加上默认字符集gb2312,可以在vi中只用下面的替换命令

% s/engine=MyISAM;/engine=MyISAM DEFAULT CHARSET=GB2312;/g
当然你可以使用你喜欢的编辑器来替换;其次是将这个sql文件转化成gb2312编码格式的文件。你可以先file看看该文件的字符集,如果是ISO8859的,那还不错,如果是Non-ISO格式,那就必须转换,可以使用下面的命令

iconv -c -t gb2312 -o outout.sql xxx.sql
UP导出的数据就是Non-ISO格式。

c)连接新的数据库服务器,创建需要的数据库

CODE:
[Copy to clipboard]
mysqladmin -uroot -p create databasename
d)在导入数据之前,看看默认的字符集,可以使用下面的方法

mysql> SHOW VARIABLES LIKE 'character_set_%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
7 rows in set (0.00 sec)
默认的字符集都是latinn1的,这个时候,你需要将latin1转换成gb2312,方法如下

mysql> set NAMES 'utf8';
Query OK, 0 rows affected (0.00 sec)
mysql> set character_set_database=utf8;
Query OK, 0 rows affected (0.00 sec)
mysql> set character_set_server=utf8;
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like 'character%';
+--------------------------+--------------------------------+
| Variable_name         | Value                 |
+--------------------------+--------------------------------+
| character_set_client   | utf8                   |
| character_set_connection | utf8                   |
| character_set_database   | utf8                   |
| character_set_filesystem | binary                 |
| character_set_results   | utf8                   |
| character_set_server   | utf8                   |
| character_set_system   | utf8                   |
| character_sets_dir     | /usr/share/mysql/charsets/ |
+--------------------------+--------------------------------+
8 rows in set (0.00 sec)
这时数据库字符集已经修改,可以导入数据了

mysql>source /path/to/xxx.sql
然后在你的网页中,在连接数据后,加上下面的一条指令

mysql_query(”set NAMES 'utf8'");
应该就可以了,当然你的网页编码本身应该也要式gb2312的。

那么UP为什么会要折腾两天呢?不是他的步骤和方法有问题,而是操作系统的问题!操作系统?ubuntu!
问题就出现在iconv转换的过程中,只要转换成GB2312,那些中文就成了空白,而同样的文件,在其他Linux操作系统上就不会出现这个问题,难道式ubuntu并不支持GB2312?还是别的原因,个人没有使用过ubuntu,不太清楚他的字符集和字体支持是如何的,不过想来我用过的 redhat,fedora,suse确实都在字符集和中文字体方面有些欠缺。这个方面,红旗Linux显然要优秀一些。

从MySQL 4.1开始引入的多语言支持确实很棒,而且一些特性已经超过了其他的数据库系统。不过我在测试过程中发现使用适用于MySQL 4.1之前的PHP语句操作MySQL数据库会造成乱码,即使是设置过了表字符集也是如此。

我使用phpmyadmin来操作mysql,使用了zh- cn-utf8的连接方式,数据库和表也使用了utf8的编码,在phpmyadmin里数据都很正常,但是使用php连接并打印出来以后成为??,既不是utf8,也不是gb2312,更不是iso8859,如果从我的表单插入数据,则显示乱码,有些是中文,有些是乱码。查看了一下mysql 4.1手册中有关字符集的问题,问题解决,总结如下:

MySQL 4.1的字符集支持(Character Set Support)有两个方面:字符集(Character set)和排序方式(Collation)。对于字符集的支持细化到四个层次: 服务器(server),数据库(database),数据表(table)和连接(connection)。

查看系统的字符集和排序方式的设定可以通过下面的两条命令:
mysql> SHOW VARIABLES LIKE 'character_set_%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
7 rows in set (0.00 sec)

mysql> SHOW VARIABLES LIKE 'collation_%';
+----------------------+-------------------+
| Variable_name | Value |
+----------------------+-------------------+
| collation_connection | latin1_swedish_ci |
| collation_database | latin1_swedish_ci |
| collation_server | latin1_swedish_ci |
+----------------------+-------------------+
3 rows in set (0.00 sec)

上面列出的值就是系统的默认值。(很奇怪系统怎么默认是latin1的瑞典语排序方式)...

当我们按照原来的方式通过PHP存取MySQL数据库时,就算设置了表的默认字符集为utf8并且通过UTF-8编码发送查询,你会发现存入数据库的仍然是乱码。问题就出在这个connection连接层上。解决方法是在发送查询前执行一下下面这句:

SET NAMES 'utf8';它相当于下面的三句指令:

SET character_set_client = utf8;
SET character_set_results = utf8;
SET character_set_connection = utf8;

再试试看,正常了吧?^_^ Enjoy!

AddThis Social Bookmark Button

相关文档(Relevant Entries)
mysql 4.1以上版本中文乱码解决方法集锦
如何用命令行SSH备份和恢复MYSQL数据库
修改MYSQL密码和密码破解的常用方法
MySQL自下而上征程 Web应用起飞?
MYSQL数据备份/恢复简易方法
SQL语句优化的原则
如何提高MySQL性能
Description of MySQL regular expression syntax
Posted on May 9, 2007 9:23 AM | | | Comments (3) | | TrackBacks (0)

引用地址(TRACKBACKS)
 
TrackBack URL for this entry:
http://www.wujianrong.com/mt-tb.cgi/5205

评论 (3)

创创新世纪:

我用的2000系统不知道怎么搞的还是不行

有什么出错信息或现象?

failsafe:

碰到一个几乎跟上面情况一样的情况。
由于更换IDC,从原服务商备份数据出来,但是此时新服务商还没有开通, 我也没有测试,以为有数据了应该不会有问题。现在原服务商帐户关闭了。phpmyadmin里面导出来的数据怎么搞都是乱码。
根据你上面的办法,除了“iconv -c -t gb2312 -o outout.sql xxx.sql”这一步以外,其他都做了。因为很不幸,我用的也是ubuntu, 所以我在windows下用一个叫convert的工具转换的。
file的结果:
原文件:UTF-8 Unicode English text, with very long lines
ubuntu下iconv转换的结果:ISO-8859 English text, with very long lines, 但是跟你上面说的一样,中文不显示
windows下转换成GB2312后的结果: Non-ISO extended-ASCII English text, with very long lines 显示还是乱码

半年的网站数据阿,我快没辙了。如果不麻烦的话,能否通过E-mail请教一下:simon.youngest@gmail.com
万分感谢


发布评论(ADD YOUR COMMENTS)
 
感谢您参与评论;发表您的意见时请保持文章的相关性;不相关的或是单纯宣传的内容可能会被删掉。您的E-mail只是用来确认您发表的文章,不会出现在网页上。
Please keep your comments relevant to this blog entry. Email addresses are never displayed, but they are required to confirm your comments.

称呼(Name):      记住我的个人信息(Remember)
邮箱(Email):
网址(URL):
评论(Add your comments):

相关内容