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