报文模拟测试(含8583)工具介绍

8583报文解析
8583报文解析是指对银行卡交易中所使用的8583报文进行分析和解码的过程。

8583报文是一种二进制格式的结构化数据，在银行卡交易中扮演着重要的角色。

通过对8583报文的解析，可以获取交易中所包含的必要信息，如交易类型、交易金额、交易时间等，从而实现交易的成功。

8583报文由多个域(field)组成，每个域包含了特定的信息。

其中，前4个域为固定域，分别为消息类型标识符、位图、主帐号(PAN)、交易处理码。

后续的域则根据交易类型的不同而有所变化，如消费交易会包含卡有效期、商户号、终端号等域。

对于每个域，都有特定的长度和格式要求，例如主帐号域为16位数字字符，交易金额域为12位数字字符等。

在解析8583报文时，需要先解析出位图域，确定哪些域存在于该报文中。

然后根据位图的内容，按照顺序解析出各个域的信息。

在解析过程中，需要注意各个域之间的关联关系和数据类型的转换。

总之，8583报文解析是银行卡交易中必不可少的环节，对于保障交易的正确进行具有重要作用。

- 1 -。

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报文（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报文解析实例：以下是主机从网控器收到的消费数据包（用二位十六进制数表示一个字节）：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报文接口说明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报文实例（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。

ISO8583简介一、定义与说明二、报文类型1、报文的分类与标识2、报文重复3、报文类型的说明三、位元表和数据元目录四、数据元详解五、拆包举例说明引言金融行业的业务包括有关金融交易的电子信息交换。

应用规范的约定通常局限在专业级别上。

ISO8583国际标准设计了一个保证在采用不同应用规范的系统间能够进行信息交换的界面规范。

各应用规范可保持在专用级别上。

在信息可以转换成能够进行国际交换的界面格式这一总的约束条件下，各应用系统的设计者可享有完全的灵活性。

ISO8583标准使用一个称为“比特图”的概念，在此，对每个数据元在控制字段或比特图中分配一个位置标记。

在一个具体信息中，数据元存在则在指定的位置上用“1”标明，数据元不存在则用“0”标明。

各个系统所采用的信息格式取决于个系统签约双方的商务关系。

ISO8583标准定义的数据格式能构保证符合标准的个系统总是兼容的。

一、定义与说明本节给出简介中涉及的部分术语的解释和定义。

1、版本版本是对交换报文格式的说明，用于区别根据不同标准或同一标准的不同版本所定义的报文格式，如GB/T15150－94或ISO8583－1993。

报文定义所依据的规范不同，其数据元的含义、组成和数据格式也不尽相同。

本规范的蓝本是国际标准ISO8583－1993《产生报文的银行卡交换报文规范金融交易内容》，并根据国家金卡网络的实际业务需求做了相应的裁剪和补充完善。

与全国银行卡中心连接的各节点机应统一采用本规范所定义的报文格式。

2、位元表用来标识报文中各数据元存在（用1表示）或不存在（用0表示）的一个64比特位序列，包括基本位元表和扩展位元表。

3、报文用于机构或其代理之间交换信息的一个数据元集合，不包括任何用于通信控制或其它目的的标识数据。

4、报文前缀指交换信息包中位于报文之前的一段固定长度和格式的数据序列，用于通信控制、报文流向控制等用途。

5、报文类别指一组报文的集合，描述被执行的一种特定活动。

8583数据解析1、8583为国际卡组织发明的交易报⽂传输。

加强了交易的安全性、⼀致性、失效性⼀直沿⽤⾄今。

2 、谈⼀下银⾏卡收单流程。

银⾏卡——pos机具——收单机构——银联——发卡⾏——银联——收单机构——pos机。

（完整流程完成⼀笔交易）从传统pos收单通道、再整个流程中数据是以8583形式传输。

当然现在银联也推出了全渠道、apple pay 等通道。

3 、报⽂传输都是以字节流进⾏传输。

作为开发⼈员、⾸先接触8583感觉很迷茫。

银联8583报⽂是以128域组成。

pos机具发送和传输则以64域组成。

中间转换曾则为收单机构进⾏转换。

具体⼦域有相关接⼝⽂档进⾏详细说明。

4 、8583报⽂组成报⽂头+TPDU+交易码+位图+⼦域值组成。

