CN111966940B - 一种基于用户请求序列的目标数据定位方法和装置 - Google Patents

Abstract

本申请提供了一种基于用户请求序列的目标数据定位方法和装置。通过该方法，首先根据用户的需求，从目标Web页面中提取关键信息，然后对用户在到达目标Web页面的操作过程中产生的请求序列的返回结果建立索引，再利用关键信息作为关键字在索引中检索，根据检索结果评分的高低，确定目标请求，最后根据目标请求的返回结果格式，定位出目标数据在目标请求返回结果中的位置。通过该方法，可以解决在提取动态Web页面的数据时目标数据难以定位的问题，为动态Web页面的数据的提取开放提供了技术支持，提升了动态Web页面的数据的提取开放的效率。

Description

一种基于用户请求序列的目标数据定位方法和装置

技术领域

本发明涉及数据处理技术领域，特别是涉及一种基于用户请求序列的目标数据定位方法和装置。

背景技术

在大数据时代，应用中存在大量有价值的数据，而提取不同应用中的数据并进行集成分析往往能产生更大的价值，应用之间数据开放和互联互通的需求越来越强。其中，Web应用由于其无需安装、访问便捷等原因已成为最主流的应用模式之一。目前已有一些方法对Web应用中的数据进行提取并开放，但随着Web应用的结构越来越复杂且多样化，现有的方法已经很难高效且普适性地适用于众多Web应用。

例如，针对动态Web页面，现有的API(Application Programming Interface，应用程序接口)生成方法无法适用，必须要用户人工辅助来进行数据提取。在相关技术中，可以通过模板提取Web页面中的数据，这一过程的首要步骤就是定位Web页面中的待提取数据，而针对动态Web页面，相关技术中并不存在可以准确定位动态Web页面中的待提取数据的方案。而随着数据开放的需求越来越高，API开发的需求量和及时性要求也在提高，无法处理动态页面这一问题严重拖累了API数据开放的效率。

发明内容

本申请实施例提供了一种基于用户请求序列的目标数据定位方法和装置，可解决在提取动态Web页面的数据时目标数据难以定位的问题，进而提高API数据开放的效率。

本申请实施例第一方面提供了一种数据定位方法，包括：

根据用户的需求，从目标Web页面提取关键数据；

收集用户在到达所述目标Web页面的操作过程中产生的请求序列；

对所述请求序列的返回结果建立索引；

利用所述关键数据作为关键字在所述索引中检索，根据检索结果评分的高低，定位出目标请求；

根据所述目标请求的返回结果格式，定位出目标数据在所述目标请求的返回结果中的位置。

本申请实施例第二方面提供了一种数据定位装置，包括：

提取模块，用于根据用户的需求，从目标Web页面提取关键数据；

收集模块，用于收集用户在到达所述目标Web页面的操作过程中产生的请求序列；

建立模块，用于对所述请求序列的返回结果建立索引；

第一定位模块，用于利用所述关键数据作为关键字在所述索引中检索，根据检索结果评分的高低，定位出目标请求；

第二定位模块，根据所述目标请求的返回结果格式，定位出目标数据在所述目标请求的返回结果中的位置。

通过本申请的基于用户请求序列的目标数据定位方法和装置，首先根据用户的需求，从目标Web页面中提取关键信息，然后对用户在到达目标Web页面的操作过程中产生的请求序列的返回结果建立索引，再利用关键信息作为关键字在索引中检索，根据检索结果评分的高低，确定目标请求，最后根据目标请求的返回结果格式，定位出目标数据在目标请求返回结果中的位置。通过该方法，可以解决在提取动态Web页面的数据时目标数据难以定位的问题，为动态Web页面的数据的提取开放提供了技术支持，提升了动态Web页面的数据的提取开放的效率。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例的描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本申请一实施例示出的一种基于用户请求序列的目标数据定位方法的流程图；

图2是本申请一实施例示出的模板规则框架的架构图

图3是本申请一实施例示出的模板规则框架工作流程；

图4是本申请一实施例示出的一种input标签示意图；

图5是本申请一实施例示出的一种关键数据组织结构提取效果示意图；

图6是本申请一实施例示出的一种接口信息示意图；

图7是本申请一实施例示出的一种请求序列相关文件的结构示意图；

图8是本申请一实施例示出的jsoup解析结果示意图；

图9是本申请一实施例示出的一种关键信息结构文本树的示意图；

图10是本申请一实施例示出的一种文本树的结构图；

图11是本申请一实施例示出的一种tree_dist数据的结果示例图；

图12是本申请一实施例示出的一种基于用户请求序列的目标数据定位装置的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在大数据时代，应用中存在大量有价值的数据，而提取不同应用中的数据并进行集成分析往往能产生更大的价值，应用之间数据开放和互联互通的需求越来越强。其中，Web应用由于其无需安装、访问便捷等原因已成为最主流的应用模式之一。目前已有一些方法对Web应用中的数据进行提取并开放，但随着Web应用的结构越来越复杂且多样化，现有的方法已经很难高效且普适性地适用于众多Web应用。

由于Web应用的服务器端往往是完全不可见的、客户端部分(前端)总是可见的，本申请采用从Web应用的表现层(即页面)入手对数据进行提取的思路。而由于Web应用在表现层上是最为多样化的，本申请考虑为相似的Web页面提供通用模板进行数据提取的方法，通过丰富模板库进而覆盖多样化的Web页面，在这一过程中主要面临以下挑战：1)目标数据难以定位：需要提取的数据很可能不在当前操作的页面中，需要在操作流程的请求序列中快速准确地找到需要提取的数据；2)目标结构多样化：Web页面相互之间差异很大，细化会出现非常多子类，如果每个子类都手写解析代码，穷举覆盖到所有子类需要的代价过大；3)目标模板难以选择：结构相似的Web页面存在多个可用模板，需要选取适用于当前页面的数据提取的最佳模板。

数据开放通常基于信息系统的服务化来实现。对于Web应用，信息系统服务化的结果通常是若干个Web API。Web API是信息系统提供的数据访问接口，基于HTTP协议(HyperText Transfer Protocol，超文本传输协议)，以XML(Extensible MarkupLanguage，可扩展标记语言)或者JSON(JavaScript Object Notation，JavaScript对象简谱)传输数据。

从系统架构模型的角度考虑，互联网信息系统可以分为移动应用/服务器(Application/Server，A/S)架构、浏览器/服务器(Browser/Server，B/S)架构与桌面客户端/服务器(Client/Server，C/S)架构三类。上述三种架构都包括客户端和服务器两部分。本申请主要针对的是B/S架构的情况：即客户端为浏览器，服务器为Web服务器，两者通过HTTP协议进行交互。

