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