CN101719124A - 基于正则匹配的无限层次多路径采集系统 - Google Patents

Abstract

本发明公开的基于正则匹配的无限层次多路径采集系统在网站信息采集中，在网站信息采集中，通过页面层与页面标签两种数据结构以及链接标签与层的引出关系、层与标签之间的包含关系、标签与标签从属等关系规划出可无限拓展的多采集路径；基于上述提出的数据结构，通过基于正则表达式的定位提取算法实现对标签内容的精确提取以及对多模板网站的采集支持；通过采集任务格式、任务工作队列以及与之配套的采集处理过程，在采集过程中实时组装采集任务入列，实现多线程无差别对待各层次任务的高效采集；针对采集结果，使用分组存储方法保证任务结果的统一性。

Description

基于正则匹配的无限层次多路径采集系统

技术领域

本发明属于互联网网站采集引擎技术领域，主要涉及的是基于正则匹配的无限层次多路径采集系统。

背景技术

现有的所有互联网的网站均是通过页面上的连接，可以从一个页面跳到另一个页面，通过这些连接，通常可以遍历整个网站(除了网站后台)。如果把网站的首页看成是一个入口的话，那么几乎所有的网站都是一个以首页为根结点的树形结构(如图1所示)，其就是通常所说的网站地图。树的层次数目因网站的不同而不一样，比如通常的新闻发布系统的具有两层结构，第一层是新闻的列表，从新闻列表的某一条进去后，是第二层——新闻阅读。通常来说，网站的树的层次不是越多越好的，往往不会超过4层。网站地图通常是多路径的，从一个页面可以连接到多种类型的页面上去，该特点对网站信息的自动采集造成了一定的困难。此外，网站之间一般具有友情连接，可以从一个站跳转到另一个站上，使得跨站采集成为可能。

目前公知的采集引擎，功能虽然强大，但是具有一些明显的缺陷，不能满足客户多样化的需求，并且在使用上比较复杂，具有很多局限性。当前流行的采集引擎一般具有以下的局限性。

1)层次限制

现有采集引擎一般是针对特定的常用的网站结构开发的，如“动易”系统，就是一个专门针对两层的网络结构的采集系统；著名的“火车头采集系统”可以支持到三层的网站结构。网络结构的限制，也导致了当前一般采集引擎不能跨站采集。一个采集规则只能采集一个网站。

2)采集路径限制

除层次限制外，现行的采集引擎具有单一路径的缺陷，单任务的情况下，他们只能从固定的一条路径进行采集。为了实现多路径，需要添加多个采集任务。多个采集任务必然会造成资源的浪费，如一个页面可能会重复下载多次，并分析多次。

3)模板限制

现有的采集引擎，一般没有采用正则匹配的方式对网页内容进行截取，使得其不能对多个模板的网站进行采集。

4)规则共享限制

规则的编写对大多数用户来说是一件麻烦的工作，现有的流行的采集引擎需要用户自己编写规则，用户之间很难利用对方编写的规则，因此对用户的使用造成了一定的限制。

发明内容

本发明的目的即由此产生，提出一种基于正则匹配的无限层次多路径采集系统。使得客户端采集工作不受任何复杂网站架构限制，摆脱以往采集引擎的层次限制、采集路径限制、模板限制和规则共享限制的弊端，不仅采集效率高，而且使得信息存储更加方便灵活人性化，具有无限层次、可跨站采集、支持多路径、采用正则匹配支持针对多模板网站的采集、无限分组存储、规则共享(下载、上传、以及导入规则)特点。

本发明实现目的采取的技术方案是：在网站信息采集中，在网站信息采集中，通过页面层与页面标签两种数据结构以及链接标签与层的引出关系、层与标签之间的包含关系、标签与标签从属等关系规划出可无限拓展的多采集路径；基于上述提出的数据结构，通过基于正则表达式的定位提取算法实现对标签内容的精确提取以及对多模板网站的采集支持；通过采集任务格式、任务工作队列以及与之配套的采集处理过程，在采集过程中实时组装采集任务入列，实现多线程无差别对待各层次任务的高效采集；针对采集结果，使用分组存储方法保证任务结果的统一性。

