CN105740292A - 一种解码方法及装置 - Google Patents

Abstract

本发明实施例公开了一种解码方法，所述方法包括：从标准协议文档中提取协议相关信息，并将所述协议相关信息以相应数据结构格式保存到数据库中；基于所述数据库所储存的信息对待解码的码流进行解码。同时，本发明实施例还公开了一种解码装置。

Description

一种解码方法及装置

技术领域

本发明涉及通信协议领域中的编解码技术，具体涉及一种解码方法及装置。

背景技术

随着通信行业技术的快速发展，通信协议也随之不断更新，进而要求应用协议也需进行相应的更新。目前，对于标准协议文档的处理，大多是通过手动翻译将标准协议文档转换为C、C++等语言，而通过手动解码，不仅浪费了很多人力和时间，而且容易出错。因此，很多厂家根据自己的需求来分析标准协议文档，建立自身的编解码系统，以求实现对与自身相关的标准协议文档的自动化编解码；当标准协议文档升级时，通过建立的编解码系统直接读取标准协议文档，即可实现编解码库的升级，大大提高了编解码的效率。

目前，针对抽象语法标记(AbstractSyntaxNotation，简称ASN)、中国智能物流骨干网(ChinaSmartLogisticNetwork，简称CSN)等协议的描述语言，均已有成熟的编解码系统，能方便地从这类协议文档中提取信息。但是，有些协议文档是以表格的形式描述协议信息的，例如24008x系列的协议文档，由于他们没有统一的语法及固定的格式，进而给自动提取这类协议信息带来了很多困难。

发明内容

有鉴于此，本发明实施例的主要目的在于提供一种解码方法及装置，能实现对以表格形式描述的协议文档的自动解码，提高解码效率。

为达到上述目的，本发明实施例的技术方案是这样实现的：

本发明实施例提供了一种解码方法，所述方法包括：

从标准协议文档中提取协议相关信息，并将所述协议相关信息以相应数据结构格式保存到数据库中；

基于所述数据库所储存的信息对待解码的码流进行解码。

优选地，所述协议相关信息至少包括：消息描述信息、信元描述信息、枚举描述信息。

优选地，所述从标准协议文档中提取协议相关信息，并将所述协议相关信息以相应数据结构格式保存到数据库中，包括：

预先设置第一存储格式；其中，所述第一存储格式包括消息描述表存储格式、信元描述表存储格式、枚举描述表存储格式、以及数组类型存储格式；

读取所述标准协议文档，从所述协议文档中提取消息描述信息、信元描述信息、枚举描述信息；

基于所述第一存储格式，将所述消息描述信息、所述信元描述信息、以及所述枚举描述信息以对应的存储格式存储到数据库中。

优选地，所述基于所述数据库所储存的信息对待解码的码流进行解码，包括：

接收待解码的码流后，从所述码流中获取解码所需相关参数；

根据所述解码所需相关参数确定与所述码流对应的消息名称；

以所述消息名称为关键字，获取与所述消息名称相对应的消息节点，循环解析消息下的子节点，并获取子节点的格式属性值，如果所述子节点的格式属性值为可选项，则跳转到可选项解码流程，否则进入必选项解码流程，直到码流结束或节点结束，当前消息解码结束。

优选地，所述可选项解码流程，包括：

首先获取可选项开始节点，每次解码可选项时，均从所述可选项开始节点开始，将实际通过当前码流获取的可选项标记值与数据库中的标准可选项标记值进行匹配，如果匹配成功，获取当前节点，调用必选项解码接口解码。

优选地，所述必选项解码流程，包括：

如果消息格式属性值中包含有长度信息，则先对所述长度信息进行解码，然后，将所述长度信息与标准长度信息进行比较，若所述长度信息在所述标准长度范围之内，则继续进行解码，否则，结束当前解码流程；如果消息格式属性值中不包含长度信息，则不需要对所述长度信息进行解码；直到解码长度为0，则当前消息解码结束。

本发明实施例还提供了一种解码装置，所述解码装置包括提取模块和解码模块；其中，

