看《O’Reilly Upgrading to php(做為現在的主流開發語言) 5》的時候，心血來潮，把MySQL(和PHP搭配之最佳組合)升級到了4.1.11，由於機器上沒有什麼正式系統，也就沒有注意到它字符集的變化。後來就把正式應用的系統也給升級了，升級之後其它系統都沒問題，唯獨一個MANTIS有了麻煩，打開頁面都成了亂碼，幸虧有備份可以恢復，在恢復的過程中就發現了MySQL(和PHP搭配之最佳組合)升級帶來的字符集的問題－－如果MySQL(和PHP搭配之最佳組合)用UTF8字符集，MANTIS數據導入之後，頁面顯示亂碼，無奈只得把MySQL(和PHP搭配之最佳組合)調為GBK字符集。
其實我還是願意使用UTF8字符集的，因為沒有不兼容的麻煩，作為長久保留的數據，日後轉換、整理起來比較省事；在與外部進行數據交換的時候，也不存在編碼轉換的問題。可是我始終不明白，在使用php(做為現在的主流開發語言)連接MySQL(和PHP搭配之最佳組合)接收用戶輸入數據，並存入數據庫的時候，如果數據庫編碼是UTF8，是否要把SQL數據也轉換為UTF8？抽空弄個小程序試試，如果真是這樣那可就麻煩大了，不過我在DOS下用命令行操作UTF8字符集的MySQL(和PHP搭配之最佳組合)服務器是沒法輸入漢字的。
以前使用SYBASE的時候曾經被字符集的問題困擾了很久，因為SYBASE如果字符集用錯了，某些漢字根本就無法輸入，比如大寫的零“○”，所以字符集從iso_1換到cp850，又從cp850換到cp936，中間捨棄了很多歷史數據，MySQL(和PHP搭配之最佳組合)千萬不要讓我重蹈覆轍。
