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

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

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

mysql> show create table testG *************************** 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 testlatin1G *************************** 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字符集，就能够正确使用。

查看更多关于MySQL数据库中数据库移植中的乱码问题的详细内容...