目前，相关技术中已针对B/S架构应用的数据开放选择从浏览器客户端入手，在云-端融合系统的资源反射机制及高效互操作技术的支持下，研发出了一款成熟的面向大数据的数据融合开放平台。在该平台的辅助下，用户可以较为高效的制作、部署、管理B/SAPI。但是随着数据开放的需求越来越高，为了打破信息孤岛和实现数据互操作，需要更大量的API支持来实现接口化。也因此导致API开发的需求量提高，及时性要求也在提高，越来越需要提升API开发的效率。

目前，基于该数据融合开放平台，效率最高且人工介入最少的生成API的方法是：用户通过该平台访问目标页面，圈选其中需要提取的数据所对应的DOM(Document ObjectModel，文档对象模型)块，然后选择一个模板大类，例如表格，指定必要的提取结果的字段名及每个字段相应的DOM节点等需求信息。在用户访问目标页面的过程中，平台会保留这个过程中发生的请求序列作为分析与API生成的基础，在用户指定待提取数据后，平台会在请求序列中取出目标页面对应的HTTP请求，然后根据模板对应的结构特点、字段、DOM节点的路径等信息生成一个API，该API的调用参数为HTTP请求的参数，返回结果为JSON结构的目标数据。在用户填写参数并调用API后，API会用这些参数向上述HTTP请求对应的URL(Uniform Resource Locator,统一资源定位符)地址发送HTTP请求，然后对返回结果进行相应的提取与重组，形成符合用户预期的、包含目标数据信息的JSON结构返回结果。

虽然API开发的需求越来越大，但是目前B/S API高效率的生成方法存在较为明显的问题，那就是无法处理动态页面。所谓动态页面主要包括以下几种情况：

一、目标数据动态加载：Web应用由于JS、Ajax、Frame等技术，很多网页上显示的数据都并不是在当前页面的请求结果HTML中。

二、关联数据动态加载：由于很多动态加载的技术，导致网页上很多内容在加载后有所变化。

三、数据依赖的结构信息复杂多变：相同长相不同结构：即可能在不同的网页上有显示相似的列表，但是实际其在原网页中的结构是不同的。

在上述动态页面情况下，现有的基于数据融合开放平台的API生成方法无法适用，必须要用户人工辅助来进行数据提取。而随着数据开放的需求越来越高，API开发的需求量和及时性要求也在提高，无法处理动态页面这一问题严重拖累了API数据开放的效率。

为了解决上述动态页面的问题，同时提高API制作的效率，本申请在现有的基于数据融合开放平台的API生成方法上进行改进，提升高效率的API生成方法所能适用的范畴，使其可以适用于动态页面。即：本申请所要解决问题是：用户(也可以理解为API用户)选定模板大类并指定需求信息后，如何根据模板大类正确高效生成API。这其实是一个模板的定义、匹配、使用、验证的问题，那么这个问题主要就包括以下三个方面：

一、目标数据定位；

二、模板解析；

三、模板选择匹配。

对应到基于模板规则的API生成问题，就是以下步骤：解析请求序列；确定哪个请求的哪个部分为需要转化的对象；分析需要转化的对象的组织结构以及语义特征，结合指定模板大类，基于模板匹配规则选定(或自定义)最优模板；根据选定模板以及转化对象生成API并验证。

然而，在实施上述第一方面的目标数据定位时，存在一个技术难点：目标数据难以定位。

具体而言，目标数据即指希望进行提取开放的数据。目前的web网页设计越发复杂且不规范，在JavaScript、Ajax等技术运用越来越广泛之后，原始页面与渲染后页面的差距也越来越大，需求的目标数据很可能不在操作的当前页面中(目标数据动态加载)，这种情况下需要在操作流程的请求序列中快速准确地找到可提取出目标数据的请求。例如在一些场景下，仅仅是从系统的首页到达目标页面就已经发生了多个网络请求，如果是在系统中连续操作，很可能累积更多的请求，而且这些网络请求的协议不同(POST、GET等)，返回内容格式不一(XML，JSON，HTML等)，如何在格式不一的返回结果中确定出目标数据对应的请求是有一定困难的。并且在确定了目标数据所对应的请求后，还需要确定目标数据是返回结果的哪一部分(关联数据动态加载)，这样才能进行准确的模板适配与API生成。但由于返回内容格式不同，以及可能存在的动态加载等原因，往往在当前页面下看到的需求数据在请求的返回结果中格式已经不同，给目标数据的定位带来了困难。

因此，在模板数据定位阶段，为了在请求序列中找到目标数据的位置，本文提出了一种基于关键需求信息的索引检索定位目标模板数据的方法，设计并实现了相关工具。该方法通过分析目标数据对应的内容块，根据页面上内容块结构的不同，提取其中的关键信息。例如对于form类型的结构提取input节点(即输入节点)的值，普通div层级结构提取节点的Text文本。对于上述提取到的关键信息，组成相应的关键字序列。然后对操作请求序列建立索引进行检索，根据关键字检索得分高低来定位模板数据的对应请求。

针对上述第二方面模板解析和第三方面模板匹配，可以采取已有技术实现，本申请只对第一方面目标数据定位的过程进行改进，下面将介绍改进后的确定模板需要匹配的业务数据的方法(即：基于关键需求信息的索引检索定位目标模板数据的方法)进行介绍。

图1是本申请一实施例示出的一种基于用户请求序列的目标数据定位方法的流程图。参照图1，本申请的基于用户请求序列的目标数据定位方法可以包括如下步骤：

步骤S11：根据用户的需求，从目标Web页面提取关键数据；

步骤S12：收集用户在到达所述目标Web页面的操作过程中产生的请求序列；

步骤S13：对所述请求序列的返回结果建立索引；

步骤S14：利用所述关键数据作为关键字在所述索引中检索，根据检索结果评分的高低，定位出目标请求；

步骤S15：根据所述目标请求的返回结果格式，定位出目标数据在所述目标请求的返回结果中的位置。

图2是本申请一实施例示出的模板规则框架的架构图。如图2所示，本申请设计了面向动态Web页面数据提取的模板规则框架，将从Web应用的表现层(即页面)入手，通过为相似的Web页面提供数据提取模板，来辅助用户实现动态Web页面的数据提取和开放。本申请的基于用户请求序列的目标数据定位方法的执行主体可以是：数据融合开放平台，其中，为了在操作流程的请求序列中快速准确地找到希望提取的目标数据所在位置，本申请为数据融合开放平台设计并实现了基于关键需求信息的索引检索来定位目标模板数据的工具。

