請問這個專案的目的、碼表來源及授權方式？

[danny0838]

如題，請問此計劃是希望達到什麼目標？是否歡迎大家協作？

此外，在下打算做一個以三代倉頡為主的模組化 RIME 輸入法方案，方便不同需求的使用者定製自己的倉頡輸入法，可能會用到這些資料，但希望最終能採取最寬鬆的 MIT 或 public domain 授權。不曉得貴方案的資料來源及授權方式為何？

[mrhso]

欢迎协作。其目标与 Jackchows/Cangjie5 相同，都是参考官方资料对码表进行规范化。 MIT 可以考虑，因为之前 Jackchows/Cangjie5 已经用了 MIT。具体的话还是要看 @Arthurmcarthur 。

[Arthurmcarthur]

本碼表通過參考官方資料等方式對碼表進行規範化，歡迎協作。 我個人對採取MIT協議並無意見，只是本碼表的原始來源為倉頡之友·馬來西亞，因此我還要先徵求其站長阿勤的同意，待阿勤先生同意後我會添加上MIT許可。

[danny0838]

說說我的一些想法：

1. 輸入法表格做出來就是要用。既然要做，我傾向把表格製成 RIME 方案的規格，這樣使用者就可以直接丟進 RIME 使用。

2. 為兼顧使用者可能的不同的客製化需求，我傾向把不同功能的編碼表分開，例如把漢字、重碼字、特殊符號、康熙部首、中日韓相容表意字元等分別製成不同的編碼表。RIME 引擎可以輕易組合不同的輸入法編碼表形成可用的輸入法方案，使用者可以把這些編碼表輕易組合成他要的方案。

3. 使用者可能會需要三代倉頡、五代倉頡、三代為主但兼容五代、五代為主但兼容三代等不同的輸入法，我傾向把三代倉頡和五代倉頡整併為一個專案下，使用者可以利用 RIME 引擎的高自訂性組合這些編碼表形成他想要的方案。

4. 我認為應該把官方編碼表和我們修訂區分編碼表區分開來。前者有需要是因為目前難以找到純粹不摻水的官方編碼表，我們應該盡可能搜集可取得資訊建立一個最大程度符合官方意向的編碼表，方便有需要的使用者查閱及使用。而為了方便使用者或修正官方不合理的編碼所做的修改，則宜另製成「補完版」的編碼表。兩個表應分開為不同檔案，讓需要的使用者可以方便地選用或用程式做差異比對。

5. 貴專案的編碼表似乎是基於五代倉頡編碼表修改，這讓修訂歷史變得混亂，不易搞清楚相對於三代倉頡到底做了什麼修改。如果可以，基於五代倉頡編碼表修改應該會比較好。

基於以上需求我開了一個整合專案，之後會慢慢合併 RIME 官方編碼表、幾個補完計畫的編碼表、以及六代倉頡的編碼表。不過我最近頗忙，進度可能會很慢。各位如有興趣也歡迎加入。

[mrhso]

实际上仓马的三代码表质量非常低下，因此才采取五改三。

[danny0838]

這我理解，不過這樣有不少官方三代倉頡的信息在以五代為基礎下不知不覺消失了。我會比較傾向記錄原始的三代編碼表，再透過三代五代差異比對的方式修正。

[Arthurmcarthur]

