版权声明：可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本声明
http://www.chedong.com/tech/weblucene.html
内容摘要：
为Lucene做一个通用XML接口一直是我最大的心愿：更方便的在WEB应用中嵌入全文检索功能
提供了XML的数据输入接口：适合将原有基于各种数据库的数据源导入到全文索引中，保证了数据源的平台无关性；
通过了基于XML的搜索结果输出：方便了通过XSLT进行前台的结果显示；
MySQL \ / JSP Oracle - DB - ==> XML ==> (Lucene Index) ==> XML - ASP MSSQL / - PHP MS Word / \ / XHTML PDF / =XSLT=> - TEXT \ XML \_________WebLucene__________/ 使用过程如下：
将数据用脚本导出成XML格式；
将XML数据源导入LUCENE索引；
从WEB界面得到XML结果输出，并通过XSLT生成HTML页面
站内全文检索的必要性
虽然大型搜索引擎的功能已经越来越强大了，很多站点都使用了Google的站内检索site:domain.com代替了自己的站内数据库“全文”检索。但依靠GOOGLE这样的大型搜索引擎做站内检索会有以下弊端：
数量有限：搜索引擎并不会深度遍历一个网站，而将网站所有的内容都索引进去，比如Google就喜欢静态网页，而且是最新更新的，而不喜欢带?的动态网页，Google甚至会定期将缺少入口的网站内容逐渐抛弃；
更新慢：搜索引擎针对站点的更新频率也是有一定周期的，很多内容需要一定时间后才能进入GOOGLE的索引：目前Google Dance的周期是21天左右；
内容不精确：搜索引擎需要通过页面内容提取技术将导航条，页头页尾等内容过滤掉，反而不如直接从后台数据库提取数据来得直接，这种摘要和排重机制是很难实现的；
无法控制输出：也许有更多的输出需求，按时间排序，按价格，按点击量，按类目过滤等
系统的搭建
下载：
http://sourceforge.net/projects/weblucene/
XML数据源的导入：
只要数据源可以导出成3层的XML结构，就都可以用IndexRunner这个命令行工具导入：
比如从数据库导出：news_dump.xml
<?xml version="1.0" encoding="GB2312"?>
<Table>
<Record>
<Title>标题</Title>
<Author>作者</Author>
<Content>内容</Content>
<PubTime>2003-06-29</PubTime>
</Record>
<Record>
<Title>My Title</Title>
<Author>chedong</Author>
<Content>abc</Content>
<PubTime>2003-06-30</PubTime>
</Record>
...
</Table>
IndexRunner -i news_dump.xml -o c:\index -t Title,Content -n Author
-i news_dump.xml: 以news_dump.xml为数据源
-o c:\index 索引库建立在c:\index目录下
索引建立Title Author Content PubTime这几个字段外，按以下规则建立索引：
-t Title,Content 一个进行分词的全文索引TokenIndex：数据是Title Content这2个字段
-n Author 一个不分词的索引：NoTokenIndex：数据源是Author这个字段。
对于RSS数据源：
<?xml version="1.0"?>
<rss version="0.92">
<channel>
<title>Amazon: Books Arts & Photography</title>
<link>http://www.lockergnome.com/</link>
<description>Amazon RSS Feed</description>
<lastBuildDate>Sun, 29 Jun 2003 01:05:01 GMT</lastBuildDate>
<docs>http://www.lockergnome.com/</docs>
<webMaster>amazonfeed@lockergnome.com (Lockergnome RSS Generator)</webMaster>
<item>
<title>The Artist's Way: A Spiritual Path to Higher Creativity - $11.17</title>
<link>http://www.amazon.com/exec/obidos/ASIN/1585421464/lockergnomedigit/?ref=nosim&dev-it=D34HUVGKB34YFX</link>
<description>http://www.lockergnome.com/ </description>
</item>
...
</channel>
IndexRunner -i http://www.example.com/rss.xml -o c:\index -t title,description -n link -l 4
-l 4 表示拿第4层节点作为字段映射，
IndexRunner还提供了-a -m这两个选项：用于增量索引和批量索引优化。
-a 增量索引，表示在原有索引的基础上扩展
-m mergeFactor 在Lucene中mergeFactor是一个针对批量索引的优化参数，控制多少条处理完多少条记录（Document）后，写入一次索引，写入频率越高，内存使用越少，但索引速度越慢，所以在大批量数据导入时需要增大文件写入的间隔，多让索引在内存中操作。
搜索结果输出：
以下是系统设计过程中一些设计的思路：
做为工业标准的XML
记得以前有关于肯德基的炸薯条断顿的报道。从这个事件报道中我们可以看到一种更高效的管理体系：对于快餐店这样全球性的企业来说，要保证各地提供的薯条品质，成本最低的方法肯定是依靠机器而不是厨师，如果要求薯条机能够处理各种形状不一的土豆，机器的复杂程度和维护成本都会很高。所以土豆必须严格符合工业标准才能让结构比较简单的薯条机生产出符合标准的薯条，因此，薯条的加工机械会严格按照土豆协会的土豆工业标准设计。高质量的原料可以大大降低后期加工设备的成本，因此从总体成本上讲还是合算的。
对于软件应用开发者来说：应用和应用之间，企业和企业之间交换的数据好比就是土豆，白菜，按照严格的XML标准设计的接口作为企业之间后台数据交换的工业标准，虽然不如简单的CSV格式高效，但缺能大大简化下游工序的后期加工成本。
不难想象为什么处理HTML的浏览器：IE和Mozilla等浏览器软件大小都在10M以上，但一般处理XML的解析器一般都在几百K。除了没有界面外，HTML浏览器需要为太多不规范的HTML代码提供大量容错处理也是一个很重要的原因，而语法严格，规则简单的XML处理器就可以做的很简短，高效，体积越“小”就意味着适应性越广：这点在手机这样的硬件配置比较低的设备环境中显得尤其重要。
虽然XML在后台数据交换方面，有着巨大的潜力。在前台表现方面，XML并不会马上代替HTML，很多通过XSLT输出的HTML仍然需要结合CSS来进行表现。XML ==XSLT==> HTML + CSS。但是由于太多的网页都是用HTML做的，相信XML没有必要马上代替这些已有的机制。
此外在应用的国际化支持方面XML和Java简直是绝配：XML数据源用Java解析后是UNICODE，这样无论是日文，繁体中文还是德文的内容我们都可以在一个索引库中同时进行搜索。这样针对其他语言的支持只是设计各种语言界面的问题了。
GBK \ / BIG5 BIG5 - UNICODE ====> Unicode - GB2312 SJIS - (XML) &nb