目标模板数据定位工具的功能是能够收集用户在到达目标Web页面的操作过程中产生的请求序列，并根据用户的需求，从目标Web页面准确提取关键需求信息，对请求序列建立索引，利用检索快速准确地定位目标请求，进而确定目标数据与结构。

本申请设计实现的面向动态Web页面数据提取的模板规则框架的工作流程从整体上看包括如图3所示的多个步骤，图3是本申请一实施例示出的模板规则框架工作流程。其中步骤1属于需求信息收集，步骤2、3属于模板数据定位，步骤4、5属于模板选择匹配，步骤6、7属于模板解析。本申请的步骤S11-步骤S15对应上述步骤1-步骤3。

步骤1：指定接口信息，选定模板大类。

用户指定接口信息，选定模板大类，目的是为后续步骤准备数据融合开放平台所需的输入信息，在动态Web页面数据提取过程中，本申请提出的模板规则框架所需要的需求信息都来自这一步骤。用户需要在数据融合开放平台中访问目标Web页面，并在目标Web页面中圈选出需要提取的数据所在的DOM块，然后选定一个模板大类，比如表格，在此过程中，生成平台会保留访问过程的请求序列，并保存圈选的DOM块的内容，以便后续步骤分析使用。

步骤2：提取关键需求信息。

数据融合开放平台分析圈选出的DOM块的内容，根据Web页面结构的特征，判断用户所需要的数据是在DOM块的哪些部分，比如属性值、文本内容等。例如圈选的DOM块为一个form表单(即表单)时，可能用户需要的数据并不是DOM块中的文本内容，而是在表单中的input节点上的value属性值。

步骤3：定位目标请求及数据块。

数据融合开放平台对请求序列的返回结果建立索引，利用关键需求信息作为关键字在索引中检索，根据检索结果评分的高低定位出目标请求。进一步的，对目标请求中关键字出现的位置结构进行提取，通过与原始DOM块中关键字的结构进行对比，确定目标请求中的哪部分对应了需求数据，进而提升后续模板适配结果的准确性。

在本申请中，在用户访问目标Web页面，通过圈选指定接口信息，并选定模板大类后，本申请的模板规则框架即开始数据提取API的生成工作，这其中的第一步就是模板数据的定位，即在访问过程的请求序列中定位出需求数据所在的位置，只有找到了目标数据的位置才能进一步考虑如何提取转化。确切地说，这一步的输入信息包括访问过程的请求序列、以及在用户访问Web页面、指定接口信息过程中所能收集到的其它信息，输出则是一个指定的请求以及需求数据在请求中的位置，后续的模板选择匹配等步骤都是基于该步定位的结果进行的。

通过本申请的基于用户请求序列的目标数据定位方法，首先根据用户的需求，从目标Web页面中提取关键信息，然后对用户在到达目标Web页面的操作过程中产生的请求序列的返回结果建立索引，再利用关键信息作为关键字在索引中检索，根据检索结果评分的高低，确定目标请求，最后根据目标请求的返回结果格式，定位出目标数据在目标请求返回结果中的位置。通过该方法，可以解决在提取动态Web页面的数据时目标数据难以定位的问题，为动态Web页面的数据的提取开放提供了技术支持，提升了动态Web页面的数据的提取开放的效率。

结合以上实施例，在一种实施方式中，本申请还提供了一种根据用户的需求，从目标Web页面提取关键数据的方法。具体地，上述步骤S11具体可以包括：

获得用户在所述目标Web页面中圈选的需要提取的数据所在的DOM块；

若所述DOM块中未出现输入节点，提取所述DOM块中节点的文本值作为关键数据；

若所述DOM块中出现输入节点，且满足多个预设条件中的任一条件，提取输入节点的属性值作为关键数据；

其中，所述多个预设条件包括：

整个DOM块存在于一个表单中；

DOM块中包含一个表单，且DOM块内输入节点数与DOM块内有非空文本值的节点数的比例高于第一预设值；

DOM块中包含一个表单，且表单下节点数与DOM块内节点数的比例高于第二预设值。

在本申请的模板规则框架下，用户对于需求数据的指定只是通过对页面的圈选来进行(类似Chrome浏览器的选中元素)，即选定浏览器显示的页面对应的DOM树中的一个节点，表示圈选的这一部分即为需要开放的数据。而从用户的圈选指定操作中，可以直接得到的信息只有该节点的xpath路径或者该节点对应的DOM树内容，但是根据前文介绍，在动态Web页面的情况下，由于目标数据的动态加载以及关联数据的动态加载等原因，直接使用该xpath路径去当前Web页面对应的请求结果中定位时，可能找不到目标数据，所以需要根据该节点对应的DOM树内容，结合其他信息在请求序列中定位目标数据。

根据DOM树内容定位目标数据最直接的想法就是，用该部分DOM树内容跟请求序列中每个HTML返回结果对应的DOM树的每个节点比较是否相同，但是这并不是一个有效的方法。用户所需的数据是通过某个JSON返回结果动态加载到当前页面、或者该部分DOM树中某些节点、属性是渲染过程中修改的，这些动态页面的情况都会导致无法在HTML返回结果中找到跟圈选部分DOM树相同的节点。因此本申请考虑将目标数据定位过程分为两步，先定位到目标请求，再在目标请求中定位目标数据，其中目标请求的定位通过用户希望获取的关键数据是否出现在请求的返回结果中来确定，这样就需要获取圈选部分DOM树中的关键数据。

在本文的模板规则框架下，用户是因为希望获取Web页面上显示的某些文本信息所以圈选了对应的DOM块，因此可以认为关键数据就是块内的文本内容，对于图片内容暂时不在本文解决的范畴内。而在渲染后的Web页面的结构中，大部分情况下显示在页面上的文本都是DOM树中某个节点的Text，因此直接提取DOM树中节点的Text即可。额外的情况下，input标签类型的节点并非如此，input标签是一种在Web页面中常用的节点类型，其没有结束标签，也因此没有Text，但其可以通过value属性在页面上显示文本，或者type＝"text"的input节点也可以将填写的内容显示在页面上，如图4所示，图4是本申请一实施例示出的一种input标签示意图。因此用户指定的DOM块中如果出现了input节点，则需要进行进一步分析以确定关键数据。

通过对动态Web页面的观察，可以发现如果需要开放在input标签节点中出现的数据，大部分情况是当前Web页面上存在一个form表单，然后通过向后台发送某个请求，把请求的结果加载到form表单的input节点中。基于这一现象，本申请对DOM块的分析采取如下思路：如果指定DOM块中未出现input节点，则关键数据就是DOM块中节点的Text值(即文本值)；而如果指定DOM块中出现了input节点，并且满足以下几个条件之一，则认为关键数据是input节点的value值(即属性值)，这些条件包括：