本系统根据网站地图的结构形式，提出了一种与网站地图结构一致的采集规则组织形式以及与规则组织形式相一致的过度性存储结构，在此基础上利用该规则结构进行信息采集并且把采集到的信息组织起来，使信息之间的关系与其在网站上的关系具有一致性，即不但采集了信息的本身，也采集了信息之间的关系。由于规则的结构与目标网站的结构相适应，使得采集的层次和路径可以与目标网站一致，突破了过去由于规则库的结构带来的层次和路径的限制，只要存在连接路径就能写出相应的规则。同时为了实现与多种用户信息存储结构之间的转换，提出了无限分组存储的方法，并提供了切实可行的处理步骤。最后，提出了系统的自我保护方案，防止系统受到破坏。提出的采集算法使得客户端采集工作可以不受任何复杂网站架构限制，摆脱以往采集引擎的层次限制，采集效率高。分组概念的提出使得信息存储更加方便灵活人性化。本发明的使用者大都为网站站长。

附图说明

图1为现有网站地图示意图。

图2为本发明的系统结构示意图。

图3为本发明规则服务器功能模块示意图。

图4为本发明客户端与转发服务器之间的通讯模式示意图。

图5为本发明分布式资源共享模式示意图。

图6为本发明集中式资源共享模式示意图。

图7为本发明客户端结构示意图。

图8为本发明规则库树形结构示意图。

图9为本发明规则库数据库关系示意图。

具体实施方式

结合附图，给出本发明的实施例如下，但本发明不局限该实施例。

本实施例采集系统架构采用C/S结构的模式，分为规则库服务端和采集客户端，他们之间的关系如图2所示。

规则库服务端包含两部分：规则数据库、转发服务器。规则数据库中保存着用户编写或由他人编写而用户使用着的规则，而用户使用规则的时候需通过转发服务器获得。转发服务器给用户提供规则查询、下载和用户登录验证等功能，其中规则下载只是把规则下载到客户的内存中。

采集客户端：根据规则完成网页信息的提取、分析、存储等功能。采集客户端需要从转发服务器中获得规则。用户编写的采集规则也通过采集客户端发送到转发服务器上并存在用户规则库中。

规则共享：指不同的用户所编辑的规则可以互相使用，具体的形式是，规则共享者提供自己编写的规则，其他用户可以把他人编写的规则添加到自己的数据库中。

系统规则库与用户规则库：规则库是规则共享得基础。系统规则库包含所有的规则信息，用户规则库是系统规则库的一个子集，因此内容相同的规则可能被包含在不同的用户规则库中而成为不同的规则。如采集新浪新闻频道的规则可能会在多个用户的规则库中，这些规则都有很多相似的地方，但不完全相等，用户把他人的规则添加到自己的规则库中后可能会作相应的调整以适应该用户自身的要求。

规则共享的模式：为在线共享、离线共享两种模式。

在线共享：用户通过转发服务器获得规则数据库中规则信息，并把需要的规则添加到自己的规则库中。

离线共享：该方式使用与用户之间私下的规则交流，通过采集客户端，用户可把自己使用的规则导出到规则文件中，该规则文件并没有包含规则的全部信息，只包含规则的标识和规则的描述信息。该规则文件可以在用户之间自由传递，并可以通过采集客户端导入到用户自身的规则库中去。

通过文件导入规则

采集客户端首先读入规则文件，读取该文件中规则的标识，然后向服务器发送规则下载请求，由转发服务器把该规则添加到用户自身的规则库中。

1.规则库服务端设计

规则服务器端包含三大功能模块，用户登录验证模块、规则查询模块、规则下载模块，如图3所示。

在客户端运行的过程中，需要时刻保持与转发服务器的通讯，通讯流程如图4所示。

1)用户登录及其处理

用户在使用本采集引擎进行信息采集前需要首先登录到系统中，并从转发服务器中获得采集规则，这是登录验证需要完成的处理。

2)登录请求及其处理

登录请求，是采集客户端发送用户名和密码以及本地程序的信息(防止原程序被破解)和本地计算机的信息(如网卡的MAC地址)到转发服务器，转发服务器验证用户的信息，并同时验证用户所使用的程序的版本，同时返回用户的规则信息，并把用户与用户使用的计算机的基本信息加入到一个在线用户列表中。在线用户列表是限制用户登录数的一个方法，不同的用户可以具有不同的登录数。

