MySQL数据库中数据库移植中的乱码效果
日期：2013-02-24 浏览次数：20483 次
MySQL移植含有中文的数据时，很容易出现乱码问题。很多是在从MySQL4.x向MySQL5.x移植的时候出现。MySQL的缺省字符集是latin1，在使用MySQL4.x的时候，很多人都是用的latin1字符集。而当使用MySQL5时往往情愿使用UTF-8。那么我们的任务是不是要把数据中的字符从latin1转为UTF-8呢？不是的。
用一句不大精确，但又比较笼统的说法是，在之前的系统中，我们是用latin1保存了使用GB系列字符集（GBK、GB2312等）的汉字。怎样这样说呢？
| 以下为援用的内容： mysql> show create table test\G mysql> show create table testlatin1\G |
字符集是通知我们，如果没有特别指定列的字符集，那么字符类型列的字符集与表的缺省字符集一样。
列的字符集是要通知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 /*!40101 SET @OLD_CHARACTER_SET_CLIENT |
/*! */是MySQL特有有句法，在其他数据库会被当成注释忽略掉。/*!后面的40101是表示版本，在4.1.1及以上版才执行该条语句。
这里看到有一条SET NAMES latin1。它的一个作用是通知mysql，客户端传过去的数据是latin1字符集。由于有这样一条SET NAMES，--default-character-set也就起不到作用了。如果不幸有这样一条SQL，那么需求把它去掉或者改成SET NAMES gbk。修正或者删除的办法，当数据量比较大的时候，可以用head和tail来配合。比如还是上面的那个文件：
先用head看一下SET NAMES在第几行（数一下），上面看到是第10行。
| 以下为援用的内容： wc -l EA192.060913.sql head -9 EA192.060913.sql > final.sql |
head -9是取前9行，tail -1977是取后1977行，这样就把第10行隔过去了。
得到fina