(1)整个DOM块存在于一个form表单中，即该DOM块的根节点的祖先节点中存在form标签节点，这意味着用户指定的内容本身就是表单的一部分。

(2)DOM块中包含一个form表单，并且DOM块内input标签节点数与DOM块内有非空Text值的节点数的比例较高，从Web页面上显示的信息判断form表单是DOM块的主要内容，避免用户指定内容中包含一个小的form表单造成误判。

(3)DOM块中包含一个form表单，并且form表单下节点数与DOM块内节点数的比例较高，从节点数判断form表单是DOM块的主要内容，避免用户指定内容中包含一个小的form表单造成误判。

通过本申请的提取目标Web页面中的关键信息的方法，可以准确地提取出Web页面中的关键信息，以便于更好地实现对目标数据的定位，进而实现对动态Web页面的数据提取和开放。

结合以上实施例，在一种实施方式中，本申请还提供了一种根据用户的需求，从目标Web页面提取关键数据的方法。具体地，上述步骤S11具体可以包括：

获得用户在所述目标Web页面中圈选出的需要提取的数据所在的DOM块；

针对所述DOM块，删除所有从自身到所有后代都未被提取成关键数据的节点，按剩余节点的结构组织生成一棵文本树，所述文本树的每个节点有一个与关键数据对应的内容属性值；

保存对应的DOM节点提取出的关键数据。

为了完成对input节点关键数据的提取，就需要前文所说的除请求序列以外的、在用户操作过程中所能收集到的其它信息辅助，包括用户指定的DOM块内容、当前Web页面的完整DOM块内容、以及当前Web页面上所有input节点的value值。这三个信息在用户圈选的时候，都可以通过数据融合开放平台对当前Web页面的分析得到。

仅仅把上述关键数据作为一个集合提取出来的话，通常情况下只能用于定位目标请求，对后续在目标请求中定位目标数据的步骤来说，仅有关键数据内容是不足的。因为不论返回结果是什么格式，某些关键数据的内容都有可能出现在多个位置，比如用户指定的是某新闻网站的今日热点新闻列表，但是这个列表中的新闻标题同样可能出现在同一请求返回结果的最新新闻列表中。在这种情况下，仅靠关键数据内容的匹配，可能定位到不准确的目标数据，因此还需要保留关键数据的组织结构信息。本申请所定义的关键数据是对指定DOM块中部分节点的部分内容的提取，可能是input节点的value值，或者其他节点的Text值，而这两种情况下每个提取出的关键数据都是对应于一个唯一且不重复的DOM节点，而DOM本身就是一个树形结构，因此直接用DOM树的结构得出关键数据的组织结构即可，思路如下：对于指定DOM块，删除所有从自身到所有后代都未被提取成关键数据的节点，按剩余节点的结构组织一棵文本树TextTree，文本树TextTree的每个节点均有一个内容属性值content，即关键数据内容，保存对应的DOM节点提取出的关键数据，然后对文本树的结构进行适当的简化压缩，去掉冗余的节点即可。关键数据组织结构提取的效果如图5所示，图5是本申请一实施例示出的一种关键数据组织结构提取效果示意图。在图5中，DOM树中虚线节点表示当前节点无关键数据，实线节点表示当前节点有非空关键数据，曲线表示各节点的转化结果。

通过本申请的提取目标Web页面中的关键信息的方法，可以准确地提取出Web页面中的关键信息，以便于更好地实现对目标数据的定位，进而实现对动态Web页面的数据提取和开放。

结合以上实施例，在一种实施方式中，本申请还提供了一种根据目标请求的返回结果格式，定位出目标数据在目标请求的返回结果中的位置的方法。具体地，上述步骤S15具体可以包括：

若所述目标请求的返回结果格式为HTML格式，抽取DOM块中关键数据内容所在的节点并组成文本树，利用树的编辑距离与关键数据结构所组成的文本树比较相似度，将相似度最高的DOM块作为目标请求的定位结果；

若所述目标请求的返回结果格式为JSON格式或XML格式，使用关键数据内容集合对其进行裁剪，去掉未出现在关键数据内容中的节点，保留剩余的节点以及结构作为目标请求的定位结果。

在本申请中，通过分析用户指定的DOM块提取出了关键信息，接下来需要根据关键信息的内容是否出现在了请求结果中来定位目标请求。Web应用前端即页面上显示的数据都来自某个发给后端的请求的返回结果，绝大多数情况下，同类型的信息只会出现在某一个请求的返回结果中。例如一个表格内的数据，很少出现表头在某个请求的返回结果中，而表的内容出现在另一个请求的返回结果中的情况，并且表内容也很少会在两个不同请求的返回结果中同时出现。基于上述考虑，本申请对于目标请求的定位采用如下方法：对请求序列的返回结果建立索引，根据关键字进行检索，按照检索结果排序确定目标请求。

索引检索是一种常见的信息检索方式，本申请所使用的索引检索的目标是查找关键信息是否出现在返回结果中，也即全文检索。全文检索的核心思想是倒排索引，首先建立索引：通过对待检索的文件进行分词处理，对于每个“词”建立索引，索引指向所有分词结果中出现了该“词”的待检索文件；根据某一关键字进行检索时：对关键字进行分词，分词结果中出现的每个“词”的索引所指向的待检索文件即为搜索结果。在此之上为进一步提升检索效率和准确率，可以在每个“词”的索引中对文件的指向上加上权重表示在目标文件中该“词”出现的次数，也可以在检索时将关键字分词结果中多个“词”都出现了的待检索文件设置为更优的结果等。

通过索引检索定位到目标请求后，还需要进一步定位到目标数据。前文已经提到，本文的模板规则框架所针对的是文本数据的开放，而根据对以往数据的分析，在Web应用中，绝大多数网络请求的返回结果的格式为以下几种之一：HTML、JSON、XML、JS、CSS、图片，其中图片基本不可能包含文本数据，而需要进行数据开放的、有价值的数据也几乎不会出现在JS和CSS中，因此本文需要处理的返回结果格式就是HTML、JSON、XML三种。

首先考虑HTML，如果定位到的目标请求返回结果格式为HTML格式，由于这里的HTML是未渲染的，那么说明目标数据应该出现在某一个DOM块中部分节点的Text值中，最坏的情况下这个DOM块是整个body，但其实通常情况下，既然用户指定的是在渲染后页面中聚集在同一个DOM块下的有意义的、同类型的内容，那么这些内容在原请求结果中通常也是相对聚集的。那么对于HTML返回结果的目标数据定位任务就是定位到上述DOM块的根节点的xpath路径，由于这个DOM块内的节点的Text值应该包含所有或至少大部分关键数据内容，且这些节点的结构应该与关键数据的结构相似，因此定位DOM块的思路如下：抽取DOM块中关键数据内容所在的节点并组成文本树，利用树的编辑距离与关键数据结构所组成的文本树比较相似度，选择相似度最高的DOM块作为定位结果。

