CN111913739A

CN111913739A - 一种服务接口原语定义方法和系统

Info

Publication number: CN111913739A
Application number: CN202010753677.8A
Authority: CN
Inventors: 易超; 张舒汇; 贺赞贤
Original assignee: Beijing Shulide Technology Co ltd
Current assignee: Beijing Shulide Technology Co ltd
Priority date: 2020-07-30
Filing date: 2020-07-30
Publication date: 2020-11-10
Anticipated expiration: 2040-07-30
Also published as: CN111913739B

Abstract

本申请提供了一种服务接口原语定义方法和系统。通过该方法，首先根据待提取数据的Web页面的特征，按照模板原语编写数据提取模板。接着对数据提取模板进行词法分析，获得词法单元。再根据词法单元，对数据提取模板进行语法分析，获得抽象语法树；然后根据抽象语法树，生成数据提取模板的以中间形式表示的XML文件；最后根据模板原语对XML文件进行语义检查，完成数据提取模板的定义。通过该方法，可以解决在提取动态Web页面的数据时Web页面相互之间差异较大而导致的数据提取转换困难的问题，有效降低了模板编写的难度，提升了模板的适用性，为动态Web页面的数据的提取开放提供了技术支持，提升了动态Web页面的数据的提取开放的效率。

Description

一种服务接口原语定义方法和系统

技术领域

本发明涉及数据处理技术领域，特别是涉及一种服务接口原语定义方法和系统。

背景技术

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

例如，针对动态Web页面，现有的API(Application Programming Interface，应用程序接口)生成方法无法适用，必须要用户人工辅助来进行数据提取。在相关技术中，可以通过模板提取动态Web页面中的数据，而不同的动态Web页面结构差异较大，如果为每一动态Web页面编写适用模板，工作量较大，且编写的模板仅限于当前适用的Web页面，通用性较差。而随着数据开放的需求越来越高，API开发的需求量和及时性要求也在提高，无法处理动态页面这一问题严重拖累了API数据开放的效率。

发明内容

本申请实施例提供了一种服务接口原语定义方法和系统，可以解决在提取动态Web页面的数据时Web页面相互之间差异较大而导致的数据提取转换困难的问题，进而提高API数据开放的效率。

本申请实施例第一方面提供了一种服务接口原语定义方法，包括：

根据待提取数据的Web页面的特征，按照模板原语编写数据提取模板；

对所述数据提取模板进行词法分析，获得词法单元；

根据所述词法单元，对所述数据提取模板进行语法分析，获得抽象语法树；

根据所述抽象语法树，生成所述数据提取模板的以中间形式表示的XML文件；

根据所述模板原语对所述XML文件进行语义检查，完成所述数据提取模板的定义。

本申请实施例第二方面提供了一种服务接口原语定义系统，包括：

编写模块，用于根据待提取数据的Web页面的特征，按照模板原语编写数据提取模板；

第一获得模块，用于对所述数据提取模板进行词法分析，获得词法单元；

第二获得模块，用于根据所述词法单元，对所述数据提取模板进行语法分析，获得抽象语法树；

生成模块，用于根据所述抽象语法树，生成所述数据提取模板的以中间形式表示的XML文件；

检查模块，用于根据所述模板原语对所述XML文件进行语义检查，完成所述数据提取模板的定义。

通过本申请的服务接口原语定义方法，首先根据待提取数据的Web页面的特征，按照模板原语编写数据提取模板。接着对数据提取模板进行词法分析，获得词法单元。再根据词法单元，对数据提取模板进行语法分析，获得抽象语法树；然后根据抽象语法树，生成数据提取模板的以中间形式表示的XML文件；最后根据模板原语对XML文件进行语义检查，完成数据提取模板的定义。通过该方法，可以解决在提取动态Web页面的数据时Web页面相互之间差异较大而导致的数据提取转换困难的问题，有效降低了模板编写的难度，提升了模板的适用性，为动态Web页面的数据的提取开放提供了技术支持，提升了动态Web页面的数据的提取开放的效率。

附图说明

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

图1是本申请一实施例示出的一种服务接口原语定义方法的流程图；

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

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

图4是本申请一实施例示出的一种服务接口原语定义系统的结构示意图。

具体实施方式

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

由于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页面相互之间差异很大，细化会出现非常多模板子类，如果每个模板子类都手写模板解析代码，穷举覆盖到所有模板子类需要的代价过大。

具体而言，Web页面相互之间存在的结构差异是非常多样化的(数据依赖的结构信息复杂多变)，如前文所述，同样是页面上显示的列表样式，实际在源页面中的DOM树结构可能完全不一样，并且由于Web页面本身并无严格的规范，所以不同的研发团队可能会产生非常多种类的结构：例如用div节点堆叠的列表、用table节点去掉表格线的列表、用form提交的表单、用table结合button提交的表单、使用thead或不使用thead的表格、使用th或不使用th的表格等等。在这样的情况下，对需求数据的源页面结构进行细化会出现非常多子类，各个子类之间既缺乏明确的区分标准，互相之间也很难共用解析代码，而且每个子类下相似的页面极少。如果对于每个子类都手写解析代码，通常较为简单的页面也需要百行左右的Java代码，来完成返回结果的JSON对象组织、根据xpath提取页面相应位置的内容等工作，如此一来穷举覆盖到所有子类需要的代价过大。如何减少每个子类的解析代码工作量，以尽可能低的代价覆盖多样化的页面结构是相当困难的。

为了尽可能降低模板覆盖Web页面子类所需的工作量，降低模板编写难度，提升模板适用性，本申请提出了基于原语的模板自定义方法，设计并实现了相关工具。通过该方法，本申请通过对大量Web页面解析代码的观察分析与总结，设计了一套简易完善的原语，以BNF范式的形式定义了相应的语法规则，并且通过词法分析和语法分析两步完成了原语定义的模板到相应模板代码的转换，使用户在发现现有模板不足时，可以较快添加新的模板加入模板库，扩充模板能力。

针对上述第一方面目标数据定位和第三方面模板选择匹配，可以采取已有技术实现，本申请只对第二方面模板解析的过程进行改进，下面将介绍改进后的模板定义的方法。

图1是本申请一实施例示出的一种服务接口原语定义方法的流程图。参照图1，本申请的服务接口原语定义方法可以包括如下步骤：

