Delphi UTF-8 Conversion Routines

http://docwiki.embarcadero.com/RADStudio/Seattle/en/UTF-8_Conversion_Routines

Indy IdUDPServer/IdUDPClient 接收傳送中文字

透過 Indy 套件的 IdUDPServer / IdUDPClient 收發訊息時，英文基本上一定是沒啥問題，但遇到傳送中文訊息，以Indy的預設編碼傳送後接收顯示為亂碼，很明顯是編碼出了狀況，測試的環境為Win7 + XE4，TextEncoding的功能參數必須 uses IdGlobal 才會正常，最初測試時試了半天找不到正確的參數，只好去 IdGlobal.pas 翻一下，找到這個：

在使用 IdUDPServer / IdUDPClient 收發時，下列兩種方式都可以正常傳送顯示中文，以IdUDPClient為例，IdUDPServer 也適用：

測試環境：

• Windows 7
• Delphi XE4 測試版

uses IdGlobal;

..............

IdUDPClient1.Send(Edit1.Text, IndyTextEncoding_UTF8);

or

GIdDefaultTextEncoding := encUTF8;
IdUDPClient1.Send(Edit1.Text);

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" 一定要勾啦!!

MySQL Big5 to UTF8 快速轉碼

延伸閱讀：Navicat 有兩種UTF8的模式嗎?? <-- 有要做的人一定要先看

昨天要幫老婆大人把客戶從MySQL dump出來的資料，從原先的Big5轉成UTF8再塞進去MySQL裡。原始檔案有將近900M，有點大所以大部份的編輯軟體都拿他沒輒，所以就開到Linux裡用iconv直接轉，轉是轉完了但是總會有"\?"的問題造成匯入不成功，去問了一下G大這有可能是換行字元的問題，為了快速找到解決方案就先把問題的研究先放著，解決問題優先。

[Navicat]是一套資料庫管理工具支援多種資料庫，可下載試用。它本身提供Data Transfer的功能可以直接讓線上的資料庫轉到另一個資料庫或輸出成檔案。轉換細節如下：

環境：Server: VMwarePlayer3.1.5 + Debian6.0.3 + MySQL 5.1.49

          Client: WinXP with SP3 + Navicat10

1. 在Navicat環境下，建立兩個Connections，一個Encoding設成950 (ANSI/OEM - Traditional Chinese Big5)，另一個設成65001 (UTF-8)
   
   
   
   
2. 點選 Tools -> Data Transfer -> General，設定Source Connection為Big5的那個，當然Target Connection就得設成UTF8的那個了，Database依需求設定
   
   
   
   
3. 在Data Transfer畫面下點選Advanced，依照你的需求增減相關的選項，在本例中我將Include character set及Use hexadecimal format for BLOB取消。Include character set如果設定會把目的table也設成Source table的character設定，所以取消；至於Use hexadecimal format for BLOB則是因為我的資料庫有使用到BLOB的欄位，轉換時會造成錯誤，所以取消。
   
   
   
   
4. 接著就按Start等待結果啦~

Delphi XE2 UTF8測試

由於Delphi7不支援UTF8，造成程式中對於UTF8字元處理及顯示上的不便，因而興起測試一下目前新版本的支援度如何。在測試前先在網路上看一下網友使用的狀況，其中看到一條消息就是XE2已經有內建支援Regular Expressions了，真是讓人高興啊!!

目標主要測試TMemo、TComboBox、TiniFiles及RegularExpressions對UTF8的支援度。有畫面有真象。測試的過程有發現一些事，應該不算新鮮事應該也許早在Delphi2009就支援了。

1. 一開始當然是先編個最基礎的空AP玩玩，看完真的很大便，Debug版要6M，找了半天弄個了Release版也要1.5M，哇~真是粉大~~，可能剛從D7過來的關係不太適應。
2. TEncoding，使用TMemo和TStrings讀寫檔案時，可指定寫入檔案的編碼如：TEncoding.UTF8，預設好像是TEncoding.ANSI，問了一下G大好像在Delphi2007就支援了，也有看到用Delphi2009寫的Code。這樣就不必每次要先準備好對的格式的文字檔來stand by了。
   Ex：
   Memo1.Lines.SaveToFile('xx.ini',TEncoding.UTF8);
   -參考資料