多登录数用户的优势：对于只有一个登录数的用户，他只能在一台机器上运行一个采集客户端，对其采集信息的速度造成一定的限制。从采集速度上看，一个登录数的用户必然比不上多个登录数的用户。多登录数的用户，相当于具有多个采集客户端，不同的采集客户端可以选择采集不同的目标网站，可以实现多个采集系统并行工作。

3)验证请求及其处理

验证请求是本系统的常规验证方式，在客户端运行的过程中，每隔一段时间就需要发送一个验证请求。验证请求是维护用户在线状态的方法。验证请求需要发送的信息有：用户名、密码、客户端程序信息、客户端机器信息。

在线用户列表：

该表记录当前登录到转发服务器的用户信息。通过在线用户列表可对用户的登录数进行限制。

在线用户列表的维护：

在线用户列表包含以下信息：用户名、客户端程序信息、客户端机器信息、本次在线时间(以分钟为单位)、本次剩余生命值。其中“本次剩余生命值”是一个整数，转发服务器每分钟对所有用户的生命值减1，而验证请求则把特定的用户的生命值恢复为一个常量，当用户的生命值变为0时，转发服务器把该用户从在线列表中删除。

4)规则查询请求及其处理

规则查询是实现规则共享的关键之一，通过发送规则的描述性信息(如规则名称、采集的目标站点、规则备注等信息)到转发服务器，转发服务器根据这些信息进行查询，并返回包含相关信息的结果。

5)规则下载请求及其处理

规则下载请求，需要客户端发送规则的标识信息到转发服务器，由转发服务器把相应的规则添加到用户的规则库中。

6)多转发服务端的协同工作

为了适应可能存在的庞大的用户数，需要一种高效的转发服务端组织形式，转发服务端可能是一个也可以是多个，为了使处理效率尽可能高，通常需要多个转发服务器协同工作。

多转发服务器协同工作涉及资源共享问题，在本系统中，转发服务端的共享资源有：客户的请求、在线用户列表。

7)资源共享模式

分布式资源共享。多个转发服务器作为独立的处理单元，各自维护自身的共享资源，在资源的添加、访问和删除的过程中需要与周围的转发服务器进行协商。如在线用户列表，每个转发服务器保持条目在整个转发服务端无重复。

在本系统的分布式资源共享中，可使用专门的协调服务器对用户的请求进行重定向取代服务器之间的协商，如图5所示。

首先客户端向协调服务器发送连接请求，协调服务器接收到该请求后，向所有转发服务器查询该用户是否可以登录，若可以则查询各个转发服务器的负荷情况(当前连接数、当前数据流量等)，得到负荷最小的一个转发服务器，并给客户端返回该转发服务器的连接方式，客户端接收到该响应后，使用该连接方式与目标转发服务器建立连接。在连接建立后，该连接将会一直维持到该客户端下线。

集中式资源共享。把所有的共享资源集中到一个Leader服务器上。由该服务器对资源进行分配。Leader服务器把任务分发到其他工作服务器上，由工作服务器返回处理的结果，这样Leader服务器是工作服务器和客户端交互的桥梁，Leader将维护所有的连接和数据传输。如图6所示。

上述两种资源共享模式中，集中式资源共享便于实现，而且可以统一对客户端的接口，可极大方便客户端和服务器的通讯。该方式不足之处在于通讯压力集中到Leader服务器上，通讯的限制可能会使系统的可扩展性受到限制。而分布式资源共享可以突破系统扩展性的限制，但通讯过程比集中式资源共享稍微复杂，并且可能存在短时间的局部的系统繁忙。本系统转发服务器将使用分布式资源共享模式。

2.采集客户端设计

采集引擎主要包含三大功能模块：采集分析模块、存储模块、规则编辑模块。采集分析模块完成对网页信息的提取和分析；而存储模块则把提取和分析的结构保存到各种各样的数据结构中；规则编辑模块提供规则编写功能。本系统采集客户端还包括验证模块。如图7所示

1)采集分析模块设计与原理

采集规则定义

