MySQL亂碼的具體原因和如何設置UTF8數據格式

本文主要給大家介紹MySQL亂碼的具體原因和如何設置UTF8數據格式，文章內容都是筆者用心摘選和編輯的，具有一定的針對性，對大家的參考意義還是比較大的，下面跟筆者一起了解下MySQL亂碼的具體原因和如何設置UTF8數據格式吧。                                                            

MySQL使用時，有一件很痛苦的事情肯定是結果亂碼。將編碼格式都設置為UTF8可以解決這個問題，我們今天來說下為什么要這么設置，以及怎么設置。

MySQL字符格式

字符集

在編程語言中，我們為了防止中文亂碼，會使用unicode對中文字符做處理，而為了降低網絡帶寬和節省存儲空間，我們使用UTF8進行編碼。對這兩者有什么不同不夠了解的同學，可以參考Unicode字符集和UTF8編碼編碼的前世今生這篇文章。

同樣在MySQL中，我們也會有這樣的處理，我們可以查看當前數據庫設置的編碼方式（字符集）：

mysql> show variables like '%char%';
+--------------------------+----------------------------------+
| Variable_name            | Value                            |
+--------------------------+----------------------------------+
| character_set_client     | latin1                           | 
| character_set_connection | latin1                           | 
| character_set_database   | latin1                           | 
| character_set_filesystem | binary                           | 
| character_set_results    | latin1                           | 
| character_set_server     | latin1                           | 
| character_set_system     | utf8                             | 
| character_sets_dir       | /usr/local/mysql/share/charsets/ | 
+--------------------------+----------------------------------+
8 rows in set (0.00 sec)

表中就是當前設置的字符集，先看不用關注的幾個值：

character_set_filesystem | binary：文件系統上的存儲格式，默認為binary（二進制）

character_set_system     | utf8：系統的存儲格式，默認為utf8

character_sets_dir       | /usr/local/mysql/share/charsets/：可以使用的字符集的文件路徑

剩下的幾個就是日常影響讀寫亂碼的參數了：
- character_set_client：客戶端請求數據的字符集
- character_set_connection：從客戶端接收到數據，然后傳輸的字符集
- character_set_database：默認數據庫的字符集；如果沒有默認數據庫，使用character_set_server字段
- character_set_results：結果集的字符集
- character_set_server：數據庫云服務器的默認字符集

字符集的轉換流程分為3步：

1、客戶端請求數據庫數據，發送的數據使用character_set_client字符集

2、MySQL實例收到客戶端發送的數據后，將其轉換為character_set_connection字符集

3、進行內部操作時，將數據字符集轉換為內部操作字符集：

（1）使用每個數據字段的character set設定值

（2）若不存在，使用對應數據表的default character set設定值

（3）若不存在，使用對應數據庫的default character set設定值

（4）若不存在，使用character_set_server設定值

4、將操作結果值從內部操作字符集轉換為character_set_results

字符序

說字符序之前，我們需要了解一點基礎知識：

字符(Character)是指人類語言中最小的表義符號。例如’A’、’B’等；

給定一系列字符，對每個字符賦予一個數值，用數值來代表對應的字符，這一數值就是字符的編碼(Encoding)。例如，我們給字符’A’賦予數值0，給字符’B’賦予數值1，則0就是字符’A’的編碼；

給定一系列字符并賦予對應的編碼后，所有這些字符和編碼對組成的集合就是字符集(Character Set)。例如，給定字符列表為{‘A’,’B’}時，{‘A’=>0, ‘B’=>1}就是一個字符集；

字符序(Collation)是指在同一字符集內字符之間的比較規則；

確定字符序后，才能在一個字符集上定義什么是等價的字符，以及字符之間的大小關系；

每個字符序唯一對應一種字符集，但一個字符集可以對應多種字符序，其中有一個是默認字符序(Default Collation)；

MySQL中的字符序名稱遵從命名慣例：以字符序對應的字符集名稱開頭；以_ci(表示大小寫不敏感，case insensitive)、_cs(表示大小寫敏感，case sensitive)或_bin(表示按編碼值比較，binary)結尾。例如：在字符序“utf8_general_ci”下，字符“a”和“A”是等價的；

因此字符序不同于字符集，用于數據庫字段的相等或大小比較。我們查看MySQL實例設置的字符序：

mysql> show variables like 'collation%';
+----------------------+-------------------+
| Variable_name        | Value             |
+----------------------+-------------------+
| collation_connection | latin1_swedish_ci | 
| collation_database   | latin1_swedish_ci | 
| collation_server     | latin1_swedish_ci | 
+----------------------+-------------------+
3 rows in set (0.00 sec)

跟utf8對應的常用字符序是：utf8_unicode_ci/utf8_general_ci和utf8_bin等，那么他們的區別是什么呢？

1、_bin是用二進制存儲并比較，區別大小寫，存儲二進制內容時使用

2、utf8_general_ci：校對速度快，但準確度稍差，使用中英文時使用

3、utf8_unicode_ci：準確度高，但校對速度稍慢，使用德法俄等外語時使用

詳細的區別可以參考 Mysql中的排序規則utf8_unicode_ci、utf8_general_ci的區別總結。

修改字符集和字符序

如果在MySQL連接時，出現了亂碼的問題，那么基本可以確定是各個字符集/序設置不統一的原因。MySQL默認的latin1格式不支持中文，由于我們在中國，所以選擇對中文和各語言支持都非常完善的utf8格式。所以，我們需要將需要關注的字符集和字符序都修改為utf8格式。

你也可以選擇utf8mb4格式，這個格式支持保存emoji

看完以上關于MySQL亂碼的具體原因和如何設置UTF8數據格式，很多讀者朋友肯定多少有一定的了解，如需獲取更多的行業知識信息 ，可以持續關注我們的行業資訊欄目的。