日本人为什么要参拜靖国神社？因为对于大和民族来说，里面所供奉的：都是他们民族的英雄呀！
             　　为了国家民族的荣誉，日本军人可以驾机冲向美国军舰，同归于尽！战败时可以集体剖腹！剖腹！
             　　你知道怎样剖腹吗？把刀插进腹部往胸部用力一剖，再横着用力一刀！
             　　淋漓尽致！
             　　为了祖国的尊严，你们谁敢！谁愿？！不敢就没有资格说日本人！
             　　张自忠，是谁？
             　　邱少云，还记得吗？
             　　朝鲜战场上的两位特级战斗英雄是谁？
             　　回答的出来吗？你知道他们的事迹吗？你知道他们是怎样死的吗？今天我们已经把他们遗忘了差不多了吧？
            
            　　我们已经蜕变了，我们已经没有了精神，我们不配做中国人，我们的时代罕有英雄，罕有男子汉！我们丢了祖宗的脸，中国历史上从来没有一个时代象今天一样窝囊！

            
            
            --------------------------------------------------------------------------------
            
             　　当然这指的不是我们的政府，而是我们的这一代人。
             　　我们的政府懂得强国之道，懂得什么叫忍辱负重，后发制人，我们的政府建立了丰功伟绩。
             　　而我们的青年，除了象狗一样叫几声，骂几声，无所作为。
            
            　　我们的祖先在历史上领先了几千年，多少英雄豪杰，多少王朝强盛之极天下之大，唯我独尊，侠客英雄，君子大家层出不穷，他们能够舍生取义，光明磊落，精忠报国，贫贱不能移，威武不能屈。

             　　而今天为了钱可以没有人格，更何况什么国家民族的尊严？！
             　　没有想到，到了今天，中国已经找不到什么英雄！
             　　即使有，也被官吏当作花瓶装饰一下政绩!被一些白痴当做傻瓜猴子嘲笑！
             　　今天是我们自己有人看不起中国传统的东西，它们是西洋的走狗！
             　　日本人有靖国神社可以参拜，我们没有！也没有人要去！
             　　烈士尸骨还在，名字已经消失……
             　　我想找个给英雄下跪的地方！
             　　我想请日本人告诉我当年是谁在中国的哪个地方和日军血战过！
             　　不过日本人肯定不告诉我，我们的英雄已经战死几十年，日本人仍然害怕他们。
            
            
            --------------------------------------------------------------------------------
            
             　　但今天我们比抗日时有钱，日本人却变本加厉地唾弃我们！
             　　这不能怪他们，我们是活该的：
            
            　　一面我们的尾巴翘得如此之高，欢迎日本的二流商品在中国称雄，陶醉于日本影片，崇拜日本明星，我宁愿他崇拜东条英机，将来成为中国的东条去灭了日本。

             　　一方面我们的下一代很多被娇生惯养，严肃的东西不看，中国历史一问三不知，中国的未来是一大群软骨头的孬种。
             　　当日本人在小学课本里彻底扭曲侵华历史时，我们的教育学家居然在讨论金庸武侠小说要不要入选中学教材！
             　　更何况，我们不知从什么时候起，居然连英雄都唾弃。
             　　这已不是悲哀那么简单了！
             　　在民族精神上，中国人不如日本人。
            
            　　日本人说：从总体上看，支纳人是世界上最低劣的种族。在总体素质上，南方支纳人又要远远优于北方支纳人……我们日本人（除了只会叩头的少数政客外）愿意称你们国家为支纳，不愿称它为中国，但我们称宋代以前为中国。我们轻视支纳人的一个原因是……我小的时候，父亲带我去日比谷公园，指着缴获北洋水师的战利品对我说，日本就是在打败支纳的北洋水师后，才成为世界上主要强国的。当我来到支纳的时候，我发现支纳人比我想象的还要低劣，他们对我这个毫无背景的日本学生点头哈腰，说什么都是日本的好……当我问他们支纳一个在韩战中为了完成任务宁愿被火烧死的英雄时，他们居然说那种傻瓜再也不会有了。我们日本有靖国神社……我们日本人将会永记为国殉死的英灵，他们在靖国神社里享受他们应得的敬意。每当我们唱起为国而逝的英魂啊，你要常常回到慈母的梦中，我们就会感慨万千，永志难忘。

             　　支纳人，我们敬拜靖国神社时，你们根本没有资格说三道四。
            
            
            --------------------------------------------------------------------------------
            
             　　对他的说法我深有知己之感，他日我若在战场上遇到他，必先干上三杯再打！
             　　张自忠将军在枣宜战役壮烈而死，日本高级军官亲自抬棺！
             　　虽为敌人，杀死日本人无数，但日本人起码知道，英雄是用来崇拜的，这样的英雄，即使是敌人，也应表示万分的敬意。
             　　只有这样敬重英雄的民族，才能长盛不衰，日本人就是这样的民族，日本人不是看不起中国，而是看不起现在的中国人。
             　　我们的祖先他们不敢辱没。
             　　只有我们这些不肖的子孙自己才干出辱没祖宗的事，忘了祖宗的许多精神和思想精髓。
             　　日本人只尊重强者，你打死他，也要尊重你。
             　　日本人唾弃弱者，你越跪得欢他越把你当狗对待。
             　　而我们是弱者。
             　　中国的历史上，有多少英雄惜英雄的故事，如今只是故事罢了。现在的人连自己眼前的英雄都讥为傻瓜！何况别人的英雄？
            
            　　当然，我说是有立场的，日本人的英雄是我的敌人，但即使要灭之而后快，也应先敬三分，对于本国的小人汉奸，即使是同一祖宗，也应诛杀而唾弃。

            
            　　我们有的人看不起先辈，看不起父辈，认为他们老土，但正是在这些老土的父辈身上，才有希望看到中华民族真正的精华，正是他们直接间接和日本美帝斗争，才保住了我们的最后一点尊严。

             　　今天中国周边形式严峻，也有许多英雄在大叫骂娘，让我感到中国真的没有希望了，关键是没有人想一下我们能干什么？
             　　我们要报仇，但只不是用嘴！那只会象阿Q！
             　　血债要血还，但我们要懂得尊重自己尊重敌人，大丈夫喜怒不露，杀人于无形。
             　　如果，打一场仗可以打出我们的民族精神来，可以让我们的科技和工业前进一大步。
             　　那么，我们打！
             　　无赖的老年日本人根本就不承认侵略过中国！
             　　无知的年轻日本人根本就不知道侵略过中国！
             　　无耻的军国主义者说当慰安妇在是一种荣耀！
             　　我们却在自我安慰的寄希望于日本人的良知！
             　　而他们认为我们这些可怜的第三世界在编造故事以敲诈他们的钱财……
            
            
            --------------------------------------------------------------------------------
            
             　　如果你是一个不太喜欢狂热、激进的温和派，那么我个人认为你应该所做的是：
             　　把不买日货这个原则默默地记在心里，我们没有必要非得用示wei或游xing来反对日本可耻的行为。
             　　我们应在心里默默的抗议日本对我们犯下的错误和他们对这些错误无耻的抵赖！
             　　这是做为中国人最起码的原则吧？
             　　我们只需要在购买商品的时候更多的忽视一下日货，能不买日货就不要去买。
             　　相信自己，只要我们团结起来，人人都能做到这一点，就会使日本在经济上受到打击，就会使他们不敢再轻视我们的力量。
             　　如果你认为我是在痴人说梦，那么可以先看看下面的数据：
             　　在世界各地，几乎90%的华人用的是日本车和日本电器。
             　　我统计过如果世界各地的华人停止购买日货，日本每年将损失1000-1400亿美元的外汇收入！
             　　而外汇收入是任何一个国家的源泉和动力！
             　　它和国民经济的关系是一带动八，或者说：损失一份外贸收入，这个国家就要损失八份的国内经济收入。
             　　换算一下：1000-1400亿美元的外汇收入等价于一兆美元：日本经济的总产值的五分之一。
             　　所以，如果世界各地华人同心协力，不用动刀动枪，就可制日本于死地！！
             　　而且是永久的死地！
            
            
            --------------------------------------------------------------------------------
            
             　　我们应该学习尤太人：曾经集体拒买一家德国工厂的产品，最后导致这家公司的彻底破产！
             　　起因就是因为这个公司的总裁说了一些所谓理解希特勒的话！
             　　现在德国人对犹太人特别好，您知道为什么吗？
             　　原因有二：
             　　一个是怕：因为尤太人特别团结；
             　　第二个是尤太人的狠：尤太人从来没有放弃过对纳粹分子的追杀！
             　　只要在这个地球上发现有任何藏匿的纳粹分子，他们就一定就会抓捕绑架如果实在无法得手，那就杀！
             　　看看我们中国呢？！
             　　对刽子手的仁慈，无疑就是自杀！
             　　开始行动吧！
             　　同胞们：多少年过去了，还要等吗？
             　　开始行动吧：
             　　从我开始做起！
             　　从我家开始做起！！
             　　从我的朋友开始做起！！！
             　　从我身边的各个组织开始做起！！！！
             　　只要大家共同努力：
             　　最后，我想最多10年，全世界所有的华人都会做到！
             　　既使能做到一半。对日本的打击也是致命的！！
             　　组织一个全球性的拒买日货复仇组织，请在各地串连串连，好吗？！
             　　同胞们，开始行动吧！
            
            
            --------------------------------------------------------------------------------
            
             　　请大家意识到拒买日货的重要性。
             　　拒买日货首先要防止被日本狗误导。
            
            　　有些所谓的爱国人士（其时是被日本秘密收买的哈巴狗，目地是挑拨分离我们本来就不团结的中华大众），它们经常提出：拒买日货是不可能做到的，原因是几乎所有的轿车、电器里，多少都有日本的零件。所以还是打住吧！

             　　拒买日货就到此为止是什么用意？
             　　难道中国人感觉不到么！感觉不到日本在害怕！
             　　他们害怕看到中国大众组织起来，进而进行有效的抵制日货运动！
             　　故而在这个五十多年来首次完全有可能组织其一个有效的全球性拒买日货运动时，他们便会迫不及待地跳出来叫停！
             　　拒买日货，并非像他们所说的哪样因为这个计算机里有一个或一些日本零件，我就不买；这个电视里有几个日本造的电子器件，我就不要。
             　　拒买日货的口号实际上是要求全球中国人，在有选择可能的情况下，尽量不买日本造的货物，如汽车、电冰箱、洗衣机、电视、音响等等！
             　　五十多年来，华人一直记恨于日本，但可笑的是却没有一个有力的拒买日货组织！
             　　究其原因,就是因为中国有太多的日本狗从中挑拨分离我们本来就不团结的中华大众！
             　　中国同胞们：清醒过来吧！千万不要再被这种人玩耍了！
             　　拒买日货的意义是巨大的！
             　　她能让我们不动一刀一枪就打击了日本，同时又加快了中国经济的发展！
             　　她能让我们扼制日本，进而让中国立于不败之地！
             　　她能让我们的子孙免遭我们的前几代祖先和我们现代中国人所遭受的痛苦！
             　　她最终也能让这个几百年来一直顽固不化，一再屠杀掠夺中国人民的丑陋民族遭受到它应有的惩罚！
             　　你以为这容易做到吗？绝对不是！
             　　这需要我们大家的共同努力，才能让全体中国人慢慢地，逐渐的，先是意识到，然后才能真实地做到！
             　　至于某些不必要的担心：
             　　1.中日关系日渐友好。
             　　中日友好根本就不存在！过去没有，现在没有，将来也不会有！
             　　清醒过来吧，不要再自己骗自己！
             　　2.现在中日两国贸易总额每年达600亿美元。会不会因为我们全球华人对抵制日货，中国就会受到损失？
             　　这是不会的！原因是：
             　　a.日本出口到中国的是高级奢侈品，我们中华大众可以拒绝；
             　　b.中国出口到日本的是普通生活必须品，日本人很难抵制，他们其实是在享受着我们廉价的产品！
            
            　　3.另外，从中国的长远利益来看，减少对日本产品的过份依赖，对中国的国家安全是非常重要的，比如日本参加美国的NMD，其目的就是与中国为敌！

