Series 2 · 第 5 篇——為什麼不 Hardcode 五萬個漢字 上一篇：從《康熙字典》到 Parser：Quizzman Fanqie Engine 的建構歷程
為什麼 Quizzman Fanqie Engine 不會 Hardcode 五萬多個漢字？
許多程式設計師在了解 Quizzman Fanqie Engine 時，都會提出一個問題：「為什麼不直接把所有漢字的讀音都存起來？」 以今天的儲存容量而言，建立一個包含數萬個漢字及其漢越音的資料庫並不困難。然而，Quizzman Fanqie Engine 選擇了一條更困難的道路：建立數百條音韻規則，讓電腦自行推導，而不是單純記憶。這不只是技術上的選擇，更代表了整個專案的設計理念。
兩種完全不同的設計方式
如果目標只是輸出漢越音，
大致有兩種方法。
第一種：Dictionary Engine
字
↓
Database
↓
quốc
每一個漢字，
都預先存好讀音。
例如：
| 漢字 | 漢越音 | |------|---------| | 國 | quốc | | 學 | học | | 德 | đức | | 明 | minh |
使用者輸入一個字，
系統直接查詢資料庫即可。
目前大多數漢越音工具，
都是採用這種方式。
第二種：Rule Engine
Quizzman Fanqie Engine
採取的是完全不同的方法。
字
↓
反切
↓
Middle Chinese
↓
音韻規則
↓
漢越音
在這個架構中，
Engine 並不是去記住每一個字。
它真正試圖理解的是：
為什麼這個字會讀成這樣？
這正是兩者最大的差異。
儲存五萬個漢字，其實一點也不難
今天，
一份包含：
- 五萬個漢字；
- 漢越音；
- Pinyin；
- Unicode；
的資料表，
甚至只需要幾 MB。
即使是手機，
也能輕鬆儲存數百萬筆資料。
因此，
Quizzman 不採用 Hardcode，
並不是因為硬體限制。
真正原因，
在於問題本身的本質。
資料無法解釋規律
假設資料庫中記錄：
| 漢字 | 讀音 | |------|------| | 國 | quốc | | 域 | vực | | 或 | hoặc | | 惑 | hoặc |
使用者知道：
國
↓
quốc
但不知道：
- 為什麼是「quốc」？
- 為什麼保留 -c 韻尾？
- 為什麼是入聲？
- 為什麼聲母會變成 qu-？
資料庫只能保存結果。
卻無法保存：
結果形成的原因。
一條規則，可以取代數千筆資料
這正是 Rule Engine 最大的優勢。
例如，
與其儲存：
谷
↓
cốc
國
↓
quốc
木
↓
mộc
錄
↓
lục
Engine 只需要知道：
通攝
+
入聲
↓
-c
一條規則，
便能適用於數千個漢字。
這就是 Rule Engine 的力量。
規則具有泛化能力
假設出現一個極為罕見的漢字。
字典沒有。
資料庫也沒有。
Dictionary Engine
只能回答：
查無資料。
Quizzman Fanqie Engine
仍然可以：
- 分析反切；
- 重建 Middle Chinese；
- 套用音韻規則；
- 推導出預測的漢越音。
這正是單純資料查詢做不到的事情。
規則可以發現資料錯誤
Rule Engine 還有另一個重要優點。
假設資料寫成：
某字
↓
陽平
但整個 Middle Chinese Profile 都顯示：
清聲母
+
去聲
↓
陰去（Sắc）
Engine 便能判斷：
可能存在：
- 資料錯誤；
- 輸入失誤；
- 或是一個值得進一步研究的歷史例外。
如果只是資料庫，
系統根本無法發現這些問題。
規則比資料更容易維護
假設後來發現了一條新的音韻規律。
如果採用資料庫，
可能需要修改：
一千兩百個漢字。
如果採用 Rule Engine，
只需要修改：
一條 Rule。
所有受影響的漢字，
都會自動更新。
當 Engine 規模越來越大，
這項優勢就越明顯。
那為什麼還需要字典？
既然規則如此強大，
是不是完全不需要字典？
答案是：
不是。
歷史語言永遠存在：
- 例外；
- 多音字；
- 不同層次的漢越音；
- 文讀；
- 白讀；
- 地方變體。
任何規則系統，
都不可能百分之百描述所有現象。
因此，
Quizzman Fanqie Engine
始終維持兩個獨立層次：
Rule Engine
↓
Pure Projection
以及：
Dictionary
↓
Lexical Validation
兩者互相補充，
缺一不可。
Pure Projection 並不追求百分之百一致
這也是 Quizzman 最重要的理念之一。
Quizzman 不會為了讓所有結果都與字典一致，
而不斷修改音韻規則。
如果這麼做，
Engine 最終只會累積越來越多特殊例外。
最後，
它就會退化成另一個大型資料庫。
因此，
Pure Projection 只回答一個問題：
如果完全依照歷史音韻規則推導，結果應該是什麼？
之後，
Lexical Normalization
才負責回答：
今天漢越語實際採用哪一種讀法？
這種分層設計，
使音韻規則始終保持一致性。
從「記憶」走向「推理」
兩種方法可以簡單比較：
Dictionary Engine
五萬個漢字
↓
五萬筆讀音
每個結果，
都是獨立資料。
Rule Engine
數百條規則
↓
數萬個漢字
漢字並不是逐一儲存。
而是由同一套音韻規則推導而來。
這也是歷史音韻學的研究方式，
同時也是 Quizzman Fanqie Engine 的核心架構。
更困難，但更有價值
建立一個 Dictionary Engine，
其實容易得多。
只需要：
- 收集資料；
- 標準化；
- 建立 API。
而建立 Rule Engine，
則需要：
- 音韻學研究；
- 反切分析；
- 規則模型化；
- 大量測試；
- 例外處理；
- Regression Test。
工作量遠遠更大。
但換來的是：
Engine 能夠：
- 解釋；
- 推理；
- 驗證；
- 擴充；
- 發現資料未曾記錄的新案例。
Quizzman Fanqie Engine 的核心理念
Quizzman Fanqie Engine
並不是為了記住五萬多個漢字的讀音而建立。
它真正要理解的是：
為什麼這些讀音會形成。
當一條音韻規則成功模型化之後，
它便不再只服務於單一漢字，
而可以同時適用於數百、數千，
甚至更多具有相同音韻特徵的漢字。
這也是 Quizzman 選擇更困難道路的原因：
與其建立龐大的資料庫，
不如建立一套能夠推理、解釋與持續擴充的 Historical Phonology Rule Engine。
對 Quizzman 而言，
資料固然重要，
真正的基礎始終是規則。