步骤S11：根据待提取数据的Web页面的特征，按照模板原语编写数据提取模板；

步骤S12：对所述数据提取模板进行词法分析，获得词法单元；

步骤S13：根据所述词法单元，对所述数据提取模板进行语法分析，获得抽象语法树；

步骤S14：根据所述抽象语法树，生成所述数据提取模板的以中间形式表示的XML文件；

步骤S15：根据所述模板原语对所述XML文件进行语义检查，完成所述数据提取模板的定义。

图2是本申请一实施例示出的模板规则框架的架构图。如图2所示，本申请设计了面向动态Web页面数据提取的模板规则框架，将从Web应用的表现层(即页面)入手，通过为相似的Web页面提供数据提取模板，来辅助用户实现动态Web页面的数据提取和开放。本申请的模板定义方法的执行主体可以是：数据融合开放平台，其中，由于Web页面目标结构的多样化，其相互之间差异较大，为辅助用户高效地针对每一种Web页面给出数据提取模板，本申请针对Web页面的数据结构特征设计了一套定义模板的原语，并针对数据融合开放平台实现了相关的原语解析工具。

对于使用本申请定义的原语语言编写的数据提取模板，原语解析工具的功能就是进行编译前端的工作，进而将原语语言解析生成语法分析树，并以XML的中间形式保存到模板库中，以便后续选择匹配模板时使用。

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

在图3所示的步骤6中，如果用户对选择的模板生成的数据提取结果满意，则本次数据提取完成。如果现有的选择模板结果无法满足用户的需求，那么用户可以考虑添加新的模板到模板库中，即使用本申请定义的模板原语，根据需求页面的特征，编写新的数据提取模板，解决用户自身需求的同时进一步丰富模板库。

在图3所示的步骤7中，在用户用原语定义了新的模板后，需要对其进行解析，也就是编译器前端的一系列工作，通过词法分析、语法分析、语义分析等步骤，将原语代码转化成抽象语法树结构，并根据抽象语法树结构生成模板的中间形式，将其保存到模板库中，以便后续使用。

通过本申请的服务接口原语定义方法，首先根据待提取数据的Web页面的特征，按照模板原语编写数据提取模板。接着对数据提取模板进行词法分析，获得词法单元。再根据词法单元，对数据提取模板进行语法分析，获得抽象语法树；然后根据抽象语法树，生成数据提取模板的以中间形式表示的XML文件；最后根据模板原语对XML文件进行语义检查，完成数据提取模板的定义。通过该方法，可以解决在提取动态Web页面的数据时Web页面相互之间差异较大而导致的模板定义困难的问题，有效降低了模板编写的难度，提升了模板的适用性，为动态Web页面的数据的提取开放提供了技术支持，提升了动态Web页面的数据的提取开放的效率。

结合以上实施例，在一种实施方式中，本申请还提供了一种按照模板原语编写数据提取模板的方法。具体地，上述步骤S11可以包括：

通过Template语句定义数据提取模板的JSON根节点；

通过add Output语句在所述JSON根节点下添加JSON节点；

通过add语句在Output下添加NameNode、ObjectNode、DOMNodeList以及DOMNode标记，以指定所述JSON节点的key值和value值；

通过set或add语句为所述标记赋予属性值，以确定对应的值所在的位置和优先顺序，其中，在所述JSON节点的value值是对象或列表时，在相应的ObjectNode或DOMNodeList下添加Output标记以表示下一层的JSON节点。

在本申请中，模板数据定位阶段可以根据用户指定的接口信息，给出一个目标请求，以及根据该请求的返回结果格式给出目标数据在其中的位置。需要注意的是，对于定位请求的返回结果为JSON和XML格式的情况，由于一方面是其本身结构比较规整，另一方面是在上述过程中已经得到了包含所有必要信息的结果，只是可能存在部分冗余，因而并非本申请讨论的重点。在此特别说明，本申请提出的模板定义方法针对结构更加不规整，内容更加冗余的HTML格式的返回结果。

在目标请求的返回结果为HTML格式的情况下，经过目标数据的定位，可以得到目标请求的相关信息，包括URL、参数、返回结果等，以及用户指定的数据所在的DOM块根节点的xpath路径。但定位到的DOM块内除了用户指定的数据外还包括很多其他信息，且DOM块结构对人并不友好，与数据融合开放平台要求的JSON格式返回结果不符，因而此处需要一种方法将目标数据提取出来，并转换成JSON格式。

在数据融合开放平台原有的实现过程中，是根据模板类型以及用户额外给出的字段名和字段xpath等信息，完成目标数据的提取转换的。但如前文所述，由于数据依赖的结构信息复杂多变，原有的少量粗糙的模板类型在很多情况下提取不出预期的结果，导致目标数据的提取转换失效。在本申请的模板规则框架下，为达到提高效率和降低用户的工作量的目的，不要求用户给出额外信息，因此就需要其他方式来解决该数据提取转换问题。

在原有方法中，当数据提取转化失败时，需要用户介入，对请求序列进行观察，确定目标数据的位置，然后编写Java代码完成对目标数据的提取和转换。但是这种方法存在较多问题：

(1)代价高，用户需要编写Java代码来完成数据的提取转化；(2)可复用性差，由于编写的代码通常是针对当前页面的数据提取的，因此通常无法适用于其他页面；(3)代码重复性高，Java代码的核心通常都是一系列根据xpath从HTML中提取内容，然后组成JSON格式返回，只是提取的xpath路径和返回的格式有所不同。

考虑到原有方法的问题，本申请对数据提取过程中编写的Java代码进行了抽象，结合数据提取转换过程中真正需要完成的任务，设计了一种模板原语，用户用模板原语编写源程序来指明目标数据如何提取转化。由于模板原语是对原有方法中Java代码的抽象，因此从工作量上看，可以降低用户编写代码的代价，避免重复代码的编写，其次，通过对模板的建库保存以及自动适配，可以大幅度提高模板的可复用性。

在设计模板原语时，具体地，由于是对Java代码的抽象，因此可以考虑一段数据提取转化的Java代码具体完成的工作，其核心是用HTML返回结果中的部分内容拼接成一个JSON。如此，可以采用如下思想：用原语描述JSON的层级结构，并对每一个JSON中的节点，用原语描述其key与value分别来自HTML返回结果中的哪一部分，即xpath路径是什么。如此，可以避免xpath提取、判断、JSON结果拼接的重复代码，降低代码量，且通过为xpath路径的选取给出备选方案与优先顺序，可以令一个模板同时适配多种存在微小结构差异的页面，从而提高模板的可复用性。

