@caos
2015-10-21T02:03:21.000000Z
字数 1845
阅读 1870
LT OM
Langguage Tool(LT) 作为一款基于Java语言的文本检查开源软件，有着多种语言的支持。目前就写匠项目的需要，对 LT 中文检查的实现与设计思路进行分析。取其优点，避其不足。
LT 包括错误规则配置、分词模块、文本检查三个主要的模块，其中错误规则配置是最为核心的模块，也是 LT 基于错误匹配对文本进行检查的核心思想的体现。
分词模块 LT 主要采用了成熟的第三方分词库 ICTCLAS 做分词处理，核心代码以 ictclas4j-1.0.1.jar 的集成在系统中，主要用于切分段落和语句，将整块的文本切分可标注的字词段。以各项字典文件做为字词标注的依据，标注切分后文本的词性。该模块的工作先于规则解析之前完成，是规则解析的基础。
LT 采用错误匹配的形式检查文本中可能出现的问题，使用 XML 文件配置的方式定义错误规则，目前中文的语法规则数量已经达到786个，全部以 XML 元素的形式保存在 grammar.xml 文件中。
支持用户自定义错误的语法规则，按照 pattern.xsd 和 rules.xsd 两个模板定义文件中的格式要求，配置额外的错误语法。规则解析前会对其进行语法校验。
软件会在文本处理的时候读取现有的规则配置，使用多线程的方式对分词过后的文本进行分析。
文本检查的核心类为 JLanguageTool 调用分词结果和规则结果，使用正则匹配对文本内容进行检查，并根据规则配置中的建议返回改错的结果。
作为 LT 的同类产品，从写匠项目中改错模块目前的需求来看，LT 面临着很多实际问题，也是写匠需要避免的。
中文中的量词包含阿拉伯数字、中文大小写数字等，数词的筛选很困难，找出统一的判断规则配置的难度极大。
解决方案：编写复杂的正则表达式尽可能的去匹配各种量词使用情景，难度在于对现有语法的穷举。另一种方式是更换更加智能的分词词库，提高量词的分词效果，能够减轻语法规则的配置工作。
以错误的匹配规则检查语法的方式，难以做到高度抽象，无法涵盖到不同的语法情况，就需要通过具体的字词匹配，才能满足改错的精确性。
解决方案：具体错误具体配置，依据实际出现的写作错误对规则众包配置。这就要求规则配置要足够简单易行，目前现有的配置方法需要略作改进。
一些不常用的词语和隐性的表达方式，难以用规则涵盖，使用LT提供的XML系统也难以进行统一规格化描述，不得不为每一种“隐性错误”进行区别对待，单独编写规则。
解决方案：暂无。
标点符号的类别多样，目前 LT 所使用的 ICTCLAS 分词系统，对大部分符号的支持度都不高，甚至会对一些符号进行断句处理，这样就无法通过规则匹配出大部分符号使用错误的语法规则。
解决方案：从分词系统中入手解决符号验证的问题，改进字词拆分的算法。
这里包括目前 LT 的匹配方式为从前至后的正向匹配，目前的规则无法做到反向匹配，同时多元表达的错误也无法纠正。
解决方案：解决反向匹配问题，可以重新设计规则匹配模块，或是在现有的模块基础上扩展反向匹配的算法，多元表达式目前暂无解决方案。
LT 所依赖的分词系统与规则耦合度很高，一旦更换分词系统，有可能导致之前的规则配置失效，更新修改的任务繁重。
解决方案：更换 ICTCLAS 分词系统，但可能需要重新设计规则匹配系统，调整 LT 语言标记模块与其耦合的代码，并更新规则。
现有的思路是用 python 语言完成写匠改错模块的实现，Web 服务使用 Django 框架驱动，数据库为 PostgreSQL ，另外会整合第三方的服务，作为规则处理的一部分。
需要通过 python 重构一个完整的文本检查模块，其中功能包括：
借鉴 LT 的设计思想，也需要注意的问题：