當初我提出補完計畫的原因正是基於目前倉頡碼表非常混亂的現象。很多碼表自稱「五代」，但卻含有大量三代編碼和二代編碼，也有很多碼表自稱「三代」，卻含有很多五代或二代編碼，因此這個補完計畫是按官方為準，對碼表實行規範化，而完善倉頡理論則暫時不是這個計畫的任務。 之所以要按五代倉頡碼表來改，原因主要是目前的三代碼表存在自行改造加根，或者存在大量錯碼，再又或者雖自稱三代但卻包含很多五代編碼的情況，例如倉頡之友·馬來西亞的三代雖然說是「三代」，但實際上甚至連很多常用字都包含五代碼，比如「兔」字，倉馬三代編了「弓山戈」，但又把五代的「弓日竹戈」放了進去。再如「卑」字，倉馬三代編了「竹竹十」，但又放入了「竹田大十」這非三非五的奇怪編碼，再如「嘅」，倉馬三代只兼容了「口竹心山」，缺乏「口日戈山」等字形，再如「怎」，有「竹尸心」和「人尸心」，但「苲」又只有「竹竹尸」，甚至C/D區是完全照搬倉馬五代，而這C/D區，質量也極其差勁。再如微軟倉頡（非大五碼部分），編碼極其混亂，還大量缺字，又如雅虎倉頡，自行加了很多根，把「车」取成「心手」等等，因此修改起來可能比改倉馬五代還費力費時，不如直接用五代來改。實際上三五差別並沒有那麼大，我改了八萬多行，只有九百多個是三五有差別的。 因為我對三五的區別還算有一定理解，因此不會出現誤改的現象，還請放心。本碼表製作時與官方交流，會對原版三代有少量修改，有時間我會寫成表格。 至於RIME方案，其實一直有在做，只不過沒有放在Github上，Github上是適用於倉頡平臺（即小小輸入法）的碼表格式。

[danny0838]

所以才要問貴專案的目的。

如果你們的目的是「打造最好的倉頡輸入法」，那你們想怎麼改怎麼優化都行。若要「以官方為準」，那就連「少量修改」都不該有（或是同時提供官方版及少量修改版），否則到頭來使用者還是用不到原汁原味的三代倉頡。

[Arthurmcarthur]

因為我們的修改都是問過官方，經過官方的認可的，很多也是官方提出的修改方案，因此仍是官方倉頡。 若要適應大字集，必然要一點修改，像是「㫈」，不把「〇」加到「口」作字根就難以取碼，再像大陸標準的「龜」，若不設成難字「竹難山」，取碼時必然面臨困擾，類似這些修改官方都是認同的。

[danny0838]

那麼像是把 OKR 的候選字順序由「佑、知」改為「知、佑」，算是官方認同的嗎？

這類修改其實倉頡五代就做過，某方面來說官方當然是支持這種修改。但我們回到使用者的角度，如果使用者已經習慣了微軟倉三的候選字順序，必然不會希望有這種改動，因此我認為這類修改都應該視為「非官方」，要嘛不要做這種修改，要嘛提供有修改和沒修改的版本。

[Arthurmcarthur]

微軟倉頡的排序並未按照官方的排序原則，實際上是按BIG5碼來排，常常有非常用字放到常用字之前，打字時會減緩速度。而官方的排序準則是這樣的：1.按字頻來排 2.字形產生器能自動生成的字往前排。3.傳承字優先。因此實際上「人大口」的官方重碼排序一直是「知佑」，並非從五代才開始如此。 但這個準則在我們實際操作時顯然存在問題，一來我們沒有字形產生器，二來有些傳承字很罕用，反而簡體字的使用頻率更高，因此為了實用起見，本表會綜合考慮簡繁頻率來排序，日後也可能有完全按繁體字頻和簡體字頻來排的版本。 由於我們使用的計算機均採用Unicode，與倉頡機的情況有所不同，因此官方的一些設計實際上是無法照搬到我們的電腦上的。比如說官方為了實現倉頡內碼，用X來排重達到一碼一字的效果，但是Unicode收錄的漢字中，三五代編成「弓弓一口月」的字已有四十多個，用X來排重早已不夠，只能對CJK基本區內的字增加X排重的方式。 總而言之，只要習慣以後，就會感到用字頻排比BIG5內碼來排重更為方便，打字準確率更高。

[mrhso]

同意。仓颉系统使用的字符集并非 UCS，有些规则硬搬到 UCS 不太合适。

[Jackchows]

有些字官方碼表沒有收，例如1984年版的官方三代手冊衹收了四千餘字，漢文庫典也衹有五萬餘字。其餘的字，除非我們也不收，否則我們衹能根據自己的理解去編碼。 我們編碼時會在官方碼表找相似的字作參考，實在疑難的會詢問官方意見。 排序的問題 Arthurmcarthur 已經說了。 實際上五代補完計劃最初是做來自己用的，公開發佈之後，已經對主要修改之處以及有爭議的的地方作了說明。 關於碼表格式，我是考慮到雖然RIME比較流行，但是其他輸入法平台也有不少用戶，所以五代補完計劃沒有製作成特定某個平台的格式。

