最近 gslin 的 blog 因為 MySQL 資料庫的 encoding 問題，發生異常現象，只好從零開始。無獨有偶地，Pesty 最近也處理了 MySQL 使用 UTF-8 的相關問題。

這些問題之所以會發生，是因為越來越多的 web application 套件使用 UTF-8 儲存資料，但大家在設定 MySQL 時卻都沒有注意到這點，仍然使用預設的 latin1 作為資料庫的 encoding。Web application 餵入 UTF-8 資料，MySQL 卻當作 latin1 在讀，雖然 web application 讀回來的時候，因為剛好是反向處理，資料看似沒有任何異常，但實際上 collation 是錯的，當進行移機、備份甚至轉換 web application 時，也都會發生問題。

我一年多前也有遇到類似的問題，原本在公司有個用 phpBB2 架的 forum，採用 big5 編碼，但實際上 mysql-3.23 裡是用 latin1 存。想要轉換成 UTF-8，移機到 FreeBSD 5 上改用 mysql-4.1，就發生問題了。我那時沒有解決，所以 phpBB2 移機計畫暫緩了一年多，但實在是多跑一個 virtual machine 只為了這個移不過來的 phpBB2，實在浪費記憶體。剛好看到 gslin 與 pesty 最近也在弄這個問題，就重新試了一遍步驟如下：

  1. 用 mysqldump 自 mysql-3.23 倒出來，發現必須加上 --default-character-set=latin1 的參數，才能正確倒出實際上是用 big5 的 phpBB2 的資料庫。
  2. 用 iconv -c -f CP950 -t UTF-8 將倒出來的 SQL 轉成 UTF-8。必須要加 -c，否則會死在半路。換句話說，其實中間已經有東西爛掉了。
  3. 進 mysql 用 SET GLOBAL/SESSION character_set_XXX=utf8 調整 system variables，將 charset 與 collation 通通改成 UTF-8，然後做 CREATE DATABASE phpbb2。
  4. 再用 SOURCE 指令把剛剛用 iconv 轉出來的 SQL 檔倒回來。

結果在第四個步驟裡，mysql (client) 就 core dump 了。猜測有可能是第二步用 -c 硬轉時，把某個指令搞爛了。不過 mysql (client) 是直接 core dump 而不是跑 error message 出來指出錯誤何在，所以這下難辦了，只能靠 iconv 不加 -c 想辦法慢慢抓問題。