CN117880392A - 一种报文发送解析的处理系统及方法 - Google Patents

Abstract

本发明提出了一种报文发送解析的处理系统及方法，该系统包括接收模块、校验模块、命令解析模块、链表遍历模块和数据回复模块。通过接收模块获取完整报文后，经过校验模块确保数据完整性，随后通过命令解析模块对数据进行解析。依靠链表遍历模块，使用循环链表遍历方式实现解析过程，将命令和数据字段信息存储在链表中，从而大幅减少冗余代码和操作的重复性。这种循环链表处理的方案使得解析流程更加固定化，提高了解析效率和程序的可维护性。对于程序移植和交接，使系统更加灵活，减少了维护成本。

Description

一种报文发送解析的处理系统及方法

技术领域

本申请涉及通讯传输技术领域，具体而言，涉及一种报文发送解析的处理系统及方法。

背景技术

在传统数据报文解析过程中，通信双方需要处理各种不同的报文，包括命令码、数据字段等。在当前的通信系统中，报文的发送与解析是设备之间进行信息交互和命令执行的核心过程。

传统的报文解析方式通常采用硬编码的方式，即针对每一种协议都需要编写相应的解析代码。这导致了大量的重复操作，例如对报文的起始标志、结束标志、协议头部和尾部的解析，以及数据字段的提取等。这样的设计不仅增加了代码量，也降低了代码的可读性和可维护性。

由于不同协议之间存在差异，采用传统方式编写的报文解析代码难以实现通用性。每次新增或修改协议都需要重新编写和测试相应的解析逻辑，使得程序的移植变得繁琐，且容易引入错误。

在程序交接方面，由于传统解析方式的复杂性，当需要修改或维护系统时，新的开发人员往往需要花费大量时间理解和修改已有的解析代码，容易引发误更改和维护成本上升的问题。

发明内容

为解决这一问题，本发明提出一种报文发送解析的处理系统和方法，采用循环链表处理的报文解析方案，能够大幅减少冗余的代码和重复操作，提高了解析效率和程序的可维护性。

本申请的实施例是这样实现的：

一种报文发送解析的处理系统，所述处理系统包括：

接收模块，用于接收报文数据；

校验模块，用于对所接收到的报文数据进行校验；

命令解析模块，用于对校验成功后的数据进行命令解析；

链表遍历模块，根据命令解析内容查找相对应的链表，并对链表进行循环遍历处理，直到最后一个链表时，结束循环；

数据回复模块，在链表的执行过程中，系统根据需要生成回复数据，回复数据的内容和格式根据协议和具体业务逻辑而定。

可选的，所述处理系统还包括报文组织模块，根据协议规定的格式将数据组织成一个完整的报文，包含报文头尾的报文组织。

可选的，所述链表遍历模块中包括有判断模块，根据链表数据内容，判断当前字段是进行解析还是组织报文发送。

可选的，所述链表通过链表结构体表示，包括数据结构体和一个指向下一个链表的地址。

可选的，所述数据结构体包含字段指针、数据类型、小数点格式、发送条件指针、数据指针、触发调用函数。

可选的，所述数据结构体允许根据使用逻辑动态增删字段。

一种报文发送解析的处理方法，包括如下处理步骤：

步骤1，接收报文数据并对所接收到的报文数据进行校验；

步骤2，对校验成功后的数据进行命令解析，并根据所解析识别出的命令码调用所述命令码对应的链表；

步骤3，判断链表的位置是否为空，如果是，则结束链表识别流程，如果否，则进入下一步；

步骤4，根据链表的数据内容，判断当前字段性质是解析类型还是发送类型，如果是解析类型进入步骤5，如果是发送类型进入步骤6；

步骤5，根据步骤4的判断结果，调用对应字符并在数组中查询该字符，在字符非空的情况下，并对该字段所属数据指针位置进行赋值；