进一步细化上述原语设计方案，其核心步骤如下：

步骤1：首先需要一个类似Java代码Main函数的模板入口标志语句，记为Template，同时也意味着JSON结构的根节点。

步骤2：其次需要一个表示JSON节点的标记，记为Output，意味着在当前位置有一个JSON节点。

步骤3：同时需要一个表示JSON节点的key来自于HTML中哪个位置的标记，记为NameNode。

步骤4：需要有表示JSON节点的value的标记，JSON节点的value可以是对象、数组或值，分别用ObjectNode，DOMNodeList，DOMNode表示。其中DOMNode需要指明该值来自HTML中的哪个位置。

为了进一步提升可复用性，降低编写复杂度，可以引入类似“宏”“类”的概念，即可以将一段编写好的、对JSON节点的定义原语保存为一个类，在模板中定义Output时可以声明其来自某个类，则将保存的类的定义加载到当前Output中。

步骤5：需要一个表示类的定义的语句，记为Class，类的定义应该在模板入口语句外，特别的，为简便起见要求其必须在模板定义之前。

步骤6：为了记录JSON节点的key、value是来自HTML中的哪个xpath路径，以及可能的xpath路径优先级等信息，标记需要有属性列表。

步骤7：为了将标记之间的父子结构表示出来，用add语句表示在父节点下加入当前节点。

步骤8：为了可以在定义语句之外修改属性的值，用set语句表示修改当前节点的某个属性值。

步骤9：如果有嵌套结构，即某个JSON节点的value是对象或者列表，则在相应的ObjectNode或DOMNodeList下面添加Output标记表示下一层的JSON节点。

整理上述步骤1-步骤9，可以总结出用原语编写的模板的过程：首先必须有一个Template语句定义模板入口即JSON根节点；然后用add Output语句在根节点下加入JSON节点；在Output下用add语句添加NameNode、ObjectNode、DOMNodeList以及DOMNode标记来指定该JSON节点的key和value；用set或add语句给标记赋予属性值来确定对应的值来自HTML中的哪个位置以及优先顺序等信息；如果有嵌套结构，即某个JSON节点的value是对象或者列表，则在相应的ObjectNode或DOMNodeList下面添加Output标记表示下一层的JSON节点。总体来看，可用的标记包括Output、NameNode、ObjectNode、DOMNodeList以及DOMNode五种，每种都有相应的含义以及可选属性值等，因此这五种标记即是模板原语的基本类型，在模板原语中可以通过定义、组合这五种基本类型的标记来描述数据提取转化方法。

对上述描述性语言进行形式化，可以得到如下表1所示的四种模板原语的语句，模板原语的每一行，都必须是其中一种语句的格式。

表1

语句操作字	语句格式及含义
		Class	定义类，语句格式为Class类名
Tamplate	定义模板，语句格式为Template模板名
		add	添加标记，语句格式为add基本类型(属性名＝属性值,…)
set	修改属性值，语句格式为set属性名＝属性值

表2中对五种基本类型的含义以及相应的可出现位置进行了说明，例如Output节点由于表示的是JSON节点，因此只能出现在根节点(Template)，JSON对象(ObjectNode)以及JSON数组(DOMNodeList)下，不能出现在JSON节点(Output)以及JSON值(DOMNode)下，需要注意的是，在同一个Output节点下只能出现ObjectNode、DOMNode、DOMNodeList中的一种。

表2

表3中对标记的可用属性值进行了简要的说明，需要注意的是，按表1中对语句的定义，模板原语中对属性值进行赋值的方法包括两种：add语句添加时进行赋值、用set语句进行赋值，如果出现对同一属性多次赋值的冲突，以当前set语句>当前add语句>引用的Class中的set语句的优先级进行解决。

表3

另外需要说明的是，为了便于用户理解、学习、修改原语定义的模板，在模板原语中加入了单行注释的概念，即以\\开头的行为注释行，解析时忽略即可。同时模板原语中每条语句都需要有明确的层级关系，即当前的add语句是在哪一条语句定义的标记之下进行添加的，为了便于用户使用，采用类似Python的缩进方式来表示层级关系，并且要求Class和Template的定义语句缩进必须为0。

经过上面的描述后，接下来将会按照词法分析、语法分析、语义分析的三步骤，根据本申请的模板原语设计，分别给出每一步的设计，进而完成编译前端的主要工作。

结合以上实施例，在一种实施方式中，本申请还提供了一种对数据提取模板进行词法分析的方法。具体地，上述步骤S12可以包括：

获得所述数据提取模板的源程序的输入字符；

识别所述输入字符中的词素，所述词素包括：关键字、类名、模板名、属性值、表示语句结构的符号以及表示层级关系的符号；

逐个匹配所述词素的正则表达式，在匹配成功时获得相应的词法单元。

在本申请中，在编译过程中，词法分析的主要任务是读入源程序的输入字符，将他们组织成有意义的词素的序列，因此在进行词法分析时首先需要确定用模板原语编写的源程序可能包含哪些有意义的词素。

首先所有关键字都是有意义的词素，包括类的定义Class、模板的定义Template、add、set以及所有基本类型和所有属性名。除此之外，合法的类名、模板名、属性值也应该被识别为相应的词素，并将其值记录在词法单元<token-name，attribute-value>的第二个分量上传给下一个阶段。最后剩下的就是括号、逗号等表示语句结构的符号应该被识别为词素，以及表示层级关系的符号应该被识别为词素。

接下来分别介绍对上述词素的识别过程：

对关键字进行识别时，匹配当前字符是否和关键字完全一致即可。

对合法的类名、模板名进行识别时，由于类名和模板名只是一种类似Java变量标识符的名字表示，只需避免重复保证唯一，同时方便后续保存类和保存模板时作为索引key即可。因此可参考Java变量名规则进行化简：由英文字母、下划线以及数字组成，且第一个字符不能是数字。

对合法的属性值进行识别时，由于属性值，尤其是xpath属性的属性值可能包含多种可能的字符，难以限定，因此将属性值写成类似字符串常量的方式，即用双引号引起来，双引号内部想要使用双引号则用转义符来完成，同时为防止后续解析出现问题，禁止使用部分特殊符号如\f等。

