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

合集下载

8583报文解析

8583报文解析

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

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

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

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

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

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

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

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

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

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

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

- 1 -。

8583报文实例

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)工具介绍

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

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就是最后的数据包。

CEB8583报文接口说明

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类消息用于在服务器和终端之间传送文件更新数据。

8583报文及各域详解

8583报文及各域详解

[精彩] 8583问题 作者:lcunix发表于:2006-02-19 00:03:51【发表评论】【查看原文】【C/C++讨论区】【关闭】各位高手能否详细的解释一下8583协议htldm回复于:2003-08-31 22:15:18ISO8583包(简称8583包)是一个国际标准的包格式,最多由128个字段域组成,每个域都有统一的规定,并有定长与变长之分。

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

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

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

选用条件:如使用65到128域,需设位图域第一位为'1'2、每个域的定义如下:typedef struct ISO8583{int bit_flag; /*域数据类型0 -- string, 1 -- int, 2 -- binary*/char *data_name; /*域名*/int length; /*数据域长度*/int length_in_byte;/*实际长度(如果是变长)*/int variable_flag; /*是否变长标志0:否2:2位变长,3:3位变长*/int datatyp; /*0 -- string, 1 -- int, 2 -- binary*/char *data; /*存放具体值*/int attribute; /*保留*/} ISO8583;ISO8583 Tbl8583[128] ={/* FLD 1 */ {0,"BIT MAP,EXTENDED ", 8, 0, 0, 2, NULL,0},/* FLD 2 */ {0,"PRIMARY ACCOUNT NUMBER ", 22, 0, 2, 0, NULL,0},/* FLD 3 */ {0,"PROCESSING CODE ", 6, 0, 0, 0, NULL,0},/* FLD 4 */ {0,"AMOUNT, TRANSACTION ", 12, 0, 0, 1, NULL,0},/* FLD 5 */ {0,"NO USE ", 12, 0, 0, 0, NULL,0},/* FLD 6 */ {0,"NO USE ", 12, 0, 0, 0, NULL,0},/* FLD 7 */ {0,"TRANSACTION DATE AND TIME ", 10, 0, 0, 0, NULL,0},/* FLD 8 */ {0,"NO USE ", 8, 0, 0, 0, NULL,0},/* FLD 9 */ {0,"NO USE ", 8, 0, 0, 0, NULL,0},/* FLD 10 */ {0,"NO USE ", 8, 0, 0, 0, NULL,0},/* FLD 11 */ {0,"SYSTEM TRACE AUDIT NUMBER ", 6, 0, 0, 1, NULL,0},/* FLD 12 */ {0,"TIME, LOCAL TRANSACTION ", 6, 0, 0, 0, NULL,0}, /* FLD 13 */ {0,"DATE, LOCAL TRANSACTION ", 4, 0, 0, 0, NULL,0}, /* FLD 14 */ {0,"DATE, EXPIRATION ", 4, 0, 0, 0, NULL,0},/* FLD 15 */ {0,"DATE, SETTLEMENT ", 4, 0, 0, 0, NULL,0},/* FLD 16 */ {0,"NO USE ", 4, 0, 0, 0, NULL,0},/* FLD 17 */ {0,"DATE, CAPTURE ", 4, 0, 0, 0, NULL,0},/* FLD 18 */ {0,"MERCHANT'S TYPE ", 4, 0, 0, 0, NULL,0},/* FLD 19 */ {0,"NO USE ", 3, 0, 0, 0, NULL,0},/* FLD 20 */ {0,"NO USE ", 3, 0, 0, 0, NULL,0},/* FLD 21 */ {0,"NO USE ", 3, 0, 0, 0, NULL,0},/* FLD 22 */ {0,"POINT OF SERVICE ENTRY MODE ", 3, 0, 0, 0, NULL, 0},/* FLD 23 */ {0,"NO USE ", 3, 0, 0, 0, NULL,0},/* FLD 24 */ {0,"NO USE ", 3, 0, 0, 0, NULL,0},/* FLD 25 */ {0,"POINT OF SERVICE CONDITION CODE ", 2, 0, 0, 0, N ULL,0},/* FLD 26 */ {0,"NO USE ", 2, 0, 0, 0, NULL,0},/* FLD 27 */ {0,"NO USE ", 1, 0, 0, 0, NULL,0},/* FLD 28 */ {0,"field27 ", 6, 0, 0, 0, NULL,0},/* FLD 29 */ {0,"NO USE ", 8, 0, 1, 0, NULL,0},/* FLD 30 */ {0,"NO USE ", 8, 0, 1, 0, NULL,0},/* FLD 31 */ {0,"NO USE ", 8, 0, 1, 0, NULL,0},/* FLD 32 */ {0,"ACQUIRER INSTITUTION ID. CODE ", 11, 0, 2, 0, NUL L,0},/* FLD 33 */ {0,"FORWARDING INSTITUTION ID. CODE ", 11, 0, 2, 0, N ULL,0},/* FLD 34 */ {0,"NO USE ", 28, 0, 2, 0, NULL,0},/* FLD 35 */ {0,"TRACK 2 DATA ", 37, 0, 2, 0, NULL,0},/* FLD 36 */ {0,"TRACK 3 DATA ",104, 0, 3, 0, NULL,0},/* FLD 37 */ {0,"RETRIEVAL REFERENCE NUMBER ", 12, 0, 0, 0, NULL,0} ,/* FLD 38 */ {0,"AUTH. IDENTIFICATION RESPONSE ", 6, 0, 0, 0, NULL,0},/* FLD 39 */ {0,"RESPONSE CODE ", 2, 0, 0, 0, NULL,0},/* FLD 40 */ {0,"NO USE ", 3, 0, 0, 0, NULL,0},/* FLD 41 */ {0,"CARD ACCEPTOR TERMINAL ID. ", 8, 0, 0, 0, NULL,0} ,/* FLD 42 */ {0,"CARD ACCEPTOR IDENTIFICATION CODE ", 15, 0, 0, 0, NULL,0},/* FLD 43 */ {0,"CARD ACCEPTOR NAME LOCATION ", 40, 0, 0, 0, NULL, 0},/* FLD 44 */ {0,"ADDITIONAL RESPONSE DATA ", 25, 0, 2, 0, NULL,0},/* FLD 45 */ {0,"NO USE ", 76, 0, 2, 0, NULL,0},/* FLD 46 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 47 */ {0,"field47 ",999, 0, 3, 0, NULL,0},/* FLD 48 */ {0,"ADDITIONAL DATA --- PRIVATE ",999, 0, 3, 0, NULL,0 },/* FLD 49 */ {0,"CURRENCY CODE,TRANSACTION ", 3, 0, 0, 0, NULL,0}, /* FLD 50 */ {0,"CURRENCY CODE,SETTLEMENT ", 3, 0, 0, 0, NULL,0}, /* FLD 51 */ {0,"NO USE ", 3, 0, 0, 0, NULL,0},/* FLD 52 */ {0,"PERSONAL IDENTIFICATION NUMBER DATA ", 8, 0, 0, 2, NULL,0},/* FLD 53 */ {0,"SECURITY RELATED CONTROL INformATION", 16, 0, 0, 0, NULL,0},/* FLD 54 */ {0,"ADDITIONAL AMOUNTS ",120, 0, 3, 0, NULL,0},/* FLD 55 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 56 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 57 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 58 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 59 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 60 */ {0,"NO USE ", 5, 0, 3, 0, NULL,0},/* FLD 61 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 62 */ {0,"NO USE ", 11, 0, 3, 0, NULL,0},/* FLD 63 */ {0,"NO USE ", 11, 0, 3, 0, NULL,0},/* FLD 64 */ {0,"MESSAGE AUTHENTICATION CODE FIELD ", 8, 0, 0, 2, NULL,0},/* FLD 65 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 66 */ {0,"NO USE ", 1, 0, 0, 0, NULL,0},/* FLD 67 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 68 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 69 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 70 */ {0,"SYSTEM MANAGEMENT INformATION CODE ", 3, 0, 0, 0, NULL,0},/* FLD 71 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 72 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 74 */ {0,"NUMBER OF CREDITS ", 10, 0, 0, 0, NULL,0},/* FLD 75 */ {0,"REVERSAL NUMBER OF CREDITS ", 10, 0, 0, 0, NULL,0 },/* FLD 76 */ {0,"NUMBER OF DEBITS ", 10, 0, 0, 0, NULL,0},/* FLD 77 */ {0,"REVERSAL NUMBER OF DEBITS ", 10, 0, 0, 0, NULL,0} ,/* FLD 78 */ {0,"NUMBER OF TRANSFER ", 10, 0, 0, 0, NULL,0},/* FLD 79 */ {0,"REVERSAL NUMBER OF TRANSFER ", 10, 0, 0, 0, NULL, 0},/* FLD 80 */ {0,"NUMBER OF INQUIRS ", 10, 0, 0, 0, NULL,0},/* FLD 81 */ {0,"AUTHORIZATION NUMBER ", 10, 0, 0, 0, NULL,0},/* FLD 82 */ {0,"NO USE ", 12, 0, 0, 0, NULL,0},/* FLD 83 */ {0,"CREDITS,TRANSCATION FEEAMOUNT ", 12, 0, 0, 0, NULL, 0},/* FLD 84 */ {0,"NO USE ", 12, 0, 0, 0, NULL,0},/* FLD 85 */ {0,"DEBITS,TRANSCATION FEEAMOUNT ", 12, 0, 0, 0, NULL,0 },/* FLD 86 */ {0,"AMOUNT OF CREDITS ", 16, 0, 0, 0, NULL,0},/* FLD 87 */ {0,"REVERSAL AMOUNT OF CREDITS ", 16, 0, 0, 0, NULL,0 },/* FLD 88 */ {0,"AMOUNT OF DEBITS ", 16, 0, 0, 0, NULL,0},/* FLD 89 */ {0,"REVERSAL AMOUNT OF DEBITS ", 16, 0, 0, 0, NULL,0} ,/* FLD 90 */ {0,"ORIGINAL DATA ELEMENTS ", 42, 0, 0, 0, NULL,0}, /* FLD 91 */ {0,"FILE UPDATE CODE ", 1, 0, 0, 0, NULL,0},/* FLD 92 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 93 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 94 */ {0,"SERVICE INDICATOR ", 7, 0, 0, 0, NULL,0},/* FLD 95 */ {0,"REPLACEMENT AMOUNTS ", 42, 0, 0, 0, NULL,0},/* FLD 96 */ {0,"NO USE ", 8, 0, 0, 0, NULL,0},/* FLD 97 */ {0,"AMOUNT OF NET SETTLEMENT ", 16, 0, 0, 0, NULL,0},/* FLD 98 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 99 */ {0,"SETTLEMENT INSTITUTION ID ", 11, 0, 2, 0, NULL,0}, /* FLD 100 */ {0,"RECVEING INSTITUTION ID ", 11, 0, 2, 0, NULL,0},/* FLD 101 */ {0,"FILENAME ", 17, 0, 2, 0, NULL,0},/* FLD 102 */ {0,"ACCOUNT IDENTIFICATION1 ", 28, 0, 2, 0, NULL,0}, /* FLD 103 */ {0,"ACCOUNT IDENTIFICATION2 ", 28, 0, 2, 0, NULL,0}, /* FLD 104 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 105 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 106 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 108 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 109 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 110 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 111 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 112 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 113 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 114 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 115 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 116 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 117 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 118 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 119 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 120 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 121 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 122 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 123 */ {0,"NEW PIN DATA ", 8, 0, 3, 2, NULL,0},/* FLD 124 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 125 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 126 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 127 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 128 */ {0,"MESSAGE AUTHENTICATION CODE FIELD ", 8, 0, 0, 2, NULL,0},};3、变长,定长域说明如第二域:域名为主帐号,数据类型为string长度为22(是长长度不得超过此数)是个2位变长域由于是2位变长,在打包时需在数据域前加上数据的实际长度,如为19位,则表示为:19+数据值(即前两位为长度)如第三域:域名为处理码,数据类型为string长度为6是个定长域必须填满6位。