⾸先我们得到⼀串8583报⽂不知道如何进⾏解析。

⼀般是剔除报⽂头和TPDU开始（长度固定）下⾯举个例⼦如何⼿动拆解8583下⾯是⼀串⼿动解析出来的pos发送的8583报⽂。

0200702406C020E09A3116|622252**********0000000000005800000000432106 ----14域07100003001227|622252**********D210620603703635333433303932343833323531353539393930303030 30303120202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020 31353657A893D87A857D9126000000000000000151|9F2608F4263027C03F06FC9F2701809F101307011703A00000010A0100000000007592C3559F37046B3E7A179F36020048950500000000009A031710219C01009F02060000005800005F2 ------55域特殊域----长度位单倍长计数。

Pos机收单系统性能压力测试实战Socket协议测试Loadrunner脚本+8583报文解析Action:#define _EOF '#'#include "lrs.h"Action(){char *recvbuf;int recvlen=0;int rc;lr_start_transaction("Trans_1");lrs_set_recv_timeout (60,0);lr_start_transaction("Conn_1");rc=lrs_create_socket("socket0","TCP","LocalHost=0","RemoteHost=192.168.205.150:7001",LrsLastArg);//RemoteHost处填入被测程序所在服务器IPlr_output_message("%d",rc);if (rc != 0 ) {lr_end_transaction("Conn_1", LR_FAIL);lr_end_transaction ("Trans_1", LR_FAIL);return 0;}lr_end_transaction("Conn_1", LR_PASS);//判断socket是否链接成功的事务lr_rendezvous("集合点");lrs_send("socket0","buf0", LrsLastArg);lrs_receive ("socket0","buf1",LrsLastArg);lrs_get_last_received_buffer("socket0",&recvbuf,&recvlen);if(recvlen==130)lr_end_transaction("Trans_1", LR_PASS);elselr_end_transaction ("Trans_1", LR_FAIL);//判断返回信息的长度是否正确，recvlen处填入预期返回信息的长度lrs_close_socket("socket0");return 0;}Data.ws:;WSRData 2 1send buf0 211"\x00\xD1"//报文xx"\x60\x00\x09\x00\x00"//TPDU信息"\x4C\x52\x49\x00\x1C\x00\x00\x00\x21\x58\x77\x96\x98\x00\x00\x00\x21\x 58\x77\x09\x79\x58\x00\x09\x49\x00\x06\x00\x00\x00\x22\x00\x30"//主被叫号码"\x01\x00""\x02\x00"//信息类型"\x70\x38\x05\x80\x30\xC0\x80\x19"//位图"\x19\x09\x55\x10\x04\x91\x00\x01\x35\x38\x52"//卡号"\x00\x00\x00"//处理代码"\x00\x00\x00\x00\x02\x00"//交易金额"\x00\x00\x14"//系统跟踪号"\x16\x41\x32"//本地交易时间"\x05\x20"//本地交易日期"\x00\x22"//服务点输入方式"\x00\x09"//NETWORK INTERNATIONAL IDENTIFIEER"\x14"//服务点条件代码"\x37\x09\x55\x10\x04\x91\x00\x01\x35\x38\x52\xD0\x00\x02\x20\x36\x00\x 60\x00\x00"//二磁道数据"\x01\x04\x99\x95\x51\x00\x49\x10\x00\x13\x53\x85\x2D\x15\x61\x56\x00\x 00\x00\x00\x00\x00\x00\x03\x00\x00\x00\x21\x41\x41\x40\x00\x01\xD0\x00\x00\ x00\x00\x00\x0D\x00\x00\x00\x00\x00\x00\xD0\x00\x00\x00\x36\x00\x60\x00"//三磁道数据"\x32\x30\x31\x30\x30\x36\x30\x31"//收卡单位终端标识码"\x30\x30\x34\x31\x31\x30\x30\x34\x35\x31\x31\x30\x30\x31\x32"//收卡商户定义码"\x01\x56"//交易货币代码"\x00\x00"//RESERVED PRIVATE"\x00\x15\x30\x30\x30\x30\x30\x31\x30\x30\x31\x30\x30\x30\x30\x30\x32"//RESERVED PRIVATE"\x61\x54\x70\xE7\x33\x6D\xB5\x48"//消息认证码recv buf1 130-1发送报文原文：00DCC030C852D852D4001D0000D035470E7336DB548是16进制的，每两位代表一个字符，所以在Loadrunner里面发送数据的应该每两位前面家转义符“\x”来代表16进制。