对括号、逗号等符号进行识别时，与对关键字的识别同理。

对层级关系符号进行识别时需要进一步考虑，层级关系用缩进来表示，但是在上下文无关文法的框架下是无法正确识别并处理缩进的，因此需要进行一轮预处理，即在词法分析之前，先扫描整个模板原语的源程序，将除注释外的每一次向内缩进都转化为一个{，每一次向外缩进都转化为一个}，如此对层级关系的识别就变成了对{}的识别，和关键字识别同理。

其中，缩进转化为{}的算法核心思想是：用一个栈维护到当前行为止，所有出现过的层级关系的缩进值，如果当前行和当前层级关系的缩进相同则表示本行未发生层级关系变化，不需要操作。如果当前行的缩进比当前层级关系的缩进大，表示从本行开始进入了下一层级，在行首加一个{。如果当前行的缩进比当前层级关系的缩进小，表示从本行开始结束了当前层级，从栈中找到本行返回了哪一层级，并每返回一层加一个}到行尾。

在进行词法分析时，通常还可以完成一些识别词素之外的其他任务，主要是过滤掉源程序的注释和空白、将编译器生成的错误信息与源程序的位置联系起来，即记录每个词素所在的行号。对于过滤注释和空白，通常的方法是将过滤和空白也看成一种特殊的空白词素进行正确识别，只是这种空白词素不会给出词法单元到语法分析部分。对于词素所在行号的记录，通常是用一个全局变量记录扫描到现在为止遇到换行符的次数，后续实现中本申请所用的词法分析器生成工具即有提供行号记录的功能，因此此处不再赘述。

在本申请中，正则表达式是一种很方便地描述词素模式的方法，将上文描述的对每种词素解析与生成词法单元的思路用正则表达式的形式描述出来即得到表4，其中词法单元的名字全部大写是一种惯例，词法单元名字为“无”意味着该词素是前文所说的空白词素，即不会给出词法单元。因而词法分析的过程可以是：读入源程序，逐个匹配词素的正则表达式，匹配成功了则获得相应的词法单元，如果所有正则表达式的匹配都失败，则报错。

表4

结合以上实施例，在一种实施方式中，本申请还提供了一种对数据提取模板进行语法分析的方法。具体地，在对数据提取模板进行解析操作时，上述步骤S13可以包括：

逐个分析所述词法单元；

在出现某一个产生式体时，将其规约为产生式头，并与此同时构建抽象语法树的一个节点，表示当次推导所使用的产生式；

重复规约过程直到整个串被规约成开始符号，以构建所述抽象语法树，所述开始符号对应所述JSON根节点。

在本申请中，在编译过程中，语法分析的作用是使用词法分析后生成的词法单元的第一个分量(终结符号)，来尝试构建一个抽象语法树，给出词法分析产生的词法单元序列的语法结构。而BNF范式(上下文无关文法)是一种常用的描述语言语法规则，也即语法分析行为模式的方法。

接下来对上文用自然语言描述的模板原语语法进行分析，给出其上下文无关文法形式的定义：

首先需要一个开始符号，表示所有合法模板原语的集合。根据上文描述，一个模板原语必须有一个Template语句表示入口，另外在Template语句之前还可以定义若干个类。

根据Class语句的格式，一个类的定义一定是形如“Class类名换行缩进一系列add和set语句换行缩回”这样的一系列语句。

根据Template语句的格式，一个模板的定义一定是形如“Template模板名换行缩进一系列add和set语句换行缩回”这样的一系列语句。

根据set语句和add语句的定义，可以得到其各自应该遵循的格式，需要注意的是，set语句是修改属性值，所以一定不会有基于set语句的下一个层级的语句，而add语句是声明标记，所以可以有基于add语句的下一个层级的语句，用来描述该语句所声明的标记的属性和下一层级标记等信息。

根据上述分析结果，进行整理以及形式化可以得到如表5所示的上下文无关文法定义，其中粗体表示终结符号也即词法单元名字(注意()＝,四种符号都是终结符号)，非粗体表示非终结符号，第一个产生式的产生式头即definition为开始符号，∈表示空产生式体，即该产生式头可以推导出空串。另外为了辅助理解文法的含义，在表6中对文法中出现的非终结符号的含义进行了简略说明。

表5

表6

非终结符号	说明
		definition	开始符号
class_defs	若干个(可以为0)类定义
		class_def	一个类的定义
template_def	一个模板的定义
		stmts	若干条(可以为0)语句
stmt	一条语句
		set_stmt	一条set语句
add_stmt	一条add语句
		opt_stmts	可能存在的一系列下一层级语句
attribute_list	若干个(至少为1)属性赋值列表
		attribute	一个属性的赋值

在有了上下文无关文法的定义后，语法分析就有了依据，按照本申请所使用的从底向上分析方法，核心思想是：依次分析词法分析后获得的词法单元(终结符号)，当发现出现某一个产生式体时，将其规约为产生式头，并与此同时构建抽象语法树的一个节点，表示这一次推导所使用的产生式，重复这一规约过程直到整个串被规约成开始符号为止，开始符号即对应根节点，抽象语法树构建完毕。如果最终未能规约成开始符号，则说明存在语法错误。

结合以上实施例，在一种实施方式中，本申请还提供了一种生成数据提取模板的以中间形式表示的XML文件的方法。具体地，上述步骤S14可以包括：

在构建所述抽象语法树的节点时，按照规约语句的类型生成必要XML节点或者修改XML节点的属性值；

在最终规约到开始符号时构建XML文件的JSON根节点，以生成所述数据提取模板的XML文件。

在本申请中，通常来说，在构建出抽象语法树后，或者在构建抽象语法树的同时，会有一套标准化的方法生成三地址码，编译的后续步骤都是基于三地址码进行。但是本申请中定义的模板原语并不需要像普通编程语言通过编译后端生成可执行程序，而是能通过原语定义的模板来确定数据的提取转化规则即可。因此本申请在进行语法分析时，需要生成的中间形式也不必是三地址码或者抽象语法树这种不太具体、解析困难的形式，而是一种能记录表示原语所含原始信息的、易于解析的形式。观察本文所定义的原语，其实是在Template语句这一入口下，用add语句逐个添加下一层级的结构，并与此同时用set语句与add语句给每个标记赋予属性值，因此本文生成一个XML格式的中间形式是一个更好的选择，XML可以保留原语定义时的层级结构，并且每个节点可以拥有属性值，而且XML形式作为一种比较规范的形式，也便于后续的解析。

