MySQL亂碼

最近幫一台Web伺服器裡的drupal網站作搬遷，從MySQL 4.0.X遷移到5.0.X的環境中，果然馬上遇到了傳說中的亂碼大戰。

drupal眾所皆知是以utf8編碼的，因此他的資料庫也是以utf8編碼，照理來說移植到新的環境應該不會出錯，沒想到將MySQL dump檔案匯入新環境後，出來的中文全成了亂碼，連在新環境直接輸入中文也會變成亂碼，我的臉也當場綠了。趕緊上網找解法，沒想到關鍵字一進去，居然讓我找出了十數種解法，每種解法背後的原理都不一樣，有的是從php著手，有的是改動MySQL的起始參數，玲瑯滿目令我頭昏眼花。

每一種解法都去試實在折磨人，因此我用了對照法來偵查到底是哪個環節出現錯誤，以對症下藥。首先，我在新環境中安裝了另一個版本一模一樣的drupal，發現它可以正確輸入輸出中文，這代表我的安裝環境的確可以讓循規蹈矩的drupal正常處理utf8，但是用偷雞摸狗法遷移過去的drupal則不行。

既然知道了，接下來的解決手段就簡單多了，我們只要把這兩個drupal的每個面向都弄得一模一樣或許就能解決問題！因此我將舊主機的drupal資料庫以mysqldump不加參數的情況輸出old.sql，新主機的對照組drupal一樣處理，得到new.sql，接著比較他們的同異點。我發現這兩份.sql檔都是純純正正的utf8編碼，以firefox瀏覽這兩個檔案，在utf8檢視環境下都可以看到中文，換句話說新舊版本的mysql輸出的過程是正常的。因此，問題應該就出在輸入的過程有錯吧！趕緊將old.sql與new.sql的相異處修正，將這分修改過參數的old.sql扔進新環境，結果在drupql出現的又是亂碼！嗯，問題就出在這裡了。

我將mysqladmin的參數列印出來，找找新舊mysql server的編碼是不是出現問題，新server的參數長這樣：

| 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 | latin1
| collation_connection | latin1_general_ci
| collation_database | latin1_general_ci
| collation_server | latin1_general_ci

這代表甚麼意思呢？意思就是說當我們把.sql輸入這個server時，無論他是甚麼樣的編碼，一律當成latin1處理！難怪我們的utf8會變成亂碼！因為他在存進資料庫時就已經幫我們亂轉一通了，因此我以這篇文章提到的方式將參數改成utf8編碼，問題的核心就在他的文章中的一段話：

下面的 client 則是設定當 client 連線時要使用什麼語系，但可惜的是這個設定不是每個client都會鳥它，基本上只有 mysql 自已家的程式，例如 mysql.exe, mysqld.exe, mysqladmin.exe 或是 MySQL Control Center這種程式會去讀取這個設定檔然後改用 utf8 連線。

當我改完設定重啟mysql後，將old.sql重新餵進mysql server之後，好久不見的utf8中文終於重回我的drupal網站了，可喜可賀！

從這件事，我學到了一個經驗：若是一件事情有錯，先找另一個成功的case，然後盡量修改自己失敗case的條件，讓它與成功者越相像越好，在檢查每個環節是否相像的流程時，往往能找到問題的癥結，進而解決它！有時整個流程不必做完，問題就已迎刃而解囉。