Jmeter+TCPSockets(8583)报文压力测试

Jmeter+TCPSockets(8583)报文压力测试

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架构程序进⾏测试。

8583各域详解

8583各域详解

8583各个域详解收藏1,信息类型(message type)定义位图位置:-格式:定长类型:N4描述:数据包的第一部分,定义数据包的类型。

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

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

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

选用条件:如使用65到128域,需设位图域为'1'3,Bit02主帐号(Primary Account Number )位图位置:02格式:变长,LLVAR类型:N..22描述:唯一的确认一个用户交易的基本帐号。

由于银行电子服务系统涉及多个应用系统,而帐号长度最多为22位,故将原标准的19长度改为22位。

Bit03 处理代码(Processing Code )位图位置:03格式:定长类型:N6描述:用于描述交易对客户帐户造成何种影响的代码。

处理代码和信息码一起可唯一定义一种交易的类型。

处理代码由以下三部分组成:位置描述1-2交易动作码3-4付出帐户类型,用于借记类,如查询、代收费、转场交易。

5-6收入帐户类型,用于代收费、转帐等。

其中:ff : 付出帐户tt:收入帐户* 视主机而定5,Bit04 交易金额(Amount, Transaction)位图位置:04格式:定长类型:N12描述:帐户人要求交易的交易金额,不含任何处理和交易费用。