步骤6，根据步骤4的判断结果组织报文，组织报文是依据链表中数据的字符名、数据类型以及具体数据来进行；

步骤7，将链表位置加1，并进入步骤3进行再判断，对当前命令的链表进行解析遍历，直到最后一个链表时，结束循环。

可选的，所述链表通过链表结构体表示，包括数据结构体和一个指向下一个链表的地址。

可选的，所述数据结构体包含字段指针、数据类型、小数点格式、发送条件指针、数据指针、触发调用函数。

可选的，所述数据结构体允许根据使用逻辑动态增删字段。

本申请实施例的有益效果包括：一种采用循环链表处理的报文解析方案，通过链表存储命令和数据字段的信息，采用循环链表遍历的方式进行解析。这种创新的方式使得解析流程被固定化，相同协议共享同一解析流程，大幅减少了冗余的代码和重复的操作，提高了解析效率和程序的可维护性。同时，通过传入不同参数，实现了不同协议的解析，使得系统更具灵活性。在程序移植和交接方面，解析流程的固定化也带来了更高的开发效率和更低的维护成本。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的系统报文解析架构；

图2为本申请实施例提供的系统报文组织架构；

图3为本申请实施例提供的链表结构；

图4为本申请实施例提供的报文解析处理的流程步骤。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本实用新形实施方式中的附图，对本实用新形实施方式中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。

在本申请的描述中，需要理解的是，指示方位或位置关系的术语为基于附图所示的方位或位置关系，仅是为了便于描述本实用新形和简化描述，而不是指示或暗示所指的设备或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本实用新形的限制。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

在本申请中，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”、“固定”等术语应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或成一体；可以是机械连接，也可以是信号连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通或两个元件的相互作用关系。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本实用新形中的具体含义。

在各种仪器、仪器与传感器，以及上位机与仪器之间，通信是一种不可或缺的交流方式。通信的目标在于实现数据和状态的获取，以及向设备下发命令。然而，在这样的通信中，确保双方明确彼此发送和接收的内容十分重要，于是基于组织发送和数据解析的通讯协议应运而生。

报文发送和解析是在系统之间进行信息交流的关键过程，也是通讯协议规制的重要内容。发送端将数据按照协议组织成报文并通过通信渠道发送，接收端接收并解析报文以获取信息。这一流程在各种领域广泛应用，包括物联网、通信协议、传感器数据传输等，确保系统间的有效通信和数据交换。

通讯协议的类型主要分为两大类：一是使用ASCII码构成报文的协议，另一种是由16进制(hex)数据直接组成的报文。尽管这两种协议本质上相同，ASCII码协议将原始数据(例如1)转换为ASCII码表示(0x31)，而16进制协议则直接使用16进制值(如0x01)组织报文。随着软件技术的不断发展，基础编程库中涌现了对ASCII码数据进行特殊解析、分类和截断的函数。由于ASCII码的易观察性，即由ASCII码组成的报文大多数情况下能够被转换和打印输出，这使得ASCII码类型的协议在应用中占据越来越重要的地位。

当前，对于ASCII码类型的报文，主要采用以下解析方式：

校验数据：对接收到的数据进行校验，确保数据的完整性和正确性。

解析命令类型：识别报文中的命令类型，确定下一步的处理方式。

根据命令调用解析函数：如果是查询类报文，设备组织数据报文进行回复；如果是命令类报文，解析对应命令字段并调用相应函数执行命令，回复执行结果；如果是设置参数类报文，解析对应字段、转换数据，并回复设置成功与否的信息。这样的处理方式使得在通信中能够有效地执行各种操作。

在系统通信中，简洁和节约的报文数据组织和解析能有效提高效率，减小数据传输开销。精简的结构降低了通信负担，提升性能，并减少了错误和混淆的可能性。这种优化不仅提高了通信速度，还降低了系统开发和维护的成本。简洁而高效的报文处理是保障系统稳定性和可维护性的关键。当前通用的报文数据组织与解析报文的方式存在一些不够简约的缺陷，导致在调整程序或者进行程序移植时，由于存在过多的重复代码，这些操作会变得繁琐，且降低系统鲁棒性。