0、准备工作
　　去Lucene的主页下载目前的稳定版本lucene-1.2.tar.gz，解压缩，将lucene-1.2目录下的两个jar文件lucene-1.2.jar和lucene-demo2-1.2.jar放到适当的目录下后，并将其加入到CLASSPATH环境变量中。

1、运行demo

3、运行LuceneWeb
　　假定tomcat装在$TOMCATHOME目录下，具体应用时用真实的目录替换$TOMCATHOME。

内容摘要：

Lucene是一个基于Java的全文索引工具包。

作者： 车东 Email: chedongATbigfoot.com/chedongATchedong.com

写于：2002/08 最后更新： 03/16/2005 16:27:52

1. 基于Java的全文索引引擎Lucene简介：关于作者和Lucene的历史
2. 全文检索的实现：Luene全文索引和数据库索引的比较
3. 中文切分词机制简介：基于词库和自动切分词算法的比较
4. 具体的安装和使用简介：系统结构介绍和演示
5. Hacking Lucene：简化的查询分析器，删除的实现，定制的排序，应用接口的扩展
6. 从Lucene我们还可以学到什么

基于Java的全文索引/检索引擎——Lucene

Lucene不是一个完整的全文索引应用，而是是一个用Java写的全文索引引擎工具包，它可以方便的嵌入到各种应用中实现针对应用的全文索引/检索功能。

