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
Code
1
public
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
Code
1
/**/
///
<summary>
2
///
加入ReadToEnd方法，读取整个流的字符
3
///
</summary>
4
///
<returns>
返回读取字符
</returns>
5
public
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 可以使用的内置分词讲到过一点，更多的还是留着后面讲，要不然内容就全放到分词里了。
二元分词比单字分词的优势是很明显的，达到了我们原先的目的：减小干扰。用户搜索的数据其实最好是给一个或者几个结果，而不是动辄上千，那和没筛选没什么区别。做搜索系统，目地就是能自动帮助用户得到他想要的东西，而不是给用户看看你有多少数据。
二元分词的劣势也充分地暴露了出来，那就是分词不准确。如果还是以二元分词为基础，尽量地让分词准确的话，可以做一些这样的考虑。比如对于中文数字按单字拆分，而对于某些特殊字，比如“的，啊，吗，呢”等助词也按单字拆分，这样就能用简单的分词来解决实际的。在小型的搜索系统中，二元分词已经足够使用了。如果还要追求更好的效果，那就要用词库匹配了。从自然语言上来说，基于语义分析当然是最好的。但是会产生另外的问题，因为分析业务的复杂，导致开发难度的加大运行速度变慢，这些都是使用时需要考虑的问题。
作为分词在一个阶段的结束篇，总感觉有点虎头蛇尾的味道。而如果现在讲基于词库，语言方面的分词感觉还是早了点，因此，这里就匆匆收笔，准备进入索引部分的探索。关于分词更加详细的应用将会在高级篇里展开。
