掌桥专利:专业的专利平台
掌桥专利
首页

技术领域

本发明属于通信协议技术领域,尤其涉及一种基于通信协议通用描述的协议解码方法及装置。

背景技术

本部分的陈述仅仅是提供了与本发明相关的背景技术信息,不必然构成在先技术。

在物联网和互联网通信中,设备通信中大量使用了通信协议,有标准协议和私有协议,尤其是没有相关标准的情况下,各设备厂家大量使用了企业内部指定的私有协议。无论是标准协议还是私有协议,针对运行在这些设备上的协议解码(也称解析)都需要大量的开发维护工作。

发明人发现,现有的通信协议解码方法通常采用“硬编码”方式编写代码方式实现。针对每一种通信协议,都需要专门开发一套代码对通信协议数据进行解析,代码编写工作量大、花费时间长;由于缺陷修复或需求变化,即便协议结构一样,但是协议包含数据不一样,也要重复编写代码进行编码,导致代码冗余,维护困难,代码很难复用。

发明内容

为了解决上述背景技术中存在的技术问题,本发明提供一种基于通信协议通用描述的协议解码方法及装置,其能够满足通用性以及私有协议的定制性,能够提高系统或设备开发效率,降低工作量和成本。

为了实现上述目的,本发明采用如下技术方案:

本发明的第一个方面提供一种基于通信协议通用描述的协议解码方法。

一种基于通信协议通用描述的协议解码方法,其包括:

获取通信协议的通用描述文件,校验通用描述文件的格式,解析描述文件中的元素;

将通信协议描述文件中的协议匹配项相关元素和属性转换为通信协议匹配对象,以及将通信协议描述文件中的协议数据项相关元素和属性转换为通信协议数据对象;

通信侦听获取通信原始报文数据;

基于协议匹配项将通信原始报文数据进行协议匹配;

根据协议匹配结果,进行协议解码,输出对象实例或json格式数据;

其中,通信协议的通用描述文件将每个通信协议指令分为协议通用描述项、协议匹配项和和协议数据项进行描述;

所述协议通用描述项,用于定义协议通用描述说明;所述协议匹配项,用于定义软件系统自动化匹配协议指令的匹配条件;所述协议数据项,用于定义协议的构成元素。

作为一种实施方式,所述协议通用描述项包括协议指令的唯一ID定义、协议指令解析或编码结果存储对应类名定义、校验项定义、校验数据区定义、消息数据区长度项定义和消息数据区定义。

作为一种实施方式,所述协议匹配项包括字节条件项和比特条件项。

作为一种实施方式,所述协议数据项包括字节项、比特项、重复项、Tag项、子协议项和加密块。

作为一种实施方式,在基于协议匹配项将通信原始报文数据进行协议匹配的过程中:

协议报文数据和协议匹配对象集合作为输入项,根据协议匹配对象集合中的定义,获取指定位置的报文数据,按照类型进行转换,转换后的值与描述文件中的value值,按照描述文件中的运算符operator进行运算;

当逻辑运算结果为true时,本匹配条件满足,继续下一匹配条件验证,直到本协议指令的所有匹配条件均满足时,则视为报文数据与本协议指令匹配成功,输出协议ID。

作为一种实施方式,在基于协议匹配项将通信原始报文数据进行协议匹配的过程中:

当本协议指令单任一条件匹配失败时,则结束本协议指令匹配对象的比较匹配,进行下一协议指令描述文件的匹配对象集合的比较匹配;

当所有协议指令的匹配对象集合均匹配失败时,则表示协议报文数据与协议描述文件不匹配,记录日志,结束处理。

本发明的第二个方面提供了一种基于通信协议通用描述的协议解码装置。

一种基于通信协议通用描述的协议解码装置,其包括:

元素解析模块,其用于获取通信协议的通用描述文件,校验通用描述文件的格式,解析描述文件中的元素;

元素转换模块,其用于将通信协议描述文件中的协议匹配项相关元素和属性转换为通信协议匹配对象,以及将通信协议描述文件中的协议数据项相关元素和属性转换为通信协议数据对象;

通信侦听模块,其用于通信侦听获取通信原始报文数据;

协议匹配模块,其用于基于协议匹配项将通信原始报文数据进行协议匹配;