金额的表示和货币代码有关,应能表示相应货币的最小单位。

ISO8583报文解包和组包

ISO8583报文解包和组包
IS08583报文协议包的解析和封装java源代码
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简介

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

测试socket协议的loadrunner脚本(8583协议)8583报文解析

测试socket协议的loadrunner脚本(8583协议)8583报文解析

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进制。

8583报文详解

8583报文详解

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ISO8583各域详解--整理版知识讲解

ISO8583各域详解--整理版知识讲解

I S O8583各域详解--整理版ISO8583各域详解8583协议的报文域编码格式分为:BINARY、CHAR、NUMERIC、LLVAR、LLLVAR、LLLVAR_NUMERIC这几种格式。

BINARY采用二进制编码(8位二进制数编码为一个字节)。

CHAR、LLVAR、LLLVAR为ASC(即正常的getBytes(Encoding))编码。

NUMERIC、LLLVAR_NUMERIC采用BCD(半个字节表示一个10进制数,每两位编码为一个字节)编码。

CHAR、BINARY、NUMERIC都需要指定长度。

CHAR类型左对齐、右补空格。

NUMERIC右对齐、左补零。

LLVAR域前加一个字节的字节长度(采用bcd编码)。

LLLVAR域前加两个字节的字节长度(采用bcd编码)。

