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來導入了。