如果是奔著解決問題而來,請直接跳到 四.5 希望能對你們有所幫助

一、前言

第一段話寫給自己:早在一年多前,剛剛上手mysql的時候,就對windows命令列下的mysql中文亂碼現象有所見聞。心裡也一直對此懷有芥蒂,畢竟之前是通過Navicat等資料庫視覺化工具來檢視資料,相當於是對這個現象強行視而不見,草草了事。現如今當我有興趣解決這個問題的時候,才發現這個問題的難度著實不小,耗費了一個下午的精力,才算是誤打誤撞解決了這個問題,特此寫下這篇部落格給自己和那些同樣遇到該問題的同學們,幫助消化該問題,一起尋找這個解決方法的本質到底是什麼。

二、背景

剛開始時,我認為以前遇到的亂碼問題是由部分character的值為latin1造成的(此時在我的腦海中,這個問題的本質是在客戶端方面新輸入的中文由utf8編碼表示,而儲存時要經過latin1與utf8之間相互轉換,因為兩種編碼之間的不相容問題所以才會造成中文變成了亂碼,後來的事實證明,這種想法是片面的、錯誤的),因此,我提前打了預防針,也就是將資料庫的那些characters能設為utf8的都設為utf8的格式(如下圖)

 

各個字符集的含義如下

三、從發現問題到提出問題:

而後,當我信心滿滿的重新建表測試的時候,遇到了比之前更為嚴重的中文無法相容問題。

建表語句為:

create table test(
num int(11) AUTO_INCREMENT,
words varchar(10) not null unique,
primary key(num)
)ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE utf8_general_ci;

先簡略描述出遇到的問題:

插入中文時,中文全部變為空白(連空格都沒),並且所有中文都受到UNIQUE約束的限制!這個限制在這裡的意思是什麼呢,不論你輸入的中文為不同的字也好不同的句子也好,統統都被認定為相同輸入——"" (即圖片所表示的空白字元,而這個特殊字元應該暫時沒什麼故事,先不做討論) 具體如圖:

圖1.1

圖1.2

 

 

圖1.1中的第二次中文插入,產生了報錯—error1062,該報錯意思即為,對"列2"進行了相同的插入,報錯原因是在UNIQUE的約束下,將兩次中文輸入都視為同一個空白串。

圖1.2表示在navicat中,中文插入被資料庫切切實實的存成了空白串。

這個錯誤顯然是一個重大阻礙,不止影響了我們對中文字元的檢視,還直接影響了我們對中文字元進行的輸入輸出。

四、從分析問題到解決問題

首先,我是通過以下幾步操作,才最終確定問題出現的源頭(應該是源頭吧¬_¬)

1.在Navicat端,我將第三行的空白串欄位修改為"你好",而在命令列的mysql客戶端卻顯示為亂碼,因此我得出結論編碼問題一定出在mysql客戶端上,而原因可能有很多,需要進一步確定

2.隨後我檢查了命令提示符的編碼格式,發現為GBK,我彷彿聞到了一絲陰謀的味道

3.我決定將命令提示符的編碼改為和mysql客戶端一致的編碼——utf8,在cmd中輸入如下指令:chcp 65001 

並將字型修改為廣為推薦的Lucida Console字型,以獲得更好的相容性

 

4.開啟mysql客戶端,重新插入語句,結果直接退出了mysql客戶端了,此刻的我已經一臉懵逼

5.不敗不餒,看來將命令提示符的編碼修改為utf8這條路行不通,我決定將狀態退回第3步前。接著來,修改mysql客戶端的編碼,使其與改為和命令提示符一致的編碼——GBK

(1)通過mysql指令:  set names gbk;   來修改客戶端的編碼格式

(2)通過指令:show variables like "%char%";   來檢視修改後的客戶端的編碼格式

(3)對測試表進行中文字元的插入

搞定!

PS:如果不想每次登陸資料庫後都使用set names gbk;指令來修改編碼,可以在配置檔案my.ini中新增或修改為下列語句:

[client]
default-character-set=gbk

這樣就能夠永久儲存編碼的修改了。

終於寫完了,謝謝自己也謝謝大家。