Lucene的作者：Lucene的贡献者Doug Cutting是一位资深全文索引/检索专家，曾经是V-Twin搜索引擎(Apple的Copland操作系统的成就之一)的主要开发者，后在Excite担任高级系统架构设计师，目前从事于一些INTERNET底层架构的研究。他贡献出的Lucene的目标是为各种中小型应用程序加入全文检索功能。

Lucene的发展历程：早先发布在作者自己的www.lucene.com，后来发布在SourceForge，2001年年底成为APACHE基金会jakarta的一个子项目：http://jakarta.apache.org/lucene/

已经有很多Java项目都使用了Lucene作为其后台的全文索引引擎，比较著名的有：

• Jive：WEB论坛系统；
• Eyebrows：邮件列表HTML归档/浏览/查询系统，本文的主要参考文档“TheLucene search engine: Powerful, flexible, and free”作者就是EyeBrows系统的主要开发者之一，而EyeBrows已经成为目前APACHE项目的主要邮件列表归档系统。
• Cocoon:基于XML的web发布框架，全文检索部分使用了Lucene

• Eclipse:基于Java的开放开发平台，帮助部分的全文索引使用了Lucene

对于中文用户来说，最关心的问题是其是否支持中文的全文检索。但通过后面对于Lucene的结构的介绍，你会了解到由于Lucene良好架构设计，对中文的支持只需对其语言词法分析接口进行扩展就能实现对中文检索的支持。

