从直观上面看，检索器一般在Form标签里面，有几个输入数据的文本框，加上一个提交的按钮。像百度这样形式的检索器，很容易自动识别出来。这样或许你会 认为检索器很容易自动构造，其实不然。现在的网页越来越美观，很少有页面还是使用那种原始的检索样式，不信你看：

 

　　这个检索器几乎是无法自动识别的。至少我暂时没有看到或者想到办法自动识别。虽然有的检索器无法自动识别，但检索器肯定都是可以人工识别的。所以，一定可以设置一个可以配置的检索器。这就是我们蜘蛛设计的第一步：检索器的配置。

 

　　检索器对于外界来说，就是一个不断产生连接请求地址的机器，直到没有可以产生的为止。它产生的地址可以认为由4部分组成：1）请求的url地址；2）请求 的方法；3）请求的参数；4）发送请求的编码。这几部分对于研究过的人来说，应该很容易理解。本处不作过多说明。

 

　　2.2 页面获取

 

　　我们首先用检索器得到一个请求的地址，接着就是发送这个请求地址，得到对应的页面信息。为了得到页面信息，我们需要一个强壮的http文件（页面）下载器。为什么这么说呢？第一，很多网站都是需要登陆才能够访问到机密信息 的， 故你的下载器必须支持cookie；第二，网页编码识别是一个难题，下载器需要认真的处理这个方面的问题；第三，http的其它各种标准也需要支持，比 如，页面跳转的支持；第四，其他特别的需求，比如，对于下载数据格式的限定（如只下载文本文件）。基于这4个方面和其他某些方面的考虑，我们建立了蜘蛛的 第一个项目：HttpDownloader。

 

　　HttpDownloader 项目介绍：

 

　　这个项目重点解决了网页编码的识别问题（这个问题是没有完美解决方案的，我们只能够从Unicode标准中定义的utf标准的说明里面找到一些额外的办 法。当然了，刚好有些开源的代码能够支持直接分析二进制数据对应的文本属于哪国文字，这个也是一个不错的补充。）其它问题大部分都是靠开源库搞定，少部分 自己写代码搞定，都没有什么得意的地方值得谈论。另外，在进行大量测试之后，发现实际情况中有各种各样的问题，比如，请求url编码就是其中的一个问题。 默认情况下，url编码应该使用utf-8，可是，国内的网站很多都是要求gb2312编码的，或者说utf-16编码。如果贸然认为都是utf-8的 话，就会遇到连baidu的页面都无法正确获得的问题。这个只是冰山一角，还有好几个这类型的问题，都是和中国国情不兼容。顺便说一句，这个项目主要以HttpClient 作为底层。

 

　　2.3 页面解析

 

　　虽然我个人曾经用C#写过html代码dom树解析的程序，但我们还是使用了开源的东西来做页面解析。HtmlParser和NekoHtml显然是做页 面解析的2个最有名最好的开源库。不过，它们都有不少的缺点（不兼容），当你遇到后，你需要修改它们的代码，让他们能够正确的运作。这里举个例子说明一 下：

 

　　基本的HtmlParser（最新版本的，2006年9月）无法解析下面的代码：

 

　　“<strong>very!</strong>”

 

　　因为它居然没有识别strong标签！

 

　　如果比较一下NekoHtml，你或许会感觉到NekoHtml才像专业人士写的代码，而HtmlParser有点业余。其实呢？？。。。

 

　　NekoHtml并不是很好很好。我们知道Balance是NekoHtml最得意的地方，因为其他的解析都是扩展的别人的代码。但是，作者身处在一个有 序的环境之中，并不需要考虑过多的容错性问题，这直接导致了Balance做的很一般（对于中国国情来说）。举个简单例子：

 

　　<table>

 

　　test

 

　　</table>

 

　　IE和FF会解释为：test<table></table>，而NekoHtml则解释为<table>test</table>

 

　　虽然我自己也感觉HtmlParser过于业余，但是，它做的是一个比较有扩展性的框架，这点比NekoHtml强。另外，它对加密Script也进行了相关处理。

 

　　综合起来看，如果你只是需要进行html解析，你就该使用HtmlParser；如果你需要对js进行处理，你就需要使用NekoHtml，不然，你会遇到很多没有html也没有body标签的网页。

 

　　为了解决NekoHtml和HtmlParser的一些问题和提高容错度，我们建立了2个新的项目：NekoHtml2007  和HtmlParser2007  ，它们专门用来解决这2个开源项目的Bug（虽然我很希望那些库的作者能够出来解决这些Bug）。

 

　　2.4 页面JS解析

 

　　至于为什么要处理js，你可以简单的访问

 

　　， 然后看看源文件。明白了吧？现在很多网站的页面都是使用js构建出来的，更不用说那些使用web2.0(AJAX)技术的网站了。一个强壮的有竞争力的商 业垂直搜索引擎，不支持这种东西是不行的。最基本的支持JS的方法是使用IE或者FF（FireFox）使用的借口，调用它们解析页面，不过，这种方法的 浏览速度超慢，不可能成为一个搜索引擎的选择。所以，必须自己想办法做一个支持的库出来（忽略图像渲染部分，能够加快构建速度和处理时间）。

 

　　说支持JS容易，可是，到底该怎么支持呢？好在我多年前关注js的时候，已经关注过一个叫SpiderMonkey的东西了。它的Java版本叫 Rhino。现在Rhino已经整合到JDK1.6里面了，所以，各位不用再去下载它了。Rhino它是一个js脚本的解释运行库。但它并不支持dom树 （因为js实际上和html已经没有任何关系了，js更多的时候用在脚本处理里面，这点和VBScript有点像）。为了让它支持dom树，需要我们自己 进行扩展。研究一番Rhino，再研究一番其他使用了Rhino的开源项目（特别推荐你看看HtmlUnit 项 目的源代码，最新的htmlunit1.13已经可以比较好的支持js的解析了，如果你只是做点基本的小应用，可以用它来做js方面的问题），你就应该能 够找到思路了。剩下的就是艰苦的编程了，很无趣的工作，因为你需要满足IE的规范，也要满足FF（dom1-dom3）的规范。

 

　　做好js的解析之后，你还可以考虑css的解析，css的解析目前没有发现特别好的开源工具。一切完备之后，就是把它们组合起来，构建一个模拟IE和FF 的浏览器了（没有图形界面，所以，速度飞快）。浏览器支持的额外功能可能要根据自己的需要来定了。

 

　　为了解决js的问题，我们建立了一个Browser  的 项目。Browser项目模拟了IE的工作方式，主要是2个方面的处理：1）Cookie的处理；2）js的处理。cookie的处理大部分由底层处理， js的处理包含了js的解析、js的运行、dom初始事件的处理等。Browser除了js的基本支持以外，它显然最需要支持的是url地址。我们知道， 很多网页的超链接都使用：javascript:...的形式，这个地址是搜索引擎需要的。所以，Browser必须支持运行js脚本，并且返回一个链接 地址回来。