1樓：
古字甚麼的我不在乎，不過另一方面動態組字能方便我造新字，不用在BCDEF裡面死命耖了。
其實這也是老論調了，方便造字甚麼的。
2樓：Henry Chan
編碼的意義除了顯示，最重要是資訊交換和資訊處理。
一、漢字不僅是部件的組合。筆畫交疊、筆畫相對位置、筆畫的長短，可能是區別兩個完全無關的字的必要資訊。要將這些資訊都記下來筆畫稍多的字就要好幾十個位元組，不利於資訊交換；相比之下，乙個字給它乙個UCS 碼位，就二到四位元組而已。
二、乙個漢字本來就有多種寫法，單單乙個「木」字就可以帶鉤可以不帶鉤。資訊處理很重要乙個部份是「等同」equivalence。如果乙個字有多過乙個寫法，文書處理系統需要為所有有可能出現的變化，其複雜程度難以估量。
再者，一般用途的搜尋時，需要搜的是「字」，不是「形」，以大量程式把不同的「形」鏈結起來，倒不如直接為「字」編碼。
三、市面上不是沒有過此類字形表達系統。比如說西方有《文林》Wenlin 的 Character Description Language (CDL)，東方有《字形維基》Glyphwiki。
再說「Unicode」的「漢字氾濫」的問題。首先，Unicode標準裡的漢字並不歸Unicode管，而是中日韓越各國及地區機構派駐國際標準化組織核下的表意文字小組的管理。漢字的標準是在 ISO10646 的框架下進行的，Unicode 標準只是影射而已。
「漢字氾濫」問題是歷史遺留問題。基本區推出時，為了使 ISO10646/Unicode 能夠盡快取代各國地區之內互不相容的內碼，採用的「原格分離原則」，即源頭標準只要將兩個字形分開編碼，ISO10646就會分開收，而不管既有的認同規則，這樣就導致「兌」和「兌」、「緒」和「緖」、「冊」和「冊」都編成兩個字，然而「者」「珊」就只收了一次。
雖然這個原則在擴充套件 A 區起被取消，但由於本身的認同規則是為了縮減碼位數量考量，僅將中日韓各地的正寫進行認同，無法有效處理歷史上常見的異體，於是異體字便海量地傾倒進 ISO10646。現時已編碼近8萬字，絕大部分都是罕用異體。以正字法的角度去看待，一部份更加是錯字。
表意文字小組的代表們似乎都開始意識到問題，即使部分代表不想改邊編碼方式，未來小組會傾向減少增收異體字。由各國及地區採用 IVD 為每個「字」編碼一系列的「形」，是比較持續 (sustainable) 的做法。
3樓：flickzhou
從使用的角度看，可以把字形認為是：我們識別它是哪個字的最根本的東西。
從計算的角度看，可以定義：字形+字型=具體字樣。
當時我從拓撲結構出發，設計了一種字形描述。先獲得乙個好處，合體字可以用偏旁、部首來遞推描述，既極大地減少了冗餘，也記錄了字與字間的關係。很快面對一些困難，比如：
區分已己巳，這個拓撲差異明顯，還算好辦；區分土士，這裡我不得不引入佔位符，不太優雅；還有更難描述的結構，等我找來更新。當然基於字形描述，加上字型風格自動生成具體字樣，就更遙不可及了。
具體描述採用以小括號為單位的遞推方式。我舉幾個例子：
刀 (橫 [1] 豎鉤,1 撇)
口 (1 豎 2,1 橫豎 3,2 橫 3)
招 (h 扌召)
扣 (h 扌口)
召 (v 刀口)
扌 (橫 [1], 豎 [12] 鉤, 提 [2])
合體字：將其拆成更簡單的字或部件，並描述它們之間的位置關係，主要有h(左右布局)、v(上下布局)、i(外內布局)、t(品字布局)等。似曾相識吧，小學生學合體字就是這樣學的啊！
例如「招」的具體描述 (h 扌召)可以解釋為:「提手」旁和「召」字在水平方向左右布局。
獨體字：將其描述為筆畫及其之間的拓撲關係。通過交叉點和相連點可以抽象地描述筆畫間的連線情況。
在小括號中按照筆順依次描述每個筆畫，筆畫間以逗號間隔。每個筆畫可能折多次，形成多個筆段。筆段沒有方向的突變，可以簡單描述為：
橫、豎、撇、捺、點、鉤、提、彎。每個筆段都有乙個起點、多個過點和乙個終點，其中與別的筆畫相交或相連的點要描述，其它省略。如果三種點都需描述，順序為：
起點、筆段、 [過點]、終點。筆段安排在起點與第乙個過點之間，為了區分過點與終點，過點用中括號括起來。所有點用數字依次編號。
例如「刀」的描述(橫 [1] 豎鉤,1 撇)可以解釋為：一橫過點 1、轉豎、轉鉤，從 1 開始一撇。
總結一下感想：
優點：這個思路有它的獨到之處，可以成為漢字的一種特色庫。用來回答「X偏旁的字有哪些」這種問題非常方便。
對國家發布漢字標準也有一定用處。要知道像GB18030這樣的標準發布時，要規定的很多漢字字型檔裡都還沒有，因此只能在pdf中用圖畫表達。標準中關於很多字的「木」結構下面是否有提甚至自相矛盾。
問題：自然文字的形狀不大可能簡潔完備地描述。比如，草體的拓撲結構與楷體差異非常大。
這有點類似「用語法來分析自然語言」的侷限性，現在都改貝葉斯、神經網路了。因此這個思路只能在有限範圍內使用。當然了，如果有一天，國家把所有漢字的拓撲結構都做了統一規定，消除了各種特例，那就是另乙個故事了。
4樓：拼音佳佳
1.定義筆畫的形狀.這個需要點陣儲存.
定義字型大小.
2.定義序號.表示每乙個筆畫的id號,和書寫順序的定義不太一樣.
3.定義起點.就是每個筆畫的定義點,在點陣上的位置.以此為起點,自動生產該筆畫.
4.定義縮放.每個筆畫外觀相同,但大小不同,以此做大小定義.
5.定義元件.將偏旁部首定義為元件,再對元件定義序號,起點,縮放.
舉例:定義一
1.定義筆畫橫,呼叫點陣儲存的筆畫橫.
2.定義序號為0(就一筆)
3.定義起點,就是點陣上一點的座標.點陣16*16.
4.定義縮放,1到F,中間是8表示1倍原比例,9abcdef表示放大的比例(1.1倍到1.7倍),76543210表示縮小的比例(0.9到0.2).暫定.
高階的:部件定義:
好定義部件:女,子.
定義序號:0,1
定義起點:FF,FF
定義縮放.包括橫軸縮放與縱軸縮放,所以是ff,ff
到這基本就搞定了.
好像不是很難.因為不是乙個字乙個字美化而成的,字型可能看上去有點彆扭...
就好像金山畫王這種給小孩子玩的畫板軟體,可以往螢幕上新增部件,然後滑鼠拖拽定義大小,配色,旋轉等變數.本質是一樣的.
有之前在別人回答下的答覆,發現算錯了.字型檔體積取65535,需要4位,FFFF,但是點陣字型檔的儲量就偏大了:16*16的點陣,每行16個點,每個點取1和0,每4個0000等於1個F,總共的儲存位數是:
64個F.加上字型大小編碼就是68位.
我這個方案,再算下碼長:
每個最小部件的點陣編碼是68位.實際可壓縮比如一的點陣可以極度.
大部分部件都可以用筆畫來描述,所以用不到點陣.
普通漢字的編碼,比如,樹,有3個部件,對這3個部件進行定義,就可以描述這個漢字.
複雜點的,贏,亡口月貝凡,定義5個部件.
大部分常用字沒有這麼多的部件,並且部件的復用率還是比較高的.
算下碼長:樹
字型大小4位FFFF
部件可以是2位單獨定義FF,但比較少,只有256個,也可以從字型檔裡面取,編碼4位FFFF
暫取4位FFFF*3=12位.如果採取常用部件點陣庫的方式,可以壓縮一半.
起點定義,FF*3=6位
縮放定義:FF*3=6位,
總長28位.由於編碼長度可變,所以還需要結束符至少1位.所以基本編碼6位(字型大小+結束符+擴充套件符),部件每多乙個,碼長增加8位.
而且也不能只有乙個部件(無意義),所以編碼長度6+16=22位,複雜漢字5位編碼=6+8*5=46位,需要達到8個部件的時候,描述所需的碼長才會超過點陣.好在超過5位的就已經極少.
5樓：劉冠偉
有的，而且是十幾年前就有。
例如京都大學的http://
chise.org
系統，其副產物之一就是大家常用的漢字部件檢索（ids檢索）。依賴於魔改的emacs，反正我就沒編譯成功過。
不過後來unicode字數跟上來之後，日常應用意義就不是很大了。
ps. 有次喝多了跟chise的守岡老師抱怨沒有api說明書，圈子外的人太難用。後來就有了這篇http://
git.chise.org/~tomo/character/chise-format.pdf。感覺一點誠意都沒有…
6樓：雪齋
有的，IDS (Ideographic Description Sequences) 就可以確定地描述乙個漢字的字型。不過要想實現自動生成字型檔案，這很難，要讓字型好看，不是「微」調可以做到的。
7樓：
這個想法很好。
漢字有多種屬性：讀音、字義、構形、筆劃、以及字典/字表順序，等等。unicode這種是按照「字典/字表順序」來進行編碼：
即漢字空間到一維線性空間的對映。這種簡單對映下，漢字的其他資訊當然丟掉了，比如字形。
於是當然可以根據別的的屬性進行編碼。你說的根據漢字的「筆劃」來編碼就是一種方案。
現在有所謂「動態組字」技術，就是在漢字的「基礎部件」（字根）——或者說漢字的最小表義構形結構——的層次上處理漢字。但是似乎目前「動態組字」偏重於漢字的具體顯示，而不是編碼本身。
我在另乙個問題中也有過根據「形」編碼的考慮，請參考：你對漢字拉丁化怎麼看？
我也問過類似的問題：「動態組字」技術現狀如何？有哪些困難？還有發展前途嗎？
回到你的問題。
unicode作為字符集無可厚非；而從編碼角度，之所以還沒有這樣乙個根據字形編碼的方案，個人覺得是因為：
一、像unicode這種「字典」式的順序編碼方式是最簡單的。
Unicode的編碼方式不需要對所編碼的物件有任何知識，因為就是按順序「數數」；編碼中也不需要附加任何額外資訊。任何更複雜的編碼都將增加單字編碼的長度，增加資訊交換的複雜性和成本。
二、Unicode因為電腦軟硬體廠商的推動，已經被普遍接受。
在沒有普遍的、不可接受的缺點的情況下，業界沒有動力去做另外一套編碼。首先歐美人士不會主動另外做一套他們不太會用的漢字的編碼；而在各種國際標準制定普遍被歐美壟斷的情況下，中中國人（或者中文圈）自己劍走偏鋒，阻力重重，吃力不討好。
三、更複雜的編碼方式並不必要。
無論何種編碼方式，無非是字符集到編碼空間（平面）的對映。至於具體的對映方式，以及對映後是否保留了原字符集的內部結構資訊（字元之間的組合關係，或者筆劃結構資訊等），即「字元空間」和「編碼空間」是否同構，不重要。從這個意義上，unicode作為字符集天經地義，作為編碼方式也無可厚非。
四、漢字的「字形」是否可以被定量化，進而被編碼，尚未可知。
漢字的構形是「筆劃」或者「部件」的平面組合，且在組合的過程中，筆劃和部件的形態都會發生變化，而非簡單疊加。這和單詞是字母的「線性排列」完全不同。所以，即便將漢字按「形」分解成「筆劃」或者「部件」，怎麼用這些基本的「構件」來獨一無二地描述乙個漢字，是個未知的問題。
不過現在一些人在進行這方面的研究（比如「部件拆分」的研究），所以將來出現乙個「字形編碼」，也不奇怪。
五、根據「字形」編碼，是個「交叉」領域。
如前所述，unicode編碼方式不需要對所編碼物件有任何知識。但是根據「字形」（筆劃或者部件）編碼，需要相當的「文字學」甚至是「古文本學」的知識，而這一點通常的編碼制定者和字型設計人員並不具備。反過來，覺得按照「字形」編碼更科學更合理的人，通常是對漢字比較了解的人，但是他們又不精通計算機。
簡而言之，就和很多事情一樣：覺得應該這樣做的人，不知道怎麼做，或者做了也沒影響；知道怎麼做、且能做成的人，覺得沒必要或者沒動力。
六、另外你說的計算機自動生成字型的思路，似乎更加困難。
（我也問過乙個類似的問題：漢字字型、書體的美觀與否有規律嗎？這種規律可以被定量化嗎？）
但是我不認為這是個不可解決的問題。現在cg技術都已經發展到嘆為觀止的地步了，計算機自動生成字型並非不可能。只是願不願意做。
同第四點一樣，這也是個交叉領域，甚至是個跨國領域——得讓歐美電腦高手對漢字感興趣。
總之：
一、如前所述，漢字有多種屬性，unicode只是簡單按照「字典/字表順序」（或者說字符集的順序）來進行編碼。當然可以根據別的的屬性進行編碼。如果將來通過研究，將漢字「構形」定量化並編碼，這可以被認為是專門的「字形的編碼」，和unicode並不矛盾，可以並行不悖。
二、個人以為，相對於編碼本身，基於「筆劃」或者「部件」的處理方式在漢字具體的顯示上（比如字型），或者輸入法、手寫識別上，可能更有前途。
如你所說，漢字字型設計的複雜性以及字型檔案的龐大，以及如無底洞的「缺字」問題，從單純的字符集層面都不可能得到根本解決。因為任何字符集都是有限的。
諸如「動態組字」技術這種， 才是解決字型問題以及古籍「缺字」，以及諸如「招財進寶」、「biangbiang面」這類字的一勞永逸的方案。但是，還有很長的路要走。
[1] 動態組字（wiki），動態組字
漢字簡化為什麼不用更加簡便的字形
榊一彌 請作者好好學習一番中國書法的歴代演変 多看中國歴代書法的碑帖 歴代書家的漢字寫體。你就會明白 所有的簡體字都是歴代即有之 根本不存在是 現代簡化 的無知言論。僅挙一例 変化的 変 字，目前在台灣和香港等寫 變 日本寫 変 新加坡和中國大陸寫 變 変來變去其實都是中國歴代書法同一漢字源體的不同...
為什麼標準日本語初級裡一些詞語沒有漢字形式？
青海裡皮蓬 我是不太理解標日的蜜汁漢字書寫標準。有許多日本漢字寫的多的單詞只給假名，有許多日本基本不寫漢字的倒是都寫了漢字 這點在文法裡尤其明顯 所以最簡單的方法是 都記漢字 至於 這個問題，是經常迷惑的乙個問題，他不讀a，而讀nga，怎麼發呢，你先發ang這個音，然後把頭音a吃了，然後用剩下的尾音...
從漢字的構造角度說明漢字為什麼沒有走上拼音化的道路。？
Coprophagist 因為篆書到隸書的轉變把漢字的筆畫拉直並且把很多不同的音件聲旁合併了。比如在篆書中邑和哪中的右耳朵是一樣的。很多部件在篆書中組合完全不會有違和感，比如將尼和右耳朵組合在篆書中不違和在隸書中看起來就很違和了，這就導致了人們不會隨便為讀音而改變字的寫法，從而導致了現在大多數形聲字...