全文检索的实现机制

Lucene的API接口设计的比较通用，输入输出结构都很像数据库的表==>记录==>字段，所以很多传统的应用的文件、数据库等都可以比较方便的映射到Lucene的存储结构/接口中。总体上看：可以先把Lucene当成一个支持全文索引的数据库系统。

比较一下Lucene和数据库：

索引数据源：doc(field1,field2...) doc(field1,field2...)
                  \  indexer /
                 _____________
                | Lucene Index|
                --------------
                 / searcher \
 结果输出：Hits(doc(field1,field2) doc(field1...))

 索引数据源：record(field1,field2...) record(field1..)
              \  SQL: insert/
               _____________
              | DB  Index   |
               -------------
              / SQL: select \
结果输出：results(record(field1,field2..) record(field1...))

全文检索 ≠ like "%keyword%"

通常比较厚的书籍后面常常附关键词索引表（比如：北京：12, 34页，上海：3,77页……），它能够帮助读者比较快地找到相关内容的页码。而数据库索引能够大大提高查询的速度原理也是一样，想像一下通过书后面的索引查找的速度要比一页一页地翻内容高多少倍……而索引之所以效率高，另外一个原因是它是排好序的。对于检索系统来说核心是一个排序问题。

由于数据库索引不是为全文索引设计的，因此，使用like "%keyword%"时，数据库索引是不起作用的，在使用like查询时，搜索过程又变成类似于一页页翻书的遍历过程了，所以对于含有模糊查询的数据库服务来说，LIKE对性能的危害是极大的。如果是需要对多个关键词进行模糊匹配：like"%keyword1%" and like "%keyword2%" ...其效率也就可想而知了。