在流行的采集引擎中，采集规则并没有形成统一的标准，每个采集引擎都有自己特有的规则结构。在本系统中我们对本系统的规则进行一个定义。所谓采集规则是指，可以指导采集引擎对网页数据进行抽取、分析、处理(不包括存储)的并组成一定结构的数据。一般采集引擎的规则包含处理结果的存储。在本系统中将把采集和存储这两个概念进行区分。把以往采集引擎中采集规则的共同处剥离出来，便于规则的共享。

规则库设计

传统采集引擎的限制主要来源于其采集规则结构的限制，采集规则支持到什么程度，采集引擎就只能做到什么程度。为了突破层次以及路径的限制，本采集引擎的规则结构采用了与网站的结构一致的树形结构。

规则中包含两种最基本的元素：层和标签。

●层，在网站的树形地图中，处在同一个层次并且类型相同的页面组成一个层，在采集规则中，我们把针对于某个层的采集规则也称为规则的一个层。

●标签，是采集分析的基本单元，指出在网页的什么位置，提取什么东西，进行怎样的后续处理。在规则的结构中，它属于一个层的组成成员。

标签的分类及不同类型的作用

标签可以分为两种类型，链接类型标签和一般内容标签。链接类型标签告诉采集引擎所提取到的内容是一个URL；而一般内容标签告诉采集引擎提取到的内容为一般的字符串。

链接标签引出子层：

连接标签可以引出一个子层，这就是告诉采集引擎从这个标签的提取结果会链接到什么类型的网页上，链接到的网页用什么层的规则进行处理。

从上面的结构可以看出，层中可以包含标签，而标签可以引出层，这跟网站上网页上包含链接，而链接可以链到特定网页的结构是一致的。这是实现无限层次多路径信息采集的关键，该规则库的结构可以引导采集引擎进行层层深入的信息采集和分析。如图7是一个典型的规则库的树形结构，具有两条采集路径。

标签之间的从属关系

标签之间可以存在从属关系，若标签A的分析目标是标签B的分析结果，即对在标签B的结果的基础上利用标签A进行内容的提取和分析，那么标签B就是标签A的父标签，而标签A是标签B的子标签。一个标签只能有一个父标签，而可以有多个子标签。

规则库包含的内容如图8所示。

Rules表，该表记录规则的基本信息

列名	类型	是否可以为空	备注
				RuleID	Int	否	规则的标识
Author	Varchar(20)	否	规则的作者
				SetUpDate	Datatime	否	规则的建立时间
RuleName	Varchar(20)	否	规则的名称
				SiteName	Varchar(100)	否	规则采集的目标网站名称
SiteUrl	Varchar(100)	是	目标网站的URL
				EnCode	Varchar(20)	否	下载页面的编码

Laser表，该表记录了层的基本信息

列名	类型	是否可以为空	备注
				LaserID	Int	否	层的标识
RuleID	Int	否	该层所属的规则
				LaserName	Varchar(20)	否	层名称
PageItemID	Int	是	层中用于翻页的标签的标识
				FatherItemID	Int	是	层的父标签的标识
ContentItemID	Int	是	层中作为文章内容的标签的标识

Item表，该表记录了标签的信息

列名	类型	是否可以为空	备注
				ItemID	Int	否	标签的标识
LaserID	Int	否	标签所属层的标识
				ItemName	Int	否	标签的名称
StartCode	Varchar(200)	是	截取的开始代码(正则表达式)
				StartOffset	Varchar(10)	是	开始代码的相对位移，格式为”m，n”，m表示行位移，n表示在开始代码后m行的第n个字符
EndCode	Varchar(200)	是	用于截取的结束代码(正则表达式)
				EndOffset	Varchar(10)	是	格式与StartOffset一样，是相对于结束代码的往前的位移
ReMatch	Varchar(100)	是	用于结果再提取的正则表达式
				Inc	Varchar(100)	是	指出提取的结果必须包含的内容，该项为正则表达式
Ex	Varchar(100)	是	指出提取的结果不能包含的内容，该项为正则表达式
				IsLink	Bool	否	指出该标签提取的结果是否为连接
FatherItemID	Int	是	该标签的父标签
				IsMerge	Bool	否	指出该标签最后处理的结果如果为多项时是否合并为一项

Page表，该表记录了层的入口页信息