协议解码模块,其用于根据协议匹配结果,进行协议解码,输出对象实例或json格式数据;

其中,通信协议的通用描述文件将每个通信协议指令分为协议通用描述项、协议匹配项和和协议数据项进行描述;

所述协议通用描述项,用于定义协议通用描述说明;所述协议匹配项,用于定义软件系统自动化匹配协议指令的匹配条件;所述协议数据项,用于定义协议的构成元素。

所述协议通用描述项包括协议指令的唯一ID定义、协议指令解析或编码结果存储对应类名定义、校验项定义、校验数据区定义、消息数据区长度项定义和消息数据区定义。

本发明的第三个方面提供一种计算机可读存储介质。

在一个或多个实施例中,提供了一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现如上述基于通信协议通用描述的协议解码方法中的步骤。

本发明的第四个方面提供一种计算机设备。

一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述程序时实现如上述所述的基于通信协议通用描述的协议解码方法中的步骤。

与现有技术相比,本发明的有益效果是:

(1)本发明的通信协议通用描述方法,对通信过程使用的标准协议和私有协议提供了一种通用的标准化描述方法,描述简单,描述能力完整强大,在编码和解码程序代码实现中可以根据协议描述本身实现动态编码和解码。通用描述方法支持协议识别匹配的描述,支持按照字节和比特的协议构成数据项的定义,支持无符号数的描述,支持协议项的不同字节序,支持字符串编码格式描述,支持变长字符串,支持子协议,支持协议项多层级灵活嵌套,支持变长的重复项,尤其是应用广泛的TLV编码重复项,支持协议项是否在报文中出现的表达式描述,支持协议项数值转换的表达式,支持协议完整性校验、协议加密描述,支持解码、编码、校验、加密、解密的内置方法和自定义方法(函数)描述。

(2)基于通信协议通用描述的协议解码方法,可以实现通信协议的大多数情况下通用、动态解码,满足了通用性,又具有扩展性。方法中协议匹配支持多种产品、多种协议版本的通信协议的混合接入,可以对协议进行动态识别,快速精准匹配的协议描述文件;协议解码方法实现了绝大多数通信解码需求的覆盖,无需再次编码即可实现新协议的动态解码,即便出现了极为少见的特殊定制协议,也可以通过编写继承了基类的自定义类实现自定义解码、校验、解密等,所以具有扩展性。因此方法通过通用性、扩展性实现了协议的快速解码,具有更高的开发效率,降低了开发成本。

本发明附加方面的优点将在下面的描述中部分给出,部分将从下面的描述中变得明显,或通过本发明的实践了解到。

附图说明

构成本发明的一部分的说明书附图用来提供对本发明的进一步理解,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。

图1是本发明实施例的通信协议通用描述构成;

图2是本发明实施例的协议匹配和解码流程;

图3是本发明实施例的协议解码程序流程图;

图4(a)是本发明实施例的解码示例1;

图4(b)是本发明实施例的解码示例2。

具体实施方式

下面结合附图与实施例对本发明作进一步说明。

应该指出,以下详细说明都是例示性的,旨在对本发明提供进一步的说明。除非另有指明,本文使用的所有技术和科学术语具有与本发明所属技术领域的普通技术人员通常理解的相同含义。

需要注意的是,这里所使用的术语仅是为了描述具体实施方式,而非意图限制根据本发明的示例性实施方式。如在这里所使用的,除非上下文另外明确指出,否则单数形式也意图包括复数形式,此外,还应当理解的是,当在本说明书中使用术语“包含”和/或“包括”时,其指明存在特征、步骤、操作、器件、组件和/或它们的组合。

术语解释:

TLV编码:ASN.1是一种ISO/ITU-T标准,其中一种编码BER(Basic EncodingRules)简单好用,它使用三元组编码,它是由数据的类型Tag(T),数据的长度Length(L),数据的值Value(V)构成的一组数据报文。TLV是基于二进制编码的,将数据以(T-L-V)的形式编码为字节数组,即TLV是字节流的数据传输协议。它规定了一帧数据的首个字节或几个字节来表示数据类型,紧接着一个或几个字节表示数据长度,最后是数据的内容。