其中，报文数据组织和解析时的一些突出问题在于：处理每个字段的组织和解析的代码重复性太高。在程序模块中，每次解析都需要相当数量的相似函数调用编译，而且频繁的需要更改函数中需要的参数。在调整程序或者进行程序移植时，由于存在过多的重复代码，这些操作会变得繁琐。另外，由于在程序中重复输入相同的检索字符，可能会导致编译后的程序体积不受欢迎的增大。

以C语言为例，常用于组织ASCII码字符串的函数有`sprintf`、`snprintf`，它们可以设置需要转换的数据类型。而常用的报文解析函数有`strstr`、`atoi`、`atof`等，其中`strstr`可以返回对应字段在数组中的位置，而`atoi`和`atof`可以将ASCII码数据转换成不同的数据类型。

在组织报文和解析报文时，每次设置都需要手动更改函数中的数据类型，而这样的操作重复次数太多，不但比较耗时，还极为容易导致人为的失误操作。

传统的实施方式中，当想要处理报文时通常的处理过程会出现大量的简单重复操作，这里给出一个原始报文进行举例。

原始报文为

unsigned char Frame[128]＝"##QN＝20231121124223；CN＝3；TEMP＝20.5；PRESS＝101.2；FLOW＝2.45；O2＝21.2；PH＝6.86；EC＝147.23；&&FFFF\r\n"；

//注释：在数组中搜寻该字符，返回首字符位置

pcBuff＝strstr((const char*)Frame,"TEMP＝")；

//注释：如果查询字符不为空，当为空时代表数组中无该字符无需查找；

if(pcBuff！＝NULL)

{

//注释：在返回地址加该字符长度

pcBuff＝strchr(pcBuff,"TEMP＝")；

//注释：转换数据到指定的变量下

Temp＝atof(pcBuff)；

}

这里给出了一个常见处理步骤类型。主要使用了`strstr`函数，在报文数组`Frame`中查找包含"TEMP＝"的子字符串，并将结果存储在`pcBuff`中。当你想要解析此报文时，一般会定义一个字符型指针char*pcBuff；然后，如果`pcBuff`不为空(即找到了包含"TEMP＝"的子字符串)，则继续使用`strchr`函数在`pcBuff`中查找第一次出现"TEMP＝"的位置，并将结果更新给`pcBuff`。将`pcBuff`指向的字符串转换成浮点数类型，并赋值给变量`Temp`。

当想要进行类似相关解析的时候，则通常仍然需要重复上述步骤，且每次重复时，所需要的每个字段都占用4、5行代码或更多，增加的字段越多，所对应代码也越长。例如，如果系统需要再针对"PRESS＝"字段再进行解析，那么势必会需要如下代码继续进行。

pcBuff＝strstr((const char*)Frame,"PRESS＝")；

if(pcBuff！＝NULL)

{

pcBuff＝strchr(pcBuff,"PRESS＝")；

Press＝atof(pcBuff)；

}

可以发现，这段代码的结构与前面解析"TEMP＝"的代码基本相一致，因此在处理多个类似字段时都会有相似的代码结构，极易造成繁琐的重复和堆叠。

在发送数据时，也会遇到类似的问题。例如，当发送一段报文时，上述报文中的组织代码，通过`sprintf`函数将数据格式化添加到报文数组`frame`中。`Num`是一个计数器，用于记录当前数组位置。代码组织为

Num＝0；

Num+＝sprintf(frame+Num,"##QN＝％04d％02d％02d％02d％02d02d；",year,month,day,hour,minute,second)；

//注释：前面输入数据的格式，后面输入参数