列名	类型	是否可以为空	备注
				LaserID	Int	否	层的标识
EnterString	Varchar(200)	否	入口url的字符串形式，格式可以为正常的URL，也可以在其中包含变量块

说明：EnterString是一个可以包含变量区块的字符串，变量区块是由“<>”括起来并包含“<>”的字符串，其格式如下所示。

<起始值，终止值，增量，是否填充位数>

其中，起始值、终止值为非负整数，增量为正整数，填充位数是指按照起始值和终止值的最大位数为标准，如果起始值或终止值位数达不到该位数则在他们前面填充“0”。

Treatment表，该表记录了标签在提取操作后进行的后续数据处理，处理的方式由替换和插入两种。

列名	类型	是否可以为空	备注
				ItemID	Int	否	所属标签的标识
OIdString	Varchar(200)	是	替换操作时作为要替换的字符串，用正则表达式表示
				NewString	Varchar(200)	是	替换操作时作为新的字符串，插入操作时作为待插入的字符串。
InsertPos	Int	是	插入的位置，若该项非负，则表示从前往后计算位置；若该项为负，则从后往前计算位置，如-1插入到最后，-2插入到倒数第一个字符的前面，以此类推。
				IsReplace	Bool	否	指出该操作是否为替换操作，否则为插入操作。

2)采集过程原理

规则库可以引导采集引擎进行采集，下面就讲述一下如何利用上述规则库进行引导。

任务的划分与任务的无差别性、任务与结果的统一性

为了实现引导，必须对一个任务进行划分，把一个大的、复杂的任务划分为简单的、处理过程相同(无差别性)的任务。为了实现这个目标，我们把采集过程中一个页面的信息的提取和分析作为一个任务。单个页面的处理过程都是相似的，因此满足无差别性的要求。此外为了使得采集分析进程的可持续性，提取、分析和处理的结果可以作为一个新的任务，这就要求结果可以是任务，任务可以是结果，因此任务与结果具有统一性。这样就要求任务与结果必须具有相同的数据结构，这样的数据结构必须包含以下内容。

●目标页面，或普通结果；

●用于分析该页面的层，如果本单位不是任务则该项无效；

●任务结果集中的元素具有与本单元相同的结构，如果本单位不是任务则结果集为空。

从上面描述的数据结构中可以看出，采集得到的结果最终形成了一棵结果树。

处理过程的总体步骤：

(1)从入口层中获得入口地址列表，并与入口层一起组装成一个任务列表，把该任务列表存入任务队列中；

(2)从任务队列中取出一个任务Ass，根据目标页面URL下载页面，若队列为空则结束；

(3)根据任务的层中的标签分析所下载的页面，并把分析的结果分标签存储到Ass的结果集中；

(4)对Ass的层中的所有标签，若标签具有引出层，则把该标签的引出层添加到其结果集的每一个结果中，并把该标签的所有结果添加到任务列表中；

(5)重复第(2)步。

任务的无差别性为实现多线程并行的采集提供了极大的方便，每个任务线程无需知道自身分析的页面跟上下层之间的关系，只需按照所用的层的标签进行数据的提取和分析。

任务与结果的统一性，方便了任务的延续，使得采集引擎可以轻易地根据规则层层深入地采集目标网站的信息。

在本系统中，利用上述特点，很方便地利用多线程并发技术，实现了并发采集，大大提高了采集数据的速度。

以上对总的处理过程进行了介绍，下面介绍分析处理过程中细小的动作的原理。

提取：提取是指使用一定的方法从目标的字符串中提取到符合某种要求的子串。本系统中有两种提取方式，一种是使用开始代码和结束代码定位要提取的字符串；另一种方式是通过正则表达式进行匹配型提取。我们把第一种称为定位提取，第二种成为正则提取。

定位提取算法：

假设目标字符串变量为strs，开始代码变量为Scode，结束代码变量为Ecode，结果集R为存放结果字符串的集合。

(1)通过正则匹配的方式，得到Scode在strs中出现后的第一个字符的位置的集合为S＝{s1，s2，…，sk}，得到Ecode在strs中出现的第一个字符的位置的集合为E＝{e1，e2，…，em}，令i＝1，j＝1；