TTLV,是指Tag,Type,Length,Value,在TLV编码的基础上加入了Type,表示数据的类型,方便协议自描述。

实施例一

参照图2,本实施例提供了一种基于如上述所述的通信协议通用描述方法的协议解码方法,其包括:

步骤1:获取通信协议的通用描述文件,校验通用描述文件的格式,解析描述文件中的元素;

步骤2:将通信协议描述文件中的协议匹配项相关元素和属性转换为通信协议匹配对象,以及将通信协议描述文件中的协议数据项相关元素和属性转换为通信协议数据对象;

具体地,转换的通信协议匹配对象以及通信协议数据对象,均放入内存或缓存。

步骤3:通信侦听获取通信原始报文数据;

具体地,打开本地串口通信或网络通信侦听。

步骤4:基于协议匹配项将通信原始报文数据进行协议匹配;

在步骤4中,在基于协议匹配项将通信原始报文数据进行协议匹配的过程中:

协议报文数据和协议匹配对象集合作为输入项,根据协议匹配对象集合中的定义,获取指定位置的报文数据,按照类型进行转换,转换后的值与描述文件中的value值,按照描述文件中的运算符operator进行运算;

当逻辑运算结果为true时,本匹配条件满足,继续下一匹配条件验证,直到本协议指令的所有匹配条件均满足时,则视为报文数据与本协议指令匹配成功,输出协议ID。

在基于协议匹配项将通信原始报文数据进行协议匹配的过程中:

当本协议指令单任一条件匹配失败时,则结束本协议指令匹配对象的比较匹配,进行下一协议指令描述文件的匹配对象集合的比较匹配;

当所有协议指令的匹配对象集合均匹配失败时,则表示协议报文数据与协议描述文件不匹配,记录日志,结束处理。

步骤5:根据协议匹配结果,进行协议解码,输出对象实例或json格式数据。

参照图1,一种通信协议通用描述方法,将每个通信协议指令分为协议通用描述项、协议匹配项和和协议数据项进行描述;

其中,协议通用描述项,用于定义协议通用描述说明;

协议匹配项,用于定义软件系统自动化匹配协议指令的匹配条件;

协议数据项,用于定义协议的构成元素。

一套通信协议可以由多条指令组成。同一套协议使用相同或类似的协议帧结构,不同的协议指令的数据部分结构不同;通信协议通用描述方法对每一个协议指令进行通用描述。

协议指令由协议通用描述项集合、协议匹配项集合和协议定义项集合构成。

协议通用描述项集合包含多个协议通用描述项。协议通用描述项是协议一般描述说明项,定义了协议指令的唯一ID、协议指令解析或编码结果存储对应类名、校验项定义、校验数据区定义、消息数据区长度项定义、消息数据区定义。

协议匹配项集合中定义了软件系统自动化匹配协议指令的匹配条件,系统根据这些匹配条件进行数据报文比较匹配,全部符合时,说明匹配成功,可以用此协议指令配置文件中的协议数据项对报文进行解析。主要有字节条件项和比特条件项两种。

协议数据项集合中定义了协议的构成元素--协议数据项。协议数据项有字节项、比特项、重复项(包括TLV类重复项和其他类型重复项)、Tag项、子协议项、加密块等几种类型。

下面对上述协议项按照公共属性和私有属性进行说明。

协议项的公共属性(Attribute)说明:

length:长度,单位为Byte,只有bitDefinition定义中单位为Bit。

lengthRef:长度引用,表示长度的值引用自其他属性值。

shift:偏移量,表示在定义中的偏移量。

