LanguageTool 介绍与选型指南

目标：面向需要在自建服务器上落地「语法 + 拼写检查」服务的读者，讲清 LanguageTool 是什么、能做什么、不能做什么、与 Grammarly / Hunspell / Aspell 等同类方案的差异，并给出量化选型依据。本篇为认知篇，全部信息来自官方渠道联网溯源（来源与查询日期均在正文标注），不含本地实测数据；部署与 API 实测见专栏后续各篇。

一、环境信息

本篇是纯联网溯源的认知篇，未做本地安装与调用实验。写作时核对过的官方信息源如下（查询日期均为 2026-10-28）：

💡 说明：LanguageTool 的版本号与发布物信息以 GitHub Releases 为准；本文所有版本、日期、限额数值均为上述来源在查询当日呈现的原始事实，非推测。

二、软件概述

LanguageTool 是一套开源（LGPL 2.1 或更高版本，见官方仓库 README/COPYING.txt，查询日期 2026-10-28）的校对（proofreading）软件，核心能力是找出「简单拼写检查器查不出来」的错误：主谓一致、冠词误用、易混淆词对（confusion pairs）、成语误写、标点冗余、风格问题等。它支持英语、法语、德语、西班牙语、波兰语、俄语、荷兰语、葡萄牙语以及更多语言——官方仓库 README 的表述是「English, Spanish, French, German, Portuguese, Polish, Dutch, and more than 20 other languages」，合计约 30 种语言具备完整支持（另有挪威语仅在浏览器插件中以纯拼写检查方式支持，见 languagetool.org/languages，查询日期 2026-10-28）。

项目的三个关键身份信息：

版本节奏方面，从 Releases Atom 流水可见近年为「一年 1~2 个大版本」：v6.5（2024-09-27）、v6.6（2025-03-28）、v6.7（2025-10-10）、v6.8（2026-05-05）。值得注意的是一个对部署有直接影响的发布物变化：v6.6 之后官方不再发布独立 ZIP 安装包（这一事实由社区镜像 meyayl/docker-languagetool 的 README 引用官方 CHANGES.md 记载：「official release ZIPs were discontinued after v6.6」），此后以 GitHub 仓库 tag + Maven 构建为主线，官方快照仍可从 languagetool.org/download/snapshots/ 获取。这意味着新版本落地自建服务器的主流路径转向了 Docker 发行镜像或自行构建。

💡 技术拓展：把「语法检查」从产品形态上拆开看，业界主要有三类做法——

形态	代表	特点	适用
规则引擎（本地）	LanguageTool	XML/Java 规则 + ngram 统计 + hunspell 词表，可私有部署	数据敏感、需批量校对的团队
云端写作助手	Grammarly	闭源 SaaS，AI 增强强，无自建路径	个人写作体验优先
拼写词表库	Hunspell / Aspell	只查「词拼没拼对」，无语法规则，以库/CLI 形态被集成	嵌入编辑器、OSS 项目

LanguageTool 属于「规则引擎」路线里少数同时提供可自托管 HTTP 服务与开放规则生态的一个；本文方案实际采用 LanguageTool。

三、核心架构

按官方 dev 文档（dev.languagetool.org，查询日期 2026-10-28）梳理，LanguageTool 的核心由四层构成：

1. 语言模块（language modules）：每种语言一个模块（仓库内 languagetool-language-modules/<代码>/），携带该语言的分词器、词性标注与规则集。规则分两类——XML 规则（grammar.xml，正则/分词模式匹配，社区可贡献）与 Java 规则（*.java，需要编程逻辑的复杂规则，如英语 54 个、德语 79 个，见 languagetool.org/languages 的 6.6 版统计，2025-03-27）。
2. 拼写词表（hunspell/dictionaries）：拼写检查基于 hunspell 词表（/<语言代码>/hunspell/ 目录下的 .dic/.aff），中文、日语等无空格分词语言不带拼写检查（官方语言页 Spell check 列为空）。
3. ngram 统计层（可选增强）：官方维护 1gram/2gram/3gram 的 Lucene 索引（dev.languagetool.org/finding-errors-using-n-gram-data），服务端配置 languageModel 指向数据目录后激活 confusion rule（易混淆词对，如 hear/here），显著提升建议质量。ngram 数据按语言从 dl.languagetool.org 下载，体积为数 GB 量级，属可选项。
4. 服务层（embedded HTTP server）：languagetool-server.jar 内嵌 HTTP 服务（官方启动命令 java -cp languagetool-server.jar org.languagetool.server.HTTPServer --config server.properties --port 8081，见 dev.languagetool.org/http-server），对外只暴露三个 REST 端点：/v2/check（校对）、/v2/languages（语言清单）、/v2/telemetry（遥测上报）。语言识别由 fastText 模型（lid.176.bin）承担，官方建议 Linux/macOS 上配置 fastText 以获得更好的自动检测效果。

