MySQL数据移植中的乱码问题

MySQL数据如果从低版本的mysql向更高的版本移植的时候，若移植的数据中含有中文的数据时，很容易出现乱码问题。很多是在从MySQL4.x向MySQL5.x移植的时候出现。例如，我找了一个用mysql.4建立的表，表结构如下：

CREATE TABLE `tb_bookcase` (

 `id` int(10) unsigned NOT NULL AUTO_INCREMENT,

 `name` varchar(30) DEFAULT NULL,

 `Column_3` char(10) DEFAULT NULL,

 PRIMARY KEY (`id`)

) ENGINE=MyISAM AUTO_INCREMENT=4 DEFAULTCHARSET=latin1;

从上面的结果中可以看出MySQL的缺省字符集是latin1，在使用MySQL4.x的时候，很多人都是用的latin1字符集。而当使用MySQL5或者更高的版本时往往使用的是UTF-8。但是这个问题怎么决解呢？

网上找了一下，发现特别麻烦，我是这样子决解的，就是我们先把整个数据库按指定的字符导出，导出的数据的中文为正常编码（亲身试过），然后再改一下编码方式导入就OK了。

导出是我们在dos命令下使用输入

Mysqldump -hlocalhost -uroot -proot--default-character-set=latin1 dataBaseName>d:\test.sql

修改下test.sql的文件中所有的编码，就是把文件中的latin1改为utf8或者其他编码，再用source命令执行test.sql脚本文件，或者按照以下的方式导入

mysql  -uroot-p123456 --default-character-set=gb2312 test<d:/test.sql

上面的default-character-set我们指定特定的字符导出，也就是上面我们所说的latin1，此时在test.sql中的脚本代码若有中文时是正常的代码。

以下是网友的代码：。

在之前的系统中，我们是用latin1保存了使用GB系列字符集（GBK、GB2312等）的汉字。 

mysql> show create table test\G *************************** 1. row Table: test Create Table: CREATE TABLE `test` ( `a` varchar(100) default NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8 1 row in set (0.00 sec)   mysql> show create table testlatin1\G *************************** 1. row * Table: testlatin1 Create Table: CREATE TABLE `testlatin1` ( `a` varchar(100) default NULL ) ENGINE=InnoDB DEFAULT CHARSET=latin1 1 row in set (0.01 sec)

字符集是告诉我们，如果没有特别指定列的字符集，那么字符类型列的字符集与表的缺省字符集一样。

列的字符集是要告诉MySQL，这里面保存的字符所使用的字符集是什么。但到底保存的是什么字符集的字符，不由MySQL决定，MySQL也不进行检查。

在UTF-8广泛使用之前，我们使用的汉字都是GB系列的字符集，比如GB2312、GBK、GB18030等等。

在缺省字符集为latin1的MySQL中，我们通常就把GB字符集的汉字保存到数据库中，但是却告诉MySQL那是latin1字符集。而GB字符集是一个汉字占两个字节，latin1是一个字符占一个字节。也就是说一个GB汉字被当成两个latin1字符来保存了。这让我想起了当初的iso8859_1，也是类似的情况。只要我们保存和读取时都当作latin1，不进行转换，然后在显示时当作GB字符集，就能够正确使用。

那么怎么把latin1保存的汉字正确地导UTF-8字符集的数据库中呢？

首先，新的数据库中的列，要使用UTF-8字符集。一种办法是创建database时指定缺省字符集，这样在建表时如果不指定字符集则使用database的缺省字符集。

导出的数据要以latin1字符集导出，实际上就是告诉MySQL导出时不做转换（因为原有的表都是latin1字符集的）。

mysqldump出来以后，再用MySQL进行导入时，还要告诉MySQL，当前的数据是gb系列的字符集，比如gbk。这样，MySQL负责把数据由gbk转换为UTF-8，保存到数据库中。

如何告诉MySQL导入的SQL是什么字符集呢，一种方法是用--default-character-set，但有时会起不到实际作用。这是因为mysqldump出来的文件里有set names语句。比如：

head EA192.060913.sql   -- MySQL dump 10.10 -- -- Host: localhost Database: EA192 -- ---------------------------------- -- Server version 5.0.16-standard-log   /*!40101 SET @OLD_CHARACTER_SET_CLIENT =@@CHARACTER_SET_CLIENT */; /*!40101 SET @OLD_CHARACTER_SET_RESULTS =@@CHARACTER_SET_RESULTS */; /*!40101 SET @OLD_COLLATION_CONNECTION =@@COLLATION_CONNECTION */; /*!40101 SET NAMES latin1 */;

/*! */是MySQL特有有句法，在其他数据库会被当成注释忽略掉。/*!后面的40101是表示版本，在4.1.1及以上版才执行该条语句。

这里看到有一条SET NAMES latin1。它的一个作用是告诉mysql，客户端传过去的数据是latin1字符集。因为有这样一条SET NAMES，--default-character-set也就起不到作用了。如果不幸有这样一条SQL，那么需要把它去掉或者改成SET NAMES gbk。修改或者删除的办法，当数据量比较大的时候，可以用head和tail来配合。比如还是上面的那个文件：

先用head看一下SETNAMES在第几行（数一下），上面看到是第10行。

wc -l EA192.060913.sql 1987 EA192.060913.sql 得到总行数是1987   head -9 EA192.060913.sql > final.sql brum@brum-laptop:~$ tail -1977 EA192.060913.sql  >> final.sql brum@brum-laptop:~$

head -9是取前9行，tail -1977是取后1977行，这样就把第10行隔过去了。

 

得到final.sql再用MySQL运行时，就可以使用--default-character-set=gbk了。

 

还有一种办法是mysqldump时使用--set-charset=false，这样就不会出现SET NAMES了。

 

目前为止，还可能有问题，出在create table的SQL中，比如：

 

DROP TABLE IF EXISTS `test`; CREATE TABLE `test` ( `a` varchar(100) default NULL ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

这里仍然有个CHARSET=latin1，它将导致新创建的表的缺省字符集是latin1，而不是我们想要的UTF8。

怎么办呢，如果数据量不大的话，可以考虑用编辑器把它去掉或者改成UTF8，如果数据量大的话可以考虑用sed，但可能仍然时间比较长。

还有一种办法就是mysqldump，使用--create-options=false，不导出表的创建属性。但如果导出的表的存储引擎不同的话就有问题了，因为引擎类型（innodb、myisam等）都被忽略了。

此外，mysqldump导出时，不要使用-B，而是直接指定一个database名字，目的是不出现CREATE DATABASE语句，因为其中也可能会有缺省字符集的子句，会影响那些未在CREATETABLE中指定字符集的表。如果你导出的SQL中有CREATEDATABASE，那么需要注意一下有没有字符集的子句，如果有的话，也需要修改。

好了，通过上述方法导出或者处理过的导出文件可以使用mysql--default-character-set=gbk来导入了。