本申请生成的XML的思路如下：根节点下挂着若干个tag为Class和一个tag为Template的节点，每次遇到add语句则在当前节点下生成新的节点，然后新节点的tag为五种基本类型之一，每次遇到set语句则为当前节点赋予属性值。遵循这一思路，在从底向上分析中发生规约的时候，也即在构建抽象语法树节点的同时，按照规约语句的类型生成必要的XML节点或者修改XML节点属性值，并在最终规约到开始符号时构建出XML文件的根节点，即可在语法分析过程中完成XML格式中间形式的生成，最后在整个编译器前端过程结束，确定不存在语法错误等问题后，将定义的模板保存到相应的模板库，定义的类保存到类库中。

结合以上实施例，在一种实施方式中，本申请还提供了一种对数据提取模板的XML文件进行语义检查的方法。具体地，上述步骤S15可以包括：

根据所述模板原语的语义，检查所述数据提取模板的命名和类的命名是否存在重复现象、引用的目标类在类库中是否存在、是否存在循环引用现象、各属性的值是否合法、层级关系是否合法、必要属性是否定义、是否定义了非法属性以及是否符合特殊规则。

在本申请中，用模板原语编写的源程序在经过词法分析与语法分析后，已经转换成了一个XML格式的中间形式表示，这个XML文件成功保留了源程序中的所有信息并且足够简洁明了。但是观察前文所述的词素模式和上下文无关文法，发现符合语法的源程序并不一定符合对模板原语的描述，例如在Output下用add语句添加Output是符合语法的，但是不符合表2中的规定。由于程序语言除了语法还有语义，而且很多语义错误都不是上下文无关文法能定义、语法分析阶段能检测出来的，因而还需要进行语义分析，根据模板原语的语义对中间形式进行检查。

需要注意的是，由于本申请所设计的原语在经过这一步后就完成了到中间形式生成为止即编译器前端的所有工作，后续也不存在三地址码生成等，因此到XML中间形式保存为止的所有检查都在语义分析这一步中进行，包括命名是否重复，特殊规则是否符合，类型检查相关的等等。具体主要包括以下几个方面：

模板和类的命名是否重复：按照合法类名、模板名的定义，其不仅仅要符合词法分析中给出的正则表达式，而且要不重名，因为该名字就是类和模板的唯一标识。即要检查类库中是否有与当前类同名的类，然后检查当前模板所在大类下是否有与当前模板同名的模板。

引用的类是否存在：按照属性class的定义，Output可以根据class属性的值来引用某一个类库中的类，所以这里需要在类库中检查目标类是否存在。

是否存在循环引用：因为Output是可以嵌套的，所以类中的可能有Output，并且该Output引用了其他类，这样就可能会导致“循环引用”的问题出现，即类似类A下的某个Output引用了类B，类B下的某个Output又引用了类A，由于该问题是可以通过静态检测出来的，所以在这里进行检查。

各属性的值是否合法：例如表示所属模板大类的rootType属性值必须是几个指定大类之一、表示优先级的priority属性值必须是规定内的整数值且不能与同级节点重复等等。

必要属性是否定义：例如DOMNode必须定义priority以指示优先级，Template必须定义rootType以确定其所属大类等等。

是否定义了非法属性：如表3所示，所有属性都有可以出现的位置，检查是否有不该出现的属性，例如Output设置了属性priority这样的情况。

层级关系是否合法：如表2中所规定，检查是否存在Output下一层级存在Output这种类似的非法层级关系；同一个Output下是否只有ObjectNode、DOMNode、DOMNodeList其中一种，即一个JSON节点的value不可以即可能是JSON对象也可能是JSON数组等等。

特殊情况的检查：为防止解析时出现冲突，引用了class的Output下不可以再使用add语句增加下一层级节点，最多使用set语句覆盖或增加属性值；由于duplicate属性的定义和DOMNodeList的xpath属性定义存在冲突，DOMNodeList不可以出现在含有duplicate属性的Output节点下；duplicate属性为1的Output节点必须有name属性，否则都使用DefaultName会导致JSON的key重名；定义了notObjectItem属性的DOMNodeList之下是否只有一个Output，且该Output下是DOMNode。检查中间结果是否符合这些特殊要求。

结合以上实施例，在一种实施方式中，本申请还提供了一种检查是否存在循环引用的方法。具体地，可以包括：

维护一个当前已引用类的列表，遍历某个类的XML中间形式；

如果某个节点引用了其它类，则将其它类添加到当前已引用类的列表中，并递归调用检测其它类是否存在循环引用。

具体地，在检查是否存在循环引用现象时，当某个类A被定义，已通过其他检测，准备添加其XML中间形式到类库中时进行循环引用检测，维护一个当前已引用类的列表，遍历该类A的XML中间形式，如果某个节点引用了类B，则将类B加到当前已引用类列表中，并递归调用检测类B是否存在循环引用。

结合以上实施例，在一种实施方式中，对所述数据提取模板进行词法分析，获得词法单元，包括：

通过Flex词法分析器，对所述数据提取模板进行词法分析，获得词法单元；

通过Yacc的语法分析器，根据所述词法单元，对所述数据提取模板进行语法分析，获得抽象语法树；

根据所述模板原语对所述XML文件进行语义检查，包括：

通过开源工具dom4j，根据所述模板原语对所述XML文件进行语义检查。

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

数据融合开放平台又细分为生成、管理、运行三个子平台，其中本文所实现的框架的输入信息都是来自用户在生成平台上访问目标页面和指定接口信息的过程中所提取的。为便于对接数据开放融合，本申请实现的系统主要是使用的Java语言，并在具体的实现过程中，使用Flex搭建词法分析器、Yacc搭建语法分析器。其中用Flex+Yacc实现的词法语法分析器，受限于这两个工具本身指定了语言，因此使用C语言实现，并通过编写脚本调用与前后步骤联系起来。

在本申请中，编写原语的方式是直接写到一个文档中，然后执行编译脚本(shell脚本)。编译脚本会首先对源代码进行预处理，然后调用词法语法分析器(C语言编写的可执行程序)，将原语文档编译为一个XML中间形式，然后调用语义分析器(Java语言编写的可执行程序)检测是否存在语义错误，若不存在语义错误则将该模板保存到模板库中。如果在编译过程中出现错误，例如语法错误、语义错误等，则脚本执行失败，将相应错误信息返回。

