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 可以使用的内置分词讲到过一点,更多的还是留着后面讲,要不然内容就全放到分词里了。

 

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

 

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

 

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

 

本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/JIN20468320/archive/2008/10/23/3129616.aspx

加支付宝好友偷能量挖...


评论(0)网络
阅读(117)喜欢(1)lucene.net/分词技术