[分享]MySQL 4.1+ 的轉碼方式
發表於 : 2006-05-15 18:30
從 MySQL 4.0 之前的版本升級到 MySQL 4.1 會碰到兩個很常見的問題，一是 password hashing 更動導致舊的 mysql client 沒辦法登入新的 server，這個問題可以參考小弟 blog 或是站內其他網友的討論解決。
另外一個問題比較讓人頭疼，就是 character set 的問題。很多人的資料內容莫名奇妙的被轉來轉去，到最後內容就炸光光了。包括我在內，有很多人都是因為升級上去然後發現內容怪怪的，又手賤去改 collation，然後原本還會正常的編碼就被一直轉來轉去，到最後就整個掰掰謝謝惠顧了。所以趁機提醒還沒升級要打算升級的人，升級前千萬要記得備份你的資料庫！
回到正題，新的 MySQL 多了幾個環境變數來定義 charset，character_set_client, character_set_connection, character_set_database, character_set_results, character_set_server, character_set_system。MySQL 會把使用者的輸入做 character_set_client -> character_set_connection 的轉換 (把輸入的內容當成是 client 的編碼方式，然後轉換成 connection 的編碼)，輸出則是依照 data 的 charset (MySQL 可以自訂各 table 的 charset 和 collation) 轉換成 character_set_result 來輸出。而一般我們加上
這段 (不管是直接加在 msql_connect 後面或是直接加在 my.ini 裡面) 為的是把 client, connection, result 這三個變數設定成 utf8，配合上原本的 UTF8 HTML 才會達到我們的目的，就是這麼一回事。為什麼要特別指定呢？因為不特別指定的話這幾個變數 default 值是 latin1，把 utf8 被當成 latin1 處理會把很多中文字給弄爛，所以網頁和 MySQL 要都設定成 utf8 才不會有問題出現。
明白這件事情了以後，我們可以在程式裡面利用 MySQL 做 charset 的轉換，資料庫裡面可以都放 utf8 的內容，但是在 I/O 上轉成 big5 (或是其他 charset) 來達到我們的目的，而不必像之前一樣另外用 iconv 來轉換。
另外一個問題比較讓人頭疼，就是 character set 的問題。很多人的資料內容莫名奇妙的被轉來轉去，到最後內容就炸光光了。包括我在內，有很多人都是因為升級上去然後發現內容怪怪的，又手賤去改 collation，然後原本還會正常的編碼就被一直轉來轉去，到最後就整個掰掰謝謝惠顧了。所以趁機提醒還沒升級要打算升級的人，升級前千萬要記得備份你的資料庫！
回到正題，新的 MySQL 多了幾個環境變數來定義 charset，character_set_client, character_set_connection, character_set_database, character_set_results, character_set_server, character_set_system。MySQL 會把使用者的輸入做 character_set_client -> character_set_connection 的轉換 (把輸入的內容當成是 client 的編碼方式，然後轉換成 connection 的編碼)，輸出則是依照 data 的 charset (MySQL 可以自訂各 table 的 charset 和 collation) 轉換成 character_set_result 來輸出。而一般我們加上
代碼: 選擇全部
SET NAMES utf8;明白這件事情了以後，我們可以在程式裡面利用 MySQL 做 charset 的轉換，資料庫裡面可以都放 utf8 的內容，但是在 I/O 上轉成 big5 (或是其他 charset) 來達到我們的目的，而不必像之前一樣另外用 iconv 來轉換。
