MySQL：windows中困擾着咱們的中文亂碼問題

前言：什麼是mysql中的中文亂碼問題？

　　話很少說，直接上圖

　　這個東西困擾了我很久，致使我如今對windows映像很是很差，因此就想改爲Linux，行了，牢騷就發到這裏，直接說問題，明眼人一眼就看出來是編碼問題，可是，很少說，繼續上圖

　　明明都設置成了utf8了，但是仍是出現了亂碼問題。不是說爲了不全部亂碼問題，應該採用UTF-8，未來要支持國際化也很是方便，但是爲何還出現這個問題。

一，關於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佔用的數據庫比GBK大。

　　三者之間的轉化

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支持幾乎全部字符

二，如何查詢mysql字符集設置狀況

　　咱們在mysql中輸入下面命令：

mysql> show variables like '%char%';

　　結果：

+--------------------------+---------------------------------------------------------+
| Variable_name            | Value                                                   |
+--------------------------+---------------------------------------------------------+
| character_set_client     | utf8                                                    |
| character_set_connection | utf8                                                    |
| character_set_database   | utf8                                                    |
| character_set_filesystem | binary                                                  |
| character_set_results    | utf8                                                    |
| character_set_server     | utf8                                                    |
| character_set_system     | utf8                                                    |
| character_sets_dir       | C:\Program Files\MySQL\MySQL Server 5.5\share\charsets\ |
+--------------------------+---------------------------------------------------------+
8 rows in set (0.00 sec)

　　在查詢結果中能夠看到mysql 數據庫系統中客戶端、數據庫鏈接、數據庫、文件系統、查詢結果、服務器、系統的字符集設置在這裏，文件系統字符集是固定的，系統、服務器的字符集在安裝時肯定，與亂碼問題無關。亂碼的問題與客戶端、數據庫鏈接、數據庫、查詢結果的字符集設置有關。從上圖中能夠看到 MySQL 有六處使用了字符集，分別爲：client 、connection、database、results、server 、system。其中與服務器端相關：database、server、system（永遠沒法修改，就是utf-8）；與客戶端相關：connection、client、results 。

client	爲客戶端使用的字符集。
connection	爲鏈接數據庫的字符集設置類型，若是程序沒有指明鏈接數據庫使用的字符集類型則按照服務器端默認的字符集設置。
database	爲數據庫服務器中某個庫使用的字符集設定，若是建庫時沒有指明，將使用服務器安裝時指定的字符集設置。
results	爲數據庫給客戶端返回時使用的字符集設定，若是沒有指明，使用服務器默認的字符集。
server	爲服務器安裝時指定的默認字符集設定。
system	爲數據庫系統使用的字符集設定。

三，MySQL中編碼轉換的思路

如圖：

 

　　*注：客戶端是看訪問mysql 數據庫的方式，經過命令行訪問，命令行窗口就是客戶端，經過JDBC 等鏈接訪問，程序就是客戶端咱們在向mysql 寫入中文數據時，在客戶端、數據庫鏈接、寫入數據庫時分別要進行編碼轉換。在執行查詢時，在返回結果、數據庫鏈接、客戶端分別進行編碼轉換。如今咱們應該清楚，亂碼發生在數據庫、客戶端、查詢結果以及數據庫鏈接這其中一個或多個環節。

 舉個例子：

如今有一個utf8 編碼數據庫，客戶端鏈接使用GBK 編碼，connection 使用默認
的ISO8859-1（也就是mysql 中的latin1），咱們在客戶端發送"中文"這個字符串，
客戶端將發送一串GBK 格式的二進制碼給connection 層，connection 層
以ISO8859-1 格式將這段二進制碼發送給數據庫，數據庫將這段編碼以utf8
格式存儲下來，咱們將這個字段以utf8格式讀取出來，確定是獲得亂碼，也就是
說中文數據在寫入數據庫時是以亂碼形式存儲的，在同一個客戶端進行查詢操做時，
作了一套和寫入時相反的操做，錯誤的utf8 格式二進制碼又被轉換成正確的GBK 
碼並正確顯示出來。 
  

　　

四，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。

• 系統變量：
– character_set_server：默認的內部操做字符集

– character_set_client：客戶端來源數據使用的字符集

– character_set_connection：鏈接層字符集

– character_set_results：查詢結果字符集

– character_set_database：當前選中數據庫的默認字符集

– character_set_system：系統元數據(字段名等)字符集

　　

　　解決亂碼的方法是，在執行SQL語句以前，將MySQL如下三個系統參數設置爲與服務器字符集character-set-server相同的字符集。

character_set_client：客戶端的字符集。

character_set_results：結果字符集。

character_set_connection：鏈接字符集。

　　
設置這三個系統參數經過向MySQL發送語句：

set names gb2312

set character_set_client = 字符集

set character_set_connection = 字符集

set character_set_results = 字符集

 

五，設置MySQL的字符編碼

　　這裏我已經將MySQL的數據庫編碼設置爲UTF-8，因此下面現實的都是UTF-8。

　　設置MySQL數據庫的編碼方式有三種，分別是基於session會話的、基於全局gloable的、永久性改變的。

5.1 基於session會話層

1.首先鏈接到MySQL ：

mysql -uroot -proot

　　

2.輸入\s，便可查看數據庫的字符編碼

　　

3.查看數據庫的詳細編碼

　　輸入：

show variables like '%char%';

　　

 　  

4.新建一個數據庫查看數據庫編碼

