Skip to content
ksqsf edited this page May 5, 2024 · 27 revisions

→ 遇到安裝問題?請參閱安裝說明

一、教程

  1. 若您首次接觸自然碼雙拼、輔助碼,請閱讀教程
  2. 若您已掌握自然碼雙拼和/或輔助碼,可按需跳過教程中的第一和/或第二節。

二、說明書

說明書尚未動筆,目前請參閱下方大綱,自行嘗試其中提到的功能:

image

三、項目介紹

本項目(「魔然項目」,Project Moran)除了維護 RIME 方案外,我們還長期維護以下內容:

  1. 開放、規範的自然碼碼表
  2. 高效的四碼上屏輸入模式
  3. 長期維護的整句詞庫

1. 開放、規範的自然碼碼表

補完 Unicode 字集編碼,目前已收錄 8 萬字,最高到 CJK 擴展 I 區。我們的願景是,所發佈的碼表可以成爲自然碼碼表的標杆。

2. 高效的四碼上屏輸入模式

已發佈的有「魔然·字詞」,爲傳承字優先方案,與默認模式共享一、二、三級簡碼,便於用戶試用、遷移。

該方案面向熟習簡快碼的高級用戶,可以實現不看候選窗的盲打。

※ 簡化字優先碼表現已推出,參見简体版

3. 長期維護的整句詞庫

我們會長期優化本方案的整句輸入體驗。

四、爲什麼是自然碼?

每個漢字,都是「音」「形」「義」的結合體。而自然碼編碼,巧妙地將這三者融合在一起。試看下面的例子:

  1. qrl 勸勧劝
  2. lkl 勞労劳
  3. hrq 歡歓欢

爲何可以如此精準地恰好將三種字形歸爲一類?因爲字的部首往往表達字的「義」,而無論字「形」如何變化,其「音」「義」卻不會變化。自然碼恰好將前三碼安排爲「音」「義」,僅在第四碼放入恆變的「形」——而這,就是自然碼好用的祕密。自然碼並不是效率最優的漢字編碼,但卻一定是(目前)最符合漢字本質的編碼。

對於常常在不同字形間切換使用的漢字愛好者來說,這樣的編碼方式可以極大地降低學習成本和使用時的心智負擔。如果你熱愛漢字文化,同時還對輸入效率略有追求,那麼基於自然碼的輸入方式一定是你的不二之選。

本方案優缺點

優點,或者說「爲什麼你應該用該方案」:

  1. 基於自然碼雙拼和輔碼,若已經會自然碼雙拼,可以無需學習,一鍵提升
  2. 收錄大量生僻字(達8萬多),爲目前各音形方案之首
  3. 細緻優化製作的簡碼碼表,可有效提升打字效率;字詞模式效率與小鶴音形相當
  4. 獨特的取碼哲學:傾向於讓「全等異體字」重碼,使用 OpenCC 或其他技術選擇一個等價類中的代表元,對經常換着使用多種形體的漢字愛好者來說更易用
  5. 豐富多樣的用法:不論是100%確定的字詞模式,還是純雙拼,還是混打簡碼、輔碼造詞,本方案都可以提供一致且良好的體驗

缺點,或者說「爲什麼你不應該用該方案」:

  1. 重碼率不是最低的:若追求無重、盲打,建議選用純形碼。
  2. 碼長不是最短的:若追求碼長短,建議選用純形碼或頂功類方案。
  3. 資料不多:由於本人精力有限,暫時沒有提供豐富的文檔和學習資料。如有疑義,請開 Issue 或 Discussion 探討。

從某種意義上來說,本方案可以視作自然碼雙拼的帕累託改進(不考慮拼音引擎和詞庫差異的話)。所以,只要你在用自然碼雙拼,只需簡單地使用本方案,往往就可以得到更好的打字體驗。

但是,如果目前並不會自然碼雙拼,是否值得專門來學習?是否值得放棄其他類型的輸入方案?這一點就見仁見智了。這裏提供一點對比:

比較維度 音碼 本方案(音形碼) 形碼
單字輸入思維難度 中,往往只需拆一個組件 較難,需要拆較多組件
單字輸入精準度 極不精準 一般,生僻字重碼多 精準,但仍有重
詞語輸入思維難度 較難
詞語輸入精準度 一般,可加輔碼篩選,但仍有重 精準,但仍有重
碼長 中,全拼打全碼則長 短~中
適用寫作類型 普通現代文本 普通現代文本,少量離散文本 幾乎任何場景
簡繁兼容性 極佳,完全無需重新學習 良,需要少量重新學習 極差,要重學一套簡碼甚至完全不同的另一套字根
練習量

總而言之,若拋開簡繁支持,僅輸入方案的角度來看的話,本方案=雙拼+精準常用單字+輔碼篩字+輔碼造詞。如果你本來對純双拼方案怨言不多,只是想減少選重時間 [1],或想要精準地輸入一些常用單字,那麼本方案幾乎就是量身定做的,Welcome!

如果你有更高的要求?即使筆者本人是放棄形碼轉用音形碼的,但我仍然建議讀者首先考慮形碼!除非你沒有時間脫產練習形碼,或忘字太多、導致無法正常使用,或者像我一樣,想要兼容簡繁字形,到那一步再退而求其次也不遲。

[1] 本方案的實際使用體驗是:若已經熟習輔碼和簡碼,那麼在90%的情況下無需選字,直接按空格上屏即可,即使是剩下9%的情況也可以在第一頁找到想要的候選字,再剩下0.9%的情況在第二頁能找到候選字。換句話說,雖然不能避免檢視候選項(也就是如果首選沒命中,那麼就至少要花掉 150ms 的反應時間),但是候選項數量大大減少了。