今天我們同大家介紹一下"詳解mysql字元的編碼轉換問題"，希望對大家有所幫助，並和大家一起來**、交流。 我們大家都知道容易過想搞好乙個站的二次開發，可以用的原資料庫的編碼有兩種，即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 "-----------
";
$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大資料的備份與匯入而設計的穩定高效軟體,系統採用分卷備份與匯入,理論上可備份任何大小的資料庫。
python 字元編碼轉換詳解
unicode所有的中文或者英文都是占用兩個位元組 16位 ascii 只能存英文 8位 utf 8 可變長的字元編碼，所有英文按ascll佔乙個位元組，常用中文字元用utf 8編碼占用3個位元組 coding gbk import sys with語句 為了避免開啟檔案後忘記關閉，可以通過管理上下...
LOAD DATA INFILE字元編碼的問題
quote load data infile c users denny desktop testpage xx.csv into table taobao shop character set utf8 fields terminated by enclosed by escaped by lin...
字元編碼的轉換
編碼轉換是指將一種編碼轉成另一種編碼，比如utf 8轉成gbk。為什麼需要編碼轉換？因為不同作業系統編碼不同，utf 8在win上沒法直接看，因為windows是gbk編碼的，需要轉成gbk才行。如果你的bgk字元想在linux mac上正常顯示，就得轉成utf 8.s 小明 在python3中，記...