所述提取模块，用于从标准协议文档中提取协议相关信息，并将所述协议相关信息以相应数据结构格式保存到数据库中；

所述解码模块，用于基于所述数据库所储存的信息对待解码的码流进行解码。

优选地，所述协议相关信息至少包括：消息描述信息、信元描述信息、枚举描述信息。

优选地，所述提取模块包括设置子模块、读取子模块和存储子模块；其中，

所述设置子模块，用于预先设置第一存储格式；其中，所述第一存储格式包括消息描述表存储格式、信元描述表存储格式、枚举描述表存储格式、以及数组类型存储格式；

所述读取子模块，用于读取所述标准协议文档，从所述协议文档中提取消息描述信息、信元描述信息、枚举描述信息；

所述存储子模块，用于基于所述第一存储格式，将所述消息描述信息、所述信元描述信息、以及所述枚举描述信息以对应的存储格式存储到数据库中。

优选地，所述解码模块包括获取子模块、确定子模块以及处理子模块；其中，

所述获取子模块，用于接收待解码的码流后，从所述码流中获取解码所需相关参数；

所述确定子模块，用于根据所述解码所需相关参数确定与所述码流对应的消息名称；

所述处理子模块，用于以所述消息名称为关键字，获取与所述消息名称相对应的消息节点，循环解析消息下的子节点，并获取子节点的格式属性值，如果所述子节点的格式属性值为可选项，则跳转到可选项解码流程，否则进入必选项解码流程，直到码流结束或节点结束，当前消息解码结束。

优选地，所述可选项解码流程，包括：

首先获取可选项开始节点，每次解码可选项时，均从所述可选项开始节点开始，将实际通过当前码流获取的可选项标记值与数据库中标准可选项标记值进行匹配，如果匹配成功，获取当前节点，调用必选项解码接口解码。

优选地，所述必选项解码流程，包括：

如果消息格式属性值中包含有长度信息，则先对所述长度信息进行解码，然后，将所述长度信息与标准长度信息进行比较，若所述长度信息在所述标准长度范围之内，则继续进行解码，否则，结束当前解码流程；如果消息格式属性值中不包含长度信息，则不需要对所述长度信息进行解码；直到解码长度为0，则当前消息解码结束。

本发明实施例提供的解码方法及装置，从标准协议文档中提取协议相关信息，并将所述协议相关信息以相应数据结构格式保存到数据库中；基于所述数据库所储存的信息对待解码的码流进行解码。如此，能够实现对以表格形式描述的协议文档的自动解码，解决了以表格形式描述的协议无法实现自动化解码的问题。另外，也提高了对以表格形式描述的协议文档的解码效率、进而也能提高解码库的维护和升级的效率。此外，本发明实施例所述方法尤其适用于对以表格形式描述的协议文档的解码，例如网络层协议文档。

附图说明

图1为本发明实施例提供的解码方法的流程示意图；

图2为本发明实施例提供的消息描述表存储格式示意图；

图3为本发明实施例提供的信元描述表存储格式示意图；

图4为本发明实施例提供的枚举描述存储格式示意图；

图5为本发明实施例提供的数组存储格式示意图；

图6为本发明实施例提供的解码装置的组成结构示意图。

具体实施方式

为了能够更加详尽地了解本发明的特点与技术内容，下面结合附图对本发明的实现进行详细阐述，所附附图仅供参考说明之用，并非用来限定本发明。

图1为本发明实施例提供的解码方法的流程示意图，如图1所示，所述方法主要包括以下步骤：

步骤101：从标准协议文档中提取协议相关信息，并将所述协议相关信息以相应数据结构格式保存到数据库中。

这里，所述标准协议文档主要是指以表格形式描述协议内容的文档，例如24008x系列协议。

优选地，所述协议相关信息至少包括：消息描述信息、信元描述信息、枚举描述信息。

优选地，所述从标准协议文档中提取协议相关信息，并将所述协议相关信息以相应数据结构格式保存到数据库中，包括：

预先设置第一存储格式；其中，所述第一存储格式包括消息描述表存储格式、信元描述表存储格式、枚举描述表存储格式、以及数组类型存储格式；

