因為 MySQL 的編碼真的會整死人。

4.0 以前進去的 big5 資料，不會因為他是 latin1 語系，dump 出來就變成 latin1，會仍然還是 big5 。是 utf8 進去的，也還是 utf8 出來。

4.0 倒出來的資料回不去 4.1 or 5.0 ，大部分還是出在 『許功蓋』上∼

我也清楚 mysql 4.0 以前是用 latin1 ，不過我們公司的 mysql 有做過不一樣的設定，這點我並沒有寫出來。

其實這些匯入匯出和 mysql 的字元校對、 client 和 server 端的預設編碼還有 phpMyAdmin 的 Language 設定都有很大的關係，我也是弄了很久才搞懂。

改天寫個比較完整的說明好了，畢竟這種不負責任的寫法有點糟糕。

從mysql4.0匯出的資料表 是latin1的編碼，所以說latin1不認識中文字是錯的，
事實上在mysql4.0以前，不管是用big5還是utf8，存入資料庫都是latin1

因此再匯入mysql4.1或5時，要選latin1的格式，就可以了

但是當你再重4.1或5的mysql匯出備份，再匯回來時，就會發現一定失敗

試試便知:)

還有設定 default-character-set=big5 之後，在 PHP 上開發時你就得更注意 magic-quotes 所帶來的影響，因為像是 PEAR::DB 或是直接使用 mysql_* 函式所開發的程式，當你用 addslashes 或 stripslashes 時，都要小心許先生會把你吃垮。

其實解決的方式很多，已經有很多高手提出來了，所以這裡我就不再多說囉。

phpMyAdmin + MySQL 4.0 轉出許功蓋時會變成：「許\功\蓋\」。

所以用 utf-8 … 不行。雖然先把匯出的 SQL 轉成 utf-8 ，但因為「反斜線」部份會造成 SQL 指令錯誤，必須一個一個去濾掉，不過太麻煩，不符合我偷懶的個性。

big5 … 也不行， big5 這個土生土長的台灣人雖然看得懂中文字，但是「反斜線」這個拖油瓶一樣會造成 SQL 指令錯誤。

latin1 … 可以，但是存進去的中文字已經變問號，因為 latin1 這個喝洋水的不認得中文字。

binary … 可以， MySQL 5.0 會完整的把資料放到對應的欄位，如果資料庫「校對」正確的話，那麼中文就會 OK 。

有沒有試過先把資料轉成 utf8 然後再去匯入？