3. TIniFile差點讓人從椅子上掉下來，一開始使用D7慣用的語法去開*.ini，慘了讀不出UTF8格式的，但是ANSI的卻可以。心裡幹譙一陣嘀咕著要改怎不全部一起改咧?後來想想那麼大的公司應該沒那麼笨吧?
   開始到程式安裝的地方把Inifiles*.*的檔案挖出來，找到"System.IniFiles.pas"，到裡面去找TEncoding這key word，還好讓我在TMemIniFile class找到。使用方式和TIniFile一樣，只是在宣告時要把TIniFile改宣告TMemIniFile就可以指定TEncoding.UTF8了。
   Ex：
   oIni: TMemIniFile;
   oIni:=TMemIniFile.Create('.\xx.ini',TEncoding.UTF8);
   -參考資料
4. Regular Expressions是最讓人喜出望外的，在其他部份測試完要進行RE的部份時，正不知如何下手就直接問G大吧，結果找到[Embarcadero原廠資料]，原來XE2的RE是承自於TPerlRegEx，讓原先的TPerlRegEx的user可以完全無痛更換開發環境，而且直接支援UTF8String解決了原先D7+TPerlRegEx對UTF8的處理問題。
   既然可以直接使用TPerlRegEx就不作他想了，使用上必須宣告uses System.RegularExpressionsCore，不可宣告uses RegularExpressions。在實際使用上目前發現有一點和D7版的不同，原本熟悉的SubExpressions[n]不見了，取而代之的是Groups[n]，至於其他像replace、split有沒差異?因為少用就沒測了。
   Ex：
   uses System.RegularExpressionsCore;
   oRE: TPerlRegEx;
   -參考資料

其他XE2還有些特異功能像FireMonkey、跨Mac、支援x64等，因為沒環境就先不測了。

結論：綜合以上各點已滿足自己小小的需求，讓人粉想換個開發環境，唯一的缺憾就剩執行檔吃了歐羅肥的問題了。

Delphi7上Unicode的問題

Delphi7是我慣用的開發工具，之前完全不考慮更換版本的最大原因就是新的版本真的是越來越肥了，重點讓人最不爽的是會在系統上裝一堆不曉得用不用得上的東東，就像MS的VisualStudio一樣。

這次在改寫[EzNetRadio]時加入了一個新平台[Now.in]，在Web上的編碼UTF-8已是主流，Hichannel和Now.in皆然，不過Hichannel站台名稱上不會使用特殊字元所以在轉換及顯示上不會有問題，反之Now.in則不然，使用者強調的個人化造成站台名稱格式大相逕庭，而且有為數不少ANSI無法顯示的特殊字元，因此興起將EzNetRadio增加支援Unicode的功能。

Delphi7在Object、procedure及function的使用上，皆以AnsiString、String為主，但是Unicode的處理都必須使用WideString。在EzNetRadio中有使用到IniFile、MainMenu、PopupMenu及站台資料快速截取的靈魂TPerRegEx都必須要支援WideString及WideStringList包括Delphi7內建的字串處理函式，麻煩大了。

TntUnicodeComponents解決了*.ini上Unicode字元顯示在MainMenu及ComboBox的問題，支援WideString的IniFiles也在網上找到解決方案WideIniFiles，至於TPerlRegEx踹了半天都解決不了就只有先放棄了。

Delphi7在Unicode上是有一些解決方案，但還是缺東缺西的，像我這樣玩票的開發人員要自行開發或修改元件還是免了，因為頭髮會掉更多。

把花了一天做的測試弄個Sample以免下次又要重來。

下載：Sample.zip