MySQL字元集 GBK、GB2312、UTF8區別 解決MYSQL中文亂碼問題_Mysql

MySQL中涉及的幾個字元集

character-set-server/default-character-set：伺服器字元集，預設情況下所採用的。
character-set-database：資料庫字元集。
character-set-table：資料庫表字元集。
優先順序依次增加。所以一般情況下只需要設定character-set-server，而在建立資料庫和表時不特別指定字元集，這樣統一採用character-set-server字元集。
character-set-client：用戶端的字元集。用戶端預設字元集。當用戶端向伺服器發送請求時，請求以該字元集進行編碼。
character-set-results：結果字元集。伺服器向用戶端返回結果或者資訊時，結果以該字元集進行編碼。
在用戶端，如果沒有定義character-set-results，則採用character-set-client字元集作為預設的字元集。所以只需要設定character-set-client字元集。

要處理中文，則可以將character-set-server和character-set-client均設定為GB2312，如果要同時處理多國語言，則設定為UTF8。

關於MySQL的中文問題

解決亂碼的方法是，在執行SQL語句之前，將MySQL以下三個系統參數設定為與伺服器字元集character-set-server相同的字元集。
character_set_client：用戶端的字元集。
character_set_results：結果字元集。
character_set_connection：串連字元集。
設定這三個系統參數通過向MySQL發送語句：set names gb2312

關於GBK、GB2312、UTF8

UTF-8：Unicode Transformation Format-8bit，允許含BOM，但通常不含BOM。是用以解決國際上字元的一種多位元組編碼，它對英文使用8位（即一個位元組），中文使用24為（三個位元組）來編碼。UTF-8包含全世界所有國家需要用到的字元，是國際編碼，通用性強。UTF-8編碼的文字可以在各國支援UTF8字元集的瀏覽器上顯示。如，如果是UTF8編碼，則在外國人的英文IE上也能顯示中文，他們無需下載IE的中文語言支援包。

GBK是國家標準GB2312基礎上擴容後相容GB2312的標準。GBK的文字編碼是用雙位元組來表示的，即不論中、英文字元均使用雙位元組來表示，為了區分中文，將其最高位都設定成1。GBK包含全部中文字元，是國家編碼，通用性比UTF8差，不過UTF8佔用的資料庫比GBD大。

GBK、GB2312等與UTF8之間都必須通過Unicode編碼才能相互轉換：
GBK、GB2312－－Unicode－－UTF8
UTF8－－Unicode－－GBK、GB2312

對於一個網站、論壇來說，如果英文字元較多，則建議使用UTF－8節省空間的。不過現在很多論壇的外掛程式一般只支援GBK。

GB2312是GBK的子集，GBK是GB18030的子集
GBK是包括中日韓字元的大字元集合
如果是中文的網站 推薦GB2312 GBK有時還是有點問題
為了避免所有亂碼問題，應該採用UTF-8，將來要支援國際化也非常方便
UTF-8可以看作是大字元集，它包含了大部分文字的編碼。
使用UTF-8的一個好處是其他地區的使用者（如香港台灣）無需安裝簡體中文支援就能正常觀看你的文字而不會出現亂碼。

gb2312是簡體中文的碼
gbk支援簡體中文及繁體中文
big5支援繁體中文
utf-8支援幾乎所有字元

首先分析亂碼的情況
1.寫入資料庫時作為亂碼寫入
2.查詢結果以亂碼返回
究竟在發生亂碼時是哪一種情況呢？
我們先在mysql 命令列下輸入
show variables like '%char%';
查看mysql 字元集設定情況:

mysql> show variables like '%char%';
+--------------------------+----------------------------------------+
| Variable_name | Value |
+--------------------------+----------------------------------------+
| character_set_client | gbk |
| character_set_connection | gbk |
| character_set_database | gbk |
| character_set_filesystem | binary |
| character_set_results | gbk |
| character_set_server | gbk |
| character_set_system | utf8 |
| character_sets_dir | /usr/local/mysql/share/mysql/charsets/ |
+--------------------------+----------------------------------------+

在查詢結果中可以看到mysql 資料庫系統中用戶端、資料庫連接、資料庫、檔案系統、查詢
結果、伺服器、系統的字元集設定
在這裡，檔案系統字元集是固定的，系統、伺服器的字元集在安裝時確定，與亂碼問題無關
亂碼的問題與用戶端、資料庫連接、資料庫、查詢結果的字元集設定有關
*註：用戶端是看訪問mysql 資料庫的方式，通過命令列訪問，命令列視窗就是用戶端，通
過JDBC 等串連訪問，程式就是用戶端
我們在向mysql 寫入中文資料時，在用戶端、資料庫連接、寫入資料庫時分別要進行編碼轉
換
在執行查詢時，在返回結果、資料庫連接、用戶端分別進行編碼轉換
現在我們應該清楚，亂碼發生在資料庫、用戶端、查詢結果以及資料庫連接這其中一個或多
個環節
接下來我們來解決這個問題
在登入資料庫時，我們用mysql --default-character-set=字元集-u root -p 進行串連，這時我們
再用show variables like '%char%';命令查看字元集設定情況，可以發現用戶端、資料庫連接、
查詢結果的字元集已經設定成登入時選擇的字元集了
如果是已經登入了，可以使用set names 字元集;命令來實現上述效果，等同於下面的命令：
set character_set_client = 字元集
set character_set_connection = 字元集
set character_set_results = 字元集
如果是通過JDBC 串連資料庫，可以這樣寫URL：
URL=jdbc:mysql://localhost:3306/abs?useUnicode=true&characterEncoding=字元集
JSP 頁面等終端也要設定相應的字元集
資料庫的字元集可以修改mysql 的啟動配置來指定字元集，也可以在create database 時加上
default character set 字元集來強制設定database 的字元集
通過這樣的設定，整個資料寫入讀出流程中都統一了字元集，就不會出現亂碼了
為什麼從命令列直接寫入中文不設定也不會出現亂碼？
可以明確的是從命令列下，用戶端、資料庫連接、查詢結果的字元集設定沒有變化
輸入的中文經過一系列轉碼又轉回初始的字元集，我們查看到的當然不是亂碼
但這並不代表中文在資料庫裡被正確作為中文字元儲存
舉例來說，現在有一個utf8 編碼資料庫，用戶端串連使用GBK 編碼，connection 使用預設
的ISO8859-1（也就是mysql 中的latin1），我們在用戶端發送“中文”這個字串，用戶端
將發送一串GBK 格式的二進位碼給connection 層，connection 層以ISO8859-1 格式將這段
二進位碼發送給資料庫，資料庫將這段編碼以utf8 格式儲存下來，我們將這個欄位以utf8
格式讀取出來，肯定是得到亂碼，也就是說中文資料在寫入資料庫時是以亂碼形式儲存的，
在同一個用戶端進行查詢操作時，做了一套和寫入時相反的操作，錯誤的utf8 格式二進位
碼又被轉換成正確的GBK 碼並正確顯示出來。