所以建立一个高效检索系统的关键是建立一个类似于科技索引一样的反向索引机制，将数据源（比如多篇文章）排序顺序存储的同时，有另外一个排好序的关键词列表，用于存储关键词==>文章映射关系，利用这样的映射关系索引：[关键词==>出现关键词的文章编号，出现次数（甚至包括位置：起始偏移量，结束偏移量），出现频率]，检索过程就是把模糊查询变成多个可以利用索引的精确查询的逻辑组合的过程。从而大大提高了多关键词查询的效率，所以，全文检索问题归结到最后是一个排序问题。

由此可以看出模糊查询相对数据库的精确查询是一个非常不确定的问题，这也是大部分数据库对全文检索支持有限的原因。Lucene最核心的特征是通过特殊的索引结构实现了传统数据库不擅长的全文索引机制，并提供了扩展接口，以方便针对不同应用的定制。

可以通过一下表格对比一下数据库的模糊查询：

全文检索和数据库应用最大的不同在于：让最相关的头100条结果满足98%以上用户的需求

Lucene的创新之处：

大部分的搜索（数据库）引擎都是用B树结构来维护索引，索引的更新会导致大量的IO操作，Lucene在实现中，对此稍微有所改进：不是维护一个索引文件，而是在扩展索引的时候不断创建新的索引文件，然后定期的把这些新的小索引文件合并到原先的大索引中（针对不同的更新策略，批次的大小可以调整），这样在不影响检索的效率的前提下，提高了索引的效率。

Lucene和其他一些全文检索系统/应用的比较：

关于亚洲语言的的切分词问题(Word Segment)

对于中文来说，全文索引首先还要解决一个语言分析的问题，对于英文来说，语句中单词之间是天然通过空格分开的，但亚洲语言的中日韩文语句中的字是一个字挨一个，所有，首先要把语句中按“词”进行索引的话，这个词如何切分出来就是一个很大的问题。

首先，肯定不能用单个字符作(si-gram)为索引单元，否则查“上海”时，不能让含有“海上”也匹配。

但一句话：“北京天安门”，计算机如何按照中文的语言习惯进行切分呢？
“北京 天安门” 还是“北 京 天安门”？让计算机能够按照语言习惯进行切分，往往需要机器有一个比较丰富的词库才能够比较准确的识别出语句中的单词。

另外一个解决的办法是采用自动切分算法：将单词按照2元语法(bigram)方式切分出来，比如：
"北京天安门" ==> "北京 京天 天安 安门"。

这样，在查询的时候，无论是查询"北京" 还是查询"天安门"，将查询词组按同样的规则进行切分："北京"，"天安安门"，多个关键词之间按与"and"的关系组合，同样能够正确地映射到相应的索引中。这种方式对于其他亚洲语言：韩文，日文都是通用的。

基于自动切分的最大优点是没有词表维护成本，实现简单，缺点是索引效率低，但对于中小型应用来说，基于2元语法的切分还是够用的。基于2元切分后的索引一般大小和源文件差不多，而对于英文，索引文件一般只有原文件的30%-40%不同，

目前比较大的搜索引擎的语言分析算法一般是基于以上2个机制的结合。关于中文的语言分析算法，大家可以在Google查关键词"wordsegment search"能找到更多相关的资料。

安装和使用

下载：http://jakarta.apache.org/lucene/

注意：Lucene中的一些比较复杂的词法分析是用JavaCC生成的（JavaCC：JavaCompilerCompiler，纯Java的词法分析生成器），所以如果从源代码编译或需要修改其中的QueryParser、定制自己的词法分析器，还需要从https://javacc.dev.java.net/下载javacc。

lucene的组成结构：对于外部应用来说索引模块(index)和检索模块(search)是主要的外部应用入口

简单的例子演示一下Lucene的使用方法：