读取所述标准协议文档，从所述协议文档中提取消息描述信息、信元描述信息、枚举描述信息；

基于所述第一存储格式，将所述消息描述信息、所述信元描述信息、以及所述枚举描述信息分别以对应的存储格式存储到数据库中。

这里，所述消息描述信息可以保存于消息描述表中，所述信元描述信息可以保存于信元描述表中，所述枚举描述信息可以保存于枚举描述表中。其中，消息描述表可以存储于一个数据库中，信元描述表、枚举描述表、以及数组类型存储格式，可以存储于另一个数据库中。当然，消息描述表、信元描述表、枚举描述表、以及数组类型存储格式也可以存储于同一个数据库中。

本发明实施例提供的消息描述表存储格式示意图如图2所示，所述消息描述表存储格式，具体为：

以消息名称作为键值，消息下面的信元描述作为子节点。

其中，每个信元属性包括：可选项标记值(IEI)、信元名称(Name)、类别(Type)、可选属性(Presence)、长度(Length)、对应的章节号(Chapter)。

显然，在图2中，消息名称为<IMSI_DETACH_INDICATION>的消息中含有5个信元。

本发明实施例提供的信元描述表存储格式示意图如图3所示，所述信元描述表存储格式，具体为：

以章节号作为第一级键值，以字节作为第二级键值，每个字节里的信元作为子节点。

其中，每个信元属性包括：名称(Name)、长度(Len)、类型(bArry)、枚举标志位(bEnum)、引用成员名称(Member)。

本发明实施例提供的枚举描述表存储格式示意图，如图4所示，所述枚举描述表存储格式，具体为：

以章节号作为第一级键值，以信元名称作为第二级键值，每个枚举值作为子节点；

其中，每个枚举值属性包括：枚举值(Val)、枚举描述(Caption)。

其中，所述枚举值用十进制表示。

本发明实施例提供的数组类型存储格式如5所示，所述数组类型存储格式，具体为：

以结构体名称作为键值，以结构体信元作为子节点。

其中，所述数组属性包括：信元名称(Name)、信元长度(Len)、信元类型(MemType)、枚举标志位(bEnum)。

其中，信元类型分为一般类型、长度类型、依赖长度类型。具体地，MemType＝0表示一般类型、MemType＝1表示长度类型、MemType＝2表示依赖长度类型。

优选地，提取消息描述表的算法，主要包括以下步骤：

获取消息名称；

以消息名称+消息内容为关键字，在所述数据库中进行查找，并确定此消息的消息描述表；

按照行的单元格读取所述消息描述表中的信息。

具体地，按照行的单元格读取所述消息描述表中的信息，包括：

当读到章节号时，说明当前成员读取完毕，继续读取下一个成员，直到所述第一张表读取结束。

以读取24008协议文档中的四个表格为例，所述四个表格具体为：“Table10.2/3GPPTS24.008:MessagetypesforMobilityManagement”、“Table10.3/3GPPTS24.008:MessagetypesforCallControlandcallrelatedSSmessages”、“Table10.4/3GPPTS24.008:MessagetypesforGPRSmobilitymanagement”、“Table10.4a/3GPPTS24.008:MessagetypesforGPRSsessionmanagement”，可取每行第10列的值作为消息名称，然后以消息名称+消息内容作为关键字查找，从找到位置的第一张表就是此消息的消息描述表，然后按照行的单元格读取所述消息描述表中的信息，当读到章节号时，说明此成员读取完毕，继续读取下一个成员，直到所述第一张表读取结束。

优选地，提取信元描述表的算法流程，包括：

以章节号作为搜索条件，搜到的章节号为目录时，说明找到了此章节，获取此章节的第一张表；以单元格为单位，依次读取所述第一张表中的信息。

其中，所述第一张表为当前成员的信元描述表。

具体地，读到第一关键词(octet)时，说明当前字节的信元读取结束，继续读取下一字节的信元，直到所述第一张表读取结束。

需要说明的是，当前字节的列数代表所述当前字节的信元数，如果有合并，则按列数少的进行合并，保存到数组中。