//注释：这样单独一长条式的组织报文或者下列一句一句的发送，为了观看查找代码方便一般都会尽量缩短代码，采取下列的方式

Num+＝sprintf(frame+Num,"CN＝％d；TEMP＝％.1f",cn,Temp)；

Num+＝sprintf(frame+Num,"PRESS＝％.1f；FLOW＝％.2f",Press,Flow)；

Num+＝sprintf(frame+Num,"O2＝％.1f；",o2)；

Num+＝sprintf(frame+Num,"PH＝％.2f；",ph)；

Num+＝sprintf(frame+Num,"EC＝％.2f；",ec)；

Num+＝sprintf(frame+Num,"％s",”&&FFFF\r\n”)；

这样就组织好了一句报文，上述发送解析代码需要对同一函数重复使用，每多一个字段就多一行代码，极大的增加了组织解析报文时可能存在误写错的概率，例如有时一个参数既要发送也要解析，就极为容易存在忘记在另一地方添加的情况。

此外，当移植程序时，需要重新删除修改，即解析流程本身，亦可能被误更改，导致软件出错。

本发明技术方案中，提出一种报文发送与解析的具体处理方法，参照图1-2，给出该方法中所使用报文解析的具体系统架构。

参照图1，在本申请的系统架构中，用于解析报文时的具体操作过程如下：

1.接收数据：从通信渠道(如串口、网络等接收模块)接收原始报文数据；此过程可以包括缓存动作，用于将接收到的数据暂时缓存，等待完整的报文。

2.校验报文：通过校验模块对接收的报文数据进行校验，校验过程可以包括检查数据完整性等内容，判断接收到的数据是否包含完整的报文。也可以通过检查报文起始标志和结束标志、计算校验和或CRC等方式进行检查。

如果校验过程未能通过，丢弃接收到的数据，结束本次报文解析流程，等待下一次接收；

如果校验过程通过(校验成功)，则进入下一步，继续进行报文解析。

3.命令解析与链表解析：通过命令解析模块对校验成功后的报文内容进行解析，解析报文内容可以包括提取报文的有效内容，定位报文中的命令码等；通过链表遍历模块进行查找对应链表操作，根据命令码查找相应的链表结构，该链表包含了该命令所需的字段信息。链表查找中，需要遍历链表内容，解析报文中的各个字段以完成报文解析动作。

4.回复数据：根据上一步骤解析得到的信息内容，可以生成需要回复的数据。这可能涉及到组织响应报文、更新系统状态等操作。将生成的回复数据通过相同的通信渠道发送给对方。最后结束报文接收端的解析过程。清空接收数据的缓存，进入等待状态，准备接收下一次数据。

同样地，参照图2，给出了在本申请的系统架构中，用于发送报文时的具体处理过程如下：

1.确定需要发送的数据或命令

首先，通过接收模块接收数据，并经过校验模块校验数据，确定需要发送的数据或命令，这可能是传感器采集的数据、系统状态信息，或者是需要向其他设备发送的命令。

本申请实施例中，需要注意的是，如果此时将系统作为从机即下位机，那么需要通过接收模块接收数据；而如果系统作为上位机，则不需要先接收数据，上位机自身可作为数据源，可以直接确定需要发送的数据或命令。

2.根据命令调用对应链表

根据确定的命令，通过查找相应的链表结构，找到与该命令相关联的链表。这个链表包含了该命令所需的字段信息。

3.根据数据组织报文内容

从链表中获取需要发送的数据，并根据协议规定的格式将数据组织成一个完整的报文，包括报文头尾报文组织。这可能包括在数据前后添加起始标志、结束标志、设备地址、协议版本号、确定字段之间的分隔符等。

4.回复数据

在需要的情况下，等待接收目标设备或系统的回复。这通常在需要确认报文是否成功发送或获取远程设备的响应时使用。如果有回复，接收并解析回复的报文数据，获取对方的应答信息。根据接收到的回复数据，执行相应的处理。这可能包括更新系统状态、触发事件、记录日志等操作。

