Mozc输入法中数字重写器过度触发问题的技术分析

问题背景

Mozc作为一款广泛使用的日语输入法引擎，在处理某些特定词汇时会意外触发数字重写功能。具体表现为当用户输入"ゆり"时，转换候选中会出现"100合"这样不符合常规用法的选项。这种现象源于引擎内部的NumberRewriter模块过度触发机制。

技术原理分析

Mozc的数字重写器(NumberRewriter)设计用于自动将日语数字表达转换为阿拉伯数字加计数单位的格式。其核心判断逻辑基于以下条件：

1. 词汇必须以日语数字开头（如"百"、"千"等）
2. 词汇结尾必须是计数单位后缀（如"合"、"遍"等）

当同时满足这两个条件时，系统会自动生成对应的阿拉伯数字表达形式。在"百合"这个案例中：

• "百"被识别为数字（100）
• "合"被识别为计数单位 因此系统自动生成了"100合"的转换选项。

问题根源

这种设计虽然对纯数字表达有效，但当应用于实际地名、人名等专有名词时就会产生不符合用户预期的结果。经过深入分析，发现以下词汇组合也会触发类似问题：

• 八戸 → 8戸
• 八代 → 8代
• 百合 → 100合
• 千歳 → 1000歳
• 千葉 → 1000葉

这些词汇在日语中都是固定地名或常用名词，用户通常不希望它们被自动转换为数字形式。

解决方案实现

Mozc开发团队通过以下方式解决了这一问题：

1. 在number_compound_util.cc中建立了例外词汇列表(kExceptions)
2. 将"百合"、"千歳"等专有名词明确添加到例外列表中
3. 当检测到这些词汇时，跳过数字重写处理

这种解决方案既保留了数字重写功能对真正数字表达的处理能力，又避免了在专有名词上的误触发。

技术启示

这个案例展示了自然语言处理中一个常见挑战：规则引擎在特定场景下的过度触发。Mozc的解决方案采用了"白名单例外"机制，这是处理此类问题的典型方法。对于输入法开发而言，需要在自动化处理和用户预期之间找到平衡点，特别是在处理日语这种数字表达复杂的语言时。

该问题的修复也体现了开源项目响应社区反馈的敏捷性，从问题报告到解决方案实施仅用了不到一个月时间，确保了用户体验的持续优化。