其次考虑JSON和XML，与HTML不同的是，JSON和XML格式的返回结果通常不包括无用的信息，例如页面结构信息和页面其他部分的信息等等，而且JSON和XML格式本身就是更加规整的格式，更重要的是，关键数据在渲染后页面中的结构与其在JSON和XML中的结构很多情况下并不保持一致，因此对于这两种格式的返回结果的基本处理思路是：直接使用关键数据内容集合对其进行裁剪，把未出现在关键数据内容中的节点去掉，保留剩余的节点以及结构作为结果。细节方面需要注意的是：由于模板规则框架下的数据提取结果返回格式为JSON，所以对于XML格式的返回结果，对其裁剪后还需要转化成JSON格式，转化的基本思路就是保留原始父子结构，去掉属性值，把相同标签的节点合并为JSON数组；对于JSON格式的返回结果中，JSON数组节点下的若干个并列JSON对象，应该保证裁剪后的结构是相同的，即取最小相同结构。

通过以上步骤，模板数据定位阶段就可以根据用户指定的接口信息，给出一个目标请求，以及根据该请求的返回结果格式给出目标数据在其中的位置。

本申请的模板规则框架，部分与云-端融合系统的资源反射机制及高效互操作技术的支持下研发出的数据融合开放平台有关，主要是在用户指定接口信息过程中提取框架所需的输入信息。如前所述，数据融合开放平台能够对B/S架构的系统重构出业务数据的接口，为数据开放提供高效的平台支撑。但该数据融合开放平台在对动态Web页面的处理上存在不足，需要用户人工介入，本申请的基于用户请求序列的目标数据定位方法正好能对其进行补充，以提高数据开放的效率。

数据融合开放平台又细分为生成、管理、运行三个子平台，其中本文所实现的框架的输入信息都是来自用户在生成平台上访问目标页面和指定接口信息的过程中所提取的。为便于对接数据开放融合，本申请实现的系统主要是使用的Java语言，并在具体的实现过程中，使用Lucene建立索引进行检索。

结合以上实施例，在一种实施方式中，本申请还提供了一种根据用户的需求，从目标Web页面提取关键数据的方法。具体地，上述步骤S11可以包括：

获得来源于生成平台的输入，包括：请求序列相关文件、需求配置文件以及目标页面结构文件；

根据所述需求配置文件为目标页面结构中的所有输入节点添加属性值；

根据所述需求配置文件中的xpath路径，从所述目标页面结构文件中获取指定DOM块的内容；

解析所述DOM块的内容，判断关键数据来源，提取关键信息及其结构组成一棵文本树。

在模板规则框架的实现过程中，为便于理解每一阶段的工作效果，以用户指定图6所示的接口信息为例，在每一阶段给出当前阶段的处理结果。图6是本申请一实施例示出的一种接口信息示意图。

如前文所述，模板数据定位的作用是能够根据用户的操作和指定，在访问过程的请求序列中定位出需求数据所在的位置。根据前文，整个模板规则框架的输入来源于生成平台，因此首先介绍框架输入的内容和格式。

一、请求序列相关文件：即用户在访问目标页面和指定需求数据过程所发送的所有网络请求的相关信息，生成平台将其保存为如图7所示的文件结构，图7是本申请一实施例示出的一种请求序列相关文件的结构示意图。在图7中，各级目录的意义分别为：1-当前项目；2-项目请求序列保存路径；3-一个文件夹对应一次用户指定需求数据过程中的所有相关文件；4-本次过程中的所有请求序列；5-一个文件夹对应一个请求的内容，文件夹名为其随机分配的唯一ID。框中的文件为模板规则框架分析时所需要的内容，rawdataConf.json文件以请求的ID为索引，保存其对应的URL和请求类型；urlConf.json文件以请求的URL为索引，保存其对应的ID；每个请求的内容保存为五个文件，SampleRequest保存参数列表，SampleResponse保存返回结果，timestamp保存本次请求发生的时间戳，url保存本次请求的URL，api.xml主要保存请求的header和返回结果的header以及编码格式等信息。

二、需求配置文件：用来保存在用户指定需求数据过程中所提供的其他额外信息，包括指定的模板大类、指定需求数据对应的DOM块的xpath路径、当前页面input节点value值。可选模板大类包括：表格、列表、单页信息等。xpath路径在用户指定需求数据时由前端计算得到。input节点的value值为一个map，保存input节点id到value的映射，同样由前端获取。

三、目标页面结构文件：保存用户指定需求数据时所在页面的当前DOM结构，内容就是当前页面DOM树根节点的outerHTML内容。

在本申请中，通过生成平台获得上述输入信息后，首先根据需求配置文件中的map，为目标页面结构中的所有input节点添加value值，然后根据需求配置文件中的xpath路径，从目标页面结构文件中获取指定DOM块的内容。获得上述DOM块内容后，使用jsoup解析DOM块内容，判断关键数据来源，提取关键信息及其结构组成一棵文本树TextTree，记为T1。TextTree的节点TextTreeNode的实际定义如下所示：

其中，children保存子节点列表，content保存当前文本树TextTree节点对应的关键信息内容，去除首尾空字符，domNode是为了后续在目标请求中定位关键数据时使用。

需要注意的是，在jsoup解析HTML时，其节点对象主要被分为两类，分别是Element和TextNode，其中Element对应DOM树中的节点，TextNode对应DOM树中节点的文本内容，如图8所示，图8是本申请一实施例示出的jsoup解析结果示意图。为了能反映出图8中左侧DOM树里Element1的结构特点，即一个Elment节点下有多个被子节点隔开的TextNode文本内容的情况，不使用Element1.ownerText()直接把多个TextNode文本内容合并为一个，而是解析到TextNode作为文本树TextTree中的节点。在这样的情况下，所有可能包含关键信息的节点都一定是文本树TextTree的叶节点：如果关键信息来自input节点的value值，那么input节点是没有子节点的，所以一定是叶节点；如果关键信息来自节点的文本内容，那么文本内容是在TextNode中的，而TextNode是没有子节点的。

结合以上实施例，在一种实施方式中，本申请还提供了一种根据用户的需求，从目标Web页面提取关键数据的方法。具体地，上述步骤S11可以包括：

对从DOM节点提取的文本信息进行转化过滤，使其只保留中英文，将转化过滤后的文本信息作为关键数据。