优选地，提取枚举信元值和枚举描述信息的算法流程，包括：

以章节号作为搜索条件，搜到的章节号为目录(即“标题”)时，说明找到了此章节；

获取此章节的第二张表；其中，所述第二张表为当前IE的枚举描述表；

以单元格为单位，依次读取所述第二张表中的信息。

具体地，以单元格为单位，依次读取所述第二张表中的信息，包括：

按照单元格读取所述第二张表，读到第二关键词“(OCTET”时，获取当前成员的信元名称；其中，截取此关键字前面的字符即为信元名称。

读到‘0’或‘1’组成字串后，转换为十进制；

读到不是‘0’或‘1’组成字串，如果信元没有换行，说明为当前枚举值的描述信息，保存到数组中；

继续读取下一个信元，直到所述第二张表读取结束。

步骤102：基于所述数据库所储存的信息对待解码的码流进行解码。

优选地，所述基于所述数据库所储存的信息对待解码的码流进行解码，包括：

接收待解码的码流后，从所述码流中获取解码所需相关参数；

根据所述解码所需相关参数确定与所述码流对应的消息名称；

以所述消息名称为关键字，获取与所述消息名称相对应的消息节点，循环解析消息下的子节点，并获取子节点的格式属性值，如果所述子节点的格式属性值为可选项，则跳转到可选项解码流程，否则进入必选项解码流程，直到码流结束或节点结束，当前消息解码结束。

其中，所述解码所需相关参数包括：协议鉴别符(ProtocolDiscriminator，PD)信息、以及消息类型(MsgType)信息。

具体地，所述从所述码流中获取解码所需相关参数，包括：

通过所述码流的第一个字节获取PD信息；

根据PD信息，确定码流中的第二个和第三个字节中的一个字节为MsgType信息。

具体地，所述根据所述解码所需相关参数确定与所述码流对应的消息名称，包括：

根据所述PD信息确定与所述PD信息对应的全局映射表；

根据所述MsgType信息，并从所述全局映射表中确定与所述码流对应的消息名称。

这里，所述全局映射表是指从MsgType到消息名称的映射。

这里，在数据库中，针对各类PD均设置有不同的全局映射表。

其中，所述可选项解码流程，包括：

首先获取可选项开始节点，每次解码可选项时，均从所述可选项开始节点开始，将实际通过当前码流获取的可选项标记值(IEI值)与数据库中标准可选项标记值进行匹配，如果匹配成功，获取当前节点，调用必选项解码接口解码。

这里，实际通过码流获取的IEI值与数据库中的标准IEI值进行匹配，如果所述实际IEI值在所述标准IEI值范围内，说明匹配较成功。

其中，所述必选项解码流程，包括：

如果消息格式属性值中包含有长度信息，则先对所述长度信息进行解码，然后，将所述长度信息与标准长度信息进行比较，若所述长度信息在所述标准长度范围之内，则继续进行解码，否则，结束当前解码流程；如果消息格式属性值中不包含长度信息，则不需要对所述长度信息进行解码；直到解码长度为0，则当前消息解码结束。

也就是说，如果当前消息格式是带有“L”的，需先解码长度，然后再对解码长度进行判断，如果比较成功，则继续解码下面信元，否则返回失败，直到解码长度为0，则当前消息解码结束。

例如，当所述格式为“TLV”或“LV”时，需先解码一个字节长度；当所述格式为“TLV-E”或“LV-E”时，需先解码两个字节长度。

为了更好地理解本发明所述解码方法，本实施例提供了一种从层三标准协议文档中提取协议相关信息，并以抽象出来的数据结构格式保存到数据库中的方法，该方法主要包括以下步骤：

步骤201：打开关于所述层三标准协议的word文档，基于所述word文档打开宏环境，并在所述宏环境中通过VBS语言提取所述word文档中的详细信息。

这里，所述VBS语言是可视化Basic脚本语言(VisualBasicScript)的简称。

这里，可以通过“ALT+F11”快捷键来打开宏环境。

这里，所述层三标准协议可以是24008协议。

步骤202：根据消息类型定义表查找消息描述表，并读取消息描述信息。

优选地，步骤202具体还包括以下步骤：

步骤202a：循环查找消息类型定义表，读取每行最后一个单元格(Cell)中的第一信息；

其中，所述每行最后一个单元格中的信息为所述消息类型定义表定义的消息名称，即所述第一信息为消息名称。

步骤202b：以步骤202a中获取的消息名称+消息内容为关键字进行查找，将所述关键字下的第一张表确定为此消息的消息描述表，并以单元格为单位循环读取所述第一张表中的内容，直到当前消息描述表读取结束。

这里，消息描述表由多个成员组成，其中，每个成员占表格的一行或者多行。

具体地，以单元格为单位，循环读取所述第一张表中的内容，当读到包含有章节号的单元格时，说明当前成员已经读取结束。另外，如果是占多行的成员，需要合并后保存到定义的变量中。

例如，以读取24008协议文档为例，当单元格中包含“10.”或“9.”时，说明当前成员已经读取结束。也就是说，可以具体根据协议文档中的章节添加条件。

步骤202c：循环步骤202a、步骤202b两个步骤，直到所有消息类型定义表中的消息读取完为止。

步骤203：将步骤202中所读取的消息描述信息保存到变量中，并将变量信息存储到数据库中。

具体地，所述变量信息包括：可选项标记值(IEI值)、名称、类型、章节号、长度、格式。

其中，格式主要包括以下几种：T、TV、V、TLV、LV、LV-E、TLV-E。

具体地，把变量信息保存到数据库中，包括：

以消息名称为键值，键值下的节点内容和变量信息对应。

步骤204：读取各成员的信元描述信息。

具体地，可以通过如下步骤读取成员的信元描述信息：

步骤204a：循环获取章节号信息。

这里，步骤202读取消息描述消息时，将每个成员的章节信息会统一保存到一个数组中，循环获取数组中的章节号信息。

步骤204b：以章节号为关键字，并且搜索到的关键字是“标题”信息，查找关键字下面的第一张表格，将所述第一张表格确定为当前成员的信元描述表格。

步骤204c：找到所述当前成员的信元描述表，获取比特位(bit)的宽度。

这里，获取比特位的宽度，包括：首先获取所述当前成员的信元描述表的宽度，将所述当前成员的信元描述表的宽度除以8，即得到比特位的宽度，这里，所述bit的宽度可以用“len”表示。

步骤204d)：以单元格为单位，循环读取所述第一张表格，读到第一关键词后，说明当前字节信元读取结束。