[danny0838]

關於平台，其實五代補完的表格做點微調就是 RIME 平台的格式了。如果表格完全與平台無關，所有平台的使用者都要先處理才能用；而做成特定平台的格式，至少有一個平台的使用者可以很方便地拿去用，整體效益是比較高的。

如果所有現有平台的格式都無法放入足夠多的信息，我會支持無平台但信息量大的格式。但RIME平台支援多表格、多欄位，還可以寫入註解，信息量非常夠，要轉換成其他平台也不用太複雜的腳本就能做到，因此我認為做成RIME格式對更多使用者更便利。

候選字順序看來是我弄錯了。但官方的規則是嚴格的按先字頻、再按產生器、再按簡化字與否嗎？如果是，那麼官方已經欽定常用簡化字優先於罕用傳承字了不是嗎？或者其實不是這樣，而是先按簡化字與否、再按字頻和產生器？

[Arthurmcarthur]

具體的技術細節我不清楚，但是在漢文庫典官方排序中簡體字通常非常靠後。比如「恋」字，被排到「戇」、「戅」之後，「艺」被排到「芎」之後。

[danny0838]

這樣看來官方做法應該是先按簡化字與否、再按字頻和產生器了。

若是如此，我建議用以下方式排序：

1. Unicode 中日韓統一表意文字優先於擴展A區以上的字。
2. 傳承字優先於簡化字。
3. 按字頻排序。無法取得字頻者視為字頻最低。
4. 按 Unicode 擴展區排序（A > B > C >...）。
5. 按 Unicode 編碼排序（目前 4,5 似乎可以合併成 5）。

如果是使用 RIME 格式，想要常用簡化字優先於罕用傳承字的使用者只要把這樣的詞典改成 by weight 排序，就可以換成按照字頻了。至於其他平台，恐怕得自行找字頻庫用腳本調整排序了。為了方便起見，建議給所有簡化字打個標記，以便程式處理。

[Arthurmcarthur]

補完三代是遵循1和4的，但是倉頡的一大優勢便是隱形雙編碼帶來的簡繁通打能力，為了兼顧繁簡，難以做到第2第3條。有些傳承字是極其罕用的，像「芎」是傳承字，但卻較為罕用，不能排在「艺」前。又有一些簡體字對於簡體用戶頻次很高，若簡體用戶使用這碼表，很常用的簡体字靠後也会影響體驗，此時便將「相對」不那麼常用的傳承字靠後，例如「廿大」的重碼排成「关艾」，「尸大」重碼排成「区尹」。日後可能會有完全按簡繁字頻的簡體專用和繁體專用表，不過可能要一段時間後才会有。另外，有些字的排序也可以採取一些特殊方法，比如「弓弓一口月」這幾十個重碼，可以按「弓弓」內部的形塊倉頡碼順序來排。總之，排序不要太死板，按實際情況靈活處理更好。

[danny0838]

「艺芎」、「关艾」、「区尹」的排法是問過官方同意的嗎？

作為繁體字使用者，需要輸入簡化字的頻率趨近於零，「艺芎」、「关艾」、「区尹」的排序是不能接受的，因為「芎」、「艾」、「尹」雖不甚常用，但也不到罕用的程度。繁體字使用者的底限大概只能接受擴展A區以上的極度罕用字排在簡化字後面。

你們這樣做，或許對簡化字用戶方便些，但一來不符合官方作法，二來也不是繁體字使用者可以接受的。

而如果採用 RIME 格式及我上述說的排序方式，繁體字使用者無障礙，簡化字使用者只要設定 by weight 排序就可以做到你們說的常用簡化字先於不常用繁體字，連做兩張表的工夫都可以省下。

[danny0838]

另外提供一個小想法：GitHub 支援 tsv 格式（用 tab 鍵分隔的純文字）可以直接呈現表格。如果表格不需要特殊格式，可以考慮用 tsv 取代 xlsx，這樣在編輯及 Git 差異比對、合併上會更便利。

[Arthurmcarthur]