在本申请中，在HTML中存在多种多样的字符，但是本申请提取出来的关键信息后续是需要作为索引检索的关键字使用，因此考虑到分词可能出现错误等原因，这里对DOM节点文本信息的提取增加了一个转化过滤的操作，使其只保留中英文，具体地：首先通过替换去掉所有的Web页面特有的&nbsp、(char)160)等符号，其次对提取出的文本信息逐字节判断是否为中文或英文字符，英文字符通过char值取值范围在0-128之内判断，中文字符通过Character.UnicodeBlock判断，最后去掉首尾空字符，如果此时结果非空，则创建TextTreeNode节点，并将结果保存到content中。

示例地，对图6中指定的接口信息，本申请提取出的关键信息结构TextTree如图9所示，图9是本申请一实施例示出的一种关键信息结构文本树的示意图。

结合以上实施例，在一种实施方式中，本申请还提供了一种定位出目标请求的方法。具体地，上述步骤S14可以包括：

遍历关键信息组织结构提取结果的文本树，获取所有关键信息组成集合；

建立索引；

遍历请求序列相关文件结构的每个文件夹内的SampleResponse文件，如果返回结果格式为XML、JSON或HTML，创建文档对象并添加到建立的索引中；所述文档对象包括StringField path和TextField content，所述StringField path用于保存SampleResponse文件路径，所述TextField content用于保存文件内容；

建立检索查询，所述检索查询为一系列条件的OR组合，每一个条件为：对关键信息集合中的某一个关键信息分词后，在TextField content域中是否出现；

用检索查询在索引中执行检索，根据评分最高的文档对象的StringField path域的值获得目标请求定位结果。

在上述过程中，建立索引可以包括：

使用线程池，每发现一个需要创建文档对象的SampleResponse文件，提交一个“创建文档对象并添加到索引中”的任务给线程池，使线程池选取一个空闲线程完成任务；

在线程池内所有任务结束时，将需要添加的文档对象写入到索引中。

在获得关键信息组织结构提取结果的文本树TextTree后，接下来需要做的就是根据关键信息，利用索引检索定位目标请求。本申请的索引检索是基于一个开源的全文检索引擎工具包Lucene实现的，这是一个全文检索引擎的架构，提供了完整的查询引擎和索引引擎，Lucene的使用主要分为以下几个步骤：指定分词器，建立索引；创建索引文档对象并将其添加到索引中；根据关键词以及查询条件建立检索query；使用检索query在索引中进行检索，获得结果。

具体地，使用Lucene索引检索定位目标请求的过程为：

首先遍历关键信息组织结构提取结果的文本树TextTree，获取所有关键信息组成集合，因为索引检索时不需要结构信息。

由于一次索引的目标文件数量不会太大，且建立的索引大概率一次性使用完毕不需要保存，所以为提高效率，直接在内存中建立索引index。同时由于本申请所使用的检索关键词包括中英文，所以使用了一个开源的、轻量级的中文分词工具包IKAnalyzer。

遍历图7中处于第五层结构的所有文件夹，对每个文件夹内的SampleResponse文件，如果返回结果格式为XML、JSON或者HTML，创建文档对象并添加到索引index中。文档对象包括两个主要的filed，分别是StringField path(用于保存该SampleResponse文件路径用于后续检索结果的获取)，以及TextField content(用于保存文件内容)。StringField只建立索引不分词，而TextField既建立索引又分词，本申请的检索就是基于TextFieldcontent的分词结果进行的。另外这里为了加速索引的建立，使用了线程池，每发现一个需要创建文档对象的SampleResponse文件，提交一个“创建文档对象并添加到索引中”的任务给线程池，线程池会选取一个空闲线程完成任务。待线程池内所有任务结束，将需要添加的文档对象都通过一次commit切实写入到索引中。

索引建立完成后，建立检索query(即检索查询)，整体上检索query为一系列条件的OR组合，每一个条件为：使用IKAnalyzer分词器对关键信息集合中的某一个关键信息分词后，在TextField content域中是否出现。需要注意query中组合子句的个数不能超过上限。

用query在index中执行检索，检索结果会对每个文档对象给出评分，取评分最高的文档对象的StringField path域的值来得到目标请求定位结果。

示例地，对图6中指定的接口信息，进行关键信息定位后得到的目标请求id为68dddcc7b8fa4229ae26293c9143a1b3，Lucene对其给出的评分为241，其返回结果类型为HTML。

结合以上实施例，在一种实施方式中，本申请还提供了一种根据目标请求的返回结果格式，定位出目标数据在目标请求返回结果中的位置的方法。具体地，上述步骤S14可以包括：

若所述目标请求的返回结果格式为XML，将XML转为JSON结果，将JSON结果返回；

若所述目标请求的返回结果格式为JSON，删除所有JSON值未在关键信息集合中出现的JSON节点，将处理后的JSON结果返回；

若所述目标请求的返回结果格式为HTML，则将其解析为DOM树，根据所述DOM树获得目标数据的定位结果，将定位结果返回。

在本申请中，在定位到目标请求后，如果目标请求返回结果格式为XML，使用开源工具dom4j解析XML返回结果文件，遍历整个XML结构，如果当前XML节点的text非空并且在关键信息集合中出现，或者当前XML节点存在未被删除的子节点，则保留当前节点，否则删除当前节点，然后使用开源工具JSON-java的XML.toJSONObject方法将XML转为JSON结果返回。如果目标请求返回结果格式为JSON，则使用开源工具Gson的JsonReader解析JSON返回结果文件，同样删除所有JSON值未在关键信息集合中出现的JSON节点，然后将结果返回。

如果目标请求返回结果格式为HTML，则使用jsoup将其解析为DOM树，然后将整棵树转化提取为文本树TextTree，此处的文本树记为T2，其大体结构如图10所示，图10是本申请一实施例示出的一种文本树的结构图。由于整个HTML所转化的文本树TextTree结构过大，因此图10中对其进行了大量简化。接下来就是对T2中所有的子树，分别与关键数据结构所转化的T1计算编辑距离，找出编辑距离最小的子树，选择其根节点所对应的原DOM节点作为目标数据定位结果返回。但是由于树的子树数量是O(N)的，所以分别计算每个子树和关键结构所转化的树的编辑距离会导致整个过程的复杂度上升一个量级，这是难以接受的。

