MySQL数据库中数据库移植中的乱码问题

mysql移植含有中文的数据时，很容易出现乱码问题。很多是在从mysql4.x向mysql5.x移植的时候出现。mysql的缺省字符集是latin1，在使用mysql4.x的时候，很多人都是用的latin1字符集。而当使用mysql5时往往愿意使用utf-8。那么我们的任务是不是要把数据中的字符从latin1转为utf-8呢？不是的。

用一句不大准确，但又比较形象的说法是，在之前的系统中，我们是用latin1保存了使用gb系列字符集（gbk、gb2312等）的汉字。怎么这样说呢？

列的字符集是要告诉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语句。比如：

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

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

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

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

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

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

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

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

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