传统Web站点的数据采集可以看成是对特定转换图的遍历过程,转换图的节点由Web页面构成,导致页面转换的边则由超链接构成。对Ajax站点来说,浏览器客户端与服务器可以仅交换少量必要数据,并动态更改页面内容,因此,转换过程不仅可以在页面之间进行,也可以在Ajax页面内部由Ajax事件触发进行。针对Ajax页面状态的转换,瑞士苏黎世联邦理工学院的Frey^{[ 5]}和Matter^{[ 6]}先后进行了总结归纳,如图1所示:

图1

	Figure Option ViewDownloadNew Window
	图1 Ajax站点页面状态转换图

在图1中,带箭头的粗线表示超链接,方框表示Ajax页面的某一特定状态,引起内部状态转换的Ajax事件信息则由带箭头的细线表示。由超链接导致的页面跳转问题在传统数据采集中已经得到了较好的处理,因此,Ajax站点数据采集的研究重点集中在Ajax页面处理方面,包括:Ajax链接元素的识别、Ajax页面状态的标识、程序可控性转换、内容动态获取和重复检测。

(1)Ajax链接元素的识别

在Ajax站点中,超链接并非导致页面内容变化的唯一元素,理想情况下,应能识别所有的相关元素与关联事件。为方便处理,现有研究仅对给定的候选元素集合(如A、Div、Span)和事件集合(如Click、Doubleclick、Mouseover)进行简单识别,以发现符合要求的元素^{[ 6, 7]}。其中,荷兰Delft理工大学软件工程研究中心的Mesbah等人把导致Ajax页面状态转换的元素定义为可点击元素(Clickable Element)^{[ 7]},瑞士苏黎世联邦理工学院的Matter则把由元素事件导致的状态转移称为Ajax链接^{[ 6]}。事实上,除了点击事件外,鼠标移动、页面加载等事件同样会导致状态变化,因此,把与状态变化有关、附加了特定事件的元素称为Ajax链接元素更为合适。

由于Ajax链接元素与附加在其上的事件密不可分,文献[8]和[9]从Ajax事件探测的角度寻求页面状态的变化,本质上也可归入Ajax链接元素识别问题。

(2)Ajax页面状态的标识

单个Ajax页面可以拥有多个不同状态,这些页面状态取代传统的Web页面,成为Ajax数据采集的基本处理单元。页面状态标识用于实现状态的引用和定位,与之相关的研究又可分为两类:

①对相邻状态之间的转换过程进行描述,间接实现页面状态的标识,如Duda等采用的事件源元素、事件类型、目标元素和事件动作四要素状态转换表示法^{[ 9]},夏冰等采用的事件和事件所在元素的XPath二元组表示法^{[ 10]};

②直接设计特定标识用于表示Ajax页面状态,如Xia采用六元组(页面状态初始URL,状态锚文本,XPath列表,状态对应的DOM树,状态哈希值,处理标志)表示每一个页面状态,其中XPath列表存储了从页面初始状态到当前状态所经历的每一个元素所对应的XPath表达式^{[ 11]},这一表示方式默认只处理元素的点击事件,要支持导致状态改变的其他事件,还需要进一步增加描述信息。

一般而言,状态标识会涉及状态所隶属的Ajax页面初始URL、父状态、进入该状态的事件源、事件等因素。页面状态的标识需要保证状态的可达性、可重现性、可理解性,并尽量简单。

(3)Ajax页面状态的程序可控性转换

Shah指出Ajax驱动的Web2.0站点爬取必须解决DOM事件的自动处理和分发问题^{[ 12]},即当Ajax页面位于某一特定状态时,能够通过程序而非人工方式,转换到新的状态。状态转换依赖于JavaScript脚本在客户端的异步执行,因此,解决脚本的正常执行与解析是实现可控性状态转换的技术前提。

罗兵以基于协议的页面获取方式,抓取Ajax页面包含的JavaScript代码文件,并直接设计实现脚本解释器,模拟浏览器行为对脚本代码进行顺序执行,以实现页面状态的控制转换^{[ 13]},肖卓磊在后来研究中也采用了相同的处理方式^{[ 14]};曾伟辉、李淼基于切片算法构建程序层次模型,解决JavaScript脚本的有序执行问题^{[ 15]}; Frey^{[ 5]}和Matter^{[ 6]}则对开源的JavaScript解释器Rhino^{[ 16]}进行改进,用于实现脚本执行和状态转换。完整重现脚本解释器耗时费力,即使已经维护多年的Rhino项目,依然存在许多脚本代码无法正常执行,因此,更多学者尝试利用嵌入式浏览器组件实现Ajax页面的渲染呈现和脚本执行,达到状态自动转换的目的。