public class IndexFiles { 
  //使用方法：: IndexFiles [索引输出目录] [索引的文件列表] ... 
  public static void main(String[] args) throws Exception {
    String indexPath = args[0];
    IndexWriter writer;
    //用指定的语言分析器构造一个新的写索引器（第3个参数表示是否为追加索引）
    writer = new IndexWriter(indexPath, new SimpleAnalyzer(), false);

    for (int i=1; i<args.length; i++) {
      System.out.println("Indexing file " + args[i]);
      InputStream is = new FileInputStream(args[i]);

      //构造包含2个字段Field的Document对象
      //一个是路径path字段，不索引，只存储
      //一个是内容body字段，进行全文索引，并存储
      Document doc = new Document();
      doc.add(Field.UnIndexed("path", args[i]));
      doc.add(Field.Text("body", (Reader) new InputStreamReader(is)));
      //将文档写入索引
      writer.addDocument(doc);
      is.close();
    };
    //关闭写索引器
    writer.close();
  }
}
　

索引过程中可以看到：

• 语言分析器提供了抽象的接口，因此语言分析(Analyser)是可以定制的，虽然lucene缺省提供了2个比较通用的分析器SimpleAnalyser和StandardAnalyser，这2个分析器缺省都不支持中文，所以要加入对中文语言的切分规则，需要修改这2个分析器。
• Lucene并没有规定数据源的格式，而只提供了一个通用的结构（Document对象）来接受索引的输入，因此输入的数据源可以是：数据库，WORD文档，PDF文档，HTML文档……只要能够设计相应的解析转换器将数据源构造成成Docuement对象即可进行索引。
• 对于大批量的数据索引，还可以通过调整IndexerWrite的文件合并频率属性（mergeFactor）来提高批量索引的效率。

检索过程和结果显示：

搜索结果返回的是Hits对象，可以通过它再访问Document==>Field中的内容。

假设根据body字段进行全文检索，可以将查询结果的path字段和相应查询的匹配度(score)打印出来，

public class Search { 
  public static void main(String[] args) throws Exception {
    String indexPath = args[0], queryString = args[1];
    //指向索引目录的搜索器
    Searcher searcher = new IndexSearcher(indexPath);
    //查询解析器：使用和索引同样的语言分析器
    Query query = QueryParser.parse(queryString, "body", 
                              new SimpleAnalyzer());
    //搜索结果使用Hits存储
    Hits hits = searcher.search(query);
    //通过hits可以访问到相应字段的数据和查询的匹配度
    for (int i=0; i<hits.length(); i++) {
      System.out.println(hits.doc(i).get("path") + "; Score: " + 
                         hits.score(i));
    };
  }
}

Hacking Lucene

简化的查询分析器

个人感觉lucene成为JAKARTA项目后，画在了太多的时间用于调试日趋复杂QueryParser，而其中大部分是大多数用户并不很熟悉的，目前LUCENE支持的语法：

Query ::= ( Clause )*
Clause ::= ["+", "-"] [<TERM> ":"] ( <TERM> | "(" Query ")")

中间的逻辑包括：and or + - &&||等符号，而且还有"短语查询"和针对西文的前缀/模糊查询等，个人感觉对于一般应用来说，这些功能有一些华而不实，其实能够实现目前类似于Google的查询语句分析功能其实对于大多数用户来说已经够了。所以，Lucene早期版本的QueryParser仍是比较好的选择。

添加修改删除指定记录（Document）

Lucene提供了索引的扩展机制，因此索引的动态扩展应该是没有问题的，而指定记录的修改也似乎只能通过记录的删除，然后重新加入实现。如何删除指定的记录呢？删除的方法也很简单，只是需要在索引时根据数据源中的记录ID专门另建索引，然后利用IndexReader.delete(Termterm)方法通过这个记录ID删除相应的Document。

根据某个字段值的排序功能

lucene缺省是按照自己的相关度算法（score）进行结果排序的，但能够根据其他字段进行结果排序是一个在LUCENE的开发邮件列表中经常提到的问题，很多原先基于数据库应用都需要除了基于匹配度（score）以外的排序功能。而从全文检索的原理我们可以了解到，任何不基于索引的搜索过程效率都会导致效率非常的低，如果基于其他字段的排序需要在搜索过程中访问存储字段，速度回大大降低，因此非常是不可取的。

但这里也有一个折中的解决方法：在搜索过程中能够影响排序结果的只有索引中已经存储的docID和score这2个参数，所以，基于score以外的排序，其实可以通过将数据源预先排好序，然后根据docID进行排序来实现。这样就避免了在LUCENE搜索结果外对结果再次进行排序和在搜索过程中访问不在索引中的某个字段值。