objectType:定义项的数值所对应的面向对象语言(如Java、C#)中的数据类型,包括:Byte、Short、Integer、Long、Float、Double、HEXSTRING(16进制字符串),当数据为复杂对象时,可以为HashMap或自定义类。

property:定义项值对应的面向对象语言中(Java、C#等)的实体对象的属性名。

propertyName:定义项值对应的面向对象语言中的实体对象的属性中文名称。

ignore:表示解析或编码时是否忽略此配置项,默认值为false,即不忽略;true表示忽略,不必解析或不必编码。

showExp:显示表达式,在报文中是否出现的逻辑表达式,true表示出现,false表示不出现。

valueExp:值表达式,属性值来自表达式或自定义方法(函数)的运算结果(要求运算前的数据类型兼容运算后结果的数据类型)。例如表达式"batteryVoltage/1000"和自定义函数"customFunction(cmd,studentsCount)"。

encoding:编码格式,Byte为String时,字符串使用的编码格式。

byteOrder:字节序,BIG_ENDIAN表示大端或LITTLE_ENDIAN表示小端。未配置的情况下,默认为大端。

协议通用描述项说明:

id元素:协议指令的唯一id,不能重复,一般以“产品(型号)-协议版本-指令-编码/解码”的约束命名。

className元素:为协议指令数据存储对应的类名,可以是自定义类或HashMap。

byteOrder元素:为协议指令多字节数值采用的字节序,BIG_ENDIAN表示大端或LITTLE_ENDIAN表示小端。

checkCodeItem元素:校验项,报文校验项(如CRC)定义。check表示是否进行报文校验,checkType为内置的校验函数名称,customFunction为用户自定义扩展的校验函数,优先级高于内置函数。Shift为偏移量,可以为0、正数或负数,负数表示从报文末尾开始偏移。

checkDataBlock元素:校验数据区定义,begin属性为校验报文内容在报文中的开始位置,end属性为结束位置;begin和end取值可以为0、正数或负数。

dataLengthItem元素:数据区长度项定义,encode表示协议编码时,是否计算数据区的长度数值;shift和length为按字节计算的偏移量和长度数值,bitShift,bitLength为按bit计算的偏移量和长度数值。

dataBlock元素:数据区定义,begin属性为校验报文内容在报文中的开始位置,end属性为结束位置;begin和end取值可以为0、正数或负数。

description元素:协议指令相关的注释说明。

协议匹配项说明:

conditionByte元素:匹配的字节条件定义,value为要比较的值,operator为运算符(默认为等号,可以为=,>,>=,<,<=,in等),即报文中从shift开始的length长度字节的数值通过运算符与value进行运算,结果为true时,该匹配项元素匹配成功。

conditionBits元素:conditionBit元素集合,只能是conditionByte元素的下级元素,conditionBit元素的父级元素。

conditionBit元素:匹配的比特条件定义,value为要比较的值,operator为运算符;元素只能定义在conditionBits的下级元素中。

协议数据项说明:

byteDef元素:协议字节项定义,按照字节定义的协议项。

bitDefList元素:协议比特项定义的集合,只能是byteDef元素的子元素,bitDef元素的父元素。

bitDef元素:协议比特项定义,按照bit进行定义数据;元素只能定义在bitDefList元素的子元素中。

repeator元素:表示协议项中的重复项(数组或集合)。times表示重复次数为固定数值。timesRef表示重复次数为引用其他属性的值,times和timesRef只设置其一即可,如果都设置了,优先使用timesRef的值。timesRef的引用属性在同级或不同级同时找到时,优先使用同级的引用属性。timesRef引用值跨层级时,必须用a.b.c的方式标识属性(例如student.course.math)。

repeator支持两种类型的重复项,一是TLV类(TLV和TTLV)重复项,二是其他重复项(一般结构体数组)。itemType取值为TLV、TTLV或””之一,为TLV时表示数据为TLV重复项;为TTLV时表示数据为TTLV重复项;itemType为TLV或TTLV时,需设置tagFieldLength、typeFieldLength、lengthFieldOption、lengthFieldLength,且此时repeator的子元素只能为tag元素;itemType取值为””时表示数据项为其他重复项,无需设置,此时repeator的子元素可以为任意协议项元素。tagFieldLength表示tag字段在协议报文中的长度,typeFieldLength表示数据类型字段对应的长度,lengthFieldOption表示是否需要配置长度字段,lengthFieldLength表示value值的长度数值所在字段的长度。

tagDef元素:TLV编码中的tag的定义,只能是repeator元素的子元素。tag属性表示标签id,length属性仅当编码时需要明确配置,表示TLV中V(value)需要用多少长度的字节进行编码,解码时无需配置。tag的子元素下面可以嵌套byteDef、repeator、subProtocol、encryptBlock等元素。

subProtocol元素:子协议数据项,表示该协议项定义了数据对应的协议定义来自嵌入的子协议指令XML定义,protocolId为协议ID,protocolFileName为协议文件名称,子协议对应的数据为复杂对象(子协议数据包含多个基本类型的属性)时,objectType的值可以为HashMap或自定义类。

encryptBlock元素:加密(数据)块,表示协议报文对应的数据部分为加密的数据块,解码时需要先解密再解码,编码时需要编码后再进行加密。algorithm为内置的加密算法,customFunction为用户自定义的扩展加密算法(优先级高于内置加密算法),key为加解密密钥。

描述方法:

建立XML文件,建立根元素protocol。

根据协议内容和通用描述方法属性说明,在根元素下面分别建立协议通用描述项元素并填充属性内容,包括id、className、byteOrder、checkCodeItem、checkDataBlock、dataLengthItem、dataBlock、description。

根据协议内容和通用描述方法属性说明,在根元素下面建立协议匹配项集合元素conditionItems并填充属性内容,根据协议指令的唯一特征配置元素,包括conditionByte、conditionBits、conditionBit元素。

根据协议内容和通用描述方法属性说明,在根元素下面建立协议数据项集合元素definitionItems,并定义子元素。按照协议规约顺序定义协议项,配置好变量引用、表达式和自定义方法,变长字符串和字符串编码,根据数组结构体类型定义循环项(TLV类别和其它类别)和嵌套,配置好加密块、子协议等;需要配置元素包括byteDef、bitDefList、bitDef、repeator、tagDef、encryptBlock、subProtocol元素。

示例协议帧结构如下表1数据帧格式所示。本协议除非特别说明均采用小端模式传递多字节数据。

表1数据帧格式

表2帧格式版本号+数据域长度

BIT0-BIT12:数据域长度(数据域包括数据域固定首部、数据域可变首部和有效数据),单位为字节,取值0-8191。

BIT13-BIT15:帧格式版本号,初始版本必须为1,之后版本其值递增。

帧流水号字段是一个INT32U类型的数据,表示数据帧序号,如表2所示。

控制码为一个INT16U类型的数据,其形式如表3控制码所示。

表3控制码

BIT0-BIT2:有效数据的格式,取值0b001:掩码形式。

BIT3-BIT7:cmd为命令码,可能的取值如表4命令码所示

表4命令码

IT8-BIT11:数据域可变首部中的Options个数,取值0-15,取值为0即表示数据帧中不包含数据域可变首部。

数据域可变首部为可选字段,仅当控制码字段的Options字段不为0时存在。数据域可变首部由多个Options组成,每个Options为TLV结构,每个Options由1字节Option编号、1字节Option数据长度和N字节Option数据组成,Option可以自由组合的形式出现。其基本形式如表5数据域可变首部所示。

表5数据域可变首部

Options编号可能的取值如表6Options编号取值所示。

表6Options编号取值

有效数据是真正需要传输的数据(如传感器采集的数据、配置参数等)。有效数据中的参数形式随“命令码”的不同而不同,下面的示例XML中有效数据部分采用了RC4加密。

CRC16校验值是一个INT16U类型的数据,表示从“帧格式版本号+数据域长度”至数据域末尾的CRC16校验值。

上面协议对应的通信协议通用描述方法一种实施方法的XML描述文件如下。

/>

/>

/>

/>

具体的协议解码实现程序流程图,如图3所示,主要流程步骤有:

步骤a:根据协议匹配成功获得的协议ID获取协议通用描述文件对应的协议项定义。转入步骤b。

步骤b:按照协议描述文件中的校验方法,对输入的协议报文数据进行校验,在定义了自定义校验方法的情况,自定义校验优先,否则使用内置校验方法进行校验;校验通过后,转入步骤c;校验不通过,跳转步骤e。

步骤c:根据协议通用描述文件的协议通用描述项中className,创建类实例对象,以方便后续协议解析后数据存储。转入步骤d。

步骤d:协议块解码(解析)。传入协议报文原始数据、协议数据项集合和协议存储类对象实例,执行协议块解码(解析)方法。图中粗框中的方法称为协议块解码(解析)方法,可以对任意协议数据项集合进行解码。协议块解码包括以步骤和过程:

步骤d1:协议块解析方法内部循环遍历协议数据项集合,根据数据项类型对报文进行分别解码。如果协议数据项是字节项跳转步骤d2,如果协议数据项是重复项跳转步骤d3,如果协议数据项是子协议项跳转步骤d4,如果协议数据项是加密项跳转步骤d5;如果循环遍历已结束,则跳转步骤d6。

步骤d2:字节项解码过程:如果是不包含比特项的字节项,则按字节项定义中读取字节,如果读取的字节是多字节的数值型报文数据,并且字节序是小端序,则对字节进行倒序,然后按照数值类型进行转换结果,即可获得属性值。如果字节项包含比特项,在字节项的解码的基础上,对字节项的解码结果根据比特项定义进行按位移位运算即可获得转换结果。协议项解码后值根据协议定义存储到对应的类对象实例的属性上。

步骤d3:重复项解码过程:根据定义获取循环次数,循环协议数据项进行解码,解码时分两种情况,一如果是TLV类重复项目,根据定义读取并比较获得报文数据对应的Tag值,进一步可获得Tag对应属性Value的Length,进一步读取Value的值;如果TLV数据项中有嵌套协议数据项,则调用协议块解码进行解码。二如果是其他重复项,传入重复项定义、报文字节数组、属性值存储对象,调用协议块解码,解码可以获得对应的属性值;循环结束即可。协议项解码后值根据协议定义存储到对应的类对象实例的属性上。

步骤d4:子协议项解码过程:根据定义获取子协议模板ID,加载子协议的协议数据项集合,然后对其进行协议块解码。协议项解码后值根据协议定义存储到对应的类对象实例的属性上。

步骤d5:加密项解码过程:根据协议定义提取原始协议报文数组,按照解密函数进行运算,获得解密后的报文数组,然后根据加密数据项内部的协议数据项定义集合进行协议块解码。协议项解码后值根据协议定义存储到对应的类对象实例的属性上。

步骤d6:遍历结束后返回数据存储对象或将数据存储对象转换为json返回,程序结束。

步骤d7:上述步骤d2-d5的协议数据项解码的过程中,如果协议数据项内部有还有嵌套的一层或多层的协议数据项,可按照从上层到下层的顺序递归调用协议块解码方法实现。

步骤d8:协议解码过程中如果有valueExp值表达式或自定义解码方法、自定义解密方法,优先使用自定义方法或对表达式进行运算,否则使用协议内部常规的解码方法或内置的解密方法进行解码解密。发生异常时,记录错误信息,结束解码。

步骤d9:自定义解码方法的实现。可以通过自定义类继承解码基类,重载基类的解码算法,方法可传入协议报文数据和已解码完成的对象,内部可以编写自定义的解码逻辑,返回解码后的对象。每一个自定义解码类只实现一个自定义解码算法,并通过配置文件进行配置,开启或关闭加载,确保项目中只有需要的自定义扩展类才被加载。

步骤e:记录校验不通过日志(可选),返回空值,程序结束。

基于协议通用描述文件的协议解码示例,输入为待解码原始报文16进制数据,程序自动匹配协议ID,输出为JSON数据,如图4(a)和图4(b)解码示例所示。

实施例二

本实施例提供了一种基于通信协议通用描述的协议解码装置,其包括:

元素解析模块,其用于获取通信协议的通用描述文件,校验通用描述文件的格式,解析描述文件中的元素;

协议转换模块,其用于将通信协议描述文件中的协议匹配项相关元素和属性转换为通信协议匹配对象,以及将通信协议描述文件中的协议数据项相关元素和属性转换为通信协议数据对象;

通信侦听模块,其用于通信侦听获取通信原始报文数据;

协议匹配模块,其用于基于协议匹配项将通信原始报文数据进行协议匹配;

协议解码模块,其用于根据协议匹配结果,进行协议解码,输出对象实例或json格式数据。

此处需要说明的是,本实施例的各个模块与实施例二中的各个步骤一一对应,其具体实施过程相同,此处不再累述。

实施例三

本实施例提供了一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现如上述实施例一所述的基于通信协议通用描述的协议解码方法中的步骤。

实施例四

本实施例提供了一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述程序时实现如上述实施例一所述的基于通信协议通用描述的协议解码方法中的步骤。

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

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

以上所述仅为本发明的优选实施例而已,并不用于限制本发明,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。

技术分类

06120115921676