引入链表在通信双方报文解析的系统架构中，简化了通讯逻辑的展现、模块移植和交接。通过该通讯系统架构使得报文解析过程更加方便、简洁。使用本架构可以使得通讯流程被固定化，相同协议共享统一解析流程，无需重复操作。通过传入不同参数就可以实现不同协议的解析过程。例如，程序移植操作中，由于解析流程固定，只需修改原始设定参数，即可快速实现不同协议的移植。程序交接也更高效，流程固定化使得对方修改时只需定位到相应参数并进行更改。所有协议流程参数在一处定义，降低了误更改的风险。

以下本申请将更具体的结合具体实施例来阐述该系统架构带来的技术优势。

参照图3，本申请中，每个协议中所需的字段通过链表结构体表示，包括数据结构体和一个指向下一个链表的地址。数据结构体包括字段指针、数据类型、小数点格式、发送条件指针、数据指针、触发调用函数等。这样的数据结构允许根据使用逻辑动态增删字段。

-字段指针：指向协议中定义的命令或数据的字段数组。

-数据类型：代表命令或数据在协议中定义的数据类型，可以是无符号8位二进制数、浮点数，或自定义的数据类型格式。

-处理类型：表示该字段在报文处理流程中如何处理，包括解析、发送或两者皆有。

-小数点格式：若数据为浮点数类型，指定小数点的位数，平衡数据精度和报文长度。

-数据指针：指向数据的首地址。

-触发调用函数：每次收到或发送该字段时，调用的函数或者对某一标志赋值，在其他地方根据该标志调用函数或者进行判断。

在定义数据时，按上述格式进行定义。需要定义下一个链表时，向系统申请空内存存储下一个链表数据。由于每种命令所包含的字段名称个数不同，因此每种命令的链表都单独定义。可以通过链表定义实现每个命令的链表长度不同，也可以通过创建函数返回每个命令对应链表的首地址。为了节省内存空间，可以定义一个空数组，每次需要处理对应命令时，重新将该命令下所有链表数据绑定至空数组，实现功能并节省内存。

本发明方案中，报文解析结构体可以通过两种方式进行定义。

第一种方式：-报文头函数指针、报文尾函数指针、报文校验函数指针、报文组织函数指针、报文解析函数指针、链表数组、无回复响应结构体、报文发送函数指针、串口初始化函数指针等。

第二种方式：-发送格式、链表数组、无回复响应结构体、报文发送函数指针、串口初始化函数指针等。

这两种定义结构体的方式有所区别。第一种方式每次更换协议或移植时只需更换报文头组织函数、报文尾组织函数、报文校验函数，然后更改报文组织函数和解析函数即可。使用函数指针方式使得后续更改方便，只需修改一处即可替代所有调用函数。第二种方式将所有报文头、报文尾等函数全部归于发送格式下，即不同发送格式对应不同协议。相似的协议可以共用部分函数，根据选用的发送格式调用相应的函数进行报文组织和解析。

本发明中两种结构体的方式各有特点。第一种方式支持的协议较少但更加简洁，第二种方式支持的协议多但需要创建更多的相关函数。无论哪种方式，都可以实现简便的协议报文组织和解析。

无回复响应结构体包含了发送命令后或一段时间没有接收到响应时的处理结构体，其中有接收标志和计时标志。当有命令下发时，标志被置为1，计时标志开始计时。每次接收到回复时，将标志清零。若一直没有回复，当计时标志超过设定时间后，重新发送上次命令。

以下对照上述传统数据报文解析过程，给出本发明的进行循环链表处理的报文解析方案。

参照图4，当系统接收到一包完整的数据，先对数据进行校验，校验通过后进行解析处理。本发明在数据报文处理时的步骤为：

步骤1，数据接收和校验：系统接收到完整报文数据后，首先对报文数据进行校验，以确保数据的完整性和准确性；

