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}就是一個字元集；

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

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

每個字元序唯一對應一種字元集，但一個字元集可以對應多種字元序，其中有一個是預設字元序(Default Collat​​ion)；

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資料格式的方法介紹的詳細內容。更多資訊請關注PHP中文網其他相關文章！