mysql的字符集設置眾多，從客戶端到連接到結果集，從服務器到庫到表到列，都可以設置字符集，靈活很強大，但就是很容易出問題，如果不了解其機制，很容易就出現亂碼問題。
為了讓大家盡量在工作中少受或者不受亂碼的困擾，這裡我結合之前其它同學在論壇的發帖，並結合自己的理解和實踐，詳細分析總結了一下，以飨各位看官。
關於字符集和亂碼的基礎知識這裡就不詳細說明了（請自行搜索），但有一個問題需要特別強調一下：亂碼是怎麼產生的？
這個問題相信很多同學都是模稜兩可，或者沒有認真想過，反正理解就是”字符編碼“不對導致亂碼，但沒有真正想過為什麼”字符編碼“會導致亂碼。
答案其實很簡單：“轉換導致亂碼”！
根據這個原則來判斷，各種情況就很簡單了：
1）數據傳送過程中不會導致亂碼
2）數據存儲不會導致亂碼
3）數據輸入和輸出（包括顯示）可能導致亂碼
4）數據接收和發送可能導致亂碼
更詳細的解釋：轉換導致亂碼是指本來是A字符集的數據被當成了B字符集進行解析，而不是說正確的A字符集轉換為B字符集。
例如：如下mysql字符處理機制流程圖中，mysql客戶端發送的實際上是2個gbk字符（4字節），但character_set_connection
設置了utf8，於是mysql服務器將收到的4字節gbk數據按照utf8解析，得到1個中文字符+1個字節，這時就產生亂碼了；
如果character_set_connection 設置為gbk，mysql服務器收到數據後按照gbk解析，得到兩個正確的中文，然後再轉換為這兩個中文對應的utf8編碼，這就不會產生亂碼。）
【mysql的字符處理機制】
詳細的處理機制如下圖：
我們模擬一下一條數據從插入到讀取的處理流程，看看在整個流程中，字符集是如何輾轉騰挪的。
【插入流程】
1. 客戶端設定了自己的編碼（character_set_client），接收用戶的輸入；
2. 客戶端將用戶的輸入“轉換”成連接的編碼（character_set_connection） =====> 第一次轉換
3. 客戶端將轉換後的數據發送給服務器； =====> 傳輸不會導致編碼轉換
4. 服務器收到客戶端的數據，再判斷數據列的字符集，進行字符轉換 =====> 第二次轉換
5. 服務器將數據存儲（例如磁盤） =====> 存儲不會導致編碼轉換
【讀取流程】
略去前面的sql語句處理流程，從數據讀取開始
1. 服務器從存儲（例如磁盤）讀取數據 =====> 存儲不會導致編碼轉換，因此從存儲讀取也不需要
2. 服務器判斷當前連接返回結果的字符集（character_set_results），
將讀取的數據轉換為結果集要求的數據 =====> 逆向的第一次轉換，對應正向的第二次編碼轉換
3. 服務器將數據發送給客戶端 =====> 傳輸不會導致編碼轉換
4. 客戶端收到服務器的數據，根據客戶端的字符集（character_set_client）進行編碼轉換 =====> 逆向第二次轉換，對應正向第一次編碼轉換
5. 客戶端顯示數據 =====> 你能看到亂碼的時候
有了這個流程，我們就很容易定位亂碼可能產生的地方，以及產生亂碼的字符集配置究竟是哪個了。
理想的情況是整個流程中，所有涉及字符轉換的地方都不需要轉換，這樣就不會產生亂碼了。
有了上面的理論分析後，我們再結合一個亂碼的抓包實例，加深理解，其中有一些問題，請大家思考一下，看看是否真的理解了。
環境：
+--------------------------+-----------------------------------------------------+
| Variable_name | Value |
+--------------------------+-----------------------------------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | utf8 |
| character_set_filesystem | binary |
| character_set_results | latin1 |
| character_set_server | utf8 |
測試語句是插入一個中文字符“你”，其utf8編碼為"0xE4 0xBD 0xA0"，
1. latin1發送包
思考一下1：為什麼客戶端和連接都設置了latin1，但最終發送的是正確的utf8編碼呢？
2. latin1接收包
思考一下2：為什麼接收到的還是正確的utf8編碼？
3. latin1不顯示亂碼
思考一下3：為什麼latin1顯示了正確的utf8字符？
4. utf8接收包
思考一下4：為什麼連接的字符集和數據庫的字符集設置成一樣了，接收的數據反而不是utf8了？（請與latin1接收數據包對比）
5. utf8顯示包
思考一下5：為什麼連接的字符集和數據庫的字符集設置成一樣了，顯示反而亂碼了？
怎麼樣，上面的思考題是否都有答案了，如果沒有，相信下面這幅圖能夠幫助你：
這個抓包案例的字符變化圖解：
附：mysql字符編碼操作技巧
【查看字符集設置】
mysql> show variables like '%char%'; +--------------------------+-----------------------------------------------------+ | Variable_name | 說明 | +--------------------------+-----------------------------------------------------+ | character_set_client | 客戶端字符集 | | character_set_connection | 當前連接字符集 | | character_set_database | 數據庫字符集 | | character_set_filesystem | 文件系統字符集，不要修改，使用binary即可 | | character_set_results | 返回結果集字符集 | | character_set_server | 服務器默認字符集，當數據庫、表、列沒有設置時， | | | 默認使用此字符集 | | character_set_system | 固定為utf8 | +--------------------------+-----------------------------------------------------+
【修改字符集設置】
服務器的配置在服務器建立的時候就由DBA設置好了，不推薦後續再改
通過SET NAMES utf8命令同時設置character_set_client/character_set_connection/character_set_results的字符集
建議所有配置都設置成utf8
【問題答案】
思考一下1：為什麼客戶端和連接都設置了latin1，但最終發送的是正確的utf8編碼呢？
客戶端設置了latin1，而我的語句是從notepad++中寫好的，是utf8格式的；
中文utf8是3個字節，而latin1是按照單個字節解析的，雖然進行了轉換，但不會導致二進制內容的變化，但實際上mysql客戶端認為我輸入了3個latin1字符；
如果客戶端設置的編碼是2個字節的gbk，這時轉換就會發生亂碼，utf8的3個字節會被轉換為1個gbk字符（可能是亂碼，也可能不是亂碼）加上一個西歐字符（小於128就是英文，大於128就是其它西歐文）
思考一下2：為什麼接收到的還是正確的utf8編碼？
這是因為mysql服務器從將數據從“列”的編碼（utf8）轉換為latin1了，而列存儲的數據並不是真正的utf8的中文“你”對應的"0xe4 0xbd 0xa0"，
而是後面抓包看到的“c3a4 c2bd c2a0”（6個字節），mysql服務器將utf8的c3a4轉換為latin1的0xe4，c2bd轉換為0xbd, c2a0轉換為0xa0
思考一下3：為什麼latin1顯示了正確的utf8字符？
因為mysql客戶端收到了mysql服務器轉換後的"0xe4 0xbd 0xa0"，並把這個數據當做latin1的3個字符處理，然後拋給終端（我的是SecureCRT），
SecureCRT又把這三個latin1當做uft8處理，結果中文的“你”就顯示出來了。
思考一下4：為什麼連接的字符集和數據庫的字符集設置成一樣了，接收的數據反而不是utf8了？（請與latin1接收數據包對比）
字符集都一樣的情況下，整個流程中不需要進行編碼轉換，直接將存儲的“c3a4 c2bd c2a0”返回給客戶端
思考一下5：為什麼連接的字符集和數據庫的字符集設置成一樣了，顯示反而亂碼了？
參考思考4，客戶端收到數據後也直接拋給終端顯示，終端認為是兩個utf8字符，並且找到了對應字符並顯示，但我們看不懂，所以知道是亂碼了，但這兩個字符顯示並沒有錯，如果真正找不到字符，可能會顯示問號或者字符集規定的缺省符號。
以上就是關於MySQL亂碼問題大集合，希望能夠幫助大家解決MySQL亂碼問題，謝謝大家的閱讀。