这里，所述第一关键词可以是“Octet”。

这里，将每个单元格宽度除以比特位的宽度，即可得到当前信元占几个比特位。

步骤204e：循环步骤204d直到所述第一张表格读取结束。

步骤204f：将读取的信元描述信息保存到结构体变量数组中。

这里，所述结构体主要包括：信元名称、信元长度、信元类型、是否包括枚举描述信息、数组结构体。

其中，所述信元类型主要包括一般类型、数组类型、扩展类型，无限扩展类型。

步骤205：将步骤204所读取的信元描述信息保存到数据库中。

具体地，以章节号为键值，每个字节为子节点，每个信元描述信息作为子节点内容保存到数据库中。

步骤206：读取各成员的枚举描述信息，并将所述枚举描述信息存储到数据库中。

具体地，可通过如下步骤读取枚举描述信息：

步骤206a：循环获取数组中的章节号信息，以章节号为搜索关键字，并且搜索到的关键字是“标题”信息，查找关键字下面的第二张表，以单元格为单位读取所述第二张表，读到第二关键词后，获取其前面的字符即为信元名称，继续读取下个单元格，读到’0’或’1’保存起来，直到读到非’0’或非’1’，把前面保存的二进制码流转换为十进制整数，接着读下个单元格，如果不为空，则为当前枚举值的的描述信息，直到所述第二张表读取完成。