步骤2，识别当前命令对应的链表：对校验成功后的数据进行命令解析，并根据所解析识别出的命令码调用命令码所对应的链表；

步骤3，判断链表的位置是否为空，如果是，则结束链表识别流程，如果否，则进入下一步；

步骤4，对字段性质进行判断：根据链表的数据内容，判断当前字段性质是解析类型还是发送类型，如果是解析类型进入步骤5，如果是发送类型进入步骤6；

步骤5，根据步骤4的判断结果，调用对应字符并在数组中查询该字符，在字符非空的情况下，并对该字段所属数据指针位置进行赋值；

步骤6，根据步骤4的判断结果组织报文，组织报文是依据链表中数据的字符名、数据类型以及具体数据来进行；

步骤7，将链表位置加1，并进入步骤3进行再判断，对当前命令的链表进行解析遍历，直到最后一个链表时，结束循环。

通过以上这种方式，即用一个循环遍历的方法来代替单次重复的操作过程，能够有效的降低系统代码冗余；通过固化流程，提升系统的移植和交接性能。

以下给出本发明方案的实际报文处理案例。

如报文为

Frame[128]＝"##QN＝20231121124223；CN＝3；TEMP＝20.5；PRESS＝101.2；FLOW＝2.45；O2＝21.2；PH＝6.86；EC＝147.23；&&FFFF\r\n"；

只需定义初始化参数

Node*list；//定义链表指针

list＝nNode[E_CN_DATA]；//绑定获取数据命令链表

//定义数据

NodeInit(list,”QN”,E_DATA_TYPE_TIME,E_POINT_NO,E_PROCEE_SEND,(u8*)&Time,(u8*)&u8MustSend,No_Fun)；

NodeInit(list,”CN”,E_DATA_TYPE_U8,E_POINT_NO,E_PROCEE_SEND,(u8*)&cn,(u8*)&u8MustSend,No_Fun)；NodeInit(list,”TEMP”,E_DATA_TYPE_FLOAT,E_POINT_1,E_PROCEE_SEND,(u8*)&temp,(u8*)&u8MustSend,No_Fun)；

NodeInit(list,”PRESS”,E_DATA_TYPE_FLOAT,E_POINT_1,E_PROCEE_SEND,(u8*)&press,(u8*)&u8MustSend,No_Fun)；

NodeInit(list,”FLOW”,E_DATA_TYPE_FLOAT,E_POINT_2,E_PROCEE_SEND,(u8*)&flow,(u8*)&u8MustSend,No_Fun)；

NodeInit(list,”O2”,E_DATA_TYPE_FLOAT,E_POINT_1,E_PROCEE_SEND,(u8*)&o2,(u8*)&u8MustSend,No_Fun)；

NodeInit(list,”PH”,E_DATA_TYPE_FLOAT,E_POINT_2,E_PROCEE_SEND,(u8*)&ph,(u8*)&u8MustSend,No_Fun)；

NodeInit(list,”EC”,E_DATA_TYPE_FLOAT,E_POINT_2,E_PROCEE_SEND,(u8*)&ec,(u8*)&u8MustSend,No_Fun)；

上述定义函数内的参数依次是链表地址，字段名，数据类型，小数点格式，数据处理类型，数据指针，发送条件指针，调用函数指针。

只需按上述定义初始化参数，然后解析时，读取对应的参数，使用下述的统一固化流程，实现协议的便捷解析处理。

解析发送流程：

即按照固定的数据定义格式，则只需上述代码，不管协议有多少的字段，都可实现所有的解析或发送流程。任何命令的增删只需增加删除相应的链表初始化，报文处理流程无需更改。

发送数据函数Send_data以及解析获取数据函数Get_data，都将调用链表初始化所定义的参数，来实现功能，即流程固定化，只需调整参数，即可实现不同的程序效果。

