以下的文章主要講述的是MySQL字符的編碼轉換問題(latin1->gbk)的詳細解析，我們大家都知道容易過想搞好一個站的二次開發，可以用的原數據庫的編碼有兩種，即gbk與lation1。而我用的是 gbk，就涉及到編碼轉換問題。
這裡在LiJun027’s Blog查到一個詳細的編碼比較，幾種情況如下：
一、實驗：
1、情況一
數據庫字段MySQL字符集：utf-8
連接字符集：沒有顯式設置，默認為latin1
頁面字符集：gbk
存入過程：
1)頁面用GBK表示的SQL向服務器提交存入請求；
2)默認情況下不用Set Names ‘??’）服務器用latin1打開連接；
3)服務器誤認為當前的SQL語句是用latin1表示的；
4)服務器將GBK字符當作latin1字符，錯誤的運用“latin1轉UTF-8函數”將MySQL字符轉換後存入UTF-8字段中；
5) 錯誤的latin1(其實是GBK) => 錯誤的UTF-8）
6)如果用phpmyadmin打開該表用utf8連接）將會看到該字段為亂碼；
讀取過程：
1)默認情況下不用Set Names ‘??’）服務器用latin1打開連接；
2)服務器將UTF-8字段中的值轉換為latin1返回給客戶端；
3)錯誤的UTF-8 => 錯誤的latin1(其實是GBK)）該過程為存入過程5的逆過程。剛好錯錯得對了）
4)將服務器誤認為是latin1的GBK編碼按頁面字符集正常顯示；
用示意圖來表示就是：
存入過程：
----------------------
頁面 連接 存儲
----------------------
GBK => latin1 => utf-8
---------------
------------- |
| +------- 該過程得到的utf-8是一串不知所雲的亂碼，但MySQL固執的認為這串碼為UTF-8
|
+------ MySQL將GBK誤認為是latin1
讀取過程：
----------------------
頁面 連接 存儲
----------------------
GBK <= latin1 <= utf-8
---------------
------------- |
| +------- 正是這串亂碼經過逆過程轉換回正確的GBK編碼，只是MySQL認為是latin1而已
|
+------ MySQL將誤認為是latin1的GBK編碼傳回了頁面，剛好得到正確的編碼。
2、情況二
數據庫字段字符集：utf-8
連接MySQL字符集：gbk
頁面字符集：gbk
文字描述略。
示意圖：
存入過程：
----------------------
頁面 連接 存儲
----------------------
GBK => GBK => utf-8
------------
------------- |
| +------- 該過程得到的utf-8是由GBK轉換而來的，是正確的utf-8編碼
|
+------ 頁面字符集等於連接字符集，MySQL認為頁面傳遞給它的是GBK編碼，它的想法正好符合事實。
讀取過程：
----------------------
頁面 連接 存儲
----------------------
GBK <= GBK <= utf-8
---------------
------------- |
| +------- 用“utf-8轉GBK函數”將正確的utf-8編碼轉換回GBK
|
頁面字符集等於連接MySQL字符集，顯示沒有任何問題。
3、情況三
數據庫字段字符集：gbk
連接字符集：沒有顯式設置，默認為latin1
頁面字符集：gbk
存入過程：
----------------------
頁面 連接 存儲
----------------------
GBK => latin1 => GBK
------------
------------- |
| +------- 字符被“latin1轉GBK函數”轉換的成了亂碼，但MySQL認為它是GBK，所以工具無法正常顯示。
|
+------ MySQL認為頁面傳遞給它的是latin1編碼，它將在後續過程中畫蛇添足地將正確的GBK轉換為亂碼。
讀取過程：
----------------------
頁面 連接 存儲
----------------------
GBK <= latin1 <= GBK
---------------
------------- |
| +------- “GBK轉latin1函數”將亂碼轉換為GBK，但MySQL卻認為它們是latin1
|
+------ 錯誤的latin1編碼其實是正確的GBK編碼，頁面顯示正常，但工具顯示不正常。
二、MySQL字符集之間的轉換
筆者試著將GBK字符誤當作latin1轉換為錯誤的utf-8能成功，逆過程中將亂碼轉換回latin1得到的剛好是正確的GBK。
$str = "中文測試";
- $str_tran = iconv('latin1', 'utf-8', $str);
- echo $str_tran;
顯示亂碼，既不是GBK也不是utf-8和latin1
- echo "<br>-----------<br>";
- $str_re_tran = iconv('utf-8', 'latin1', $str_tran);
- echo $str_re_tran;
顯示 “中文測試”
而將GBK字符誤當作utf-8轉換為錯誤的GBK編碼則出現錯誤
$str = "中文測試";
- #$str_tran = iconv('utf-8', 'gbk', $str);
錯誤！！！
可見一種編碼是否能被當作另一種編碼被轉換為第三種編碼，取決於編碼的固有屬性，上面我們舉的第一個例子只是碰巧GBK編碼能被誤當作latin1被轉換為utf-8。如果是如下情況，則數據庫肯定不能正常存取數據。
先說一下教訓，建立數據庫的時候，同一個應用，所有的編碼一定要一致，不然就是自尋煩惱。
搞了半天用iconv轉換後還是不行。在Windows下開啟iconv只需要把php.ini裡面的;extension=php_mbstring.dll前面的“;”去掉即可。網上查了下。很多都說要開啟;extension=php_iconv.dll這個東東，但下了幾個版本的PHP都沒有看到有這一行，估計是老版本才需要這麼干吧？）
最後找到一個工具，可以實現latin1<->gbk,gbk<->utf8,gbk<->big5,的編碼的相互轉換，程序可以進行多次轉換即可以實現latin1->gbk->utf8等的轉換，但是不能跳躍轉換例：latin1不能直接轉換成utf8）。
還不錯，轉過來沒有亂碼，終於解決問題。
另外提一下備份數據庫工具：帝國數據備份王(Empirebak)。一款開源免費、專門為MySQL大數據的備份與導入而設計的穩定高效軟件,系統采用分卷備份與導入,理論上可備份任何大小的數據庫。
