看《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搭配之最佳組合)千萬不要讓我重蹈覆轍。
http://www.bkjia.com/PHPjc/508663.htmlwww.bkjia.comtruehttp://www.bkjia.com/PHPjc/508663.htmlTechArticle看《O’Reilly Upgrading to php (做為現在的主流開發語言) 5》的時候，心血來潮，把MySQL (和PHP搭配之最佳組合) 升級到了4.1.11，由於機器上沒有什...
