Navicat 有兩種UTF8的模式嗎??

這兩天在幫老婆大人轉檔的過程中發現了個怪問題，其實以前就有遇過只是沒去深入去探究可能的原因，下面是測試的畫面：

圖1.mysql.exe 直接連接畫面1(MySQL預設狀態)

圖2.mysql.exe直接連接畫面2(MySQL預設狀態)

圖3.localhost-Big5 Connection

圖4.localhost-Big5 Console

圖5.localhost-UTF8 Connection

圖6.localhost-UTF8 Console

圖7.localhost-UTF8-Defaule

圖8.localhost-UTF8-Defaule Console

圖1、圖2是用mysql-4.1.22-w32.exe以系統預設安裝後的狀態，圖3、圖5、圖7則是三個Navicat上建立的Connection，不同的只是在Encoding的部份設定不同，但是設定的不同卻造成了相同也不同的結果，圖4、圖6、圖8分別是各Connection連線後，以Navicat提供的Console功能，執行show variables like '%c' 所show出的MySQL對於character set的狀態。
圖3與圖5的Encoding設定分別是950 (ANSI/OEM - Traditional Chinese Big5)和65001 (UTF-8)，但是玄了，從各別的Console畫面圖4、圖6卻是完全相同，各個character set都沒有變更，再以實際的連線去select資料出來看，卻又沒辦法正常顯示對方連線時可正常顯示的資料。
圖5與圖7的Encoding設定都是UTF-8，但是圖7的UTF-8是勾選 Use MySQL character set而成的，原則上兩個連線都是以UTF-8為character set，但是從Console畫面圖6、圖8來看使用Use MySQL character set的選項才有辦法造成真的UTF-8的存儲使用環境。在實際連線測試select資料也是同樣無法正常顯示對方連線時可正常顯示的資料。
就目前來講這樣的測試還無法證明什麼，到底是MySQL的問題還是Navicat的Bug，不過自己覺得MySQL的character set的問題真的是個大麻煩，但也因為Navicat這個對UTF-8的怪原因，讓人浪費了不少zZZ的時間，不過至少知道一個結果..那就是如果要使用Navicat將原先Big5編碼的資料庫轉為UTF-8編碼時，UTF-8 Connection properties 的 "Use MySQL character set" 一定要勾啦!!