但是也有很多簡化字用戶使用倉頡，你不能完全否認這些人的存在。 簡化字在前的例子並不多，而排序大部分來自倉馬，我只調了一些，有一些還是把簡化字往後排的。 排序不涉及到編碼思想，官方也很繁忙，沒必要詢問這種問題。而且我已經說過，官方除編碼思想外的一些設定沒必要都拿到我們的電腦上。官方原設定甚至是不能用數字鍵選字的，只能用X避重，或者在出現重碼後打X，再按空格鍵來選下一字，難道這些設定都要搬到電腦上嗎？

[Jackchows]

以「廿大弓中」為例： 繁體字使用者希望排序是「鄭鄚郑」； 簡體字使用者希望排序是「郑鄚鄭」； 同時使用繁簡體，但是用繁體較多的使用者希望排序是「鄭郑鄚」； 同時使用繁簡體，但是用簡體較多的使用者希望排序是「郑鄭鄚」。 一張表如何實現此需求？

[danny0838]

確實，只用一張表無論如何都無法滿足各種需求，於是需要釐清目標，並做先後取捨。

如果目標是做出符合官方原意的碼表，那麼按照漢文庫典的做法是「鄭鄚䣐郑」。不過我相信無論是繁簡字使用者，應該都能同意把擴展區的「䣐」字排到最後面，這點的確是在一般電腦環境下可以不完全符合官方。

如果目標是方便各種需求使用者使用，那麼分成多個表格是不可避免的。

如果基於成本只能做一個表格，按照 @Arthurmcarthur 兄的做法排成「鄭郑鄚䣐」，是方便了「同時使用繁簡體，但是用繁體較多的使用者」，但對於繁體字、簡化字使用者都是不夠優化的。按照我的做法排成「鄭鄚郑䣐」，至少能滿足繁體字使用者，還可以套上 RIME 的 by weight 設定做字頻排序變成「鄭郑鄚䣐」，滿足另一族群。

簡化字優先使用者想要的「郑鄚鄭䣐」、「郑鄭鄚䣐」，恐怕字頻排序也無法滿足需求，非得要專門為簡化字使用者客製的簡化字優先、繁體字置後表格才能達到，只能說倉頡輸入法本來就不為簡化字設計，對簡化字支援相對不友善。

專門客製的表格就是專門客製的表格，要做並無不可，但這樣的表格恐怕不那麼適合冠上「官方倉頡」的招牌並做為一般性的預設方案。

[danny0838]

附帶一提，如果能接受 RIME 格式多表格的做法，另一個解法是把所有簡化字獨立放到另一個表格，這樣使用者就可以籍由調整 import 表格順序達到簡化字置後和簡化字置前的效果，也就是「鄭鄚郑」和「郑鄭鄚」。不過還是無法滿足其他幾種需求。

[Jackchows]

上面提出的四種排序，你提出的方案可以實現兩種，而分開多個表格的做法可以實現全部（雖然目前五代補完計劃沒有做第四種）。 你認為「只能說倉頡輸入法本來就不為簡化字設計，對簡化字支援相對不友善」，這不是理由。因為現在不是做不到簡化字排序優化，而是有意不做。 而且這種格式對不使用RIME的人來說反而更麻煩了。（我不是反對RIME格式，衹是我自己不打算做而已。） 另外，據我所知這兩個項目都從未冠上過「官方倉頡」的招牌。

[danny0838]

分成多個表格的確可以解決所有客製化需求，只是維護成本也很高。如果擔不起這樣的成本而只打算維護較少個表格，那就必須有所取捨。

除了多表格外，還有一個可考慮的做法是提供完整元資料及程式排序。為表格中所有漢字標上字頻、繁體字、簡化字三個屬性，技術上就可以透過腳本程式全自動產生上述四種繁簡優先度的表格，就可以只維護一個表格。

（順帶一問： @Jackchows 兄是怎麼把五代補完的表格當成輸入法使用的？）

[Jackchows]

我有做 RIME 格式的碼表，衹是沒有在 GitHub 上發佈而已。不過也是各個版本獨立的。

[danny0838]

剛才想到：其實並不需要在表格中標示每個漢字的屬性，另外建立表格標示漢字的屬性也可以辦到。