Hi! I’m clsung

先看看這個，裡面提到重要的一點，有 SUPER 權限的 user 在連線的時候不會去執行 init_connect 。這好像說明了很多人為什麼都要在連線後自己加上 ‘SET NAMES UTF8′ 了。

根據實驗結果，如果你像我一樣，在很久以前（大概在 mysql 3.x 的時期）就開始將：

放在心上，啊不，是放在 /etc/make.conf （還在用 linux 嗎？趕快換 FreeBSD 吧）裡。那麼你應該都不會出現各家長輩們哀嚎的畫面。

不過很不幸地，在某一台上，我忘了做這件事，所以被 mysql 狠狠地修理了好幾天。事情緣起於我想把 blog 系統由 plog 換成 wordpress，沒想到由 f0rth 寫的 plog2wp.rb 竟然跑出亂碼來，明明在資料庫裡，怎麼看都是 utf8 ，連 mysqldump 也是 utf8，但只要由程式去連線，就死了。（奇怪，上面的網頁明明寫說 root 連線不執行 ini_connect，為什麼 mysqldump 出來是正確的？啊 ruby 等 client 連線就是錯的？）

這裡還有一點要先提。不管資料庫裡面的實際儲存 encoding 為何（可以用 vim 去直接讀資料庫檔案看看），在網頁上各個資料庫呈現的文字都是漂亮的 utf8 ，但若是用 phpMyAdmin 進去看，會發現有的根本不是 utf8 。而唯一是 utf8 的 plog db，用 ruby 去 select （我猜 perl 的也一樣啦）出來卻是亂碼。

最後在一連串的亂七八糟 encoding conversion 測試之後，得出一個結論，至少對我有用。對於你確定是以 utf8 存的資料庫，在 connect 之後加 ’set names utf8′ 準沒錯⁽¹⁾，而對於可能是以 latin1或big5 格式存 utf8 資料的資料庫（很繞口），就分別用 ’set names latin1/big5′ 來做連線看看，目前為止幾乎都是準的，唯一的例外是我的 gallery2 系統，目前要看到部份中文字要先 ’set names latin1′ 然後將 dump 出來的資料由 encoding utf8 轉為 encoding big5 。而另一部份的中文，則要由 encoding latin1（cp950）轉為 big5。

簡直一團糟！！！

下一步，就是朝全面 utf8 化邁進啦。

1. 上面說過囉，具有 SUPER 權限的人，加在 my.cnf 是沒用的[back]