全面掌握ISO8583报文最开始时，金融系统只有IBM这些大的公司来提供设备，象各种主机与终端等。

在各个计算机设备之间，需要交换数据。

我们知道数据是通过网络来传送的，而在网络上传送的数据都是基于0或1这样的二进制数据，如果没有对数据进行编码，则这些数据没有人能够理解，属于没有用的数据。

起初的X.25、SDLC以及现在流行的TCP/IP网络协议都提供底层的通讯编码协议，它们解决了最底层的通讯问题，能够将一串字符从一个地方传送到另一个地方。

但是，仅仅传送字符串是没有太大意义的，怎样来解析字符串代表什么内容是非常重要的，否则传送一些“0123abcd”的字符串也是无用的乱码。

让我们随着时光回到几十年前的某个时刻，假设我们被推到历史的舞台上，由我们来设计一个通用报文协议，来解决金融系统之间的报文交换，暂且称该协议叫做ISO8583协议。

此时，技术是在不断的前行，当初IBM一支独秀的局面好像已经不妙了，各种大小不一的公司都进入金融行业以求能有所斩获，呈一片百花齐放的局面。

我们怎样来设计一个报文协议，能够将这些如雨后春笋般出现的所有公司都纳入进来，其实也不是一件很简单的事。

我们还是先一步步的来考虑吧。

金融行业其实涉及到的数据内容并不是成千上万，无法统计，恰恰相反，是比较少的。

我们都可以在心底数得过来，象交易类型、帐号、帐户类型、密码、交易金额、交易手续费、日期时间、商户代码、2磁3磁数据、交易序列号等，把所有能够总结出来的都总结起来不过100个左右的数据。

那我们可以首先简单的设计ISO8583，定义128个字段，将所有能够考虑到的类似上面提到的“帐号”等金融数据类型，按照一个顺序排起来，分别对应128个字段中的一个字段。

每个数据类型占固定的长度，这个顺序和长度我们都事先定义好。

这样就简单了，要发送一个报文时，就将128个字段按照顺序接起来，然后将接起来的整串数据包发送出去。

任何金融软件收到ISO8583包后，直接按照我们定义的规范解包即可，因为整个报文的128个字段从哪一位到哪一位代表什么，大家都知道，只要知道你的数据包是ISO8583包即可，我们都已经定义好了。

回归测试工具用户手册目录目录 (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加密。

本软件运行程序无需安装，只需将相关程序和测试案例文件拷贝到相应的文件夹下即可执行。

Jmeter+TCPSockets（8583）报⽂压⼒测试
Jmeter⼀般被⽤来测试HTTP协议，我第⼀次拿来测试socket协议，pos机传输报⽂为8583，协议属于socket，也是TCP协议的⼀种，⽹上有LR怎么测试8583报⽂，我就研究了⼀下怎么⽤Jmeter来测试，以下是我的研究结果，供⼤家参考
1、先打开\apache-jmeter-3.1\bin\jmeter.propertles⽂件，修改jmeter.propertles中的“TCP Sampler configuration”内容，见附图，添加“tcp.handler=BinaryTCPClientImpl”这⼀⾏
2、打开Jmeter，新建线程组，添加Sampler中的TCP取样器，添加结果树
3、填写TCP取样器的各项值，服务器IP地址，服务器端⼝号，报⽂体（报⽂内容必须为为16进制，Jmeter默认发送报⽂内容为16进制，8583报⽂各个域的内容可以找⼀下开发的童鞋进⾏协助，也可以⾃⼰抓包获得，推荐抓包⼯具“Wireshark”）
⼤功告成，这个时候就可以运⾏⼀下看看了，看⼀下结果树返回的信息是否正确
⾄于报⽂内容是怎么来的就要⾃⼰想办法了，我是⽤的“Wireshark”进⾏抓包，这个⼯具百度就有，还是⽐较好⽤的，同样的原理，可以对QQ、微信，以及各种使⽤TCP协议的C/S架构程序或B/S架构程序进⾏测试。

（转载）ISO8583报文128个域说明ISO8583包（简称8583包）是一个国际标准的包格式，最多由128个字段域组成，每个域都有统一的规定，并有定长与变长之分。

8583包前面一段为位图，用来确定包的字段域组成情况。

其中位图是8583包的灵魂，它是打包解包确定字段域的关键，而了解每个字段域的属性则是填写数据的基础，1、位图描述如下：位图位置：1格式：定长类型：B16（二进制16位，16*8=128bit）描述：如将位图的第一位设为'1'，表示使用扩展位图（128个域），否则表示只使用基本位图（64个域）。

如使用某数据域，应在位图中将相应的位设位'1'，如使用41域，需将位图的41位设为'1'。

选用条件：如使用65到128域，需设位图域第一位为'1'2、变长，定长域说明如第二域：域名为主帐号，数据类型为string长度为22（是长长度不得超过此数）是个２位变长域由于是２位变长，在打包时需在数据域前加上数据的实际长度，如为１９位，则表示为：１９＋数据值（即前两位为长度）如第三域：域名为处理码，数据类型为string长度为６是个定长域必须填满６位。

附A:ISO8583各域段的说明1，信息类型（message type)定义位图位置：－格式：定长类型：N4描述：数据包的第一部分，定义数据包的类型。