在转换控制方面,较简单的方法是采用事件过滤机制,对过滤后的事件逐一触发。为提高效率, Duda等^{[ 9]}和Xia^{[ 11]}分别提出了支持用户自定义规则,引入接收规则和拒绝规则,使状态转换只能在符合条件的有限集合中进行;Mesbah等使用全自动扫描、HTML元素注解和面向领域的手工配置三种不同方式控制状态转换^{[ 7]};Matter则提出启发式爬行策略,力图避免从不同路径转入相同页面状态^{[ 6]}。

(4)Ajax页面状态的内容动态获取

Ajax页面所呈现的数据依赖于当前的状态,动态获取有效页面状态的内容是Ajax站点数据采集的直接目的。Frey^{[ 5]}和Matter^{[ 6]}对Cobra工具集^{[ 17]}进行扩展,实现了HTML代码的动态加载和解析,进而通过内部形成的DOM结构树获取状态所包含的数据内容。与状态转换问题相似,为充分利用已有技术,主流的状态内容获取方式利用嵌入浏览器作为Ajax运行容器,通过浏览器提供的外部接口与页面DOM树交互,并获取其完整数据内容^{[ 7, 8, 11, 18]}。

(5)Ajax页面状态的重复检测

状态重复检测可以有效减少冗余数据,消除重复状态的二次采集,提高效率。重复检测可以通过对比DOM树的内容和结构的变化实现,Duda等以计算页面状态内容的哈希值是否相同作为简单的判重依据^{[ 9]};基于树编辑距离算法^{[ 19]}的重复检测方式应用更为普遍,如夏冰等把该算法应用于Ajax页面的结构相似性判定,进而归约出引向有效页面的页面元素的XPath特征,在效果上等同于状态的重复检测^{[ 10]},Xia则把节点权重纳入计算过程,以改进树编辑距离算法的应用效果^{[ 20]};另外,编辑距离及其改进算法^{[ 21]}、基于Path Shingles^{[ 22]}的方法等也可用于页面状态的重复检测过程^{[ 11]}。

Ajax站点的数据采集还会涉及并行采集^{[ 6]}、页面状态重要性评估^{[ 5]}、结果表示与聚集^{[ 9]}等许多问题,但它们大都归于性能改进和系统优化方面,本文不再细述。

在处理流程研究方面,罗兵设计的Ajax网络爬虫由网页抓取、网页分析、JS解析、DOM支持和页面生成5部分组成^{[ 13]};Mesbah以伪代码方式给出了Ajax数据采集的流程描述,包括初始化嵌入式浏览器、进入指定状态、获取候选可点击元素、触发事件、获取DOM内容、更新页面状态等步骤^{[ 7]};文献[11]进一步引入了保存状态标识和内容的状态仓库概念,在流程中增加了初始状态注入和状态检测与存储处理;文献[10]则明确给出了事件列表需要循环触发的处理步骤。

图2

	Figure Option ViewDownloadNew Window
	图2 Ajax站点数据采集处理流程

图2所示的Ajax站点数据采集处理流程涵盖了当前研究所提到的主要步骤,在该流程中,状态标识库用于存储Ajax页面的状态标识,状态内容库则用于存储最终获取的Ajax数据,它们的功能分别等同于传统网络爬虫系统中的URL链接库和网页内容库,合为一起则统称为状态仓库^{[ 11]}。

Ajax站点的采集入口通过初始状态注入加入到状态标识库,形成最初的待处理页面状态集合(步骤⓪);对于每一条待处理页面状态,在Ajax运行容器中重现该状态,探测Ajax链接元素和可能导致状态转换的事件列表(步骤①、②);对于每一个事件,通过触发执行转移到新页面状态,并获取其内容,再经重复检测步骤决定新状态是否有效(步骤③-⑥);对于有效的页面新状态则存储其标识到状态标识库,同时存储其内容到状态内容库,页面状态内容也可在第①步重现页面状态的时候更新到状态内容库中,具体方式在不同研究中有不同实现。

上述流程是一个不断循环的过程,终止判断条件已有多种不同策略^{[ 9, 10, 11]}:当前页面状态相对于起始状态的深度大于指定数值时,不再继续处理其子状态;有效页面状态总数量达到指定数值;处理时间达到截止时间点;用户指定的其他终止条件。