(2)如果si＞ej，则j＝j+1，若j＜＝m，重复第(2)步，否则结束；

(3)如果si＜＝ej，则i＝i+1，若i＜＝k，重复第(3)步，否则进入第(4)步；

(4)i＝i-1，如果i＞＝1，且i＜＝k，且si＜＝ej，则从strs截取字符串，该字符串的开始位置为si，结束位置为ej，并把得到的字串加入到结果集R中；

(5)j＝j+1，i＝i+1如果j＜＝m且i＜＝k，则返回第(2)步，否则结束。

算法特点：该算法不要求开始代码和结束代码在文档中具有很强的唯一性。假设被提取的源字符串为：

<a>…<a><c><b>…<b>

开始代码为“<a>”，结束代码为“<b>”，则提取到的内容为“<c>”。这可以大大方便规则的编写者，可让他们不必投放太多的精力寻找文档中唯一性的代码，降低规则编写的难度。

正则提取是简单地利用现有系统正则表达式方面的功能函数实现的，这里不作介绍。

使用标签进行提取分析的步骤

本系统使用标签进行提取分析的具体步骤如下：

(1)根据StartCode、StartOffset构造用于提取的开始代码，设为SC；根据EndCode、EndOffset构造用于提取的结束代码，设为EC；

(2)使用SC和EC进行定位提取，得到初步结果集R，R中元素为普通字符串；

(3)若ReMatch项不为空，则对结果集R中所有的元素进行正则匹配，使用的正则表达式为ReMatch，得到新的结果集R2，清空结果集R，并把R2中的元素添加到R中；

(4)若Inc不为空，则对结果集R中的所有元素进行筛选，保留含有Inc这种格式字符串的元素，其他元素从结果集中排除；

(5)若Ex项不为空，则对结果集R中的元素进行排除，把包含Ex的元素从结果集中排除；

(6)对于标签的所有Treatment项，对结果集R中的元素进行插入或替换操作；

(7)若IsMerge项为true，则对R中的元素进行合并，若R不为空集，则最终合并为一项，清除R中元素，并把这一个字符串保存在R中；

(8)若IsLink项为true，对R中的每个元素进行绝对地址转换，并把转换后的内容替换R中原来的元素；

(9)对R中元素进行结果组装，组装成需要的数据形式，并存放在所在任务的标签结果集中(分标签存放)，若该标签引出子层，则把该标签的结果加入到任务队列中。

从上述步骤中可以看出系统运行时的详细过程，而标签之间存在着从属关系，对于没有父标签的标签我们称其为起始标签，下面介绍这种从属关系作用的方式。

标签的递归处理步骤

对于任务的层，找到所有起始标签，存放在集合I中，其中处理的素材为strs，对I中的每个元素进行如下处理：

(1)对素材strs执行标签分析提取步骤，得到结果集R；

(2)对R中的每个元素，令其为素材strs，对该标签的子标签执行第(1)步操作。

显然这是一个深度优先遍历标签树的过程，子标签对父标签的结果进行再次的提取和分析。

3)存储模块原理与设计

所提取和分析的结果需要保存下来，信息的保存必须满足两个要求：

●数据正确性，如实反映结果；

●数据关系完整性，保证数据之间的关系。

上述两条中数据的关系完整性，指的是得到的结果必须与网站上的信息的关系是一致的，也就是说我们不仅仅采集了信息本身，也采集了信息的关系。在上一节关于任务与结果的统一性的描述中提到任务与结果之间的关系，一个任务中会存放其结果，而其结果也可能是一个任务，被处理后也具有结果。下面我们将详细描述这种数据结构，这里我们称它们为过渡性存储结构。

过渡性存储结构

为此我们定义了两种结构

class Assignment

{

     public string strResult＝″″；//可以是Url

     public Laser laser；//所用来处理的层

     public ArrayListalItemRes＝new ArrayList()；//本任务的提取结果，类型为ItemResult

        ……}

该结构可以用来作结果也可以用来作为任务进行处理，该结构指出了用什么层处理的，处理的结果保存在alItemRes中，而线性表“alItemRes”是由如下结构的数据组成的：

class ItemResult

{

       public Item item；//所用的标签