这里需要修改的是IndexSearcher中的HitCollector过程：

...
　scorer.score(new HitCollector() {
	private float minScore = 0.0f;
	public final void collect(int doc, float score) {
	  if (score > 0.0f &&			  // ignore zeroed buckets
	      (bits==null || bits.get(doc))) {	  // skip docs not in bits
	    totalHits[0]++;
	    if (score >= minScore) {
              /* 原先：Lucene将docID和相应的匹配度score例入结果命中列表中：
	       * hq.put(new ScoreDoc(doc, score));	  // update hit queue
               * 如果用doc 或 1/doc 代替 score，就实现了根据docID顺排或逆排
               * 假设数据源索引时已经按照某个字段排好了序，而结果根据docID排序也就实现了
               * 针对某个字段的排序，甚至可以实现更复杂的score和docID的拟合。
               */
              hq.put(new ScoreDoc(doc, (float) 1/doc )); 
	      if (hq.size() > nDocs) {		  // if hit queue overfull
		hq.pop();			  // remove lowest in hit queue
		minScore = ((ScoreDoc)hq.top()).score; // reset minScore
	      }
	    }
	  }
	}
      }, reader.maxDoc());

更通用的输入输出接口

虽然lucene没有定义一个确定的输入文档格式，但越来越多的人想到使用一个标准的中间格式作为Lucene的数据导入接口，然后其他数据，比如PDF只需要通过解析器转换成标准的中间格式就可以进行数据索引了。这个中间格式主要以XML为主，类似实现已经不下4，5个：

数据源: WORD       PDF     HTML    DB       other
         \          |       |      |         /
                       XML中间格式
                            |
                     Lucene INDEX

目前还没有针对MSWord文档的解析器，因为Word文档和基于ASCII的RTF文档不同，需要使用COM对象机制解析。这个是我在Google上查的相关资料：http://www.intrinsyc.com/products/enterprise_applications.asp
另外一个办法就是把Word文档转换成text：http://www.winfield.demon.nl/index.html

索引过程优化

索引一般分2种情况，一种是小批量的索引扩展，一种是大批量的索引重建。在索引过程中，并不是每次新的DOC加入进去索引都重新进行一次索引文件的写入操作（文件I/O是一件非常消耗资源的事情）。

Lucene先在内存中进行索引操作，并根据一定的批量进行文件的写入。这个批次的间隔越大，文件的写入次数越少，但占用内存会很多。反之占用内存少，但文件IO操作频繁，索引速度会很慢。在IndexWriter中有一个MERGE_FACTOR参数可以帮助你在构造索引器后根据应用环境的情况充分利用内存减少文件的操作。根据我的使用经验：缺省Indexer是每20条记录索引后写入一次，每将MERGE_FACTOR增加50倍，索引速度可以提高1倍左右。

搜索过程优化

lucene支持内存索引：这样的搜索比基于文件的I/O有数量级的速度提升。
http://www.onjava.com/lpt/a/3273
而尽可能减少IndexSearcher的创建和对搜索结果的前台的缓存也是必要的。

Lucene面向全文检索的优化在于首次索引检索后，并不把所有的记录（Document）具体内容读取出来，而起只将所有结果中匹配度最高的头100条结果（TopDocs）的ID放到结果集缓存中并返回，这里可以比较一下数据库检索：如果是一个10,000条的数据库检索结果集，数据库是一定要把所有记录内容都取得以后再开始返回给应用结果集的。所以即使检索匹配总数很多，Lucene的结果集占用的内存空间也不会很多。对于一般的模糊检索应用是用不到这么多的结果的，头100条已经可以满足90%以上的检索需求。

如果首批缓存结果数用完后还要读取更后面的结果时Searcher会再次检索并生成一个上次的搜索缓存数大1倍的缓存，并再重新向后抓取。所以如果构造一个Searcher去查1－120条结果，Searcher其实是进行了2次搜索过程：头100条取完后，缓存结果用完，Searcher重新检索再构造一个200条的结果缓存，依此类推，400条缓存，800条缓存。由于每次Searcher对象消失后，这些缓存也访问那不到了，你有可能想将结果记录缓存下来，缓存数尽量保证在100以下以充分利用首次的结果缓存，不让Lucene浪费多次检索，而且可以分级进行结果缓存。

