上一篇主題 :: 下一篇主題 |
發表人 |
內容 |
css
註冊時間: 2004-12-31 文章: 32
第 1 樓
|
發表於: 星期三 十月 05, 2005 12:15 am 文章主題: Unicode,VFP愛用者心中永遠的痛…… |
|
|
在社區搜索「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
註冊時間: 2004-09-17 文章: 357
第 2 樓
|
發表於: 星期五 十月 07, 2005 9:33 am 文章主題: |
|
|
是ㄚ!
為何有些回應者不願回覆,可能是他的系統裝一次玩補計畫就能解決怪字的出現,所以就不想回答
事實上
我有四台電腦(xp),但只有一台能有效的解決怪字現象,其它的電腦有裝跟沒裝完補計畫是一樣的出現怪字
我想他們不願回覆的原因
1.只有一台電腦且安裝完補計畫後解決怪字
2.他們也是有些可解決有些不能而........
以上
謝謝您的主題發表
我贊同您! |
|
回頂端 |
|
|
a123eric
註冊時間: 2003-10-20 文章: 64
第 3 樓
|
發表於: 星期五 十月 07, 2005 7:17 pm 文章主題: |
|
|
目前您需看以何角度來看
完補不是真正的支援,完補會影響系統原有unicode,挾義可以使用完補,廣義卻需再等或變通
目前在Taiwan,Big5是全部支援,unicode....支援上…仍有許多的問題
若不考量授權需加注在使用者身上的話,可使用Office的text相關物件 (有一次問微軟的回覆可以使用office的text)
或使用相關 third party 物件
以上純屬個人意見,也許這些資訊有錯 |
|
回頂端 |
|
|
cchvfp
註冊時間: 2003-07-05 文章: 18
第 4 樓
|
發表於: 星期三 十月 12, 2005 4:44 pm 文章主題: |
|
|
紅狐有篇vfp 10 wish list,那時我就提出支援unicode才是最重要的,
您說的VB有支援應該是VB.NET吧,DELPHI也沒支援UNICODE,
所以應該還不用太悲觀.畢竟還是有很多程式不支援UNICODE. |
|
回頂端 |
|
|
summer
註冊時間: 2003-06-19 文章: 32
第 5 樓
|
發表於: 星期三 十月 19, 2005 10:40 pm 文章主題: |
|
|
Unicode 支援尚有其成本考量的問題~~
今天才與幾個同事談到這個問題,Unicode 在資料庫儲存定義上,與 ANSI 有著不同的意義,同是資料,關念確必須有所改變,當然,它對非文字資料,是沒什麼意義的,只對文字型態的資料產生變化~~
一般而言,當我們定義一個欄位型態為一般文字型別時,對於任何一個圖形文字的字符而言,它的可容納字數是用該欄位的總 Byte 數除以二,因此對英文字母來說,字數則會是圖形文字的一倍。
接下來,在換成 Unicde 後,全數必須強迫改變,它不再是以 Byte 為最小單位,而是以一個 Word 為最小單位,一個Word等於二個 Byte,這時,不管您是儲存中文也好,英文也好,同一欄位,所能容納的字數完全一樣(即中文是十個字,英文也是十個字),說到這裡,代表著一件事情,改用Unicode 去定義您的資料庫時,它將會成倍數的關系成長,這對管理成本來講不會是一件好事,當然,對儲存設備的供應商來說會是一件好事。Unicode 早在十多年前,就被發展 Unix 系統的那群組織團體所定義規範出來,當時的儲存設備非常的貴,所以發展起來一直不是很理想。現在!儲存設備便宜了,但相對人事成本的提高,管理者依然佔不到便宜,管理成本依然以每 MB 數美元的方式保持著,所以,支援Unicode 不單單是技術問題而已,還有很複雜的管理成本問題,對我個人而言,我當然希望能改過去,因為如此一來,就可以解決多國語言及指令運用等技術問題啦~~~ |
|
回頂端 |
|
|
css
註冊時間: 2004-12-31 文章: 32
第 6 樓
|
發表於: 星期五 十月 21, 2005 8:15 pm 文章主題: |
|
|
「……一件事情,改用Unicode 去定義您的資料庫時,它將會成倍數的關系成長,這對管理成本來講不會是一件好事……」
這樣一種審慎推測與估算(就好比火警發生時,首先想到的,不是救火,而是細細考量:要撲滅這廚房的大火,預計我要消耗多少加侖淡水,然後呢,本月我就要多繳納多少水費,然後呢,不行!我得先坐下來,開啟電腦,仔細計算清楚其中的經濟帳,然後再決定是否需要救火……),估計微軟是不會贊同的,MS-SQL Server 2000頑固地堅持以Unicode來儲存資料,即是一個證明。 |
|
回頂端 |
|
|
goto-dream
註冊時間: 2004-05-11 文章: 909
第 7 樓
|
|
回頂端 |
|
|
goto-dream
註冊時間: 2004-05-11 文章: 909
第 8 樓
|
|
回頂端 |
|
|
|