页面状态重现、事件触发执行和状态内容动态获取都依赖于对页面HTML代码的渲染呈现和JavaScript脚本的解析执行,这些功能可统一归入Ajax运行容器的作用范围,主流方式是以某个HTML渲染器作为Ajax运行容器,这使得HTML渲染器成为Ajax数据采集必备的支撑技术。然而,现有的HTML渲染器功能各异,分散于互联网上,缺少完整资料和对比介绍,因此,有必要对其作进一步总结整理。整体看来,应用较为广泛的网页渲染器可分为三类:基于Mozilla Gecko浏览器内核的渲染器、基于微软IE(Internet Explorer)浏览器内核的渲染器和开放代码实现的渲染器。

(1)基于Mozilla Gecko内核的HTML渲染器

该类渲染器通过对Mozilla组织开发的Gecko内核进行封装,提供HTML渲染访问API。Gecko内核具有跨平台、标准化、开放性等特点,因而得到了广泛应用^{[ 4, 7]}。较有代表性的项目有WebRenderer^{[ 23]}、Webclient^{[ 24]}、JRex^{[ 25]}。

其中,WebRenderer是由JadeLiquid发布的一款商业程序,提供了对HTML渲染、访问内部DOM树、执行脚本等功能的完整支持,使用较为方便。Webclient由Mozilla组织开发,致力于提供一款具有通用Web浏览功能的浏览器中立的Java应用编程接口,其功能包括HTML内容渲染、导航、进度通知等。JRex则利用JNI技术对Gecko引擎进行封装,并提供Java类库以供应用程序调用。与WebRenderer不同,Webclient和JRex都属于开源项目,用户可以免费使用,但易用性方面略有欠缺。

(2)基于IE内核的HTML渲染器

该类渲染器底层使用微软公司的IE内核,通过代码封装提供HTML渲染服务,其典型代表有JExplorer^{[ 26]}、Watij^{[ 27]}、Watir^{[ 28]}。

JExplorer提供了一组便捷的Java应用程序接口,把IE与Java程序无缝集成到一起,用户无需深入掌握组件对象模型技术,就可以通过代码访问渲染后的网页DOM对象。Watij则是为实现Web应用程序自动测试而提供的一组Java编程接口,底层采用了JExplorer。Watij具有丰富的HTML访问接口,使得它在Ajax数据采集中也得到了广泛应用^{[ 7, 11]}。JExplorer需要付费使用,Watij内核虽然基于JExplorer,但已经过特殊授权,可免费使用。Watir是比Watij更早出现的Web自动测试框架,但其面向的语言为Ruby。

(3)开放代码实现的HTML渲染器

基于Gecko或IE内核的渲染器虽然能够较好地实现页面渲染和脚本执行等功能,但依赖于特定的软件环境,增加新功能或扩展已有功能比较困难,对脚本事件的拦截和调试不便。因此,部分研究人员针对Ajax站点的数据采集问题,采用了开放代码实现的HTML渲染器^{[ 5, 6, 9]}。该类渲染器主要以Java语言设计实现,以充分利用Java语言的跨平台、易复用等优点,典型代表有Cobra^{[ 17]}、HtmlUnit^{[ 29]}、Flying Saucer XHTML Renderer^{[ 30]}。

Cobra是一个纯Java实现的HTML渲染器和DOM解析器,支持HTML4.0,JavaScript以及CSS2等。Cobra中许多功能模块直接使用了已有开源项目,其脚本解析执行基于Rhino^{[ 16]}实现,CSS解析采用了CSS Parser^{[ 31]}。HtmlUnit最初是一个Web应用程序自动测试框架,底层使用了Cobra,但屏蔽了运行时的图形用户接口以提高效率,同时提供了一组丰富的API,便于上层模块调用。Flying Saucer目前仅能对结构良好的XHTML和CSS进行渲染,不支持JavaScript,需要额外增加脚本解析模块才可应用于Ajax数据采集之中。

随着Web标准的不断发展,重新完整实现一个HTML渲染器并非易事,因此,开放代码实现的HTML渲染器还存在不少功能限制,例如,通过Cobra解析腾讯评论页面内容时,仍然无法正常获取Ajax动态内容。具体选择哪种渲染器,可根据Ajax站点的Web标准规范化程度、效率、易用性、可扩展性等因素综合考虑。

在HTML渲染器使用方面,部分文献并没有给出确切版本说明,在此,笔者仅把可以确认并有一定代表性的使用分布情况进行汇总,如表1所示:

表1

表1

表1 HTML渲染器使用情况统计 HTML渲染器类型 代表文献 Mozilla Gecko内核 [4], [7] IE内核 [7], [11] 开放代码实现 [5], [6],[9]

表1 HTML渲染器使用情况统计