Re: [問題] big5 與 utf8 的使用經驗

看板C_and_CPP作者 (/欣塞玲/)時間12年前 (2013/02/07 13:51), 編輯推噓9(9012)
留言21則, 8人參與, 最新討論串4/5 (看更多)
//del oldpost 處理文字(plain text)從來都是複雜到不行的工作,我將一些我知道的整理一下 + utf-8處理從來都是跟big5(或任何MBCS)一樣,用char[]來處理,offset單位 是1個byte,所以是"non-wide/narrow character" + utf-16LE相反,是wide character approach,使用wchar_t[]來處理,offset 單位是"2個"byte;但是Linux下wchar_t是4個byte,所以Linux下wide character 是utf-32(UCS-4),Linux下不大適合用wchar_t,反而愛用utf-8 approach,也就是 永遠將char[]視為utf-8 string,原因好像是UNIX system call不像Windows有平行 提供兩套function(A和W結尾的api) + L"\0"和"\0"不會一樣,因為一個是wide,一個narrow + 不管是utf-8,utf-16LE還是UCS-4,都"理論"完整支援目前最新unicode 6.2,但實作 上一堆"沒文化(XD)"的老外都搞出跛腳版的處理,例如 + 用UCS-2做出自以為的UTF-16,不支持non-BMP character,因為沒去處理 surrogate pair + 搞utf-8卻搞錯轉換方式,做出CESU-8 + plain text從來都沒有random access的特性,就算是UCS-4也一樣,因為一個 codepoint對應出來(在很多語言)並不總是"語言文化"上的一個"字/char",所以 處理length不過是處理offset: wstrlen == 3只是代表wchar_t[0] ~ wchar_t[2]有 codepoint對應的wchar_t,wchar_t[3] == L"\0",有可能這整個wchar_t[]只存一個文 化上的"字"。 + C標準明明很早就廣為使用wchar_t[] (連UEFI程式都使用wchar_t),但是main卻只支持 char版本的argv,造成windows下只能使用__wargv之類的方式來處理argument,再加上 console下使用者可以任意設定command shell環境,我不知道版上高手有沒有方法能 夠寫出任意command shell環境都能運作的程式,再者,console下還有萬惡的字寬問題 ,連寫出個真正用wprintf排版整齊的程式都不可能。相反的,GUI下一點問題都沒有。 + unicode其實並不一定是萬國語言的解法,pdf格式就從來都不是用unicode去處理字的 問題。 + 光是中文處理,unicode化不過是第一步,因為unicode本身其實還是有很多問題, 像是簡繁,異體字(很多文化上相同的字,unicode卻給予不同的編號),筆畫,全半 形文字/符號,直書符號等。 + 字型也從來就是阻礙unicdoe化的問題,多少truetype是non-unicode,還有邪惡的 type 1,一堆TeX生出來的文件為了好看美觀都用adobe早就拋棄的type 1。 + windows下其實可以使用utf-8 approach支援unicode,也就是一律用char[]儲存, 要api call時候,以MultiByteToWideChar把char[]餵給W結尾的win api。 + NTFS下,Windows全面支持utf-16LE檔案路徑,所以windows程式永遠使用 _wfopen開檔案。就算是FAT32(像是隨身碟),由於LFN(長檔名)也是uft-16LE, 所以讓我們忘了FAT32短檔名吧。 + 如果只侷限在中英文世界,GB 18030好像看不到啥缺點? + 阻礙unicode,人人都推了一把,例如使用bbs、TeX、unicode補完等。 有錯的話,麻煩指證。還有有人能補充Linux下的相關問題嗎? 題外話,我至今有幾個問題, + 中文就glyph而言,根本是天生的等寬字,但是實際上中文字型卻都往往做成非等寬 的字型檔。目前有良好支援unicode卻又是台灣筆畫的字型檔案嗎? + 是不是使用XeTeX取代TeX才能從根本解決unicode的問題? ※ 編輯: seansylin 來自: 111.243.104.33 (02/07 22:02)

02/07 22:36, , 1F
針對最後一句:是
02/07 22:36, 1F

02/07 22:37, , 2F
啊不過當然這是現在, 以後如果有人要另外寫一套也是行
02/07 22:37, 2F

02/07 22:37, , 3F
中文字也是很詭異, 除了細明體之外我還沒看過能夠完美處
02/07 22:37, 3F

02/07 22:38, , 4F
TeX不一定要用type1,dvipdfmx可以從truetype取字
02/07 22:38, 4F

02/07 22:38, , 5F
但即使如此產生tex所需要的tfm還是很智障
02/07 22:38, 5F

02/07 22:38, , 6F
理羅馬字/方塊字混雜文件字元寬的字型...
02/07 22:38, 6F

02/07 22:39, , 7F
所以是的,就用 XeTeX 吧
02/07 22:39, 7F

02/07 22:42, , 8F
字型阻礙 Unicode 的議題,現代 Windows 有幾個方案,比如
02/07 22:42, 8F

02/07 22:42, , 9F
A字體只有英文字的Glyph,他可以在機碼設定幾個連結字體,
02/07 22:42, 9F

02/07 22:43, , 10F
比如缺中文,可能就連到細明體。不然就是系統判斷這字型
02/07 22:43, 10F

02/07 22:44, , 11F
沒有韓文Glyph,系統就用特地為韓文準備的後備字體來顯示
02/07 22:44, 11F

02/07 22:57, , 12F
fontconfig!!!
02/07 22:57, 12F

02/07 23:07, , 13F
XeTeX 王道 +1
02/07 23:07, 13F

02/08 08:41, , 14F
偷問一下有沒有人知道 Unicode 中,左岸繁中、台灣正體
02/08 08:41, 14F

02/08 08:42, , 15F
、日本語中的「誤」字三種語系不同寫法卻用同一個編碼
02/08 08:42, 15F

02/08 08:42, , 16F
要怎麼解決 XD
02/08 08:42, 16F

02/08 09:30, , 17F
應該是誰不爽誰就換字型吧...就像有些字型也可以是草書
02/08 09:30, 17F

02/08 09:30, , 18F
行書,甚至是注音文,但是不影響底層內碼值相同的事實
02/08 09:30, 18F

02/08 10:55, , 19F
非等寬是為了處理英數半型那塊吧
02/08 10:55, 19F

02/13 00:34, , 20F
回Bencrie: 關鍵字: Unicode normalization form
02/13 00:34, 20F

02/14 09:45, , 21F
ConTexT也可以用unicode寫
02/14 09:45, 21F
文章代碼(AID): #1H4x5IDy (C_and_CPP)
討論串 (同標題文章)
文章代碼(AID): #1H4x5IDy (C_and_CPP)