Lucene的另外一个特点是在收集结果的过程中将匹配度低的结果自动过滤掉了。这也是和数据库应用需要将搜索的结果全部返回不同之处。

我的一些尝试：

• 支持中文的Tokenizer：这里有2个版本，一个是通过JavaCC生成的，对CJK部分按一个字符一个TOKEN索引，另外一个是从SimpleTokenizer改写的，对英文支持数字和字母TOKEN，对中文按迭代索引。
• 基于XML数据源的索引器：XMLIndexer，因此所有数据源只要能够按照DTD转换成指定的XML，就可以用XMLIndxer进行索引了。
• 根据某个字段排序：按记录索引顺序排序结果的搜索器：IndexOrderSearcher，因此如果需要让搜索结果根据某个字段排序，可以让数据源先按某个字段排好序（比如：PriceField），这样索引后，然后在利用这个按记录的ID顺序检索的搜索器，结果就是相当于是那个字段排序的结果了。

从Lucene学到更多

Luene的确是一个面对对象设计的典范

• 所有的问题都通过一个额外抽象层来方便以后的扩展和重用：你可以通过重新实现来达到自己的目的，而对其他模块而不需要；
• 简单的应用入口Searcher, Indexer，并调用底层一系列组件协同的完成搜索任务；
• 所有的对象的任务都非常专一：比如搜索过程：QueryParser分析将查询语句转换成一系列的精确查询的组合(Query),通过底层的索引读取结构IndexReader进行索引的读取，并用相应的打分器给搜索结果进行打分/排序等。所有的功能模块原子化程度非常高，因此可以通过重新实现而不需要修改其他模块。 
• 除了灵活的应用接口设计，Lucene还提供了一些适合大多数应用的语言分析器实现（SimpleAnalyser,StandardAnalyser），这也是新用户能够很快上手的重要原因之一。

这些优点都是非常值得在以后的开发中学习借鉴的。作为一个通用工具包，Lunece的确给予了需要将全文检索功能嵌入到应用中的开发者很多的便利。

此外，通过对Lucene的学习和使用，我也更深刻地理解了为什么很多数据库优化设计中要求，比如：

• 尽可能对字段进行索引来提高查询速度，但过多的索引会对数据库表的更新操作变慢，而对结果过多的排序条件，实际上往往也是性能的杀手之一。
• 很多商业数据库对大批量的数据插入操作会提供一些优化参数，这个作用和索引器的merge_factor的作用是类似的，
• 20%/80%原则：查的结果多并不等于质量好，尤其对于返回结果集很大，如何优化这头几十条结果的质量往往才是最重要的。
• 尽可能让应用从数据库中获得比较小的结果集，因为即使对于大型数据库，对结果集的随机访问也是一个非常消耗资源的操作。
  

参考资料：

Apache: Lucene Project
http://jakarta.apache.org/lucene/
Lucene开发/用户邮件列表归档
Lucene-dev@jakarta.apache.org
Lucene-user@jakarta.apache.org

The Lucene search engine: Powerful, flexible, and free
http://www.javaworld.com/javaworld/jw-09-2000/jw-0915-Lucene_p.html

Lucene Tutorial
http://www.darksleep.com/puff/lucene/lucene.html

Notes on distributed searching with Lucene
http://home.clara.net/markharwood/lucene/

中文语言的切分词
http://www.google.com/search?sourceid=navclient&hl=zh-CN&q=chinese+word+segment

搜索引擎工具介绍
http://searchtools.com/

Lucene作者Cutting的几篇论文和专利
http://lucene.sourceforge.net/publications.html 

Lucene的.NET实现：dotLucene
http://sourceforge.net/projects/dotlucene/

Lucene作者Cutting的另外一个项目：基于Java的搜索引擎Nutch
http://www.nutch.org/   http://sourceforge.net/projects/nutch/

关于基于词表和N-Gram的切分词比较
http://china.nikkeibp.co.jp/cgi-bin/china/news/int/int200302100112.html

2005-01-08 Cutting在Pisa大学做的关于Lucene的讲座：非常详细的Lucene架构解说