对本申请所实现的树编辑距离计算算法进行分析，由于该算法的基本思路是基于动态规划进行编辑距离求解的，那么很可能在计算过程中的中间结果里保留了子问题的解，即子树之间的编辑距离。进一步分析发现，算法计算过程中存在一个tree_dist数组，其中保存了以各个节点为根的子树之间的编辑距离。tree_dist[i][j]中的保存就是，以一棵树中编号为i的节点为根的子树与以另一棵树中编号为j的节点为根的子树的编辑距离，编号是指以树的后序遍历顺序对节点进行编号，如图11所示，图11是本申请一实施例示出的一种tree_dist数据的结果示例图。在图11中，圆圈内为节点的标签，方括号内为节点的编号，tree_dist的计算中，添加删除修改节点的代价都为1。那么本申请所需要的T2中每棵子树与T1的编辑距离就是tree_dist中的第一行(或第一列)结果。

为了实现树编辑距离的计算，需要对TextTreeNode定义代价函数，即删除节点、添加节点、修改节点的代价分别如何计算。对于TextTreeNode，其代价函数应该只与content字段有关，而该字段为字符串，并非取自一个有限字符集，另一方面，该字段代表的是该节点所对应的关键信息串，可以认为只要不相等就是不同的关键信息，因此将节点v修改为节点w的代价函数定义如下：

其中λ表示空节点，前四个条件分别表示删除节点和添加节点时，如果待删除(添加)节点的content为空，则代价为1，否则代价为2，后四个条件表示修改节点时代价取决于节点的content字段是否相等、以及是否其中某个节点的content字段为空。

在上述编辑距离的度量下，最后找到的树编辑距离最小的子树，对应的DOM节点为图10中的table节点，即该节点就是目标数据定位的结果。

为了满足日益增加的Web应用业务数据开放需求，提升在动态页面情况下数据提取的效率，本申请从Web应用的表现层入手，通过为相似Web页面提供通用模板的方法，提出并实现了面向动态Web页面数据提取的模板规则框架，从而实现了一种面向动态Web页面业务数据开放的方法。

在实施本申请中的面向动态Web页面业务数据开放的方法时，模板数据定位阶段的目的是根据用户指定的接口信息，在请求序列中快速准确地定位到包含这一信息的请求以及目标数据在请求中的位置。为此，本申请首先实现了基于DOM树结构的关键信息提取，通过对指定接口信息对应DOM树结构的分析，确定关键信息所在位置，并将其结构化地提取为一棵文本树TextTree。随后，本申请实现了基于Lucene的索引检索来定位目标数据，通过对请求序列建立索引，以文本树TextTree中保存的关键信息作为搜索关键字，利用全文检索确定目标请求。在目标请求为JSON或XML格式的情况下，利用关键信息对其内容进行过滤，然后转化为数据提取JSON结果。在目标请求为更为复杂的HTML格式的情况下，将整个HTML转化为文本树TextTree，并与关键信息TextTree计算树编辑距离，找出与关键信息TextTree相似度最高的HTML节点，作为目标数据定位的结果。

通过本申请的方法，可以解决在提取动态Web页面的数据时目标数据难以定位的问题，为动态Web页面的数据的提取开放提供了技术支持，提升了动态Web页面的数据的提取开放的效率。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明实施例并不受所描述的动作顺序的限制，因为依据本发明实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本发明实施例所必须的。

基于同一发明构思，本申请还提供了一种数据定位装置1200。图12是本申请一实施例示出的一种基于用户请求序列的目标数据定位装置的结构示意图。参照图12，本申请的基于用户请求序列的目标数据定位装置1200可以包括：

提取模块1201，用于根据用户的需求，从目标Web页面提取关键数据；

收集模块1202，用于收集用户在到达所述目标Web页面的操作过程中产生的请求序列；

建立模块1203，用于对所述请求序列的返回结果建立索引；

第一定位模块1204，用于利用所述关键数据作为关键字在所述索引中检索，根据检索结果评分的高低，定位出目标请求；

第二定位模块1205，根据所述目标请求的返回结果格式，定位出目标数据在所述目标请求的返回结果中的位置。

可选地，所述提取模块1201包括：

第一获得子模块，用于获得用户在所述目标Web页面中圈选的需要提取的数据所在的DOM块；

第一提取子模块，用于若所述DOM块中未出现输入节点，提取所述DOM块中节点的文本值作为关键数据；

第二提取子模块，用于若所述DOM块中出现输入节点，且满足多个预设条件中的任一条件，提取输入节点的属性值作为关键数据；其中，所述多个预设条件包括：整个DOM块存在于一个表单中；DOM块中包含一个表单，且DOM块内输入节点数与DOM块内有非空文本值的节点数的比例高于第一预设值；DOM块中包含一个表单，且表单下节点数与DOM块内节点数的比例高于第二预设值。

可选地，所述提取模块1201包括：

第二获得子模块，用于获得用户在所述目标Web页面中圈选出的需要提取的数据所在的DOM块；

删除模块，用于针对所述DOM块，删除所有从自身到所有后代都未被提取成关键数据的节点，按剩余节点的结构组织生成一棵文本树，所述文本树的每个节点有一个与关键数据对应的内容属性值；

保存模块，用于保存对应的DOM节点提取出的关键数据。

可选地，所述第一定位模块1204包括：

抽取模块，用于若所述目标请求的返回结果格式为HTML格式，抽取DOM块中关键数据内容所在的节点并组成文本树，利用树的编辑距离与关键数据结构所组成的文本树比较相似度，将相似度最高的DOM块作为目标请求的定位结果；

裁剪模块，用于若所述目标请求的返回结果格式为JSON格式或XML格式，使用关键数据内容集合对其进行裁剪，去掉未出现在关键数据内容中的节点，保留剩余的节点以及结构作为目标请求的定位结果。

可选地，所述提取模块1201包括：

第三获得子模块，用于获得来源于生成平台的输入，包括：请求序列相关文件、需求配置文件以及目标页面结构文件；

添加模块，用于根据所述需求配置文件为目标页面结构中的所有输入节点添加属性值；

第四获得子模块，用于根据所述需求配置文件中的xpath路径，从所述目标页面结构文件中获取指定DOM块的内容；

解析模块，用于解析所述DOM块的内容，判断关键数据来源，提取关键信息及其结构组成一棵文本树。

可选地，所述提取模块1201包括：

过滤模块，用于对从DOM节点提取的文本信息进行转化过滤，使其只保留中英文，将转化过滤后的文本信息作为关键数据。

可选地，所述第一定位模块1204包括：

第一遍历模块，用于遍历关键信息组织结构提取结果的文本树，获取所有关键信息组成集合；

第一建立子模块，用于建立索引；

第二遍历模块，用于遍历请求序列相关文件结构的每个文件夹内的SampleResponse文件，如果返回结果格式为XML、JSON或HTML，创建文档对象并添加到建立的索引中；所述文档对象包括StringField path和TextField content，所述StringFieldpath用于保存SampleResponse文件路径，所述TextField content用于保存文件内容；

