VFP 愛用者社區

[css]

在社區搜索「Unicode」，結果：「有 40 筆資料符合您搜尋的條件」。逐筆逐筆查看過一遍，感覺這裡的大大們似乎對討論「Unicode」的問題不太友善，甚至有些厭煩了任何與「Unicode」相關的問題。

事實上，無論是所謂「Unicode補完計劃」，或是Strconv()，均未能從根本上真正地解決Unicode問題。

一個比較現實一點的問題是：若一家較正規的公司要購買閣下的vfp軟體，卻被告知，必須在其公司內部每一部安裝該vfp軟體的電腦上，都加裝一個由第三方開發的免費軟體「Unicode補完計劃」；儘管你一再聲明，該軟體完全免費，使用該軟體不存在任何著作權問題；小公司或許會相信你，但大一些的公司，你認為他們會輕易地信任你，並毫不猶豫為所有電腦裝上這來歷不明、且無任何技術擔保的「Unicode補完計劃」文檔麼？……

比較有創意的是這一筆資料：http://vfp.sunyear.com.tw/viewtopic.php?t=2584&highlight=Unicode，不過它也僅僅實現了在某些ActiveX控件（象常用的Treeview就不支援）當中顯示輸入Unicode字元而已。

有一句俗話叫：「治標不治本」，可以用來形容VFP面對Unicode時的尷尬與窘迫。

一個來自微軟的反面的例子是：Windows CE，純粹的Unicode支援，它根本不支援非Unicode的ANSI字元。這似乎是一種來自微軟的極微妙的暗示：Unicode是未來發展的大勢所趨，否則微軟絕不敢冒天下之大不韙，公然拋棄ANSI標準而一心一意地向Unicode投懷送抱。要知道，最初的PDA硬體RAM容量並不大，若用ANSI，幾乎每個字元可節省一半的RAM，何以微軟卻毅然決然地支援Unicode，寧願多出一倍RAM的代價呢（許多大型的知名的軟體，如Adobe的Photoshop/Acrobat/InDesign...都直接支援Unicode，且不再Windows 98 support！原因何在，我們不妨思考一下。Unicode程式可方便地實現國際化，無須複雜地維護程式的各個不同Native版本，由此帶來的成本節省，確是巨大難以估量的！）？自Windows NT開始，直至2000/XP/2003……Unicode離我們的生活漸行漸近，SQL是Unicode，Access也Unicode了，VC/VB都Unicode了......然而很遺憾，VFP卻一直站在Unicode的河對岸徜徉，不肯前行一步！可以下這樣一個稍嫌悲觀的結論：

只要VFP一天不真正地徹底地支援Unicode，VFP愛用者們就一天不得安寢——萬一有一天睡夢中醒來，ANSI代碼與字符不再為客戶的電腦識別，……所有的夢想、所有的榮光，頃刻間破碎。

[KKKLYNN]

是ㄚ!
為何有些回應者不願回覆,可能是他的系統裝一次玩補計畫就能解決怪字的出現,所以就不想回答
事實上
我有四台電腦(xp),但只有一台能有效的解決怪字現象,其它的電腦有裝跟沒裝完補計畫是一樣的出現怪字
我想他們不願回覆的原因
1.只有一台電腦且安裝完補計畫後解決怪字
2.他們也是有些可解決有些不能而........
以上
謝謝您的主題發表
我贊同您!

[a123eric]

目前您需看以何角度來看
完補不是真正的支援，完補會影響系統原有unicode，挾義可以使用完補，廣義卻需再等或變通
目前在Taiwan，Big5是全部支援，unicode....支援上…仍有許多的問題
若不考量授權需加注在使用者身上的話，可使用Office的text相關物件 (有一次問微軟的回覆可以使用office的text)
或使用相關 third party 物件

以上純屬個人意見，也許這些資訊有錯

[cchvfp]

紅狐有篇vfp 10 wish list,那時我就提出支援unicode才是最重要的,
您說的VB有支援應該是VB.NET吧,DELPHI也沒支援UNICODE,
所以應該還不用太悲觀.畢竟還是有很多程式不支援UNICODE.

[summer]

Unicode 支援尚有其成本考量的問題~~
今天才與幾個同事談到這個問題，Unicode 在資料庫儲存定義上，與 ANSI 有著不同的意義，同是資料，關念確必須有所改變，當然，它對非文字資料，是沒什麼意義的，只對文字型態的資料產生變化~~

一般而言，當我們定義一個欄位型態為一般文字型別時，對於任何一個圖形文字的字符而言，它的可容納字數是用該欄位的總 Byte 數除以二，因此對英文字母來說，字數則會是圖形文字的一倍。
接下來，在換成 Unicde 後，全數必須強迫改變，它不再是以 Byte 為最小單位，而是以一個 Word 為最小單位，一個Word等於二個 Byte，這時，不管您是儲存中文也好，英文也好，同一欄位，所能容納的字數完全一樣(即中文是十個字，英文也是十個字)，說到這裡，代表著一件事情，改用Unicode 去定義您的資料庫時，它將會成倍數的關系成長，這對管理成本來講不會是一件好事，當然，對儲存設備的供應商來說會是一件好事。Unicode 早在十多年前，就被發展 Unix 系統的那群組織團體所定義規範出來，當時的儲存設備非常的貴，所以發展起來一直不是很理想。現在！儲存設備便宜了，但相對人事成本的提高，管理者依然佔不到便宜，管理成本依然以每 MB 數美元的方式保持著，所以，支援Unicode 不單單是技術問題而已，還有很複雜的管理成本問題，對我個人而言，我當然希望能改過去，因為如此一來，就可以解決多國語言及指令運用等技術問題啦~~~

[css]

「……一件事情，改用Unicode 去定義您的資料庫時，它將會成倍數的關系成長，這對管理成本來講不會是一件好事……」

這樣一種審慎推測與估算（就好比火警發生時，首先想到的，不是救火，而是細細考量：要撲滅這廚房的大火，預計我要消耗多少加侖淡水，然後呢，本月我就要多繳納多少水費，然後呢，不行！我得先坐下來，開啟電腦，仔細計算清楚其中的經濟帳，然後再決定是否需要救火……），估計微軟是不會贊同的，MS-SQL Server 2000頑固地堅持以Unicode來儲存資料，即是一個證明。

[goto-dream]

1.Unicode 這部分 Microsoft .NET
是最完整的解決方案。

2.css你講的沒錯！
現在只能轉向用.NET,要不就忍著用vfp

[goto-dream]

我剛剛試過.NET對於unicode支援很好∼

準備轉換工具去！！