大家好, 我在 Delphi 8 以 dbexpress 連結 SQL SERVER 2000 資料庫,  已知資料庫確定是以 Unicode 並存繁簡中文字。      不知爲何標準 Delphi 資料感知元件(例如 TDBGrid TDBEdit)依然是以亂碼 顯示, 但 非資料感知元件則可以正常顯示。 難道說用 VCL FORM 則不是 fully Unicode 的 .net 嗎? 希望千萬不是!       懇請諸位先進提供寶貴建議, 如何可以讓 "資料感知元件" 可以正確的存取 unicode! 

引言: 大家好, 我在 Delphi 8 以 dbexpress 連結 SQL SERVER 2000 資料庫, 已知資料庫確定是以 Unicode 並存繁簡中文字。 不知爲何標準 Delphi 資料感知元件(例如 TDBGrid TDBEdit)依然是以亂碼 顯示, 但 非資料感知元件則可以正常顯示。 難道說用 VCL FORM 則不是 fully Unicode 的 .net 嗎? 希望千萬不是! 懇請諸位先進提供寶貴建議, 如何可以讓 "資料感知元件" 可以正確的存取 unicode! < face="Verdana, Arial, Helvetica"> 我之前在 台中 Delphi 8上市發表中,聴說 dbexpress 尚未支援 Unicode !! 如用 ADO.net 就可以,

很謝謝 jeffreck 兄! 相信你聽到的沒錯! 很感激! 

等三月份出來的 8.1 版看看吧... 不然這次 D8 已經被人家"幹瞧"了... 真慘... -- 聰明的人，喜歡猜心；雖然每次都猜對了，卻失去了自己的心 傻氣的人，喜歡給心；雖然每次都被笑了，卻得到了別人的心

------
聰明的人，喜歡猜心；雖然每次都猜對了，卻失去了自己的心
傻氣的人，喜歡給心；雖然每次都被笑了，卻得到了別人的心

唉 這是所有用 Delphi 者的無奈, 既愛又容易受傷害, 我想告訴Borland ㄧ聲, 我們的聲音與需求 要聽進去啦! 畢竟我們高價買原版軟體, 不是買來玩玩看, 大家將心比心!

當初買 Delphi 8 就是為了解決 Unicode 的問題, 結果還是無法達到預期, 目前 Delphi 8 還冰到那兒!

謝謝您的回應, 我的 Delphi 8 也是冰起來! 難怪在各地的 Delphi 研討會, 老師問大家用甚麼版本, Delphi 5 依然是超過 80% 我們真的當了大頭了, 又不捨 又不滿! 興德是賣產品的人, 但卻賣了之後, 撇得很清, 實在非做生意之道。 Main Chen , 您要寫Unicode 我建議, 與我現在一樣, 用 VisualStudio.NET 來做, 很順手, 又安心! 參考資源有很充足了! 發表人 - brandes 於 2004/03/03 12:53:10

有點奇怪，發表會上就有說D8 dbexpress還不支援unicode了啊.. 當初的d8express driver規格制定時肯定就沒考慮到unicode，以致現在翻不過身來。如果之前寫DB的東西時就直接用ADO，起碼現在unicode問題會少些。

http://cpatch.org/unicode/ 去下載把 至少解決部份繁體問題 unicode問題 不單是寶籃問題 台灣字碼未整合才是跟本問題 說再多 政府的無能 也無濟於事 系統轉換不該只是寶籃的錯 不過 寶籃的不支援 還真會讓人 失望 除了利用html轉換方式 好像沒啥好方式 如要 要一個一個判斷轉 天阿 那還真不好玩 ms有點又攪起當年 OLE 的封閉把戲

我是不明白dbexpress這問題跟M$哪邊扯上關係了，ADO/OLEDB支援unicode支援得好好的，要怪就怪Borland當初訂dbexpress的時候眼光短淺吧。 至於big5日文跟shift-jis日文在unicode字碼位置上不互換的問題，真的是政府無能了，誰叫香港的big5跟台灣的big5也不太一樣，日文假名字元的編碼位置兩邊不一樣。在Java中，shift-jis的假名字元對到MS950 encoding裡的位置是遵循香港那邊的big5規範，台灣這邊的big5日文假名字元則是放在造字區；台灣這邊的big5日文假名轉成unicode後，當然也還是在造字區。 說穿了，大家都用unicode/utf-8，不就不用煩惱big5還分新舊、分台灣香港版的差別，也不用管台灣方面政府機關的無能與無知了。又如果要考慮大陸市場，乾脆就用GB18030也就好了。

在delphi.net的VCL.net里使用Ado.net http://www.csdn.net/develop/Read_Article.asp?id=25703 這邊有個相關的。我還是覺得用ADO是正途，DBExpress是個落伍的選擇。