       public ArrayList alAssigment＝new ArrayList()；//由本item提取到的结果，类型为

Assignment，若本item由子层或者本item是分页item，则可以作为任务

        ......

}

该结构指出了某个标签的处理结果都有什么，线性表“alAssigment”是结果的列表，上述就是结果存储的组织关系，具有与网站的结构保持一致的特点，结果树中具有两种类型的节点，一种是“Assignment”类型(若为任务，可看成是一个页面)，另外一种是“ItemResult”类型(可以看成是页面上的内容)，他们可以互相包含。而“Assignment”类型的节点可能是一个任务(也可以是普通的结果)，如果是任务则会被任务处理线程进行处理，并把处理结果存放到该节点中。

由于结果的存储保证了关系的完整性，这使得上述的结果树可以向其他的存储类型进行转换，如数据库和生成静态页或者文本等。上述结构是一个存储的过渡性结构。

存储结构转换

每个用户可能都有不同的数据库结构，不同的信息发布方式，过渡性结构是一个中间结构，因其保存了信息的关系，所以可向任何结构转换。

现行的存储结构一般是数据表，关系数据库就是采用数据表的方式进行组织很存储的，数据表可以很方便地向其他存储结构转换，下面介绍如何实现存储结构转换。

组，与用户数据库表结构对应的数据结构，它指出什么标签的提取结果放在一张数据表中。不同层的标签可以组成一个组，但同一层中的标签只有结果数相等的才能组成一个组(关系完整性的要求)。组可以很方便地转换为现有的存储方式，如生成静态页等。组具有以下的内容：列名、标签、存储类型、最大长度。其中存储类型可以是数字、字符串、图片等，而最大长度只有存储类型为字符串时才会有效。

分组存储的具体过程就是从过渡性结构中把同一组的标签的结果存到一个表中，有些信息会被重复多遍，就像数据库中的外键一样。

分组存储后就是一个数据库表的形式，有很多的方法可以存储到现有的流行的结构中，而且方法都很简单，这里不作描述。

无限分组的思想

无限分组具体是指标签与组之间的关系，一个标签可以属于一个或多个组，一个组可以包含一个或多个标签。这样采集引擎的采集结果存储将最大限度地摆脱限制，可在多种模式之间转换，适应最广大用户的需求。

分组存储方法

过渡性存储结构最终是一个树形结构，按照深度优先的方法对结果树进行遍历，可以遍历树的所有信息，在遍历过程中可以把结果存储到组中。

路径，在深度优先遍历结果树的过程中，记录从树的根节点到当前节点的所有节点的信息的数据结构就是路径。路径是包含了数据关系的数据结构。路径信息可以使用线性表进行存储，而路径中的每个单元可以是任意形式的数据结构。

转换步骤：

设G＝{g1，g2，…，gn}为分组的集合；设T＝{t1，t2，…，tn}是与G对应的表结构；设路径为R，rs为结果树中的节点，root为树的根节点，则

(1)rs＝root；

(2)对G中所有的元素，检查路径R上的信息与节点rs的信息，是否存满足存储的分组，若存在，则把路径R上的信息与rs相应标签上的信息进行组合(路径R的信息可能会被多次使用)，存放到对应的数据表中。

(3)令i＝1；

(4)对rs的分标签存储的结果集，提取这些结果集的第i个结果，由这些结果组成路径上的一个节点r存入路径R中；分别对rs的结果，若其具有子节点，则令rs等于其结果节点，重复第(2)步；

(5)从路径R中去除节点r，令i＝i+1，若i大于rs中最大的分标签结果集的长度，则结束该过程，否则重复第(4)步。

上述过程是一个递归过程，路径R相当于一个栈区，第(4)步新的路径节点入栈，并往树的深层节点递归，而第(5)步则是出栈。

4)规则编辑模块设计

规则编辑模块采用树形控件，使得在编辑的过程中，规则的层、标签等的逻辑关系可视化。

标签可以复制，从层中删除，可以把标签粘贴到层中，如果是连接类型的标签，则可以添加“子层”。同样第，层也可以拷贝、删除、粘贴到某个位置。这里不作详细描述。

5)验证模块

验证模块是客户端的自我保护模块，采用守护进程的方式对程序的合法性进行监视。验证模块实现以下功能。

