子璉's profile鄭子璉PhotosBlogListsMore  |  Tools Help |
|
4/23/2006 MySQL for Windows + .Net本來啦，我是不想用 MySQL ，去年還 7 月還當面向某個xx技術組組長直接面報，在 9 月以電子郵件專門說明，在政府招標的計畫中，若是直接使用 MySQL 的話，會有授權問題，這樣的情況符合 MySQL 官方網站定義商用授權的第二種情況，故應取得商用授權：
若要免費使用 MySQL ，依據官方網站的說明：
Under the Open Source License, you must release the complete source code for the application that is built on MySQL. You do not need to release the source code for components that are generally installed on the operating system on which your application runs, such as system header files or libraries.
亦即政府網站若使用到 MySQL 的應用程式須釋放完整原始碼才可免費使用 MySQL ，我所開發專案或其他網站，目前似乎沒有釋放相關應用程式原始碼，而且釋放原始碼可能導致廠商或學校單位開發存取時，若有少許漏洞，反而導致資料外洩或系統遭受攻擊，又目前開發之資料販售系統，似乎明顯違反免費授權的基礎，故委辦單位宜取得商用授權。 商用授權每套每年在每台 Server 起跳為 595 美金：
https://shop.mysql.com/product.php?c=1&rz=1 由於 MySQL 國內無正式代理商，學校單位及政府採購可能無法網路下單，可能有採購困難，或者需要開國際標，此外其所販售的授權需每年購買，建議非必要時，MySQL 的應用系統開發可能要多加琢磨。
不管怎樣，今年已經強制採用 MySQL ，說實在的，MySQL 並不是最好的選擇，而且是 Server 型的資料庫，有些小需求只需要檔案型的，例如說 Access ，資料庫並非只有唯一選擇，強制採用 MySQL 實在是不當的策略，甚至產生指廠的問題，既然是公開招標的案子，廠商依據標單或進度報告規劃採用對應的資料庫，經主席核可後，應無必要堅持轉換成 MySQL 。既然要求下來了，也只好去做。
原先我採用的是 Access / SQL Server ，這兩種資料庫都支援 Unicode ，可處理簡繁體及罕用字，別的不說，光是游錫堃的堃字，能不能處理就差很多。早期 MySQL 4.0 以前版本，怕碰上 \ 字元，常會碰到的關鍵字都成為專有名詞：「許功蓋」，可由 google 搜尋到千篇以上的討論：
http://www.google.com.tw/search?hl=zh-TW&q=MySQL+%E8%A8%B1%E5%8A%9F%E8%93%8B&meta=lr%3Dlang_zh-TW 直到 MySQL 4.1 以後才以 utf8 方式解決這個問題。但是這個問題並非是澈底解決，雖然在 4.1 以後的版本裡面有 ucs2 (Unicode) 編碼，但是在線上手冊明確表示，不能使用 ucs2 作為 client 端：
Note: Currently, UCS-2 cannot be used as a client character set, which means that SET NAMES 'ucs2' does not work.
此外，真正允許用 utf8 編碼連線的只有 Linux 及 jdbc for Windows ，而在 Windows 最直接的 MyODBC 3.51.13 Driver 卻不支援，只能用 ANSI 來傳輸，變成罕用字還是不能處理，此問題在官方網站已經被使用者回報為 bug 超過一年以上，仍然未解決，成為懸案。以 utf8 為關鍵字，可以找到一堆未 Close 的 bug ：
在官方網站的論壇，也可以找得到很多相關討論：
網路上能找到少有號稱能支援簡繁共用的，除了透過 jdbc 外，凡是透過 ODBC 跟 .Net Connector 的，都語焉不詳，沒有明確的說明。
為了解這個問題，分別跟小朱、好手等 MVP 交流，似乎仍無明確解決方案。故目前只好暫時放棄罕用字，以繁中 (big5) 為限。
再繼續下去，先討論 ucs2 及 utf8 兩種編碼，基本上 utf8 是西方國家愛用的選項，因為平時不太用得到遠東文字，所以維持英數 1 byte，而遠東文字經過 utf8 編碼後，會由原先 2 bytes 放大到 3 ~ 4 bytes ，純粹以中文為主的資料庫，應該採用 ucs2 ，而非 utf8 ，ucs2 即是 Unicode ，所以全球所有的文字都採用 2bytes ，當然，英數也是 2 bytes 。採用 ucs2 也有利於 VarChar(nn) 的設定，若是採用 utf8 ，以姓名欄位來說，假定含複姓下可能有四個字，4x4 = 16 ，則應保留 16 bytes 來儲存姓名，在計算字串所需位元組上，十分的不便，用 ucs2 則固定 2 bytes 的量計算。
原先想將 MySQL 安裝成預設 ucs2 的資料庫，無奈，不管怎樣安裝，若是預設為 ucs2 ，就會發生無法連線，再檢視官方網站的論壇與錯誤回報，可以推定 ucs2 目前還有 bug ，並無法作為預設字碼頁，只好退而求其次，資料庫安裝為 utf8 ，資料表則設定為 ucs2 。
假定將 Access 資料庫匯入 MySQL ，以附圖來說明操作步驟，先使用工具軟體：
MySQL Migration Toolkit
圖片跳過只需要按下 Next 鍵的頁面，順序請參閱檔名。特別注意在 Object Mapping 這邊改成 ucs2 ，當然也可以先用 utf8 ，事後再轉，不過先前經驗發現，有些表格會無法轉換，所以最好在匯入時轉換，匯入時轉換也可以直接使用中文欄名，不受影響。
完成後就可以使用工具軟體：
MySQL Query Browser
觀看匯入的資料。如附圖。
在透過 MyODBC 3.51 連線時，由於 ucs2/utf8 皆無法作用，所以請在連線參數加上 stmt=SET NAMES 'big5' (在 VB6/ASP/.NET 下，單引號可省略) ，則可正常連線，即使在 SQL 語法內出現中文欄名都不受影響，在這邊用 VS.NET 2005 伺服器總管為範例。伺服器總管以先建立一個 DSN 比較方便，設定好後直接滑鼠右鍵，顯示資料表即可編修資料，如附圖。
當然，可以建立連線對應到 mysql 及 information_schema ，這樣就可以直接插入新使用者帳號、密碼，設定權限了。
這邊有個奇怪的小問題，有時用 VS.NET 看，欄名順序會由小到大重排 (Select * Form table) ，但是直接用 .Net Odbc.Data 來連接又正常，這邊可能還要再查原因。網頁顯示如附圖。
補充：
由於 MySQL 可以 client / Server / Table 分別採用不同的編碼，所以我懷疑先前網路上看到的可以在 VB6/VBA/ASP/VBScript/.NET 中，討論到可以簡繁並用的狀況可能是下列兩種，這兩種狀況都會導致 MySQL Query Browser 無法正確瀏覽，但 client 端程式可以正常顯示： 1.存取資料庫前後事先編碼。我有看過這種範例，比如說 .NET 用 Text.Encoding.utf8 再讀出、存入都編碼，個人以為這不是正道，有點類似要將密碼寫入資料庫前後，以自定編解碼處理。 2.連線端用跟 Server 端都用 utf8 ，也就是連線端不指定 SET NAMES 'big5' ，這樣 client 端的 MyODBC 送出去的文字會被轉成 big5 再當成英數轉 utf8 ，在 MySQL Query Browser 裡面看到的字就是 big5 當成英數顯示，也就是有規則的亂碼... 當然，1, 2 項應該可以結合出在 client 端程式經手動編碼後，當成 utf8 傳給 MySQL ，讓 MySQL Query Browser 可以瀏覽的方式，這會造成程式碼不一致，在無解決方案時，可能可以考慮這個。
而 MySQL Query Browser 無法正確瀏覽，就表示另一種情況，這個資料庫不能跟其他應用程式交換資料。 MySQL Query Browser 是用 jdbc 連的，所以表示 jdbc 連線的應用程式都會讀成亂碼，未來新增或更新的模式也必須採用 1, 2 項方式處理，資料庫的存在並非是為了單一 client 端使用而設計，而是將資料以標準公開的方式保存，使得資料保存不受應用程式開發、更新、維護改變而改變，亦即，若是目前正在測試的 MyODBC Connector/Net v5 alpha 若已改進 MyODBC 的連線方式可使用 utf8/ucs2 時，原先的應用程式只需變更連線 driver 及連線字串，即可支援日韓繁簡罕，但是 1 則涉及程式碼全面改寫，故此應變應在沒有方法的情況下，採用來作暫時解決方案，不適宜作標準方案來看待，當然，網頁程式可說是只有唯一 client 端在使用，但是考慮到未來升級、變更、重新開發下，此暫時解決方案仍不宜當作標準解決方案看待。
註：目前測試 MyODBC Connector/Net v5 alpha ，只要一牽扯到編碼就無回應 Comments (6)
TrackbacksThe trackback URL for this entry is: http://tlcheng.spaces.live.com/blog/cns!145419920BFD55A7!763.trak Weblogs that reference this entry
|
|
|
