[轉載]MySQL 的 "SET NAMES xxx" 字元編碼問題分析 | Vixual

先說 MySQL 的字符集問題。Windows 下可透過修改 my.ini 內的
# CLIENT SECTION
[mysql]
default-character-set=utf8
# SERVER SECTION
[mysqld]
default-character-set=utf8
這兩個字段來更改資料庫的預設字符集。第一個是客戶端預設的字符集，第二個是伺服器端預設的字符集。假設我們把兩個都設為 utf8，然後在MySQL Command Line 裡面輸入 “show variables like ‘character%’;”，可看到如下結果：

character_set_client latin1
character_set_connection latin1
character_set_database utf8
character_set_results latin1
character_set_server utf8
character_set_system utf8
其中的 utf8 隨著我們上面的設置而改動。此時，要是我們透過採用 UTF-8 的 PHP 程式從資料庫裡讀取資料，很有可能是一串 “?????” 或者是其他亂碼。網上查了半天，解決辦法倒是簡單，在連結資料庫之後，讀取資料之前，先執行一項查詢 “SET NAMES UTF8″，即在 PHP 裡為

mysql_query("SET NAMES UTF8");
即可顯示正常（只要資料庫裡資料的字元正常）。為什麼會這樣？這句查詢 “SET NAMES UTF8″ 到底是什麼作用？

到 MySQL 命令行輸入 “SET NAMES UTF8;”，然後執行 “show variables like ‘character%’;”，發現原來為 latin1 的那些變數 “character_set_client”、”character_set_connection”、 ”character_set_results” 的值全部變為 utf8 了，原來是這 3 個變數在搗蛋。

查閱手冊，上面那句等於：

SET character_set_client = utf8;
SET character_set_results = utf8;
SET character_set_connection = utf8;
看看這 3 個變數的作用：

資料輸入路徑：client → connection → server；

資料輸出路徑：server → connection → results。

換句話說，每個路徑要經過 3 次改變字符集編碼。以出現亂碼的輸出為例，server 裡 utf8 的資料，傳入 connection 轉為 latin1，傳入 results 轉為 latin1，utf-8 頁面又把 results 轉過來。如果兩種字符集不相容，比如 latin1 和 utf8，轉化過程就為不可逆的，破壞性的。所以就轉不回來了。

但這裡要聲明一點，”SET NAMES UTF8″ 作用只是臨時的，MySQL 重啟後就恢復預設了。