数据类型由数据包的发起者设定，应遵循以下要求：数据包开始部分必须是信息类型；对不支持的信息类型能给出拒绝应答。

0100授权交易0110授权交易答复0200金融交易0210金融交易答复0240查询交易0250查询交易答复0400冲正交易0410冲正交易答复0800管理交易0810管理交易答复2，位图(Bit Map) - 基本位图和扩展位图位图位置：1格式：定长类型：B16描述：如将位图的第一位设为'1'，表示使用扩展位图，否则表示只使用基本位图。

银联ISO8583报⽂解析过程主密钥：aabbccddeeff112233445566778899001、从签到报⽂中获取⼯作密钥，包括MACKEY明⽂,PINKEY明⽂签到：12-03-31 16:38:09---->[Receive]02 00 91 60 00 03 00 00 60 31 00 31 54 32 08 00 00 20 00 00 00 C0 00 16 00 00 39 31 32 33 34 35 36 37 36 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 00 11 00 00 00 03 00 30 00 29 53 65 71 75 65 6E 63 65 20 4E 6F 31 36 33 30 38 31 30 33 38 35 4E 4C 32 34 37 35 33 36 00 03 30 31 20 03 11TDUP：60 00 03 00 00 60报⽂头：31 00 31 54 32数据类型：08 00位图：00 20 00 00 00 C0 00 16（0000 0000 0010 0000 0000 0000 0000 0000 0000 0000 1100 0000 0000 0000 0001 0110）11域（受卡⽅系统跟踪号）：00 00 3941域（受卡机终端标识码）：31 32 33 34 35 36 37 3642域（受卡⽅标识码）：31 32 33 34 35 36 37 38 39 30 31 32 33 34 3560域（⾃定义域）：00 11 00 00 00 03 00 3062域（⾃定义域）：00 29 53 65 71 75 65 6E 63 65 20 4E 6F 31 36 33 30 38 31 30 33 38 35 4E 4C 32 34 37 35 33 3663域（⾃定义域）：00 03 30 31 2012-03-31 16:38:09---->[Send]02 01 21 60 00 00 00 03 60 31 00 31 54 32 08 10 00 38 00 01 0A C0 00 14 00 00 39 16 38 09 03 31 08 01 03 10 00 30 34 36 38 37 39 30 38 37 35 36 34 30 30 31 32 33 34 35 36 37 36 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 00 11 00 00 00 03 00 30 00 40 8B 3D 47 86 55 51 F1 FB 54 8F D4 72 5C C5 0A 57 FF EF A8 D9 8B 3D 47 86 55 51 F1 FB 00 00 00 00 00 00 00 00 6F B2 3E AD 03 41TDUP： 60 00 00 00 03 60报⽂头： 31 00 31 54 32数据类型：08 10位图： 00 38 00 01 0A C0 00 14 (0000 0000 0011 1000 0000 0000 0000 0001 0000 1010 1100 0000 0000 0000 0001 0100)11域（受卡⽅系统跟踪号）：00 00 3912域（受卡⽅所在地时间）：16 38 0913域（受卡⽅所在地⽇期）：03 3132域（受理⽅标识码）：08 01 03 10 0037域（检索参考号）：31 32 33 34 35 36 37 38 39 30 31 32 33 34 3539域（应答码）： 30 3041域（受卡机终端标识码）： 31 32 33 34 35 36 37 3642域（受卡⽅标识码）：31 32 33 34 35 36 37 38 39 30 31 32 33 34 3560域（⾃定义域）：00 11 00 00 00 03 00 3062域（⾃定义域）：00 40 8B 3D 47 86 55 51 F1 FB 54 8F D4 72 5C C5 0A 57 FF EF A8 D9 8B 3D 47 86 55 51 F1 FB 00 00 00 00 00 00 00 00 6F B2 3E AD（PIN的16个密⽂）（checkvalue）（MAC的8个密⽂）（checkvalue）PINKEY⼯作密钥明⽂：1122334455667788 9900112233445566 将PINKEY⼯作密钥与0X 00 00 00 00 00 00 00 00进⾏3DES运算得：FFEFA8D9 607ED326MACKEY⼯作密钥明⽂：1122334455667788 将MACKEY⼯作密钥与0X 00 00 00 00 00 00 00 00进⾏3DES运算得：6FB23EAD 0534752B2、根据上⾯得到的MACKEY,PINKEY,计算出⽤户输⼊的密码，以及计算出这个报⽂的MAC值。

