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 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 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字元集，就能夠正確使用。

那麼怎麼把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 */;