这里，所述第二关键词是“(OCTET”。

步骤206b：循环读取结构体数组，以章节号为键值、信元名称为成员名、信元每个枚举值作为一个子节点保存到数据库中。

步骤207：将预设的数组存储到数据库中。

具体地，以结构体名称为键值，结构体信元为子节点，将预设的数组信息保存到数据库中。

本实施例中，所述数据库可以为可扩展标识语言(XML，ExtensibleMarkupLanguage，XML)文件。

上述实施例仅为本发明的一个优选实施例。需要说明的是，从协议文档中读取消息描述信息、信元描述信息、以及枚举信息，以及将所述消息描述信息、所述信元描述信息、以及所述枚举信息存储到数据库、将预设的数组信息存储到所述数据库中；并不存在先后顺序，。

为了更好地理解本发明所述解码方法，本实施例提供了一种自动解码的具体流程，包括：

步骤301：接收到码流后，从所述码流中获取PD信息，以及消息类型(MsgType)信息；根据所述PD信息以及所述MsgType信息确定与所述码流对应的消息名称。

具体地，所述根据所述PD信息以及所述MsgType信息确定与所述码流对应的消息名称，包括：

根据所述PD信息确定与所述PD信息对应的全局映射表；

根据所述MsgType信息，并从所述全局映射表中确定与所述码流对应的消息名称。

这里，所述全局映射表是指从MsgType到消息名称的映射。

这里，在数据库中，针对各类PD均设置有不同的全局映射表。

其中，码流的第一个字节包含有PD信息，码流的第二个或者第三个字节中包含有MsgType信息。

步骤302：以所述消息名称为关键字，在“消息描述表”中查找消息开始节点，找到消息描述表，循环读取所述消息描述表中的每个IE子节点。

这里，消息描述表为数据库的一部分。

步骤303：步骤302读取IE子节点时，获取消息格式、消息长度信息、成员章节号，如果消息格式中包含有长度信息，则先对所述长度信息进行解码，然后，将所述长度信息与标准长度信息进行比较，若所述长度信息在所述标准长度范围之内，则继续进行解码，否则，结束当前解码流程；

进一步地，如果消息格式中不包含长度信息，则不需要对所述长度信息进行解码。

其中，所述标准长度范围预先存储于数据库中。

步骤304：以所获取的成员章节号为关键字，从“信元描述表”中找到信元(Element)节点下对应的章节和枚举(Enum)节点下的章节，循环读取此成员章节号下面的每个节点。

这里，所述“信元描述表”为数据库的一部分，所述“信元描述表”存储有信元描述表、枚举描述表和结构体数组。

需要说明的是，所述“消息描述表”、所述“信元描述表”均可以作为独立的数据库存在，也可以位于同一个数据库中。

对步骤304中的节点进行解码时，首先，判断当前节点类型，然后根据节点类型进行不同的解码。也就是说，不同类型的节点对应有不同的解码接口。

这里，所述节点类型，可能为一般类型、或一般扩展类型、或无线扩展类型、或数组类型。

步骤305：节点类型为一般类型时，直接根据节点长度解码即可，如果需要枚举描述值，根据当前解码的值从信元描述表中获取枚举描述值。

步骤306：节点为一般扩展类型时，解码一个bit的扩展位，如果为0，则回到步骤304；如果为1，则需要跳出和当前字节号相同的字节，比如：octet3需要跳出octet3a、octet3b….等，直到跳到字节为octet4时，重复回到步骤304。

步骤307：节点为无线扩展类型时，解码一个bit扩展位，如果为0，则在当前字节循环解码；如果为1，则跳出和当前字节号相同的字节。

步骤308：节点为数组类型时，则以结构体名称为关键字，找到数组下面对应的节点，循环读取节点。

这里，步骤308中循环读取的节点有三种类型：一般类型、长度类型、依赖长度类型；其中，对于一般类型，可直接根据长度解码；对于长度类型，根据长度解码后保存到长度变量中，以方便下面节点使用；对于依赖长度类型，根据解码出的长度进行解码，直到码流结束。

步骤309：重复循环以上8个步骤，直到当前消息节点为空或者码流为空，判断解码结束。

在上文所述消息描述表存储格式、信元描述表存储格式、枚举描述存储格式、数组存储格式的基础上，本发明还提出了一种解码装置。

图6为本发明实施例提供的解码装置的组成结构示意图，如图6所示，所述解码装置包括提取模块61和解码模块62；其中，

所述提取模块61，用于从标准协议文档中提取协议相关信息，并将所述协议相关信息以相应数据结构格式保存到数据库中；

所述解码模块62，用于基于所述数据库所储存的信息对待解码的码流进行解码。

优选地，所述协议相关信息至少包括：消息描述信息、信元描述信息、枚举描述信息。

优选地，所述提取模块61包括设置子模块611、读取子模块612和存储子模块613；其中，

所述设置子模块611，用于预先设置第一存储格式；其中，所述第一存储格式包括消息描述表存储格式、信元描述表存储格式、枚举描述表存储格式、以及数组类型存储格式；

所述读取子模块612，用于读取所述标准协议文档，从所述协议文档中提取消息描述信息、信元描述信息、枚举描述信息；

所述存储子模块613，用于基于所述第一存储格式，将所述消息描述信息、所述信元描述信息、以及所述枚举描述信息以对应的存储格式存储到数据库中。

优选地，所述解码模块62包括获取子模块621、确定子模块622以及处理子模块623；其中，

所述获取子模块621，用于接收待解码的码流后，从所述码流中获取解码所需相关参数；

所述确定子模块622，用于根据所述解码所需相关参数确定与所述码流对应的消息名称；

所述处理子模块623，用于以所述消息名称为关键字，获取与所述消息名称相对应的消息节点，循环解析消息下的子节点，并获取子节点的格式属性值，如果所述子节点的格式属性值为可选项，则跳转到可选项解码流程，否则进入必选项解码流程，直到码流结束或节点结束，当前消息解码结束。

其中，所述可选项解码流程，包括：

首先获取可选项开始节点，每次解码可选项时，均从所述可选项开始节点开始，将实际通过当前码流获取的可选项标记值与数据库中标准可选项标记值进行匹配，如果匹配成功，获取当前节点，调用必选项解码接口解码。

其中，所述必选项解码流程，包括：

如果消息格式属性值中包含有长度信息，则先对所述长度信息进行解码，然后，将所述长度信息与标准长度信息进行比较，若所述长度信息在所述标准长度范围之内，则继续进行解码，否则，结束当前解码流程；如果消息格式属性值中不包含长度信息，则不需要对所述长度信息进行解码；直到解码长度为0，则当前消息解码结束。

本领域技术人员应当理解，图6所示的解码装置中的各单元的实现功能可参照前述解码方法的相关描述而理解。

实际应用中，所述提取模块61和解码模块62可由解码装置所属终端中的中央处理器(CPU，CentralProcessingUnit)、微处理器(MPU，MicroProcessorUnit)、数字信号处理器(DSP，DigitalSignalProcessor)或现场可编程门阵列(FPGA，FieldProgrammableGateArray)实现。

本发明实施例还提供了一种计算机存储介质，所述计算机存储介质中存储有计算机可执行指令，所述计算机可执行指令用于执行前述的解码方法。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元，即可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本发明各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(ROM，Read-OnlyMemory)、磁碟或者光盘等各种可以存储程序代码的介质。

或者，本发明上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本发明各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (12)

1.一种解码方法，其特征在于，所述方法包括：

从标准协议文档中提取协议相关信息，并将所述协议相关信息以相应数据结构格式保存到数据库中；

基于所述数据库所储存的信息对待解码的码流进行解码。

2.根据权利要求1所述的方法，其特征在于，所述协议相关信息至少包括：消息描述信息、信元描述信息、枚举描述信息。

3.根据权利要求2所述的方法，其特征在于，所述从标准协议文档中提取协议相关信息，并将所述协议相关信息以相应数据结构格式保存到数据库中，包括：

预先设置第一存储格式；其中，所述第一存储格式包括消息描述表存储格式、信元描述表存储格式、枚举描述表存储格式、以及数组类型存储格式；

读取所述标准协议文档，从所述协议文档中提取消息描述信息、信元描述信息、枚举描述信息；

基于所述第一存储格式，将所述消息描述信息、所述信元描述信息、以及所述枚举描述信息以对应的存储格式存储到数据库中。

4.根据权利要求2所述的方法，其特征在于，所述基于所述数据库所储存的信息对待解码的码流进行解码，包括：

接收待解码的码流后，从所述码流中获取解码所需相关参数；

根据所述解码所需相关参数确定与所述码流对应的消息名称；

以所述消息名称为关键字，获取与所述消息名称相对应的消息节点，循环解析消息下的子节点，并获取子节点的格式属性值，如果所述子节点的格式属性值为可选项，则跳转到可选项解码流程，否则进入必选项解码流程，直到码流结束或节点结束，当前消息解码结束。

5.根据权利要求4所述的方法，其特征在于，所述可选项解码流程，包括：

首先获取可选项开始节点，每次解码可选项时，均从所述可选项开始节点开始，将实际通过当前码流获取的可选项标记值与数据库中的标准可选项标记值进行匹配，如果匹配成功，获取当前节点，调用必选项解码接口解码。

6.根据权利要求4所述的方法，其特征在于，所述必选项解码流程，包括：

如果消息格式属性值中包含有长度信息，则先对所述长度信息进行解码，然后，将所述长度信息与标准长度信息进行比较，若所述长度信息在所述标准长度范围之内，则继续进行解码，否则，结束当前解码流程；如果消息格式属性值中不包含长度信息，则不需要对所述长度信息进行解码；直到解码长度为0，则当前消息解码结束。

7.一种解码装置，其特征在于，所述解码装置包括提取模块和解码模块；其中，

所述提取模块，用于从标准协议文档中提取协议相关信息，并将所述协议相关信息以相应数据结构格式保存到数据库中；

所述解码模块，用于基于所述数据库所储存的信息对待解码的码流进行解码。

8.根据权利要求7所述的解码装置，其特征在于，所述协议相关信息至少包括：消息描述信息、信元描述信息、枚举描述信息。

9.根据权利要求7所述的解码装置，其特征在于，所述提取模块包括设置子模块、读取子模块和存储子模块；其中，

所述设置子模块，用于预先设置第一存储格式；其中，所述第一存储格式包括消息描述表存储格式、信元描述表存储格式、枚举描述表存储格式、以及数组类型存储格式；

所述读取子模块，用于读取所述标准协议文档，从所述协议文档中提取消息描述信息、信元描述信息、枚举描述信息；

所述存储子模块，用于基于所述第一存储格式，将所述消息描述信息、所述信元描述信息、以及所述枚举描述信息以对应的存储格式存储到数据库中。

10.根据权利要求7所述的解码装置，其特征在于，所述解码模块包括获取子模块、确定子模块以及处理子模块；其中，

所述获取子模块，用于接收待解码的码流后，从所述码流中获取解码所需相关参数；

所述确定子模块，用于根据所述解码所需相关参数确定与所述码流对应的消息名称；

所述处理子模块，用于以所述消息名称为关键字，获取与所述消息名称相对应的消息节点，循环解析消息下的子节点，并获取子节点的格式属性值，如果所述子节点的格式属性值为可选项，则跳转到可选项解码流程，否则进入必选项解码流程，直到码流结束或节点结束，当前消息解码结束。

11.根据权利要求10所述的解码装置，其特征在于，所述可选项解码流程，包括：

首先获取可选项开始节点，每次解码可选项时，均从所述可选项开始节点开始，将实际通过当前码流获取的可选项标记值与数据库中标准可选项标记值进行匹配，如果匹配成功，获取当前节点，调用必选项解码接口解码。

12.根据权利要求10所述的解码装置，其特征在于，所述必选项解码流程，包括：

如果消息格式属性值中包含有长度信息，则先对所述长度信息进行解码，然后，将所述长度信息与标准长度信息进行比较，若所述长度信息在所述标准长度范围之内，则继续进行解码，否则，结束当前解码流程；如果消息格式属性值中不包含长度信息，则不需要对所述长度信息进行解码；直到解码长度为0，则当前消息解码结束。