在本申请中，词法分析器基于Flex实现，Flex是一个快速词法分析生成器，它支持使用正则表达式来描述各个词法单元的模式，由此给出一个词法分析器的规约。具体来说，按照Flex规定的方式编写一个描述词法分析器的输入文件*.l，Flex会将输入的模式转换成一个状态转换图，并编译生成相应的C语言源码文件(默认命名lex.yy.c)，然后使用C编译器即可将源码文件编译为可执行程序，这个可执行程序就是一个读取输入字符流并生成词法单元流的可运行的词法分析器。

其中，词法单元<token-name,attribute-value>包括两个部分，分别是词法单元类型标识和该词法单元附加的属性。在Flex生成的词法分析器中，每次调用词法分析器，都会从输入流的当前位置解析出一个词法单元，并返回一个整数值表示该词法单元类型，同时将属性值保存在一个union类型的yylval变量中，通过与语法分析器共享该yylval变量，来实现词法单元两个部分内容的返回。这里需要说明的是，该union类型的内容是可以自定义的，而且该yylval变量不只表示每一个词法单元即终结符号的属性，同时在语法分析器中每个非终结符号的属性也用该变量表示，事实上该类型内容的自定义是在语法分析器生成工具Yacc中进行的，只是在词法分析器中需要根据该union类型的定义来完成词法单元属性的生成，因此提前在这里进行介绍。

词法单元的属性只需要一个字符串类型的字段即可，但是考虑到后续语法分析器部分需要基于这个yylval变量生成XML中间形式，因此额外添加一个表示当前符号对应的XML节点的字段，这里说明一下，本申请使用C语言生成XML文件时使用的是libxml2库，xmlNodePtr是libxml2库中表示XML节点指针的类型。具体的定义如表7所示，即该union类型必须是一个struct，而且该struct内有两个字段，其类型分别是字符串和XML节点指针。

表7

在有了词法单元属性的定义，以及词素模式，接下来就可以开始编写描述词法分析器的输入文件primitive.l。该文件分为三个部分：声明部分、转换规则、辅助函数。

声明部分可以包括以下内容：1)一段C语言声明，可以定义变量常量、声明函数、使用include插入头文件等，这一段C语言声明会被直接放入编译后的C源码文件中，这里主要是声明了两个辅助函数saveText和saveValueText用来保存识别字符内容到yylval中，并且加入了一些必要的头文件。2)一系列可选的选项options声明，本申请使用了两个：nodefault表示如果扫描器不能匹配到任何合法词法单元的输入，要求其立刻终止并返回错误；yylineno表示要求扫描器自动记录当前行号到yylineno变量中。3)一系列正则定义，用于辅助简化词素模式的正则表达式书写，本文定义的正则定义如表8所示，需要注意的是，在Flex的正则定义中，双引号表示匹配双引号中的内容自身，因此对于正则表达式中出现的双引号进行了转义。

表8

转换规则部分就是一系列符合Flex语法定义的转换规则，每个转换规则具有如下形式：模式{动作}，其中模式是一个正则表达式，可以使用声明部分中给出的正则定义，动作部分是C代码片段，用于给属性yylval赋值，并返回一个整数值表示的词法单元类型。本文定义的转换规则如表9所示，需要注意的是：按照Flex转换规则书写语法，优先匹配写在上面的模式，例如关键字模式的要优于类名模式的匹配、即add应该被识别为关键字而非类名，因此关键字的模式要写在类名上面；模式中被双引号引起来的表示一个匹配该双引号内内容的正则表达式，例如"{"表示匹配一个{字符；模式中被花括号引起来的表示引用声明部分的该正则定义。另外，动作中返回语句return返回的标识符对应的整数值是在Yacc中定义的，这里认为其为不重复整数值即可；yytext为Flex保存当前识别到的词法单元对应的源程序字符串，yyleng表示该字符串长度，例如识别到一个ADD词法单元时，yytext中应该就保存了add，yyleng为3；YY_FATAL_ERROR为一个Flex提供的报错用的宏；saveText和saveValueText是在Flex“声明部分”声明的C语言函数，实现在Flex“辅助函数”部分，saveText功能是将当前识别的源程序字符串保存到yylval的content字段，saveValueText额外去掉了字符串的首尾引号。动作一列中的内容为实际动作中最主要的代码部分，除此之外还有带行号的日志打印等其他操作。

表9

辅助函数部分包含了各个动作所需要使用的所有辅助函数，此外为了保证Flex编译的程序能够正常运行，需要在此处实现一个yywrap函数，其作用是告知Flex扫描完当前文件后该怎么做。本文中yywrap函数直接返回1即可，表示扫描完当前文件后已经没有其他输入文件了，可以直接结束，因为本文每个模板原语都是定义在一个文件内的。另外本文辅助函数部分还包括声明部分定义的两个辅助函数saveText和saveValueText的实现，基于yytext保存的当前识别字符串和yyleng保存的当前识别字符串长度，将需要的内容保存到yylval中，以saveValueText为例，实现如表10所示。

表10

在定义好了词法分析器的输入文件primitive.l后，使用Flex命令flex--header-file＝lex.yy.h primitive.l即可将primitive.l编译为lex.yy.c并生成头文件lex.yy.h，将这个C源程序文件和下一节Yacc生成的C源程序文件一起编译即可生成词法语法分析器。

本文的语法分析器基于Yacc实现，Yacc是一个经典的LALR语法分析器生成工具，它支持使用BNF范式来描述程序语言的语法，结合语法规约的语义动作即处理代码，生成语法分析器。具体来说使用方式类似Flex，即按照Yacc规定的方式编写一个描述语法分析器的输入文件*.y，Yacc会采用LALR(1)语法分析方法为其生成C语言源码文件(默认命名y.tab.c)。需要注意的是，Yacc生成的语法分析器必须要和词法分析器配合，所以通常Yacc会和Flex一起使用，即将Yacc生成的C语言源码文件与Flex生成的C语言源码文件一起编译为可执行程序，该程序就可以完成词法分析与语法分析的工作。

这里需要介绍一下语义动作的概念，所谓语义动作就是指，为每个产生式绑定一段代码，当语法分析器使用该产生式进行规约时，执行这段代码，以完成日志打印、信息统计、代码中间形式生成等任务，本申请所定义的语义动作的主要任务就是生成XML中间形式。LALR这种自底向上分析的方法，构建抽象语法树、即规约的过程是从底向上的，就是说先构建出抽象语法树中的子节点，再构建其父节点，例如对于推导过程a→bC→DC(小写字母表示非终结符号，大写字母表示终结符号)其分析过程是先使用产生式c→D进行规约，再使用a→bC进行规约，对应于XML中间形式的生成的过程，就应该是类似下面这样：先根据终结符号D的信息构建b对应的XML节点，然后根据终结符号C的信息构建a对应的XML节点，并且将b的XML节点添加到a的子节点中。即XML节点的生成与组织也是自底向上的，先构建叶节点，再逐渐拼接出父节点。

下面描述语法分析器的Yacc的输入文件primitive.y。该文件类似Flex的输入文件，也包括三个部分：声明，翻译规则，辅助性C语言例程。

声明部分可以包括以下内容：1)一段C语言声明，类似Flex，可以定义变量常量、声明函数、使用include插入头文件等，这一段C语言声明会被直接放入编译后的C源码文件中，本文这里主要是声明了一个辅助函数copyAllPropTo用来将某个XML节点的属性复制到另一个XML节点中、声明了一个全局变量rootXmlNode用来保存生成的XML的根节点，并且加入了一些必要的头文件。2)一系列可选的Yacc规定下的声明，本文使用了两种：使用％union定义yylval变量的内容，即表7左列所示的部分就是在这里定义的；使用％token定义终结符号即词法单元类型，也就是上文所说的Flex“动作中返回语句return返回的标识符对应的整数值是在Yacc中定义的”就是在这里定义的。那么定义的终结符号就是出现在表9的中间列中return语句返回的十种大写字母标识：CLASS、TEMPLATE、SET、ADD、TYPE、ATTRIBUTE_NAME、ATTRIBUTE_VALUE、NAME、INDENT、DEDENT，这里需要注意的是，Yacc会为在这里用％token定义的标识符自动分配一个大于256的整数值，例如#define CLASS 257，这里大于256的原因是为了给标点符号的终结符号类型保留其ASCII码值作为其整数值的空间，例如表9中对于operator即＝(),四种符号是直接返回了其ASCII码值的，为了不与这里定义的其他终结符号整数值重复，因此除标点符号外自定义的终结符号的整数值都是从257开始的。

