librime：把输入法引擎做成可编程的 YAML 配方
Rime输入法引擎，核心库。 RIME：Rime 输入法引擎 === Rime 与您的按键。
秒懂
- 它是什么？
- librime 是一个跨平台的输入法引擎核心库，用 C++ 编写，把输入法设计变成 YAML 配方。本文拆解它的架构、构建方式、适用边界，并给出替代方案。
- 适合谁用？
- librime 适合两类人：一是想深度定制输入法、愿意写 YAML 配方和 C++ 插件的开发者，二是需要跨平台一致输入体验的团队，官方前端覆盖 Linux、macOS、Windows，社区前端延伸到 Android、iOS、Vim、Emacs 甚至 tmux。不适合只想要开箱即用输入法的普通用户，他们应该直接使用 Squirrel、Weasel 或 fcitx5-rime。
- 能商用吗？
- 可以。BSD-3-Clause 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 2 天前。
- 用什么语言写的？
- 主要是 C++（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
librime 解决的是输入法的“可编程性”问题
大多数输入法引擎把方案写死在代码里，用户只能切换几个选项。librime 反过来，把输入法设计变成一份 YAML 配方，引擎负责执行。它用 C++ 实现，跨平台，覆盖了拼音、注音、双拼、方言等各类输入方案。它面向的不是普通输入用户，而是输入法开发者、语言学爱好者，以及想要在多个平台上获得一致输入体验的团队。librime 本身不提供界面，它只处理“按键到候选词”的逻辑，界面由前端负责。
从按键到候选词：librime 的模块化流水线
librime 的架构是模块化的，核心引擎处理按键序列，通过一系列组件完成输入法逻辑。它内置了拼写代数（Spelling Algebra）机制，可以创建变体拼写，这对汉语方言特别有用。例如，你可以定义规则，把某些声母或韵母映射成其他形式，从而支持方言发音。引擎还内置了 OpenCC 支持，原生处理繁体中文，并能转换到简体中文及其他区域标准。这种设计让输入法逻辑与 UI 完全分离，前端只需要把按键事件传给引擎，再把引擎返回的候选词渲染出来。
YAML 配方：输入法设计的 DSL
librime 的输入方案用 YAML 语法描述，称为 Rime schema。这是一门领域特定语言，用来快速试验输入法设计的新想法。配方里定义按键映射、拼写规则、候选词排序等。拼写代数在这个 DSL 中是一个关键机制，它允许你通过规则生成变体拼写，而不是为每个变体写死映射。例如，你可以定义一条规则，把某个韵母替换为另一个，从而模拟特定方言的发音。这种设计让输入法原型迭代变得很快，改一个 YAML 文件就能测试新方案，不用重新编译引擎。
构建 librime：依赖比想象中多
librime 的构建依赖包括 C++17 编译器、cmake 3.12 以上、boost 1.74 以上、leveldb、marisa-trie、opencc 1.0.2 以上、yaml-cpp 0.5 以上。glog 和 gtest 是可选的。在 Linux 上，README 给出的命令很简洁：make 然后 sudo make install。但实际构建前需要先装好这些依赖，其中 marisa-trie 是双许可证（BSD 2-Clause 和 LGPL 2.1），opencc 是 Apache 2.0，这些许可证的兼容性需要自己确认。macOS 和 Windows 有单独的构建说明，但 README 里没有给出具体命令，需要去对应文档查看。
前端生态：引擎之外的完整世界
librime 本身没有界面，它依赖前端来提供输入体验。官方前端有三个：ibus-rime 用于 Linux，Squirrel 用于 macOS，Weasel 用于 Windows。社区前端覆盖了更广的平台：Trime 用于 Android，Hamster 用于 iOS，fcitx5-rime 用于 Linux，还有针对 Vim、Emacs、tmux、Zsh 甚至 Readline 的接口。这种生态让同一套输入方案可以在多个平台复用，但代价是每个前端的维护状态和体验参差不齐。例如，fcitx5-rime 由 fcitx 团队维护，而 rime.nvim 是个人项目，两者的稳定性和更新频率差异很大。
插件机制：扩展的代价是许可证和复杂度
librime 提供了插件接口，官方列出的插件包括 librime-lua（Lua 脚本）、librime-octagram（语言模型）、librime-predict（预测下一个词）、librime-proto（CapnProto IPC）。其中两个已废弃：librime-charcode 和 librime-legacy，后者包含 GPL 许可的代码。这意味着如果你使用 librime-legacy，整个项目的许可证状态会受影响。librime-lua 让你用 Lua 写输入逻辑，降低了定制门槛，但引入了一个脚本引擎，调试起来比纯 C++ 更复杂。librime-octagram 和 librime-predict 都涉及语言模型，前者可能依赖额外的数据文件，后者需要训练数据。插件的选择直接影响维护成本，因为每个插件都有自己的依赖和更新节奏。
librime 的边界：什么时候它不合适
librime 不适合需要图形化配置界面的场景。它的配置是 YAML 文件，普通用户不会愿意手写。如果你只是想要一个能用的拼音输入法，直接装 fcitx5-rime 或 Squirrel 就好，不需要碰 librime。另一个局限是构建复杂度，依赖库众多，在非 Linux 平台上需要额外步骤，如果目标环境无法安装这些依赖，librime 就跑不起来。此外，librime 的引擎逻辑是通用的，对于高度特化的输入法（比如手写输入、语音输入），它没有内置支持，需要自己实现或找其他方案。它的拼写代数机制虽然强大，但学习曲线陡峭，新手可能被 YAML 规则绕晕。
替代方案：不同的设计哲学
与 librime 相比，fcitx5 是一个更完整的输入法平台，它自带拼音引擎，也支持加载 librime 作为后端。fcitx5 的架构是插件化，但它的配置是 GUI 驱动的，用户不需要写 YAML。另一个替代是 IBus，它类似 fcitx5，但更轻量，主要面向 Linux 桌面。区别在于，librime 把输入法逻辑抽象成可编程的 DSL，而 fcitx5 和 IBus 把输入法框架和具体引擎绑定在一起。如果你要开发一个全新的输入法，librime 的 YAML 配方和拼写代数提供了更灵活的原型工具；如果你只是想在桌面上配置一个现成的输入法，fcitx5 的图形界面更直接。
编辑结论
librime 适合两类人：一是想深度定制输入法、愿意写 YAML 配方和 C++ 插件的开发者，二是需要跨平台一致输入体验的团队，官方前端覆盖 Linux、macOS、Windows，社区前端延伸到 Android、iOS、Vim、Emacs 甚至 tmux。不适合只想要开箱即用输入法的普通用户，他们应该直接使用 Squirrel、Weasel 或 fcitx5-rime。采用前需要验证三件事：确认你的平台有对应的官方或社区前端，检查依赖库（boost、leveldb、marisa-trie、opencc、yaml-cpp）能否在目标系统上编译，以及评估维护成本，librime 的发布节奏较快（2026 年已有 1.17.0），跟进上游更新需要投入时间。librime 的 BSD-3-Clause 许可允许商业使用，但如果你依赖 librime-lua 或 librime-octagram 这类插件，它们各自的许可证需要单独检查。最终判断：librime 是一个强大但门槛高的引擎，适合把输入法当作软件项目来维护的人，而不是当作工具来用的人。
社区笔记