Lucene.Net 2.3.1开发介绍 —— 二、分词（六）

Lucene.Net的上一个版本是2.1，而在2.3.1版本中才引入了Next(Token)方法重载，而ReusableStringReader类也是在新版本中引入的。这样改变，导致了2.3.1版本不得不修改2.1版以前的所有分词器。带来的另外一个问题的是，以前的一些现有分词器，拿到这里可能就不能用了。

 

要使用ReadToEnd还有另外一个解决方法——修改Lucene.Net源码。

 

在修改之前，我们需要知道ReusableStringReader作为StringReader的子类，为什么让ReadToEnd方法无效了。先查看.Net Framework StringReader源码关于ReadToEnd方法的那段。

 

 

代码 2.1.3.7

 

 1public override string ReadToEnd()
 2{
 3    string str;
 4    if (this._s == null)
 5    {
 6        __Error.ReaderClosed();
 7    }
 8    if (this._pos == 0)
 9    {
10        str = this._s;
11    }
12    else
13    {
14        str = this._s.Substring(this._pos, this._length - this._pos);
15    }
16    this._pos = this._length;
17    return str;
18}

 

代码 2.1.3.7就是我们要找的源码，对比ReusableStringReader类，发现，在ReusableStringReader类里没有为父类——StringReader——的私有字段"_s"赋值。而赋值的方式就是调用构造函数。ReusableStringReader为什么没有那么做呢？这点是让人看不明白，不过看看它的java版本也就释然了。在java版本中有这么一个类，所以在dot net版本中也就出现了。这个类是完全按照Java代码克隆出来的，是工具转换处理的，翻译人员应该是没注意到这里可以用直接用StringReader,或者注意到了但是为了保持代码的一致性而故意没有转换过来。

 

因为ReusableStringReader实例化的时候给了StringReader一个空值，为了做最小改造，重新实例化StringReader并不是好主意。所以重载一个ReadToEnd方法是个不错的选择。

 

 

代码 2.1.3.8

 

 1/**//// <summary>
 2/// 加入ReadToEnd方法，读取整个流的字符
 3/// </summary>
 4/// <returns>返回读取字符</returns>
 5public override string ReadToEnd()
 6{
 7    string str;
 8    if (this.s == null)
 9    {
10        return string.Empty;    //如果为null，这里本来该报错的
11    }
12    if (this.upto == 0)
13    {
14        //当指针在开始位置，返回整个字符。
15        //在调用了Read方法后，指针就会不在开始位置。
16        str = this.s;
17    }
18    else
19    {
20        str = this.s.Substring(this.upto, this.left - this.upto);
21    }
22    this.upto = this.left;
23    return str;
24}

 

写好了代码2.1.3.8 再次运行 代码 2.1.3.3 ，就OK了，不会出现读不出的问题了。测试一下：

 

搜索词：英语
结果：
content:英语
英语单词，语法，口语都很重要。
口语，语法，单词都是英语的重要组成部分。
-----------------------------------
搜索词：语法
结果：
content:语法
英语单词，语法，口语都很重要。
口语，语法，单词都是英语的重要组成部分。
-----------------------------------
搜索词：单词
结果：
content:单词
英语单词，语法，口语都很重要。
口语，语法，单词都是英语的重要组成部分。
我们要学好英语不但要学语法，单词还有口语。
-----------------------------------
搜索词：口语
结果：
content:口语
英语单词，语法，口语都很重要。
口语，语法，单词都是英语的重要组成部分。
我们要学好英语不但要学语法，单词还有口语。
-----------------------------------
搜索词：+content:"英" +content:"语" +content:"单" +content:"词"
结果：
+content:英 +content:语 +content:单 +content:词
-----------------------------------

结果和预料的一样，看来修改成功了。既然拿了源码，在用的不舒服的地方适当的修改修改还是很好的，呵呵。

 

当然在制作分词时，这个转换其实也可以不用的。可以直接拿缓冲字符来进行处理，那样速度会将会快那么一点。怎么做，还是大家思考一下吧，呵呵，在高级篇里将会有讲到。

 

现在二元分词器已经可以使用了，当然查询表达式也要跟着改变，如何构造查询表达式，在2.1.2 可以使用的内置分词讲到过一点，更多的还是留着后面讲，要不然内容就全放到分词里了。

 

二元分词比单字分词的优势是很明显的，达到了我们原先的目的：减小干扰。用户搜索的数据其实最好是给一个或者几个结果，而不是动辄上千，那和没筛选没什么区别。做搜索系统，目地就是能自动帮助用户得到他想要的东西，而不是给用户看看你有多少数据。

 

二元分词的劣势也充分地暴露了出来，那就是分词不准确。如果还是以二元分词为基础，尽量地让分词准确的话，可以做一些这样的考虑。比如对于中文数字按单字拆分，而对于某些特殊字，比如“的，啊，吗，呢”等助词也按单字拆分，这样就能用简单的分词来解决实际的。在小型的搜索系统中，二元分词已经足够使用了。如果还要追求更好的效果，那就要用词库匹配了。从自然语言上来说，基于语义分析当然是最好的。但是会产生另外的问题，因为分析业务的复杂，导致开发难度的加大运行速度变慢，这些都是使用时需要考虑的问题。

 

作为分词在一个阶段的结束篇，总感觉有点虎头蛇尾的味道。而如果现在讲基于词库，语言方面的分词感觉还是早了点，因此，这里就匆匆收笔，准备进入索引部分的探索。关于分词更加详细的应用将会在高级篇里展开。