ISO8583金融报文详细分析ISO8583金融报文详细分析2011-08-26 14:23转载至网络，自己编辑了一下。

向原作者表示感谢，写的很详细。

不要以为我这篇文章是告诉你什么是8583，告诉你map的原理,然后分析各个域是什么意思，格式如何, 再有详细一点的甚至告诉你如何写程序等等. 不是, 之所以不写上面这些，基于两点:1 太多的人写这些了, 网上一搜8583,出来的文章都是关于这些的.2 作用不大, 因为这些规范上都有, 大家一看规范就明白了, 我写了也是无用.我篇文章适合两类人看:1 对8583报文非常熟悉，属于这一领域的资深工程师, 为什么这一类人要看呢, 因为他们看了，可以给我提一些意见和建议.2 看了很多遍规范，但是还有一些细节不是很明白.好，我要开始了.8583报文大部分情况下用在POS终端与后台收单系统的数据交换, 一般情况下(请注意这里的用词)一段完整的报文由以下几个部分组成图1不同的应用领域, 上面几个部分在长度和格式上有一些差别, 有一些应用甚至前面的"长度"部分没有.所以如果等一下你看到下面一些数据的长度或格式跟你的不一样，不要惊讶.先说说"长度"部分, 一般占两个字节, 表示报文的总长度(即"报文头"+"数据"部分的长度), 这两个字节在报文里的表示方法因系统与终端的协议不同而不同. 一般有两种:1 BCD方法, 比如报文的总长度是134字节, 那么在实际的报文中, 这两个字节为"01h,34h"(注意16进制)2 实际的计算的长度, 比如还是134长度的字节, 实际的报文中，两个字节为"00h, 86h"(注意也是16进制，00h*256+86h = 134d).然后说说"报文头", 这一部分不同的系统应用差别也不小, 但一般这部分中会包含TPDU, 这个TPDU决定了终端与系统之间的网络协议. TPDU是一个10位的数字, 实际传输的报文, 有些用ASCII表示这10位数字, 有些用BCD表示, 举个例子:TPDU是"6000120000",如果用ASCII表示, 报文中的字节是"36h,30h,30h,30h,31h,32h,30h,30h,30h,30h"(10个字节).如果用BCD表示, 报文中的字节如下:"60h,00h,12h,00h,00h"(5个字节).重头戏来了, "数据"部分.这一部分就是8583了, 我上面说了，我这篇文章只写别人没写过的东西,so.....,直接上例子.一段8583报文."02 00 70 20 00 00 20 C0 82 00 19 06 20 51 32 00 00 00 02 61 20 60 00 00 00 00 00 02 00 00 00 00 73 37 06 20 51 32 00 00 00 02 61 20 d1 91 12 01 00 00 00 00 00 30 30 30 30 31 31 31 31 31 30 32 32 35 30 31 35 33 31 31 31 31 31 31 01 56 00 44 9f 26 08 92 b6 ae 9a 9b 10 2e d6 9f 27 01 80 9f 10 13 07 01 01 03 a0 a0 10 01 0a 01 00 00 00 10 37 51 3a 22 be"这是一串实际传输的报文, 上面显示的是这些数据的16进制表示.你准备好了吗，我要开始分析了.<02 00>这个是信息类型(MTI), 是一个四位的数字, 这里为"0200", 传输时用BCD表示即为"02h,00h"(如果用ASCII呢？看看上面的内容). 这个四位数字，每一位都有它的意义,第一位:8583 version number第二位:message class第三位:message sub-class第四位:transaction originator就不翻译了，毕竟本来就是老外的东西, 自己理解吧.<70 20 00 00 20 C0 82 00>bit map域, 指示哪些域存在, 我们用windows自带的计算器计算出它对应的二进制是1110000001000000000000000000000001000001100000010 00001000000000, 由此可以看出下面几个域存在:2, 3, 4, 11, 35, 41, 42, 49, 55.<19 06 20 51 32 00 00 00 02 61 20>field 2, 账号, n..19, LLVAR, 一字节表示长度(19), 账号是19位, 前面补0后, 用10字节BCD表示.<60 00 00>field 3, 处理码, n6, 定长, 用3字节BCD表示<00 00 00 02 00 00>field 4, 交易金额, n12, 定长, 用6字节BCD表示, 这里的金额是200.00元<00 00 73>field 11, 流水号, n6, 定长, 用3字节BCD表示.流水号为"000073".<37 06 20 51 32 00 00 00 02 61 20 d1 91 12 01 00 00 00 00 00>field 35, 二磁道数据, z..35, LLVAR, 一字节表示长度(37), 后面是19字节BCD表示的磁道数据<30 30 30 30 31 31 31 31>field 41, 终端号, ans8, 定长, ASCII表示, 这里终端号为"00001111"<31 30 32 32 35 30 31 35 33 31 31 31 31 31 31>field 42, 商户号, ans15, 定长, ASCII表示, 这里商户号为"102250153111111"<01 56>field 49, 货币代码, n3, 定长, 前面补0后，用两字节BCD表示, 这里货币代码为"156"<00 44 9f 26 08 92 b6 ae 9a 9b 10 2e d6 9f 2701 80 9f 10 13 07 01 01 03 a0 a0 10 01 0a 0100 00 00 10 37 51 3a 22 be>field 55, 这是IC卡交易的相关数据, 最大长度是255, 这一域用的IC卡数据一般在PBOC/EMV规范里都有自己的定义(包括格式), 所以，一般在报文里的格式跟它们在PBOC/EMV里定义的一致.一般是TLV(tag+lenght+value)表示一个数据.简单介绍一下数据的意义."00 44":长度, 表示44个字节"9f 26 08 92 b6 ae 9a 9b 10 2e d6":应用密文(application cryptogram), TLV, b8"9f 27 01 80":密文信息数据(cryptogram information data), TLV, b1"9f 10 13 07 01 01 03 a0 a0 10 01 0a 01 00 00 00 10 37 51 3a 22 be":发卡行应用数据(issuer application data), TLV, 变长，最大32字节,b..32.。