翻译规则部分包括若干条翻译规则，每个规则由一个文法产生式和一个相关联的语义动作组成，语义动作是一系列C语言语句，完成XML中间形式的生成。在翻译规则的书写中，Yacc做了如下规定：在声明部分定义的终结符号在这里作为终结符号使用，即产生式体出现CLASS意味着这里词法分析器应该是返回了一个类型为CLASS的词法单元；用单引号引起来的单个字符是终结符号，并且其对应的整数值为该单个字符的ASCII码值，即产生式体出现'＝'意味着这里词法分析器发现了一个＝并且直接返回了＝的ASCII码值；除上述两种情况外，其他的字母数字下划线组成的标识都是非终结符号，例如class_defs、stmts等；产生式体什么都不写意味着空产生式体；语义动作中可以使用$i表示和产生式体中第i个文法符号(终结符号或非终结符号)关联的属性值即yylval，使用$$表示和产生式头关键的属性值，例如attribute→ATTRIBUTE_NAME'＝'ATTRIBUTE_VALUE这一产生式的语义动作中，可以使用$1.token_p.content获取Flex为这一ATTRIBUTE_NAME词法单元的yylval赋予的content值即该属性名字符串。本文定义的翻译规则如表11所示，其中BAD_CAST是一个强制类型转换宏，为了将字符串转为libxml2可接受的输入参数。

表11

辅助性C语言例程包含了各个翻译规则所需要适用的所有辅助函数，此外为了保证Yacc编译的程序能够在出现语法错误时给出较详细的报错，需要在此处实现一个yyerror函数，根据yytext、yylineno以及错误信息，打印出具体在哪一行的哪一个字符处发现了语法错误。此处实现的辅助函数就是上文声明部分定义的void copyAllPropTo(xmlNodePtr source,xmlNodePtr target)该函数，将XML节点source的属性值复制到XML节点target中，需要注意的是，为了保证属性的重名覆盖顺序与本文定义的相同，复制应该以target为准，即如果target中已经存在这一属性了，就不进行复制覆盖。最后就是在这里需要定义词法语法分析器的入口main函数，在main函数中调用yyparse开始语法分析，在其中会调用Flex的yylex函数进行词法分析，并根据yylex返回的词法单元序列进行语法分析，语法分析结束即yyparse函数返回后，将保存在全局变量rootXmlNode中的XML中间形式根节点写入结果文件中，整个词法语法分析过程就结束了。

对于原语，经过词法分析与语法分析后，被转换成如表12所示的XML中间形式。

表12

在经过词法分析和语法分析后，已经生成了原语的XML中间形式，语义分析需要做的就是进行一系列的检测，以确保不存在语义错误。需要注意的是，此步骤与Flex和Yacc的关系就已经不太紧密，所以回归Java实现，使用开源工具dom4j解析生成的XML文件。接下来给出几个具体的检测标准。

对于属性值是否合法的检测，具体如表13所示，表中扩展xpath路径是指本文为了针对某些情况(例如表格标题与内容分割)，简化模板定义的复杂度并提升模板适应性，为xpath做了一定的扩展：允许xpath使用类似[1:-1]这样的方式来选取第二个到倒数第二个作为结果，那么合法的扩展xpath路径的检测就是，用正则匹配找出扩展xpath路径中符合\[\d*:(\d*|-\d+)\]这一正则表达式的部分全部替换成[1]，得到的结果是合法xpath路径则原扩展xpath路径也合法。

表13

对于各个节点类型必要属性是否定义的检测，具体如表14所示。

表14

关于非法属性的检测依据表3即可，对于层级关系合法性的检测依赖表表2即可。对于特殊情况中“引用了class的Output下不可以再使用add语句增加下一层级节点”这一检测，对应到XML中间形式中的检测就是带有class属性的Output节点不可以有子节点。