一句话概括数据流：文本 POST 到 /v2/check → fastText 识别语言（或用请求指定的语言）→ 命中该语言的规则集（XML/Java 规则 + hunspell 拼写 + 可选 ngram 混淆规则）→ 返回 JSON 形式的 matches（每条含 rule id、出错位置 offset/length、上下文、替换建议）。

部署形态上（官方 README 与 Docker Hub Registry API，查询日期 2026-10-28），官方 README 明确列出三个社区维护的 Docker 发行镜像：meyay/languagetool、erikvl87/languagetool、silviof/docker-languagetool。截至查询日，Docker Hub 上并不存在名为 languagetool/languagetool 的官方镜像（Registry API 返回 404 object not found）；三个社区镜像中以 meyay/languagetool 跟进最快——其 6.8/latest 标签于 2026-10-11 更新、约 288 MB，直接从官方仓库 tag 构建，内置 fastText 与 Temurin 21 JRE。这些部署细节的实测与选型在 《LanguageTool 6.8 Docker Compose 部署实战》篇展开。

💡 技术拓展：拼写检查的词典实现不止 hunspell 一种，LanguageTool 语境下常见的对比——

实现	原理	在 LanguageTool 中的角色
hunspell	词表 + 词缀规则（.dic/.aff）	主流语言的拼写检查基础，替换词建议
morfologik	有限状态转换机（FST）二进制词典	部分语言（如英语 en-US 的 MORFOLOGIK_RULE_*）实际走这套
自定义词表	服务端 spelling.txt 追加词	放行产品名/黑名单词

本文（及本专栏）所述部署沿用镜像内置默认——英语走 morfologik 词典、多数欧洲语言走 hunspell，无需额外配置。

四、功能特性

以下特性清单依据官方 README、dev 文档与语言支持页整理（查询日期 2026-10-28）：

1. 约 30 种语言的语法/拼写校对。语言间支持深度差异很大：以 6.6 版官方统计（2025-03-27）为例，XML 规则数最多的是加泰罗尼亚语（8251 条，活跃度最高）、法语（6984）、英语（6074，另有 54 个 Java 规则、686 个混淆词对）、德语（5224，另有 79 个 Java 规则）；中文有 1863 条 XML 规则（以同音字/成语混淆为主，无拼写检查）；日语 735 条（无拼写检查）。
2. 语言变体感知。英语分 AU/CA/GB/NZ/ZA/US 六种变体，德语分 AT/CH/DE，葡语分 AO/BR/MZ/PT，加泰罗尼亚语分 balear/valencia 等变体；规则按变体生效（如 en-US 与 en-GB 的拼写建议不同）。
3. HTTP 服务形态。languagetool-server.jar 内嵌服务可直接被浏览器插件、编辑器插件或业务后端调用；官方浏览器插件支持把服务器指向自建实例（http://<服务器>/v2）。
4. 自动语言检测。可选 fastText 驱动（language=auto），官方测试模型为 lid.176.bin。
5. ngram 混淆规则增强（可选）。挂载 1/2/3gram Lucene 索引后，en/de/es/fr/nl 等语言激活 confusion rule，典型收益是 hear/here、their/there 这类词对建议更准。
6. 规则可按请求控制。enabledRules/disabledRules/enabledOnly 参数可在每次请求粒度启停规则；服务端也有 disabledRuleIds 等配置做全局控制。
7. 多级别校对。level 参数支持命名档位（default/picky/academic/clarity/professional/creative/customer/jobapp/objective/elegant），从「只报错误」到「风格挑刺」。
8. Premium 差异。开源版之外，官方另有付费的 LanguageTool Premium 与 Enterprise Proofreading API；云端版含开源版没有的 AI 增强规则（dev 文档明示自建基础服务「will give you a basic LanguageTool server without AI-based rules. The AI-based rules are only available in the cloud」）。公共 API 的响应也会随官方部署而变、可能包含非开源规则（dev.languagetool.org/public-http-api 原文）。

五、快速开始（最小可用示例）

本节按官方文档给出两条「零安装成本」的最小可用路径。本篇为认知篇，以下命令均为官方文档原样（来源标注在各小节），未做本地实测；逐参数实测与真实回显见专栏 《LanguageTool API 调用与运维实战（核心篇）》。

5.1 用官方公共 API 试一次校对

来源：dev.languagetool.org/public-http-api 与官方 README（查询日期 2026-10-28）：

curl -d "text=This is an test." -d "language=auto" https://api.languagetool.org/v2/check

公共 API 的官方使用约束（dev.languagetool.org/public-http-api，查询日期 2026-10-28）：

⚠️ 注意：公共 API 只适合人工低频试算与个人小工具；自动化、批量或商业用途官方明确要求自建实例或购买 Enterprise API（来源同上）。

5.2 自建服务的官方最小命令

来源：dev.languagetool.org/http-server（查询日期 2026-10-28）。官方路径是：下载快照包 LanguageTool-latest-snapshot.zip 解压后，在解压目录执行：