LLLVAR_NUMERIC域前加两个字节的长度(注:非字节长度,而是数字的长度,即字节长度的两倍)(采用bcd编码)。

代码中会在IsoField setValue时进行格式化,组装报文时计算LLVAR等域长。

ISO8583域说明ATM、前置机间通讯采用 ISO8583 包格式。

以下是位元、报文等的定义。

位元定义: (注:带*号的本行没用)1、信息类型(message type)定义位图位置:-格式:定长类型:N4描述:数据包的第一部分,定义数据包的类型。

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

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

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

ISO8583简介

ISO8583简介

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ISO8583各域详解--整理版

ISO8583各域详解--整理版

ISO8583各域详解8583协议的报文域编码格式分为:BINARY、CHAR、NUMERIC、LLVAR、LLLVAR、LLLVAR_NUMERIC这几种格式。

BINARY采用二进制编码(8位二进制数编码为一个字节)。

CHAR、LLVAR、LLLVAR为ASC(即正常的getBytes(Encoding))编码。

NUMERIC、LLLVAR_NUMERIC采用BCD(半个字节表示一个10进制数,每两位编码为一个字节)编码。

CHAR、BINARY、NUMERIC都需要指定长度。

CHAR类型左对齐、右补空格。

NUMERIC右对齐、左补零。

LLVAR域前加一个字节的字节长度(采用bcd编码)。

LLLVAR域前加两个字节的字节长度(采用bcd编码)。

LLLVAR_NUMERIC域前加两个字节的长度(注:非字节长度,而是数字的长度,即字节长度的两倍)(采用bcd编码)。

代码中会在IsoField setValue时进行格式化,组装报文时计算LLVAR等域长。

ISO8583域说明ATM、前置机间通讯采用ISO8583 包格式。

以下是位元、报文等的定义。

1、信息类型(message type)定义位图位置:-格式:定长类型:N4描述:数据包的第一部分,定义数据包的类型。

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

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

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

8583报文解析实例

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”。

ISO8583报文协议详解

ISO8583报文协议详解

ISO8583报文协议详解ISO8583包(简称8583包)是一个国际标准的包格式,最多由128个字段域组成,每个域都有统一的规定,并有定长与变长之分。

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

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

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