收集计算机基本信息，如网卡MAC，使用一个加密算法对程序文件进行加密得到多个字符串信息作为程序的基本信息；

定时向服务器发送加密的验证信息，这些信息包括：客户端用户名、密码、计算机基本信息、程序信息串；若服务器返回验证失败信息，则把采集和存储进程关闭。

采集和存储进程在每台计算机上只能有一个在运行，在运行的过程中需要检查验证进程是否还在运行，如果验证进程结束，则自身进程自动结束。

Claims (4)

1.一种基于正则匹配的无限层次多路径采集系统，其特征在于：在网站信息采集中，在网站信息采集中，通过页面层与页面标签两种数据结构以及链接标签与层的引出关系、层与标签之间的包含关系、标签与标签从属等关系规划出可无限拓展的多采集路径；基于上述提出的数据结构，通过基于正则表达式的定位提取算法实现对标签内容的精确提取以及对多模板网站的采集支持；通过采集任务格式、任务工作队列以及与之配套的采集处理过程，在采集过程中实时组装采集任务入列，实现多线程无差别对待各层次任务的高效采集；针对采集结果，使用分组存储方法保证任务结果的统一性。

2.根据权利要求1所述的基于正则匹配的无限层次多路径采集系统，其特征在于：所述的定位提取算法如下，

(1)通过正则匹配的方式，得到Scode在strs中出现后的第一个字符的位置的集合为S＝{s₁，s₂，…，s_k}，得到Ecode在strs中出现的第一个字符的位置的集合为E＝{e₁，e₂，…，e_m}，令i＝1，j＝1；

(2)如果s_i＞e_j，则j＝j+1，若j＜＝m，重复第(2)步，否则结束；

(3)如果s_i＜＝e_j，则i＝i+1，若i＜＝k，重复第(3)步，否则进入第(4)步；

(4)i＝i-1，如果i＞＝1，且i＜＝k，且s_i＜＝e_j，则从strs截取字符串，该字符串的开始位置为s_i，结束位置为e_j，并把得到的字串加入到结果集R中；

(5)j＝j+1，i＝i+1如果j＜＝m且i＜＝k，则返回第(2)步，否则结束；

假设目标字符串变量为strs，开始代码变量为Scode，结束代码变量为Ecode，结果集R为存放结果字符串的集合。

3.根据权利要求1所述的基于正则匹配的无限层次多路径采集系统，其特征在于：所述的标签进行提取分析的步骤为

(1)根据StartCode、StartOffset构造用于提取的开始代码，设为SC；根据EndCode、EndOffset构造用于提取的结束代码，设为EC；

(2)使用SC和EC进行定位提取，得到初步结果集R，R中元素为普通字符串；

(3)若ReMatch项不为空，则对结果集R中所有的元素进行正则匹配，使用的正则表达式为ReMatch，得到新的结果集R₂，清空结果集R，并把R₂中的元素添加到R中；

(4)若Inc不为空，则对结果集R中的所有元素进行筛选，保留含有Inc这种格式字符串的元素，其他元素从结果集中排除；

(5)若Ex项不为空，则对结果集R中的元素进行排除，把包含Ex的元素从结果集中排除；

(6)对于标签的所有Treatment项，对结果集R中的元素进行插入或替换操作；

(7)若IsMerge项为true，则对R中的元素进行合并，若R不为空集，则最终合并为一项，清

(8)除R中元素，并把这一个字符串保存在R中；

(9)若IsLink项为true，对R中的每个元素进行绝对地址转换，并把转换后的内容替换R中原来的元素；

(10)对R中元素进行结果组装，组装成需要的数据形式，并存放在所在任务的标签结果集中(分标签存放)，若该标签引出子层，则把该标签的结果加入到任务队列中。

从上述步骤中可以看出系统运行时的详细过程，而标签之间存在着从属关系，对于没有父标签的标签我们称其为起始标签，下面介绍这种从属关系作用的方式

4.根据权利要求1所述的基于正则匹配的无限层次多路径采集系统，其特征在于：通过设计过渡性采集内容存储结构、组的数据结构以及存储转化算法，让用户在此基础上自由将标签采集结果自定义分组，从而使每个用户都可以定制个性化的存储方案。

Images