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 而言，
资料固然重要，
真正的基础始终是规则。