选用条件:如使用65到128域,需设位图域第一位为'1’2、每个域的定义如下:typedef struct ISO8583{int bit_flag; /*域数据类型0 —- string, 1 —- int,2 —— binary*/char *data_name; /*域名*/int length;/*数据域长度*/int length_in_byte;/*实际长度(如果是变长)*/int variable_flag; /*是否变长标志0:否2:2位变长, 3:3位变长*/int datatyp; /*0 —- string,1 —- int,2 —- binary*/char *data;/*存放具体值*/int attribute;/*保留*/}ISO8583;ISO8583 Tbl8583[128]={/*FLD 1 */ {0,”BIT MAP,EXTENDED ", 8, 0,0, 2,NULL,0},/* FLD 2 */ {0,"PRIMARY ACCOUNT NUMBER ”, 22,0,2, 0, NULL,0},/* FLD 3 */ {0,"PROCESSING CODE ",6, 0, 0,0,NULL,0},/*FLD 4 */ {0,”AMOUNT,TRANSACTION ",12,0, 0,1, NULL,0},/*FLD 5 */ {0,"NO USE ",12,0, 0,0,NULL,0},/*FLD 6 */ {0,”NO USE ", 12,0, 0,0,NULL,0},/* FLD 7 */ {0,"TRANSACTION DATE AND TIME ", 10,0, 0, 0,NULL,0},/* FLD 8 */ {0,”NO USE ”, 8, 0,0,0, NULL,0},/*FLD 9 */ {0,"NO USE ”, 8,0,0,0, NULL,0},/*FLD 10 */ {0,”NO USE ",8, 0, 0,0, NULL,0},/*FLD 11 */ {0,”SYSTEM TRACE AUDIT NUMBER ”, 6, 0,0,1,NULL,0},/*FLD 12 */ {0,”TIME,LOCAL TRANSACTION ", 6, 0,0,0, NULL,0},/* FLD 13 */ {0,”DA TE, LOCAL TRANSACTION ”,4,0,0, 0, NULL,0},/* FLD 14 */ {0,”DATE, EXPIRATION ", 4, 0, 0,0, NULL,0},/*FLD 15 */ {0,"DA TE,SETTLEMENT ”,4,0,0, 0, NULL,0},/* FLD 16 */ {0,”NO USE ”, 4,0, 0,0, NULL,0},/*FLD 17 */ {0,”DATE,CAPTURE ", 4, 0,0,0, NULL,0},/* FLD 18 */ {0,”MERCHANT'S TYPE ", 4,0,0, 0, NULL,0},/* FLD 19 */ {0,”NO USE ",3, 0, 0,0, NULL,0},/* FLD 20 */ {0,"NO USE ”,3,0, 0, 0, NULL,0},/*FLD 21 */ {0,"NO USE ”,3, 0,0, 0,NULL,0},/*FLD 22 */ {0,"POINT OF SERVICE ENTRY MODE ", 3, 0, 0,0,NULL,0},/* FLD 23 */ {0,”NO USE ”,3, 0,0, 0,NULL,0},/* FLD 24 */ {0,”NO USE ",3,0, 0, 0, NULL,0},/* FLD 25 */ {0,"POINT OF SERVICE CONDITION CODE ”, 2,0,0,0,NULL,0},/*FLD 26 */ {0,”NO USE ", 2, 0,0,0, NULL,0},/*FLD 27 */ {0,”NO USE ”, 1,0,0, 0,NULL,0},/* FLD 28 */ {0,"field27 ", 6, 0,0, 0, NULL,0},/*FLD 29 */ {0,”NO USE ”, 8,0, 1, 0, NULL,0},/* FLD 30 */ {0,"NO USE ”, 8,0,1,0, NULL,0},/* FLD 31 */ {0,”NO USE ",8,0,1,0,NULL,0},/* FLD 32 */ {0,"ACQUIRER INSTITUTION ID. CODE ”,11,0, 2, 0,NULL,0},/*FLD 33 */ {0,"FORW ARDING INSTITUTION ID. CODE ",11,0,2, 0, NULL,0},/*FLD 34 */ {0,"NO USE ", 28,0,2, 0, NULL,0},/* FLD 35 */ {0,”TRACK 2 DATA ”, 37,0,2,0, NULL,0},/* FLD 36 */ {0,”TRACK 3 DATA ",104,0, 3,0, NULL,0},/* FLD 37 */ {0,”RETRIEV AL REFERENCE NUMBER ",12, 0,0,0,NULL,0},/*FLD 38 */ {0,”AUTH. IDENTIFICATION RESPONSE ”,6, 0, 0, 0,NULL,0},/* FLD 39 */ {0,"RESPONSE CODE ", 2,0,0, 0, NULL,0},/*FLD 40 */ {0,”NO USE ”,3, 0, 0, 0, NULL,0},/* FLD 41 */ {0,”CARD ACCEPTOR TERMINAL ID。

8583数据解析

8583数据解析

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域特殊域----长度位单倍长计数。

基于ISO8583的模拟测试软件

基于ISO8583的模拟测试软件

基于ISO8583的模拟测试软件
陈盾
【期刊名称】《中国信用卡》
【年(卷),期】1999(000)005
【摘要】一、概述随着银行卡业务的不断发展,很多地方都建立了“金卡转接中心”,各专业银行也都在建设全国转接中心。

这些转接中心的关键部件是银行卡交换软件系统,灵活性、可靠性、可伸缩性、以及系统性能(响应时间、吞吐量、所占系统资源、所消耗的网络资源)是衡量交换中心软件系统优劣的主要标准。

为了达到所要求的指标,这些系统软件不可避免地被设计成为一个复杂的系统,对这个复杂系统的测试就成了非常重要的环节,它往往是项目成功与否的关键。

【总页数】3页(P34-36)
【作者】陈盾
【作者单位】华北计算技术研究所
【正文语种】中文
【中图分类】TP399
【相关文献】
1.一种基于类ISO8583通信协议的数据交换格式 [J], 姚振锋;张志鸿
2.基于VC的波浪模拟测试台检测软件的设计 [J], 唐原广;徐嘉骏;徐春玲
3.基于X86架构的Android软件模拟测试环境 [J], 王润杰
4.一种基于PDA+GPRS的仿ISO8583通信应用方案 [J], 徐涛;柯文辉;陈祖宁
5.基于ISO8583的自助终端系统的设计与实现 [J], 甄慕华;刘昌余;杨富富
因版权原因,仅展示原文概要,查看原文内容请购买。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

回归测试工具用户手册
目录
目录 (1)
工具描述 (2)
功能特点 (3)
适用范围 (3)
文件目录结构说明 (3)
case目录 (3)
file目录 (4)
ini目录 (4)
log目录 (4)
report目录 (4)
主界面 (4)
使用说明 (4)
密钥配置界面 (4)
通讯参数配置界面 (5)
修改案例界面 (5)
文本模式修改界面 (6)
设置案例集界面 (6)
报文属性设置 (6)
常量设置界面 (6)
发送案例 (6)
发送次数 (6)
清空 (6)
终止发送 (6)
清空日志 (7)
文件格式说明 (7)
config.ini 例子 (7)
Case.ini 例子 (8)
iso.ini 例子 (8)
交易文件的配置 (9)
正交易配置 (9)
反交易配置 (10)
可选配置 (10)
支持函数列表 (11)
String (11)
time (11)
Req (11)
Rev (11)
Def (12)
Tlv (12)
Tlvasc (12)
更新计划 (12)
修改记录 (13)
工具描述
系统用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 文件)
需要更多功能请联系作者:
部分函数示例:
适用范围 可以模拟各类报文; 针对8583规范,可以模拟不同的8583规范; 如支持:多渠道项目中的各个规范接口(终端1.0,终端2.0,商户1.0,商户2.0,渠道1.0,渠道2.0,CUPS 发起等发起方的报文规范)。