另外需要说明的还有，根据上节定义的语法分析器，类名和模板名会作为XML节点的saveName属性保存，因此关于类名模板名重名之类问题的检测依据于这一属性的值。为了简便起见，降低类的循环引用检测、引用的类是否存在检测等步骤的复杂性，目前不允许对保存到类库中的类进行二次操作包括删除修改等，因为如果允许删除或者修改，那么可能出现类似这样的问题：一个模板在定义的时候检测其引用的类A存在，但是之后有人删除了该类，会导致下一次使用改模板进行适配的时候加载类失败。

对于表12所示的中间形式，语义分析阶段未检测到错误，因此就会将该XML中间形式中定义的模板和类分别保存到库中。

模板原语解析阶段的目的是将用户给出的、描述数据提取规则的模板原语，解析为XML中间形式并保存到模板库，以便后续适配选择使用。为此，本申请首先设计了一种模板原语，从形式化描述逐渐细化，给出其语句语法类型属性的定义，并遵循编译技术的思想，给出这种语言的词素模式的正则表达式、上下文无关文法的定义以及语义分析阶段需要检查的任务。随后，本文使用Flex基于词素模式的正则表达式实现了词法分析器，使用Yacc基于上下文无关文法的定义实现了语法分析器，并在Yacc进行从底向上的语法分析过程中，生成并组合出XML形式的中间结果，最后基于XML中间形式进行语义分析检查，并将结果保存到模板库中。

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

基于同一发明构思，本申请还提供了一种服务接口原语定义系统400。图4是本申请一实施例示出的一种服务接口原语定义系统的结构示意图。参照图4，本申请的服务接口原语定义系统400可以包括：

编写模块401，用于根据待提取数据的Web页面的特征，按照模板原语编写数据提取模板；

第一获得模块402，用于对所述数据提取模板进行词法分析，获得词法单元；

第二获得模块403，用于根据所述词法单元，对所述数据提取模板进行语法分析，获得抽象语法树；

生成模块404，用于根据所述抽象语法树，生成所述数据提取模板的以中间形式表示的XML文件；

检查模块405，用于根据所述模板原语对所述XML文件进行语义检查，完成所述数据提取模板的定义。

可选地，所述编写模块401包括：

提取模块，用于通过Template语句定义数据提取模板的JSON根节点；

第一添加模块，用于通过add Output语句在所述JSON根节点下添加JSON节点；

第二添加模块，用于通过add语句在Output下添加NameNode、ObjectNode、DOMNodeList以及DOMNode标记，以指定所述JSON节点的key值和value值；

赋值模块，用于通过set或add语句为所述标记赋予属性值，以确定对应的值所在的位置和优先顺序，其中，在所述JSON节点的value值是对象或列表时，在相应的ObjectNode或DOMNodeList下添加Output标记以表示下一层的JSON节点。

可选地，所述第一获得模块402包括：

第一获得子模块，用于获得所述数据提取模板的源程序的输入字符；

识别模块，用于识别所述输入字符中的词素，所述词素包括：关键字、类名、模板名、属性值、表示语句结构的符号以及表示层级关系的符号；

第二获得子模块，用于逐个匹配所述词素的正则表达式，在匹配成功时获得相应的词法单元。

可选地，所述第二获得模块403包括：

分析模块，用于逐个分析所述词法单元；

第一构建模块，用于在出现某一个产生式体时，将其规约为产生式头，并与此同时构建抽象语法树的一个节点，表示当次推导所使用的产生式；

第二构建模块，用于重复规约过程直到整个串被规约成开始符号，以构建所述抽象语法树，所述开始符号对应所述JSON根节点。

可选地，所述生成模块404包括：

生成子模块，用于在构建所述抽象语法树的节点时，按照规约语句的类型生成必要XML节点或者修改XML节点的属性值；

第三构建模块，用于在最终规约到开始符号时构建XML文件的JSON根节点，以生成所述数据提取模板的XML文件。

可选地，所述检查模块405包括：

第一检查子模块，用于根据所述模板原语的语义，检查所述数据提取模板的命名和类的命名是否存在重复现象、引用的目标类在类库中是否存在、是否存在循环引用现象、各属性的值是否合法、层级关系是否合法、必要属性是否定义、是否定义了非法属性以及是否符合特殊规则。

可选地，所述检查子模块还用于：维护一个当前已引用类的列表，遍历某个类的XML中间形式；如果某个节点引用了其它类，则将其它类添加到当前已引用类的列表中，并递归调用检测其它类是否存在循环引用。

可选地，所述第一获得模块402包括：

第三获得子模块，用于通过Flex词法分析器，对所述数据提取模板进行词法分析，获得词法单元；

所述第二获得模块403包括：

第四获得子模块，用于通过Yacc的语法分析器，根据所述词法单元，对所述数据提取模板进行语法分析，获得抽象语法树；

所述检查模块405包括：

第二检查子模块，用于通过开源工具dom4j，根据所述模板原语对所述XML文件进行语义检查。

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

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

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

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

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

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

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

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

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

Claims

1.一种服务接口原语定义方法，其特征在于，包括：

对所述数据提取模板进行词法分析，获得词法单元；

2.根据权利要求1所述的方法，其特征在于，根据待提取数据的Web页面的特征，按照模板原语编写数据提取模板，包括：

通过Template语句定义数据提取模板的JSON根节点；

通过add Output语句在所述JSON根节点下添加JSON节点；

3.根据权利要求2所述的方法，其特征在于，对所述数据提取模板进行词法分析，获得词法单元，包括：

获得所述数据提取模板的源程序的输入字符；

4.根据权利要求3所述的方法，其特征在于，根据所述词法单元，对所述数据提取模板进行语法分析，获得抽象语法树，包括：

逐个分析所述词法单元；

5.根据权利要求4所述的方法，其特征在于，根据所述抽象语法树，生成所述数据提取模板的以中间形式表示的XML文件，包括：

6.根据权利要求5所述的方法，其特征在于，根据所述模板原语对所述XML文件进行语义检查，包括：

7.根据权利要求6所述的方法，其特征在于，检查是否存在循环引用现象的方法可以包括：

维护一个当前已引用类的列表，遍历某个类的XML中间形式；

8.根据权利要求1所述的方法，其特征在于，对所述数据提取模板进行词法分析，获得词法单元，包括：

根据所述模板原语对所述XML文件进行语义检查，包括：

9.一种服务接口原语定义系统，其特征在于，包括：