Lucene应用越来越多，在对中文对索引过程中，中文分词问题也就越来越重要。

在已有的分词模式中，目前比较常用的也是比较通用的有一元分词、二元分词和基于词库的分词三种。一元分词在Java版本上由yysun实现，并且已经收录到Apache。其实现方式比较简单，即将每一个汉字作为一个Token，例如：“这是中文字”，在经过一元分词模式分词后的结果为五个Token：这、是、中、文、字。而二元分词，则将两个相连的汉字作为一个Token划分，例如：“这是中文字”，运用二元分词模式分词后，得到的结果为：这是、是中、中文、文字。

一元分词和二元分词实现原理比较简单，基本支持所有东方语言。但二者的缺陷也比较明显。一元分词单纯的考虑了中文的文字而没有考虑到中文的词性，例如在上述的例子中，“中文”、“文字”这两个十分明显的中文词语就没有被识别出来。相反，二元分词则分出了太多的冗余的中文词，如上所述，“这是”、“是中”毫无意义的文字组合竟被划分为一个词语，而同样的缺陷，命中的词语也不十分准确，如上：在“这是中文字”中，“中文字”这个词语应该优先考虑的。而二元分词也未能实现。

基于词库的分词实现难度比较大，其模式也有多种，如微软在自己的软件中的汉语分词、海量的中文分词研究版，还有目前在.Net下实现的使用率较高的猎兔，和一些其他人自发实现的分词工具等等。其都有自己的分析体系，虽然分析精度高，但实现难度大，实现周期长，而且，对一般的中小型应用系统来讲，在精度的要求不是十分苛刻的环境下，这种模式对系统对消耗是一种奢侈行为。

在综合考虑一元分词、二元分词及基于词库的分词模式后，我大胆提出一种基于StopWord分割的分词模式。这种分词模式的设计思想是，针对要分割的段落，先由标点分割成标准的短句。然后根据设定的StopWord，将短句由StopWord最大化分割，分割为一个个词语。如：输入短句为“这是中文字”，设定的StopWord列表为：“这”、“是”，则最终的结果为：“中文字”。

这个例子相对比较简单，举个稍微长一点的例子：输入短句“中文软件需要具有对中文文本的输入、显示、编辑、输出等基本功能”，设定的StopWord列表为：“这”、“是”、“的”、“对”、“等”、“需要”、“具有”，则分割出对结果列表为：

====================
中文软件
中文文本
输入
显示
编辑
输出
基本功能
====================

基本实现了想要的结果，但其中也不乏不足之处，如上述的结果中“中文软件”与“中文文本”应该分割为三个独立词“中文”、“软件”和“文本”，而不是上述的结果。

并且，对StopWord列表对设置，也是相对比较复杂的环节，没有一个确定的约束来设定StopWord。我的想法是，可以将一些无意义的主语，如“我”、“你”、“他”、“我们”、“他们”等，动词“是”、“对”、“有”等等其他各种词性诸如“的”、“啊”、“一”、“不”、“在”、“人”等等（System32目录下noise.chs文件里的内容可以作为参考）作为StopWord。