针对定长,XML ,变长等报文,目前仅显示报文内容。

文件目录结构说明
程序目录结构如下所示:
case 目录 每个目录下配置了对应的iso 格式标准,案例配置文件和案例文件
如xml 目录下:
包含case.ini ,iso.ini,*.txt
其中case.ini 指定了案例的文件,在选择案例的时候根据输入内容查找到对应的案例文件。

其中iso.ini 为相应的8583配置接口。

其中*.txt 为相应的案例配置文件。

function resp_count(caseroot)
static str; static send,recv,succ; static rate1,rate2; send = caseroot.sendcount; recv = caseroot.recvcount; succ = caseroot.succount; if ( send > 0) rate1 = string.format("%.2f",100*recv/send); rate2 = string.format("%.2f",100*succ/send); else rate1 = "--"; rate2 = "--" end if
str = "[统计]累计发送:" .. send .. ",累计收到=" .. recv ..",交易成功=" .. succ .. ","; str = str .. " 回复率=" .. rate1 .."%" .. " ,成功率=" .. rate2 .. "%";
return str end function function display_count(caseroot)
static str;
static tps;
if (sttime >0)
tps = string.format("%.2f",1/caseroot.calltime); print("本次交易耗时...",1000*sttime,"毫秒","平均耗时:",1000*caseroot.calltime,"毫秒"); end if str = resp_count(caseroot);
color_print(22,str);
return str;
end function。

相关文档
最新文档