第二建立子模块，用于建立检索查询，所述检索查询为一系列条件的OR组合，每一个条件为：对关键信息集合中的某一个关键信息分词后，在TextField content域中是否出现；

第五获得子模块，用于用检索查询在索引中执行检索，根据评分最高的文档对象的StringField path域的值获得目标请求定位结果。

可选地，所述第一建立子模块包括：

提交模块，用于使用线程池，每发现一个需要创建文档对象的SampleResponse文件，提交一个“创建文档对象并添加到索引中”的任务给线程池，使线程池选取一个空闲线程完成任务；

写入模块，用于在线程池内所有任务结束时，将需要添加的文档对象写入到索引中。

可选地，所述第一定位模块1204包括：

第一返回模块，用于若所述目标请求的返回结果格式为XML，将XML转为JSON结果，将JSON结果返回；

第二返回模块，用于若所述目标请求的返回结果格式为JSON，删除所有JSON值未在关键信息集合中出现的JSON节点，将处理后的JSON结果返回；

第三返回模块，用于若所述目标请求的返回结果格式为HTML，则将其解析为DOM树，根据所述DOM树获得目标数据的定位结果，将定位结果返回。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本发明实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本发明实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明实施例是参照根据本发明实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本发明所提供的一种基于用户请求序列的目标数据定位方法和装置，进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (10)

1.一种基于用户请求序列的目标数据定位方法，其特征在于，包括：

根据用户的需求，从目标Web页面提取关键数据；

收集用户在到达所述目标Web页面的操作过程中产生的请求序列；

对所述请求序列的返回结果建立索引；

利用所述关键数据作为关键字在所述索引中检索，根据检索结果评分的高低，定位出目标请求；

根据所述目标请求的返回结果格式，定位出目标数据在所述目标请求的返回结果中的位置。

2.根据权利要求1所述的方法，其特征在于，根据用户的需求，从目标Web页面提取关键数据，包括：

获得用户在所述目标Web页面中圈选的需要提取的数据所在的DOM块；

若所述DOM块中未出现输入节点，提取所述DOM块中节点的文本值作为关键数据；

若所述DOM块中出现输入节点，且满足多个预设条件中的任一条件，提取输入节点的属性值作为关键数据；其中，所述多个预设条件包括：整个DOM块存在于一个表单中；DOM块中包含一个表单，且DOM块内输入节点数与DOM块内有非空文本值的节点数的比例高于第一预设值；DOM块中包含一个表单，且表单下节点数与DOM块内节点数的比例高于第二预设值。

3.根据权利要求1所述的方法，其特征在于，根据用户的需求，从目标Web页面提取关键数据，包括：

获得用户在所述目标Web页面中圈选出的需要提取的数据所在的DOM块；

针对所述DOM块，删除所有从自身到所有后代都未被提取成关键数据的节点，按剩余节点的结构组织生成一棵文本树，所述文本树的每个节点有一个与关键数据对应的内容属性值；

保存对应的DOM节点提取出的关键数据。

4.根据权利要求1所述的方法，其特征在于，根据所述目标请求的返回结果格式，定位出目标数据在所述目标请求的返回结果中的位置，包括：

若所述目标请求的返回结果格式为HTML格式，抽取DOM块中关键数据内容所在的节点并组成文本树，利用树的编辑距离与关键数据结构所组成的文本树比较相似度，将相似度最高的DOM块作为目标请求的定位结果；

若所述目标请求的返回结果格式为JSON格式或XML格式，使用关键数据内容集合对其进行裁剪，去掉未出现在关键数据内容中的节点，保留剩余的节点以及结构作为目标请求的定位结果。

5.根据权利要求1所述的方法，其特征在于，根据用户的需求，从目标Web页面提取关键数据，包括：

获得来源于生成平台的输入，包括：请求序列相关文件、需求配置文件以及目标页面结构文件；

根据所述需求配置文件为目标页面结构中的所有输入节点添加属性值；

根据所述需求配置文件中的xpath路径，从所述目标页面结构文件中获取指定DOM块的内容；

解析所述DOM块的内容，判断关键数据来源，提取关键信息及其结构组成一棵文本树。

6.根据权利要求5所述的方法，其特征在于，根据用户的需求，从目标Web页面提取关键数据，包括：

对从DOM节点提取的文本信息进行转化过滤，使其只保留中英文，将转化过滤后的文本信息作为关键数据。

7.根据权利要求5所述的方法，其特征在于，利用所述关键数据作为关键字在所述索引中检索，根据检索结果评分的高低，定位出目标请求，包括：

遍历关键信息组织结构提取结果的文本树，获取所有关键信息组成集合；

建立索引；

遍历请求序列相关文件结构的每个文件夹内的SampleResponse文件，如果返回结果格式为XML、JSON或HTML，创建文档对象并添加到建立的索引中；所述文档对象包括StringField path和TextField content，所述StringField path用于保存SampleResponse文件路径，所述TextField content用于保存文件内容；

建立检索查询，所述检索查询为一系列条件的OR组合，每一个条件为：对关键信息集合中的某一个关键信息分词后，在TextField content域中是否出现；

用检索查询在索引中执行检索，根据评分最高的文档对象的StringField path域的值获得目标请求定位结果。

8.根据权利要求7所述的方法，其特征在于，建立索引包括：

使用线程池，每发现一个需要创建文档对象的SampleResponse文件，提交一个“创建文档对象并添加到索引中”的任务给线程池，使线程池选取一个空闲线程完成任务；

在线程池内所有任务结束时，将需要添加的文档对象写入到索引中。

9.根据权利要求5所述的方法，其特征在于，利用所述关键数据作为关键字在所述索引中检索，根据检索结果评分的高低，定位出目标请求，包括：

若所述目标请求的返回结果格式为XML，将XML转为JSON结果，将JSON结果返回；

若所述目标请求的返回结果格式为JSON，删除所有JSON值未在关键信息集合中出现的JSON节点，将处理后的JSON结果返回；

若所述目标请求的返回结果格式为HTML，则将其解析为DOM树，根据所述DOM树获得目标数据的定位结果，将定位结果返回。

10.一种基于用户请求序列的目标数据定位装置，其特征在于，包括：

提取模块，用于根据用户的需求，从目标Web页面提取关键数据；

收集模块，用于收集用户在到达所述目标Web页面的操作过程中产生的请求序列；

建立模块，用于对所述请求序列的返回结果建立索引；

第一定位模块，用于利用所述关键数据作为关键字在所述索引中检索，根据检索结果评分的高低，定位出目标请求；

第二定位模块，根据所述目标请求的返回结果格式，定位出目标数据在所述目标请求的返回结果中的位置。

Images