java -cp languagetool-server.jar org.languagetool.server.HTTPServer --config server.properties --port 8081 --allow-origin

官方同时说明：该方式得到的是不带 AI 规则的基础服务；Linux/macOS 上强烈建议先部署 fastText 与其语言识别模型（fasttextModel=/path/to/lid.176.bin 写入 server.properties），否则语言自动检测效果不佳；服务默认只监听本机，对外开放需 --public 参数；生产暴露建议置于 nginx/Apache 反代之后做 TLS 终结（来源同上）。专栏的 B2 篇以 Docker Compose 方式完成了上述过程的完整落地实测。

六、适用场景与限制

适合自建 LanguageTool 的场景（依据官方文档定性归纳）：

1. 内部写作平台、CMS、工单系统的「发帖前校对」——文本不出内网，规避公共 API 的上传与限流约束；
2. 浏览器插件用户群的统一私有服务——插件原生支持 http://<服务器>/v2 指向自建实例；
3. 中小规模的自动化校对作业（文档审校流水线、PR 描述检查）——需要可控的吞吐与规则集；
4. 需要「按请求启停规则」「按语言定制词表」的集成方——开源版规则引擎完全可控。

官方明示或由发布物事实推出的限制（来源标注）：

1. 无 Web 管理界面、无认证：自建服务不带 UI，也不支持用户鉴权（meyayl/docker-languagetool 官方 README「The self-hosted LanguageTool server does not come with its own UI or supports user authentication」）；访问控制需靠反代与网络层完成。
2. TLS 不内置：官方建议用 Apache/nginx 反代做 HTTPS（dev.languagetool.org/http-server）。
3. AI 增强规则云端专属：自建只有规则引擎 + ngram，云端 AI 规则（Premium）不随开源版分发（dev 文档原文）。
4. 部分语言深度有限：拼写检查依赖词表，中文/日语等无拼写检查；规则数少的语言检出能力有限（languagetool.org/languages 统计表）。
5. v6.6 后无官方 ZIP：裸机安装需走快照包或自行从源码构建（构建要求 Java 17 + Maven，官方 README）；新版本迭代首选 Docker 镜像。
6. 资源门槛：JVM 服务，官方社区镜像默认最大堆 1536m，ngram 全量数据多 GB——小内存机器需要压堆并慎选语言包（镜像参数表，见 meyayl/docker-languagetool README；专栏实测约束在 B2/C1 篇）。

七、同类选型对比

在「文本校对（语法 + 拼写）」这个需求域内，常见的候选及量化/定性对比如下（LanguageTool 数据来源与上文一致，查询日期 2026-10-28；Grammarly/Hunspell/Aspell 均以各自官网或官方仓库的公开定性信息为准）：

关键差异与选型建议：

1. 只需要「把拼错的词挑出来」，且能接受嵌入开发——Hunspell/Aspell 足够，资源占用几乎为零；但要「语法/搭配/风格」级别的校对，它们无法覆盖，这是 LanguageTool 存在的核心价值。
2. 追求最强英语写作体验、文本可出域、预算允许——Grammarly 体验最好，但它没有自托管路径，且官方无开源版本可比较。
3. 文本敏感（合规、内网）、需要批量自动化、或要给浏览器插件配统一后端——LanguageTool 自建是四者中唯一同时满足「语法级检查 + 私有部署 + 零按量费用」的选项；代价是维护一个 JVM 服务（内存 512MB 量级起步）与可选的数 GB ngram 数据。
4. 已在本平台落地的读者，建议按顺序阅读本专栏：《LanguageTool 6.8 Docker Compose 部署实战》完成部署，《LanguageTool 6.8 配置参数详解》吃透 JVM 与限流配置，《LanguageTool API 调用与运维实战（核心篇）》掌握全部参数与规则演示。

八、参考链接

1. LanguageTool 官网：https://languagetool.org
2. 官方仓库（README/Releases/LICENSE）：https://github.com/languagetool-org/languagetool
3. 自建 HTTP 服务官方说明：https://dev.languagetool.org/http-server
4. 公共 HTTP API 官方说明（含限流）：https://dev.languagetool.org/public-http-api
5. HTTP API 交互式文档（Swagger）：https://languagetool.org/http-api/swagger-ui/
6. 各语言规则数量统计：https://languagetool.org/languages
7. ngram 语言模型官方说明：https://dev.languagetool.org/finding-errors-using-n-gram-data
8. 官方快照下载：https://languagetool.org/download/snapshots/
9. 官方推荐社区镜像 meyayl/docker-languagetool：https://github.com/meyayl/docker-languagetool
10. 官方推荐社区镜像 Erikvl87/docker-languagetool：https://github.com/Erikvl87/docker-languagetool
11. 官方论坛：https://forum.languagetool.org
12. Enterprise Proofreading API（商业）：https://languagetool.org/proofreading-api