　　create database test1;
　　show create database test1;

　　

　　

5.設置當前窗口的數據庫字符編碼，即便基於會話session級別的，關閉此窗口，從新打開另外的窗口操做數據庫依然是原來的字符編碼

　　這裏將utf-8設置爲gbk：

　　set character_set_database=gbk;
　　set character_set_server=gbk;
  　 show variables like '%char%';

　　

　　

咱們發現database和server都變成了gbk，而後咱們再從新建立一個數據庫，查看其編碼，

　　create dabase test2;
　　show create dabase test2;

　　

 　　 

　　咱們發現數據庫編碼已經變爲gbk了。

　　可是咱們將此窗口關閉後，從新打開一個新的窗口來鏈接數據庫，從新查看數據庫的編碼，發現不是咱們剛剛修改的gbk了，仍是原來的utf-8。如圖：

　　 

　　由於是基於會話級別的改變編碼的方式，當從新新建一個窗口鏈接的時候，會話已經改變，因此變爲了原來的字符編碼。

5.2 設置全局編碼，永久性改變

1.設置全局的數據庫字符編碼，即便基於整個MySQL服務的，當重啓MySQL服務的時候，編碼依然會變爲原來的字符編碼

　　set global character_set_database=gbk;
　　set global character_ser_server=gbk;
　　show variables like '%char%';

　　

　　 

　　咱們發現數據庫的編碼沒有修改爲功，仍是原來的utf-8。可是當咱們從新建立數據庫或者從新建立表的時候，編碼就會是咱們所指望的gbk了。

　　在本窗口的新建數據庫是確定能夠的，session級別的均可以，全局的確定ok的。重點是在另外一個窗口中的編碼現實的是什麼，下面咱們複製一個窗口，新建數據庫，來查看數據庫和表的編碼

　　create database test3;
　　show variables like '%char%';

　　

　　 

　　咱們發現這是沒有問題的。

　　可是咱們重啓MySQL數據庫的時候，編碼又是回覆爲原來的utf-8了。

2.設置永久的字符編碼，即須要在配置文件中修改數據庫的字符編碼

　　編輯 /etc/my.cnf，

　   在裏面加入，已經有[XXX]的，在裏面直接加入便可。 

　　　　[mysqld]
　　　　character-set-server=utf8 
　　　　[client]
　　　　default-character-set=utf8 
　　　　[mysql]
　　　　default-character-set=utf8

　　

　　而後重啓數據庫便可，service mysql restart.

必定要注意：修改完的數據庫和庫裏的表 並不會使原來的數據生效，而是新加入的數據纔會生效。

5.3 一勞用逸

　　在 MySQL 的安裝目錄下有一個 my.ini 配置文件，經過修改這個配置文件能夠一勞永逸的解決亂碼問題。在這個配置文件中 [mysql] 與客戶端配置相關，[mysqld] 與服務器配置相關。默認配置以下：

 

[mysqld]
character-set-server=utf8
collation-server=utf8_general_ci
[client]
default-character-set=utf8
[mysql]
default-character-set=utf8

 

　　這時只須要將下的默認編碼 default-character-set=utf8 改成 default-character-set=gbk ，從新啓動 MySQL 服務便可。

[mysqld]
character-set-server=utf8
collation-server=utf8_general_ci
[client]
default-character-set=gbk
[mysql]
default-character-set=gbk

　　修改以後，直接上圖：

 

 

 5.4  修改數據庫字符編碼

mysql> alter database mydb character set utf8 ;

　　

六，檢測字符集問題的一些手段

SHOW CHARACTER SET;

• SHOW COLLATION;

• SHOW VARIABLES LIKE ‘character%’;

• SHOW VARIABLES LIKE ‘collation%’;

• SQL函數HEX、LENGTH、CHAR_LENGTH

• SQL函數CHARSET、COLLATION

　　

使用MySQL字符集時的建議

• 創建數據庫/表和進行數據庫操做時儘可能顯式指出使用的字符集，而不是依賴於MySQL的默認設置，不然MySQL升級時可能帶來很大困擾；

• 數據庫和鏈接字符集都使用latin1時雖然大部分狀況下均可以解決亂碼問題，但缺點是沒法以字符爲單位來進行SQL操做，通常狀況下將數據庫和鏈接字符集都置爲utf8是較好的選擇；

• 使用mysql C API時，初始化數據庫句柄後立刻用mysql_options設定MYSQL_SET_CHARSET_NAME屬性爲utf8，這樣就不用顯式地用 SET NAMES語句指定鏈接字符集，且用mysql_ping重連斷開的長鏈接時也會把鏈接字符集重置爲utf8；

• 對於mysql PHP API，通常頁面級的PHP程序總運行時間較短，在鏈接到數據庫之後顯式用SET NAMES語句設置一次鏈接字符集便可；

但當使用長鏈接時，請注意保持鏈接通暢並在斷開重連後用SET NAMES語句顯式重置鏈接字符集。

 

其餘注意事項

• my.cnf中的default_character_set設置隻影響mysql命令鏈接服務器時的鏈接字符集，不會對使用libmysqlclient庫的應用程序產生任何做用！

• 對字段進行的SQL函數操做一般都是之內部操做字符集進行的，不受鏈接字符集設置的影響。

• SQL語句中的裸字符串會受到鏈接字符集或introducer設置的影響，對於比較之類的操做可能產生徹底不一樣的結果，須要當心！