报文模拟测试(含8583)工具介绍
8583报文解析
8583报文解析
8583报文解析是指对银行卡交易中所使用的8583报文进行分析和解码的过程。
8583报文是一种二进制格式的结构化数据，在银行卡交易中扮演着重要的角色。
通过对8583报文的解析，可以获取交易中所包含的必要信息，如交易类型、交易金额、交易时间等，从而实现交易的成功。
8583报文由多个域(field)组成，每个域包含了特定的信息。
其中，前4个域为固定域，分别为消息类型标识符、位图、主帐号(PAN)、交易处理码。
后续的域则根据交易类型的不同而有所变化，如消费交易会包含卡有效期、商户号、终端号等域。
对于每个域，都有特定的长度和格式要求，例如主帐号域为16位数字字符，交易金额域为12位数字字符等。
在解析8583报文时，需要先解析出位图域，确定哪些域存在于该报文中。
然后根据位图的内容，按照顺序解析出各个域的信息。
在解析过程中，需要注意各个域之间的关联关系和数据类型的转换。
总之，8583报文解析是银行卡交易中必不可少的环节，对于保障交易的正确进行具有重要作用。
- 1 -。
8583报文实例
18583报文1.1数据包格式ISO 8583金融交易信息数据包由信息类型（MSG＿TYPE＿ID）、一个或多个位图（BIT＿MAP）和按位图描述的顺序排列的数据元序列（ELEMENTS）等三段组成。
信息类型是一个4位数字的数字型字段，用来描述每一个交易信息的类别和功能，其中前两位数字标明信息类别，如授权信息、金融交易信息、管理信息，等等。
在一个金融系统中，信息类型的定义应该是唯一的，无二义性的。
网间交易具有不同的信息类型定义时应在交换报文的发送前和接收后完成类型转换处理。
位图由64位二进制比特位构成，每一位用1或0来表示与该比特位相对应的数据元存在或不存在。
位图的第一位为1时，表示64位的位图后紧接着一个扩展的64位位图。
本实施规范未使用扩展位图。
数据元指交易中一个数据项的实际内容，数据元在数据包中是否存在及存放位置由位图中的相应比特位确定。
一些数据元有固定的长度，一些数据元为变长项。
具有可变长度类型的数据元应在实际数据之前附加标明长度的前缀字节。
1.2符号定义本规范使用以下标识符来说明数据元的属性：1.2.1一般描述1.2.2长度属性1.2.3数据元值ASCII 表示该字段采用ASCII码表示，长度按字节计。
BCD 表示该字段采用BCD码表示，即每四比特位表示一数据位。
BIN 二进制数据，长度按比特位表示。
1.2.4数据属性1.2.5数据项使用规则a)所有独立的数据项按整字节计算。
b)以BCD码（Binary Code Decimal）表示的n型数据项，奇数长度（固定长度）n型数据项以字节边界右靠，左填0；例1234567表示为01234567共4个字节。
可变长度n型数据（如主帐号域）以字节边界左靠，右填0;例：1234567表示为1234570共4个字节。
c)可变长度数据项的长度域，以独立数据项n型数对待。
例LL 表示为ll一个字节，LLL表示为0lll共2字节。
d)z型数据项与n型数据项类似，为16进制数据。
8583报文
8583报文（64域报文）●域：域是一种管理边界，用于一组计算机共享共用的安全数据库，域实际上就是一组服务器和工作站的集合。
域在文件系统中，有时也称做“字段”，是指数据中不可再分的基本单元。
一个域包含一个值。
如学生的名字等。
可以通过数据类型（如二进制、字符、字符串等）和长度（占用的字节数）两个属性对其进行描述。
LLV AR，用1位字节定义数量，LLLV AR,是2位字节表示数量，比如0x01,0x04 = 104域也就是这样的，一共有64个域，每个域预先定义了内容和长度有一个叫做BITMAP的，也就是位图，定义了一个数据包里包含了几个域。
举个例子：20 00 38 00 00 00 00 34你把它解开，排列一下20 = 0010 000000 = 0000 000038 = 0011 1000依次类推，得到一串数字：0010 0000 0000 0000 0011 1000 0000 0000 0000 0000 0000 0000 0000 0000 0011 0100然后从左到右数一下里头含有1的是那几位，上面的例子我们得到3 19 20 21 59 60 62 ,这几位含有1。
也就是说接下来的报文包含有这几个域。
●实例：比如消费交易，需要上送交易类型，卡号等等，定义如下卡号第2域LLV AR BCD 5309987876545342交易类型第3域长度6 BCD 900000金额第4域长度12 BCD 100分时间第7域长度8 BCD 200308022磁道信息第35域LLV AR ASCII 1234563磁道信息第36域LLLV AR BCD 123456001商户号第41域LLV AR ASCII 98765432现在开始打包：首先按照长度和类型把上面的数据处理一下卡号165309987876545342交易类型900000金额000000000100时间200308022磁道063132333435363磁道0009123456001商户号083938373635343332接下来我们按照域信息生成位图：有第2域，第二个位置是1，有第三域，第三个位置是1，……依此类推得到一串数字：0111 0010 0000 0000 0000 0000 0000 0000 0011 0000 1000 0000 0000 0000 0000 0000 转换过来，就是：72 00 00 00 30 80 00 00 这个就是BITMAP了然后把上面的数据按照BITMAP+每个域的内容，依次排列就得到这个包的内容了：720000003080000016530998787654534290000000000000010020030802063132333435360009123456001083938373635343332前头再加上TPDU和MSGID就是最后的数据包。
8583报文解析实例
8583报文解析实例8583报文解析实例：以下是主机从网控器收到的消费数据包（用二位十六进制数表示一个字节）：0201 0630 30 30 30 3000 06 30 30 30 30 30 31| 03 22备注：|…|之间是8583数据包（|是人为加的）;颜色只作为各个域区分，没其他含义。
解包分析：02 表示是数据开始01 06 表示后面数据长度为106个字节（在06到结束符03之间，不包括03字符,即8583包)60 00 07 08 08 是网控tpdu的地址02 00 8583包开始，表示交易信息码 message_id消费信息码为020030 20 05 00 20 c0 02 01 是数据包的位图，8个字节，64位，3的二进制0011第一位为0，所以没有扩展位图,二进制展开后如下域有信息： 3 4 11 22 24 35 41 42 52 60 61 6203 是数据结束？？31 是crc校验：02后面开始，即从01开始到03之间字？？节（包括03）异或的结果。
？？数据元解包分析：实据元是从位图后开始，到03结束之前。
位图分析有3 4 11 22 24 35 41 42 52 60 61 62 域的信息格式说明:a表示字符，n表示数字，s表示特殊字符，b二进制数据第3域：名称：处理代码格式：n6（固定长度为6的数字）截取字符：00 40 00原始数据：“004000”。
第4域：名称：交易金额格式：n12截取字符：00 00 00 00 99 80原始数据：99.80第11域：名称：系统流水号格式：n6截取字符：00 00 01原始数据：000001第22域：名称：服务点方式格式：n3截取字符：00 21原始数据: “021”第24域：名称：国际网络识别符格式：n3截取字符：00 03原始数据：“003”第35域：名称：第2磁道数据格式：llvar长度为37，取整后有19个字符截取字符：37 62 14 02 10 00 07 41 50 78 d1 56 07 12 20 10 00 00 00 00原始数据：62 14 02 10 00 07 41 50 78 d1 56 07 12 20 10 00 00 00 0第41域：名称：终端号格式：ans8 （字母，数字，特殊字符皆可,长度为8）截取字符：31 32 33 34 35 36 37 38原始数据：“12345678”第42域：名称：商户号格式：ans15截取字符：30 34 33 20 20 20 20 20 20 20 20 20 20 20 20原始数据：“043”第52域：名称：个人密码格式：b64 (表示二进制数据64位)截取字符：c5 8e b2 00 18 03 1e 9a原始数据：c5 8e b2 00 18 03 1e 9a第60域：名称：保留使用（实际存放pos的批次号）格式：lllvar长度为00 06截取字符：00 06 30 30 30 30 30 31原始数据：“000001”第61域：名称：保留使用（实际存放操作员和操作员密码）格式：lllvar长度为00 06截取字符：00 06 30 30 30 30 30 30原始数据：“000000”00操作员，0000密码第62域：名称：保留使用（实际存放pos的票据号）格式：lllvar长度为00 06截取字符：00 06 30 30 30 30 30 31原始数据：“000001”。
CEB8583报文接口说明
CEB8583报文接口说明1 概述1.1 前言目前国内各大A TM厂家提供不同的A TM接口标准。
由于缺乏规范和控制，严重地阻碍了金融电子化的实施。
为了改变这种工作方式，在此规范一个终端接口标准。
这个接口标准具有以下几个特点：1、标准化：所有交易使用国际金融标准ISO8583。
2、规范化：所有交易及控制都提供明确的流程。
3、公开性：所有的加密算法都明确规定。
为了改变终端软件的质量，减少各家用户的协调工作，任何一家终端厂家必须严格遵守此终端标准。
我们希望通过努力，使各大银行逐步具备自己的终端规范。
1.2 应用范围本文件描述服务器网络的外部报文格式和交易过程的报文流程，供入网单位开发接口程序时使用。
ISO8583是国际标准化组织推荐用于交换中心和成员行主机通讯的报文格式，本手册介绍服务器网络对ISO8583标准的解释和实现。
在阅读本文时，用户应参考ISO8583（1987）文本。
1.3 支持的通信协议TCP/IP1.4 网络构成说明主机CRS DDN/FR/X.25A TM CDM …………网络拓扑结构图2 交易术语、符号说明2.1 消息类型说明ISO8583标准定义了几类消息来确定交易类型，在服务器系统中使用的报文类型有以下几种：除03XX、08XX、90XX报文类型外的其它所有报文类型都需要MAC校验。
02XX02XX类消息用于金融请求，被批准的金融交易的请求消息可用于立即对持卡人帐户的记帐处理。
包括：ATM/柜台-- 存款、取款，余额查询，（本系统内帐户间）转帐，IC卡圈存、圈提、代交费、发卡等。
注：以上交易需要提供密码。
02XX支持的信息：0200 金融交易请求，0200消息要求对方以0210消息作为其应答。
0201 金融交易请求的重发，0201消息要求对方以0210消息作为其应答。
0210 金融交易请求应答，对0200金融交易请求必须用它来回答。
03XX03XX类消息用于在服务器和终端之间传送文件更新数据。
系统报文精品解析讲稿
金融系统ISO8583报文精品解析讲稿ISO8583报文理解，举个例子就是农行与VISA网络之间通讯，各个银行间通讯，ATM或POS通讯都是这个ISO8583报文。
再比如第三方支付网银在线与银行之间的通讯报文也是8583。
1234567891011121314面贴片元件的手工焊接技巧现在越来越多的电路板采用表面贴装元件，同传统的封装相比，它可以减少电路板的面积，易于大批量加工，布线密度高。
贴片电阻和电容的引线电感大大减少，在高频电路中具有很大的优越性。
表面贴装元件的不方便之处是不便于手工焊接。
为此，本文以常见的ＰＱＦＰ封装芯片为例，介绍表面贴装元件的基本焊接方法。
一、所需的工具和材料焊接工具需要有２５Ｗ的铜头小烙铁，有条件的可使用温度可调和带ＥＳＤ保护的焊台，注意烙铁尖要细，顶部的宽度不能大于１ｍｍ。
一把尖头镊子可以用来移动和固定芯片以及检查电路。
还要准备细焊丝和助焊剂、异丙基酒精等。
使用助焊剂的目的主要是增加焊锡的流动性，这样焊锡可以用烙铁牵引，并依靠表面张力的作用光滑地包裹在引脚和焊盘上。
在焊接后用酒精清除板上的焊剂。
二、焊接方法 1．在焊接之前先在焊盘上涂上助焊剂，用烙铁处理一遍，以免焊盘镀锡不良或被氧化，造成不好焊，芯片则一般不需处理。
2．面贴片元件的手工焊接技巧现在越来越多的电路板采用表面贴装元件，同传统的封装相比，它可以减少电路板的面积，易于大批量加工，布线密度高。
贴片电阻和电容的引线电感大大减少，在高频电路中具有很大的优越性。
表面贴装元件的不方便之处是不便于手工焊接。
为此，本文以常见的ＰＱＦＰ封装芯片为例，介绍表面贴装元件的基本焊接方法。
一、所需的工具和材料焊接工具需要有２５Ｗ的铜头小烙铁，有条件的可使用温度可调和带ＥＳＤ保护的焊台，注意烙铁尖要细，顶部的宽度不能大于１ｍｍ。
一把尖头镊子可以用来移动和固定芯片以及检查电路。
还要准备细焊丝和助焊剂、异丙基酒精等。
使用助焊剂的目的主要是增加焊锡的流动性，这样焊锡可以用烙铁牵引，并依靠表面张力的作用光滑地包裹在引脚和焊盘上。
ISO8583报文解包和组包
javabytestringexceptionnulllist
一：IS08583包介绍：
ISO8583包（简称8583包）是一个国际标准的包格式，最多由128个字段域组成，每个域都有统一的规定，并有定长与变长之分。
8583包前面一段为位图，用来确定包的字段域组成情况。其中位图是8583包的灵魂，它是打包解包确定字段域的关键， 而了解每个字段域的属性则是填写数据的基础。
{37,1,12,0},
{39,1,2,0},
{40,2,50,2},
{41,1,8,0},
{48,1,52,3},
{120,2,128,3},
};
｝
四：定义BitMapiso类
类说明：此类提供解析请求包和封装信息包两个方法，例如：
package com.lottery.pos.utils;
map = new byte[16];
System.arraycopy(realbody, 0, map, 0, 16);
} else {
map = map8;
}
boolean[] bmap = LoUtils.getBinaryFromByte(map);
System.arraycopy(realbody, tmplen, nextData, 0,nextData.length);
tmplen += nextData.length;
} else {
nextData = new byte[config[bit][2]];
byte[] map8 = new byte[8];
解析ISO8583报文实例
解析ISO8583报文实例（Pos应用）现在我们有ISO8583报文如下(十六进制表示法)：60 00 03 00 00 60 31 00 31 07 30 02 00 30 20 04 C0 20 C0 98 11 00 00 00 00 00 00 00 00 01 00 03 49 02 10 00 12 30 62 25 82 21 12 99 63 01 5D 15 11 10 10 00 00 35 36 38 35 32 33 31 34 32 33 35 32 31 34 35 32 36 38 35 39 32 33 36 31 35 36 C6 24 83 4D 36 7E 9E 9E 20 00 00 00 00 00 00 00 00 13 22 00 00 08 00 05 00 36 37 41 32 32 39 39 41第一步POS终端上送POS中心的消息报文结构包括TPDU、报文头和应用数据三部分：——TPDU说明：长度为10个字节,压缩时用BCD码表示为5个字节长度的数值。
——报文头说明：总长度为12字节，压缩时用BCD码表示为6个字节长度的数值。
——应用数据说明：一般长度都是4个字节，压缩时用BCD码表示为2个字节的长度的数值。
所以上述报文中前五个字节为TPDU，即60 00 03 00 00报文头占用六个字节，即60 31 00 31 07 30应用数据占用2个字节，即02 00 也就是"0200"——0200金融类请求消息：●POS查询请求。
●POS消费请求。
●POS消费撤销请求。
●POS预授权完成（请求）请求。
●POS预授权完成撤销请求。
●电子现金脱机消费请求。
●分期付款消费请求。
●分期付款消费撤销请求。
●基于PBOC电子钱包/电子现金的IC圈存类交易请求。
●磁条卡现金充值请求。
第二步分析位图：首先取第十四个字节，即0x30 ，转化为二进制为0011 0000，在该字节的第一位为0（从左往右）表示当前报文中只需包括64个域，也就是从当前字节开始连续8个字节为位图（包括当前字节），如要包括128个域，该位为1。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
回归测试工具用户手册目录目录 (2)工具描述 (4)功能特点 (5)适用范围 (6)文件目录结构说明 (7)case目录 (7)file目录 (7)ini目录 (7)log目录 (8)report目录 (8)主界面 (8)使用说明 (9)密钥配置界面 (9)通讯参数配置界面 (10)修改案例界面 (11)文本模式修改界面 (12)设置案例集界面 (12)报文属性设置 (13)常量设置界面 (14)发送案例 (15)发送次数 (15)清空 (15)终止发送 (15)清空日志 (15)文件格式说明 (16)config.ini 例子 (16)Case.ini 例子 (16)iso.ini 例子 (17)交易文件的配置 (18)正交易配置 (18)反交易配置 (19)可选配置 (20)支持函数列表 (21)String (21)time (21)Req (21)Rev (21)Def (21)Tlv (22)Tlvasc (22)更新计划 (23)修改记录 (23)工具描述系统用Visual C++软件开发而成，数据存储采用文本文件进行保存，便于开发测试人员修改、共享测试案例。
本软件可以模拟不同类型的交易报文，可以对交易测试案例进行统一管理，并可以进行简单时间统计和成功率统计。
使用本软件可以减轻传统测试过程中的修改-编译-测试-的循环等待时间，在测试过程中可以根据需要随时更改报文内容。
本软件支持任意格式的报文，可以模拟不同格式的报文，如定长，变长，XML,8583等报文。
每个域的内容可以是常量，也可以支持约定的表达式。
本软件可以根据需要设置对应答相关域进行合法性检查，可以校验应答报文和请求报文的匹配关系，可以校验域的长度，校验域的内容等。
本软件支持MAC的生成、校验以及PIN加密处理，同时可以根据需要调整是否需要进行MAC和PIN加密。
本软件运行程序无需安装，只需将相关程序和测试案例文件拷贝到相应的文件夹下即可执行。
本系统目前局限性如下：目前仅对8583格式报文进行了解包处理，显示应答报文的各个域和内容；而对于其他非8583的报文仅仅列出发送报文和接收报文的实际内容。
目前通讯协议仅支持短连接协议；因此目前对于多条发送只能逐条进行发送，暂不支持并发。
功能特点本软件主要功能实现全部基于脚本编写，改造方便，可自由扩充功能。
脚本支持常用语法if/elseif/else if/end if , while/end while , for/end for等。
脚本支持常用字符串功能string.len(),string.format()等。
脚本支持常用时间处理功能time.format(),time.clock()等。
脚本支持扩展动态库。
脚本支持用户自定义函数。
暂只提供经编译后的脚本(*.e文件）需要更多功能请联系作者：部分函数示例：。
其中case.ini 指定了案例的文件，在选择案例的时候根据输入内容查找到对应的案例文件。
其中iso.ini 为相应的8583配置接口。
其中*.txt为相应的案例配置文件。
file目录存放每笔交易报文信息，用于匹配原交易报文内容。
ini目录Const.ini 常量配置文件，配置相关常量信息Errmsg.ini 错误代码配置文件，配置错误代码和错误提示信息Seq.ini 流水号配置文件，存放交易流水号Key.ini 密钥配置文件，存放交易密钥信息log目录存放日志信息，日志信息统一按照日期进行存放，便于查看。
report目录存放案例回归测试日志信息和统计信息。
主界面本软件启动后，主界面显示如下所示：刷新：刷新案例文件目录。
增加案例：新建交易案例。
修改案例：对案例进行修改。
修改：对指定的文件内容进行修改。
报文属性：设置报文的属性。
删除案例：删除交易案例。
回归设置：对案例集进行回归配置。
常量设置：对常量内容进行配置。
使用说明密钥配置界面通过该界面可以手工设置对应的终端（机构）的主密钥，PINKEY和MACKEY的相关信息。
增加功能PIKLEN（设定PINKEY的长度，单倍长度为16，双倍长度为32)通讯参数配置界面设置某类交易规范的通讯信息和其他配置信息。
日志级别：设置日志显示的级别，从0-9，级别越高，显示的提示信息越多。
主机地址：设置交易发送的主机地址。
端口：设置交易发送的主机端口。
信息头数据：设置交易报文的信息头报文内容。
报文长度属性：设置交易报文的长度属性（属性+长度,a4：4位ASCII，b2：2位BCD)。
最大域个数：设置交易报文的最大域个数。
MAC域：设置MAC所对应的域。
PIN域：设置PIN所对应的域。
是否MAC加密：设置是否需要MAC校验。
是否PIN加密：设置是否需要PIN校验。
密钥关联域：设置密钥的取值关联域。
原子数据域：设置密钥的原始数据关联域。
原始数据组成：设置原始数据域的组成内容。
密钥应答域：设置密钥的应答域，即签到交易从该域中取的密钥的信息，进行更新密钥。
修改案例界面通过界面的模式对交易案例进行修改，修改后保存即可。
域：待设置的域，并赋值。
子项：设置域的子项，并指定值。
检查标志：设定请求，应答X,_,M等类别（X：必须无，M：必须有，_：应答必须同请求）文本模式修改界面直接对案例配置文件进行修改，修改完毕后点击保存。
设置案例集界面设置案例集，左边显示的是目前已经配置好的案例，右边是待发送的回归案例集。
通过拖拽的方式可以实现案例的发送顺序。
报文属性设置配置每个域的属性，类型，长度已经描述信息。
常量设置界面配置交易的常量信息交易发送时从配置的常量信息表中获取相关的结果进行组包发送其中@string.format为字符串格式化@time.format为时间串格式化发送案例发送次数设置发送的次数，进行循环发送清空清空界面显示的提示信息终止发送终止目前的交易清空日志清理多余的交易日志文件格式说明config.ini 例子Case.ini 例子iso.ini 例子类型为LLVAR ：长度按2位打包类型为LLLVAR ：长度按3位打包类型为其他：不进行长度位打包aa ：长度asc ，数据ascbb ：长度bcd ，数据bcdab ：长度asc ，数据bcdba ：长度bcd ，数据asc交易文件的配置正交易配置配置格式为：域(.子域)=内容若内容为空则取常量中的设置反交易配置冲正（撤销，退货）交易配置文件例子：&指引用原交易域，必须指定REV，设置原交易的文件名&req 指仅引用原交易请求域&resp 指仅引用原交易应答域，必须有应答报文后存在该值。
可选配置[CHECK]可选，可以通过界面配置或者直接修改文件[SCRIPT]可选，只能修改文件例子1：string.format类似C语言中的sprintfstring.format("%s","123") 123string.format("%s%s","123","456") 123456string.len类似C语言中的strlenstring.len("abcd\n1234") 9String.len("\01\02\03\04\05") 5timetime.format类似C语言中的time格式time.format("%Y%m%d %H：%M：%S") // YYYYMMDD HH:MM:SS time.time类似C语言中的timetime.clock类似C语言中的clockReqreq表示请求域如req(1) 表示请求1域的内容Rev@rev(field [,flag] )rev表示原交易的域内容（flag参数可选）Flag不填先取请求域，如无请求则再取应答域的内容Flag=1 特指原交易请求flag=2 特指原交易应答如rev(2) 表示只取请求2域的内容rev(39,2) 表示只取应答39域的内容Defdef表示取常量设置中的内容如：def("cardno") 取常量中设置的cardno对应的内容def(2）取常量中设置的2对应的内容Tlvtlv表示设定(tag-length-value)的格式@tlv(tag,value,[flag])flag参数可选，取值为aa,ab,bb,ba中任一，默认flag为bb分别对应于tag是否压缩（b压缩，a否），value是否压缩（b压缩，a否）即tag压缩（如“9F26”->“0x9f,0x26)”，value压缩（如"abcd" -> "0xab,0xcd")如：tlv("9F46","abcd") 设定9F46,内容为0xab,0xcd实际报文[9F][46][02][AB][CD]tlv("9F47","1234","bb") 设定9F47,内容为0x12,0x34实际报文[9F][47][02][12][34]tlv("9F47","1234","ba") 设定9F47,内容为1234实际报文[9F][47][04][31][32][33][34]Tlvasctlvasc表示设定(tag-length-value)的格式,均为asc形式,length为3位（左补零）@tlvasc(tag,value,flag)如：tlvasc("9F46","1234") 设定9F46,内容为1234，结果为:9F45，实际报文[39][46][34][36][30][30][34][31][32][33][34]更新计划版本持续更新中，更新记录请参见“修改记录”如果您发现有什么BUG，或者有什么更好的建议，请联系作者：修改记录2010.03 初始版本1.02010.06 修改报文属性中域属性，00-aa,01-ab,10-ba,11-bb,(a表示asc，b表示bcd）2010.07 增加tlv支持（@tlv实现tlv打包报文)2010.07 扩展反交易的“同原交易配置”（&表示）增加同原请求@req,同原交易应答@resp如果配置了@resp，若原交易无应答则无法发起反交易2010.08 扩展@rev用法，增加可选参数2010.08 增加支持多个交易请求标签2010.08 增加报文域内容合法性校验属性为a：校验字母，n：校验数字，an：校验数字和字母2010.09 增加报文解包功能(暂只支持8583)，输入8583报文按报文属性进行解包2010.09 增加报文长度属性功能（b2：表示2位bcd长度,a4：表示4位asc长度）2010.09 增加显示修改案例中的“域描述”内容，同“报文属性”中每个域的“描述”2010.10 版本更新为1.5。