[信息与通信]POS机8583接口文档[信息与通信]POS机8583接口文档1 概述 ..................................................................... ........................................... ............................. . (3)2 术语和定义 ..................................................................... ........................................... ............................. .. (3)2.1 POS 中心 POScenter (3)2.2 特约商户merchant (3)2.3 持卡人 cardholder ................................................................. .. (3)2.4 发卡行issuer ................................................................. ........................................ ...............................32.5 收单行acquirer (3)2.6 参考号 referencenumber ................................................................. . (3)2.7 交易批次号batch number.................................................................. .. (4)2.8 主账号 primary accountnumber ................................................................. .. (4)2.9 交易处理码 processingcode (4)2.10 POS 流水号 tracenumber ................................................................. .. (4)2.11 服务点输入方式码 point of service entrymode ................................................................... .. (4)2.12 授权码 authorizationnumber (4)2.13 响应码 responsenumber ................................................................. . (4)2.14 个人标识码 personal identification number;PIN .................................................................... . (4)2.15 报文鉴别码 messang authenticationcode;MAC................................................................ .. (5)2.16 安全控制信息 security control relatedinformation ............................................................ . (5)2.17 密钥加密密钥 key encryption key;KEK .................................................................... .. (5)2.18 工作密钥 workingkey;WK (5)3 安全 ..................................................................... ........................................... ............................. . (5)3.1.1 密钥管理 ..................................................................... .. (5)4 消息域说明 ..................................................................... ........................................... ............................. .. (6)4.1 说明 ..................................................................... ........................................... ............................. . (6)4.2 数据类型 ..................................................................... ........................................... ............................. .. 64.3 数据元名称及其定义 (7)4.3.1 位图 ..................................................................... . (7)4.3.2 消息类型 ..................................................................... .. (7)4.3.3 域2 ...................................................................... . (8)4.3.4 域3 ...................................................................... . (8)4.3.5 域4 ...................................................................... . (8)4.3.6 域11 (9)4.3.7 域12 ..................................................................... . (10)4.3.8 域13 ..................................................................... . (10)4.3.9 域14 ..................................................................... .. (11)4.3.10 域15 ..................................................................... .. (11)4.3.11 域22 ..................................................................... . (12)4.3.12 域23 ..................................................................... . (12)4.3.13 域4.3.14 域26 ..................................................................... . (13) 4.3.15 域32 ..................................................................... . (14) 4.3.16 域35 ..................................................................... . (14) 4.3.17 域36 ..................................................................... . (15) 4.3.18 域37 ..................................................................... . (15) 4.3.19 域38 ..................................................................... . (16) 4.3.20 域39 ..................................................................... . (16) 4.3.21 域41 ..................................................................... . (17) 4.3.22 域42 ..................................................................... . (17) 4.3.23 域44 ..................................................................... . (18) 4.3.24 域48 ..................................................................... . (18) 4.3.25 域49 ..................................................................... . (19) 4.3.26 域52 ..................................................................... . (20) 4.3.27 域53 ..................................................................... . (20) 4.3.28 域4.3.29 域55 ..................................................................... . (22)4.3.30 域58 ..................................................................... . (23)4.3.31 域60 ..................................................................... . (25)4.3.32 域61 ..................................................................... . (26)4.3.33 域62 ..................................................................... . (27)4.3.34 域63 ..................................................................... . (29)4.3.35 域64 ..................................................................... . (30)5 终端消息交换说明 ..................................................................... .. (3)5.1 管理类 ..................................................................... ........................................... ............................. . (30)5.1.1 签到(900800/900810) ........................................................ ........................... ..................... 30 5.1.2 签退(900820/900830) (31)5.1.3 请求黑名单(900840/900850) (31)5.2 消费类 ..................................................................... ........................................... ............................. . (32)5.2.1 余额查询(310200/310210) ........................................................ ........................... ................... 32 5.2.2 查询商户授信(310220/310230) ........................................................ ................................... ... 33 5.2.3 查询代缴信息(310240/310250)(注意此处发送时,,,,包和其他不一样，数据包头定义如下:) ................................................................... ........................................... ............................. . (33)5.2.4 充值(630200/630210)(说明:在充值之前先看签到之后获得的商户充值授信额度是否足够，如果不足，不能进行充值，否则可以进行充值，后台会随时更新该额度) (34)5.2.5 充值冲正(630400/630410) ........................................................ ........................... ................... 35 5.2.6 消费(000201/000211)脱机情况下的检索参考号生成机制，使用MIK 将以下数据计算MAC(4字节)，然后转换成BCD形式;计算MAC数据包含主帐号【2域】+受卡方所在地时间【11域自己生成】+受卡方所在地日期【12域自己生成】+ Pos 中心流水号【37域】+终端代码(41域)+商户代码(42域)+【60域】 ................................................................................................... 36 5.2.7 消费冲正(000400/000410) ........................................................ ........................... ................... 37 5.2.8 退货(200220/200230) (38)5.2.9 退货冲正(200400/200410) ........................................................ ........................... ................... 39 5.2.10 批上送(000320/000330) ........................................................ .. (40)5.3 结算类 ..................................................................... ........................................... ............................. . (41)5.3.1 结算(900500/900510) (41)1 概述2 术语和定义2.1 POS 中心 POS center接受、处理或转发POS的交易请求信息，并向POS回送交易结果信息的机构。