本发明技术方案的优势在于将参数标准化后，添加删除参数将更加的方便，移植修改更加简单，用链表循环的方式，修改起来更加灵活，任何字段的增删，修改定义只需在一处修改即可，其他任何功能，都将跟随定义内容自动更改。

通过本发明的实施方案，可以较大的节省代码空间，之前一个字段需要占用多条代码来实现功能，现在通过共用代码，将其他字段的重复命令节省下来，尤其对于字段较多的协议来说，将会更加有益。

此外，通过本发明的实施方案，可以减少编译后的程序大小，经过实际对比，例如对于a项目的程序，在更改代码书写格式前，编译后的程序文件有73k大小，更改后则只有32k大小；对于b项目，更改前有94k，更改后，变为59k；对于c项目，更改前有98k的大小，重新调整后，编译的程序文件只有65k。每个程序文件基本减小了30-40k不等的flash存储空间。

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

Claims (10)

1.一种报文发送解析的处理系统，其特征在于，所述处理系统包括：

接收模块，用于接收报文数据；

校验模块，用于对所接收到的报文数据进行校验；

命令解析模块，用于对校验成功后的数据进行命令解析；

链表遍历模块，根据命令解析内容查找相对应的链表，并对链表进行循环遍历处理，直到最后一个链表时，结束循环；

数据回复模块，在链表的执行过程中，生成回复数据，回复数据的内容和格式根据协议和具体业务逻辑而定。

2.根据权利要求1所述的报文发送解析的处理系统，其特征在于：所述处理系统还包括报文组织模块，根据协议规定的格式将数据组织成一个完整的报文，其中包含报文头尾的报文组织。

3.根据权利要求1所述的报文发送解析的处理系统，其特征在于：所述链表遍历模块中包括有判断模块，根据链表数据内容，判断当前字段是进行解析还是组织报文发送。

4.根据权利要求3所述的报文发送解析的处理系统，其特征在于：所述链表通过链表结构体表示，包括数据结构体和一个指向下一个链表的地址。

5.根据权利要求4所述的报文发送解析的处理系统，其特征在于：所述数据结构体包含字段指针、数据类型、小数点格式、发送条件指针、数据指针以及触发调用函数。

6.根据权利要求5所述的报文发送解析的处理系统，其特征在于：所述数据结构体允许根据使用逻辑动态增删字段。

7.一种报文发送解析的处理方法，其特征在于，包括如下处理步骤：

步骤1，接收报文数据并对所接收到的报文数据进行校验；

步骤2，对校验成功后的报文数据进行命令解析，并根据所解析识别出的命令码调用所述命令码对应的链表；

步骤3，判断链表的位置是否为空，如果是，则结束链表识别流程，如果否，则进入下一步骤；

步骤4，根据链表的数据内容，判断当前字段性质是解析类型还是发送类型，如果是解析类型则进入步骤5，如果是发送类型则进入步骤6；

步骤5，根据步骤4的判断结果进行数据解析，调用对应字符并在数组中查询该字符，在字符非空的情况下，对该字段所属数据指针位置进行赋值，完成后进入步骤7；

步骤6，根据步骤4的判断结果组织报文，组织报文是依据链表中数据的字符名、数据类型以及具体数据来进行，完成后进入步骤7；

步骤7，将链表位置加1，转入步骤3进行循环再判断，对当前命令的链表进行解析遍历，直到最后一个链表时，结束循环。

8.根据权利要求7所述的报文发送解析的处理方法，其特征在于：所述链表通过链表结构体表示，包括数据结构体和一个指向下一个链表的地址。

9.根据权利要求8所述的报文发送解析的处理方法，其特征在于：所述数据结构体包含字段指针、数据类型、小数点格式、发送条件指针、数据指针、触发调用函数。

10.根据权利要求9所述的报文发送解析的处理方法，其特征在于：所述数据结构体允许根据使用逻辑动态增删字段。