全面掌握ISO8583报文协议

合集下载

银行卡和ISO8583要点

银行卡和ISO8583要点

– 嵌有集成电路芯片的一种便携式塑料卡片 – 通常,智能卡上包含专门的算法协处理器 – – – – 数据计算 信息处理 访问控制 存储功能
CPU
数据总线 协处理 器

智能卡包含有通用微处理器、 I/O接口及存储器

智能卡具有的功能:
ROM
安全单元
RAM
输入输出 EEPROM

卡片的大小、接点定义目前是由ISO规范统一
借记/贷记应用
脱机数据认证
借记/贷记应用
目的:作为终端的一个功能,用于认证来自IC卡数据的正确性 方法:采用公钥算法验证IC卡上的签名和证书 采用公钥技术: • 私钥产生加密数据(证书或签名) • 公钥解密证书或签名而用于验证和数据恢复 有三种类型的数据认证: 1. 静态数据认证 - SDA 2. 动态数据认证 - DDA 3. 复合动态数据认证/应用密文生成 – CDA
银联IC卡借贷记应用
银联芯片卡终端应支持正常的芯片卡交易和降级使用交易。终端应首先尝 试进行芯片交易,当芯片或芯片读卡器不能正常工作时方可进行降级使用 交易。 降级使用交易必须联机处理, 如果联机不能则拒绝交易。
不允许终端设备主动提示使用磁条而跳过芯片认证控制。
应正确标识芯片卡交易及降级使用交易。 发卡机构对受理机构正确标识并且经发卡机构授权的降级使用交易承担责 任。
卡片及ISO8583知识
磁条卡介绍
• 磁条
银行卡磁条的特性、编码技术及编码字符集应符合 GB/T 15120.2中的有关要求。 第1磁道的信息格式:磁道1为只读磁道,数据编码可记录数 字(0-9)、字母(A-Z)和其他一些符号(如括号、 分隔符等),最大可记录 79 个数字或字母。 第2磁道的信息格式:磁道2为只读磁道,所记录的字符只能 是数字(0-9)和“ =” ,最大可记录40 个字符。 第3磁道的信息格式:磁道3为读写磁道,所记录的字符只能 是数字(0-9),最大可记录107 个字符。

8583协议理解

8583协议理解

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

8583包前⾯⼀段为位图,⽤来确定包的字段域组成情况。

其中位图是8583包的灵魂,它是打包解包确定字段域的关键,⽽了解每个字段域的属性则是填写数据的基础。

在POS机的开发上时经常要⽤到,例如回头客会员管理系统在POS机上的应⽤就是采⽤8583报⽂。

报⽂的类型有很多种,⽐如:sale,reversal,settlement等等,不同的类型组包也是不⼀样的, 下⾯是“消费”类型报⽂的测试和组8583报⽂的过程,针对我们⽇常使⽤POS机系统来说的,这⾥主要是模拟的POS终端发向POSP系统的8583报⽂。

其基本业务流程图如下所⽰基础知识:1byte = 8bit1byte = 2个16进制数2个字节=1个字符BCD码:⽤4位⼆进制数来表⽰1位⼗进制数中的0~9这10个数码,即1bcd码=4bit报⽂结构:TPDU头 = ID(60H) + ⽬的地址(N4) + 源地址(N4),长度为10字节,压缩时⽤BCD码表⽰为5个字节长度的数值。

报⽂头 = 应⽤类别定义(N2 )+软件总版本号(N2) + 终端状态(N1) + 处理要求(N1)+ 软件分版本号(N6),总长度为12字节,压缩时⽤BCD码表⽰为6个字节长度的数值。

报⽂长度(2字节)+TPDU(5字节)+报⽂头(6字节)+域数据(指令码(0域 2字节消息类型)+位图(8字节)+其他域数据POS终端上送POS中⼼的消息报⽂结构包括TPDU、报⽂头和应⽤数据三部分:16进制报⽂:007b 6000160000 602200000000 0200 7020048020c08811600016000060220000000002007020048020c08811165477666265921222000000000000014959555556022000375477666265921222d25085060000012600000青⾊背景:报⽂长度 007b 如上是246个字节->123个字符->长度是123(10进制)->7b(16进制)->占⽤两个字节007b黄⾊背景:TUDU头 6000160000红⾊背景:报⽂头 602200000000磁条卡⾦融⽀付类应⽤为:60软件版本号 22终端状态 0(正常交易状态)处理要求 0(⽆处理要求)保留使⽤ 000000灰⾊背景:消息类型 0200绿⾊背景:bitmap位图,转成bit显⽰, 7020048020c08811根据⽂档我们可以轻易的得到需要的域为2,3,4,11,22,25,35,41,42,49,53,60,64域(6) 2域165477666265921222(16个字节,最⼤是19个字节) 主账号N..19(LLVAR),2个字节的长度值+最⼤19个字节的主账号,压缩时⽤BCD码表⽰的1个字节的长度值+⽤左靠BCD码表⽰的最⼤10个字节的主账号。

Iso-8583协议与磁条卡

Iso-8583协议与磁条卡

Copyright 2005 Prochip Electronics Co,ltd. All Rights Reserved. , 8 Not to be reproduced by any means without prior written consent.
2012-4-21
表2 第2磁道信息格式
}ISO_8583
Copyright 2005 Prochip Electronics Co,ltd. All Rights Reserved. , 3 Not to be reproduced by any means without prior written consent.
2012-4-21
2012-4-21
磁条卡的时序图
Copyright 2005 Prochip Electronics Co,ltd. All Rights Reserved. , 14 Not to be reproduced by any means without prior written consent.
1:消息类型标识 每个消息类型标识时报文内容得头. 占用四个字节,在打包时用压缩得BCD码.向外传输 2:位图 位图是8583包的灵魂,它是打包解包确定字段域的关键, 而了解每个字段域 的属性则是填写数据的基础, 在此中用8个字节(1个字节为8位,则为8*8=64) 设置其后64位的域.8583通过检查位图中的1的位置可以确定其后的数据的域, 然后根据域中规定的长度来取数据,这样解包就很方便了,打包则为相反.首先 检查域中有无数据,如有,则在相应的位图中的位置放置1,来标识此域中有数据 打包与解包: 为第1个域中有数据
1:磁条卡外部的硬件逻辑 1:轨道二的数据线 2:轨道三的数据线 3:时钟线 4:卡在线 5:地

8583报文解析

8583报文解析

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

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

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

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

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

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

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

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

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

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

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

- 1 -。

ISO8583报文协议详解

ISO8583报文协议详解

ISO8583报⽂协议详解ISO8583包(简称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, 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,"FORWARDING 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 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 73 */ {0,"NO USE ", 6, 0, 0, 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 105 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 106 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 107 */ {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位。

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, 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,"FORWARDING 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,"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 73 */ {0,"NO USE ", 6, 0, 0, 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 107 */ {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位。

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报文协议我刚进入金融行业时,就知道了IS08583报文协议,我想可能我还没进入这个行业都已经听过了,可知ISO8583的影响力有多大了。

最初刚接触它时,确实对其中的一些细节概念不是很清晰,对有些地方比较迷惑。

鉴于此,我想很多同行也必然会经历同样得阶段,所以我写下本文,以便大家能够少走一些弯路。

同时,我在网上写下我要写“全面掌握ISO8583报文”和“符合CEN/XFS(即WOSA/XFS)规的SP编写”两篇文章时,很多人都询问我什么时候能够写出来,可知许多人是需要了解这方面的知识的,即使我时间不是很多,也得尽量将这两篇文章写出来,给需要的人提供一些参考。

如果单纯的讲IS08583那些字段的定义,我觉得没有什么意思,标准中已经对每个字段解释的非常详细了,如果你觉得理解英文版的ISO8583规有些困难,网上也有同行为我们翻译好的中文版ISO8583规,所以我的目的是达到阅读本文后能够对ISO8583知其然,亦知其所以然,使以前基本没有接触它的人也能够达到掌握ISO8583报文规。

好了,我们该转入正题了。

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

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

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

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

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

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

解析ISO8583报文实例

解析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。

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

ISO8583各域详解

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都需要指定长度。

NUMERIC右对齐、左补零。

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

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

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

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

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

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

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

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

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

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

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

解析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。

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 包格式。

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

位元定义: (注:带*号的本行没用)位元数据元名称格式属性会晤报文头An8报文类型an4- (主位图) B641 (扩展位图) B642 主帐号LLVAR n..193 处理代码n64 交易金额n125 清算金额n126* 持卡人签单金额n127 传输日期和时间MMDDhhmmss n108* 持卡人签单手续金额n89 清算兑换率n810* 持卡人签单兑换率n811 系统跟踪审计号n812 本地交易日期和时间YYMMDDhhmmss n613 本地交易日期YYMM n414* 截止日期YYMM n415 结算日期YYMMDD n616* 兑换日期MMDD n417* 受理日期MMDD n418 商户类型n419* 代理机构国家代码n320* 主帐号国家代码n321* 发送机构国家代码n322* 服务点输入方式an1223 卡顺序号n324 卡种类n325 服务点条件代码n426* 受卡方业务代码n427* 批准代码长度n128 交易手续费X+n 829 地区代码N830* 原始金额n24 31* 代理方参考数据LLVAR Ans..9932 受理行标识代码LLVAR n..1133 发送方标识代码LLVAR n..11 34* 扩展的主帐号LLVAR ns..2835 第二磁道数据LLVAR z..3736 第三磁道数据LLLVAR z..104 37* 检索参考号Anp1238 授权代码Anp639 响应代码An2 40* 服务代码n341 终端代码Ans1542 终端标识Ans1543 受卡方名称/地点Ans..4044 附加响应数据LLVAR Ans..25 45* 第一磁道数据LLVAR Ans..76 46* 手续费金额LLLVAR Ans..204 47* 附加数据——国家LLLVAR Ans..99948 附加数据LLLVAR Ans..99949 交易贷币代码n350 结算贷币代码n351* 持卡人签单贷币代码a3或n3 52 个人识别号(PIN)B6453* 安全控制信息LLVAR b..48 54 附加金额LLLVAR An..120 55* 集成电路卡系统数据LLLVAR b..48 56* 原始数据元LLVAR n..35 57* 授权生命周期代码n358* 授权代理机构标识代码LLVAR n..11 59* 传输数据LLLVAR Ans..99960 附加数据LLLVAR Ans..99961 附加数据LLLVAR Ans..99962 主机交易检索号LLLVAR Ans..99963 附加数据LLLVAR Ans..99964 报文鉴别代码字段B6465* 保留给ISO使用b866* 原始手续费金额LLLVAR Ans..204 67* 扩展的付款数据n268* 接收机构国家代码n369* 清算机构国家代码n370 网络管理信息代码n371 报文编号N472* 数据记录LLLVAR Ans..999 73* 动作日期YYMMDD n674* 贷记笔数n1075* 撤消贷记笔数n1076* 借记笔数n1077* 撤消借记笔数n1078* 转帐笔数n1079* 撤消转帐笔数n1080* 查询笔数n1081* 授权笔数n1082* 撤消查询笔数n1083* 付款笔数n1084* 撤消付款笔数n1085* 手续费收取笔数n1086* 贷记金额n1687* 撤消贷记金额n1688* 借记金额n1689* 撤消借记金额n1690 原始交易数据N4291 文件更新代码An192* 交易发起机构国家代码n393* 交易终点机构标识代码LLVAR n..11 94* 交易发卢机构标识代码LLVAR n..11 95 替换金额an..42 96* 密钥管理数据LLLVAR b..999 97* 净对帐金额x+n16 98* 收款人Ans25 99* 清算机构标识代码LLVAR an..11 100 接收机构标识代码LLVAR n..11 101 文件名称LLVAR Ans..17 102 转出帐户帐号LLVAR Ans..28 103 转入帐户帐号LLVAR Ans..28 104 交易描述LLLVAR Ans..999 105* 反向贷记金额n16 106* 反向借记金额n16 107* 反向贷记笔数n10 108* 反向借记笔数n10 109* 手续费贷记金额LLVAR Ans..84 110* 手续费借记金额LLVAR Ans..84 111* 保留给ISO使用LLLVAR Ans..999 112* 保留给ISO使用LLLVAR Ans..999 113* 保留给ISO使用LLLVAR Ans..999 114* 保留给ISO使用LLLVAR Ans..999 115* 保留给ISO使用LLLVAR Ans..999 116* 保留给国家使用LLLVAR Ans..999 117* 保留给国家使用LLLVAR Ans..999 118* 保留给国家使用LLLVAR Ans..999 119* 保留给国家使用LLLVAR Ans..999 120* 保留给国家使用LLLVAR Ans..999 121* 保留给国家使用LLLVAR Ans..999 122* 保留给国家使用LLLVAR Ans..999 123* 保留给民间使用LLVAR Ans..999 124* 保留给民间使用LLVAR Ans..999 125 新个人标识号B64 126* 保留给民间使用LLVAR ans..999 127* 保留给民间使用LLVAR ans..999128 报文鉴别代码字段B641、信息类型(message type)定义位图位置:-格式:定长类型:N4描述:数据包的第一部分,定义数据包的类型。

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各域详解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 包格式。

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

位元定义: (注:带*号的本行没用)位元数据元名称格式属性会晤报文头An8报文类型an4- (主位图) B641 (扩展位图) B642 主帐号LLVAR n..193 处理代码n64 交易金额n125 清算金额n126* 持卡人签单金额n127 传输日期和时间MMDDhhmmss n108* 持卡人签单手续金额n89 清算兑换率n810* 持卡人签单兑换率n811 系统跟踪审计号n812 本地交易日期和时间YYMMDDhhmmss n613 本地交易日期YYMM n414* 截止日期YYMM n415 结算日期YYMMDD n616* 兑换日期MMDD n417* 受理日期MMDD n418 商户类型n419* 代理机构国家代码n320* 主帐号国家代码n321* 发送机构国家代码n322* 服务点输入方式an1223 卡顺序号n324 卡种类n325 服务点条件代码n426* 受卡方业务代码n427* 批准代码长度n128 交易手续费X+n 829 地区代码N830* 原始金额n24 31* 代理方参考数据LLVAR Ans..9932 受理行标识代码LLVAR n..1133 发送方标识代码LLVAR n..11 34* 扩展的主帐号LLVAR ns..2835 第二磁道数据LLVAR z..3736 第三磁道数据LLLVAR z..104 37* 检索参考号Anp1238 授权代码Anp639 响应代码An2 40* 服务代码n341 终端代码Ans1542 终端标识Ans1543 受卡方名称/地点Ans..4044 附加响应数据LLVAR Ans..25 45* 第一磁道数据LLVAR Ans..76 46* 手续费金额LLLVAR Ans..204 47* 附加数据——国家LLLVAR Ans..99948 附加数据LLLVAR Ans..99949 交易贷币代码n350 结算贷币代码n351* 持卡人签单贷币代码a3或n3 52 个人识别号(PIN)B6453* 安全控制信息LLVAR b..48 54 附加金额LLLVAR An..120 55* 集成电路卡系统数据LLLVAR b..48 56* 原始数据元LLVAR n..35 57* 授权生命周期代码n358* 授权代理机构标识代码LLVAR n..11 59* 传输数据LLLVAR Ans..99960 附加数据LLLVAR Ans..99961 附加数据LLLVAR Ans..99962 主机交易检索号LLLVAR Ans..99963 附加数据LLLVAR Ans..99964 报文鉴别代码字段B6465* 保留给ISO使用b866* 原始手续费金额LLLVAR Ans..204 67* 扩展的付款数据n268* 接收机构国家代码n369* 清算机构国家代码n370 网络管理信息代码n371 报文编号N472* 数据记录LLLVAR Ans..999 73* 动作日期YYMMDD n674* 贷记笔数n1075* 撤消贷记笔数n1076* 借记笔数n1077* 撤消借记笔数n1078* 转帐笔数n1079* 撤消转帐笔数n1080* 查询笔数n1081* 授权笔数n1082* 撤消查询笔数n1083* 付款笔数n1084* 撤消付款笔数n1085* 手续费收取笔数n1086* 贷记金额n1687* 撤消贷记金额n1688* 借记金额n1689* 撤消借记金额n1690 原始交易数据N4291 文件更新代码An192* 交易发起机构国家代码n393* 交易终点机构标识代码LLVAR n..11 94* 交易发卢机构标识代码LLVAR n..11 95 替换金额an..42 96* 密钥管理数据LLLVAR b..999 97* 净对帐金额x+n16 98* 收款人Ans25 99* 清算机构标识代码LLVAR an..11 100 接收机构标识代码LLVAR n..11 101 文件名称LLVAR Ans..17 102 转出帐户帐号LLVAR Ans..28 103 转入帐户帐号LLVAR Ans..28 104 交易描述LLLVAR Ans..999 105* 反向贷记金额n16 106* 反向借记金额n16 107* 反向贷记笔数n10 108* 反向借记笔数n10 109* 手续费贷记金额LLVAR Ans..84 110* 手续费借记金额LLVAR Ans..84 111* 保留给ISO使用LLLVAR Ans..999 112* 保留给ISO使用LLLVAR Ans..999 113* 保留给ISO使用LLLVAR Ans..999 114* 保留给ISO使用LLLVAR Ans..999 115* 保留给ISO使用LLLVAR Ans..999 116* 保留给国家使用LLLVAR Ans..999 117* 保留给国家使用LLLVAR Ans..999 118* 保留给国家使用LLLVAR Ans..999 119* 保留给国家使用LLLVAR Ans..999 120* 保留给国家使用LLLVAR Ans..999 121* 保留给国家使用LLLVAR Ans..999 122* 保留给国家使用LLLVAR Ans..999 123* 保留给民间使用LLVAR Ans..999 124* 保留给民间使用LLVAR Ans..999 125 新个人标识号B64 126* 保留给民间使用LLVAR ans..999 127* 保留给民间使用LLVAR ans..999128 报文鉴别代码字段B641、信息类型(message type)定义位图位置:-格式:定长类型:N4描述:数据包的第一部分,定义数据包的类型。

银联ISO8583报文解析过程

银联ISO8583报文解析过程

银联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简介

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

ISO8583金融报文详细分析

ISO8583金融报文详细分析

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

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

全面掌握ISO8583报文协议我刚进入金融行业时,就知道了IS08583报文协议,我想可能我还没进入这个行业都已经听过了,可知ISO8583的影响力有多大了。

最初刚接触它时,确实对其中的一些细节概念不是很清晰,对有些地方比较迷惑。

鉴于此,我想很多同行也必然会经历同样得阶段,所以我写下本文,以便大家能够少走一些弯路。

同时,我在网上写下我要写“全面掌握ISO8583报文”和“符合CEN/XFS(即WOSA/XFS)规范的SP编写”两篇文章时,很多人都询问我什么时候能够写出来,可知许多人是需要了解这方面的知识的,即使我时间不是很多,也得尽量将这两篇文章写出来,给需要的人提供一些参考。

如果单纯的讲IS08583那些字段的定义,我觉得没有什么意思,标准中已经对每个字段解释的非常详细了,如果你觉得理解英文版的ISO8583规范有些困难,网上也有同行为我们翻译好的中文版ISO8583规范,所以我的目的是达到阅读本文后能够对ISO8583知其然,亦知其所以然,使以前基本没有接触它的人也能够达到掌握ISO8583报文规范。

好了,我们该转入正题了。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

比如第1个字段是“交易类型”,长度为4位,第2个字段位是“帐号”,为19位等等。

接收方就可以先取4位,再取接着的19位,依次类推,直到整个数据包128个字段都解完为止。

其实这种做法真是简单直接,基本上就可以满足需要了。

不过我们有几个问题要思考下:1、我怎么知道每个字段的数据类型呢,是数字还是字符?2、每个传送的报文都把128个字段都传过去,那网络带宽能够承受得了,有时候我可能只需要其中5个字段,结果多收到了123个无用的字段。

3、如果我某些字段的长度不固定,属于变长怎么办,因为你现在解包是当作数据包每个字段都是固定的,用C语言解包时直接依靠指针取固定长度的一串字符做为一个字段。

我们来一一解决这些问题。

第一个问题简单,我在定义ISO8583时除了定义每个字段表示什么,还规定其内容是数字或是字符等即可。

考虑可能出现的类型不过有以下几种:字母、数字、特殊字符、年月日等时间、二进制数据。

比如我对128个字段中的“商户类型”字段定义其长度是15,同时定义其类型为字母。

再精细点,如果“商户类型”里面的数据同时包括数字和字母呢?那我们就定义其类型为字母也可,为数字也可,即一个字段可以同时属于多个类型。

第二个问题稍微复杂点。

其本质就是如果我只传128个字段的5个字段,接收方怎么知道我传了哪几个字段给它了。

要是我们把剩下的123全部填成0或其他特殊标识,标明该字段不需要使用?这种处理方法没有半点用处,没有解决网络带宽的本质问题,还是要传128个字段。

2 4 162 8 256换个思路,我在报文前面加上个包头,包头里面包含的信息能够让别人知道只传了5个字段。

怎样设计这个包头,可以这样,我们用16个字节,即128个bit(一个字节等于8bit)来表示128个字段中的某个字段是否存在。

每个bit在计算机的二进制里面不是1就是0,如果是1就表示对应的字段在本次报文中存在,如果是0就是不存在。

这样好了,如果别人接收到了ISO8583报文,可以先根据最前面的报文头,就知道紧接着报文头后面的报文有哪些字段,没有哪些字段了。

比如,我要发送5个字段,分别属于128个字段中的第2、3、6、8、9字段,我就可以将128bit的报文头填成011001011000000000………..,一共128个bit,后面就全是0了。

注意其中第2、3、6、8、9位为1,其他都为0。

有了这个128bit的报文头,我们就可以只发送需要的5个字段了。

怎样组织报文?先放上这128bit,即2个字节的头,然后在头后面放2、3、6、8、9字段,这些字段紧挨在一起,3和6之间也不需要填上4、5这两个字段了。

接收方收到这个报文,它会根据128bit的报文头来解包,它自然知道把第3个字段取出后,就直接在第3字段的后面取第6个字段,每个字段的长度在ISO8583里面都定义好了,很轻松就把数据包解出来了。

这下好了,为了解决上面的第二问题,我们只是在报文中增加了2个字节的数据,就轻松搞定了,我们把这2个字节称为bit map,即位图,用来表示某个位是否存在。

不过我们再稍微优化一下,考虑到很多时候报文不需要128个字段这么多,其一半64个字段都不一定能够用完。

那我可以将报文头由128bit减到64bit,只有在需要的时候才把剩下的64bit放到报文里面,这样报文长度不又少了1个字节吗?是个好主意。

我们把ISO8583的128个字段中最常见的都放到前64个字段中,那我们可以将处理缩小一倍。

这样我一般发送报文时只需发送64bit,即一个字节的报文头,再加上需要的几个字段就可以了。

如果有些报文用到64到128之间的字段呢?这个也好办,我把64bit报文头的第一位bit用来代表特殊含义,如果该bit为1,则表示64bit后面跟了剩下的64bit报文头;如果第一位bit为0,则表示64bit后面没有跟剩下的64bit报文头,直接是128个字段中的报文了。

那们,接收方会判断一下报头的第一个bit是1还是0,从而知道报文头是64bit还是128bit了,就可以做相应处理。

因为报文头第二个64bit属于有时候有,所以我们叫它Extended bit map扩展位图,相应的报文头最开始的64bit我们叫它Primary bit map主位图。

我们直接把扩展位图固定放到128个字段的第一个字段,而主位图每个数据包都有,就强制性放在所有128个字段的前面,并不归入128个字段中去。

第三个问题可以考虑这样解决。

比如第2个字段是“帐号”,是不定长的,可能有的银行帐号是19位,有的是17位等。

我们定ISO8583规范时可以规定第2个字段是25位,这下足够将19和17的情况都包含进来,但是如果以后出现了30位的怎么办?那我们现在将字段定为100位。

以后超过100位怎么办,况且如果你只有19位的帐号,我们定义了100位,那81位的数据不是浪费了网络的带宽。

看来预先定义一个我们认为比较大的位数是不太好的。

我们这样,对于第2个字段“帐号”,在字段的开头加上“帐号”的长度。

比如帐号是0123456789,一共10位,我们变成100123456789,注意前面多了个10,表示后面的10位为帐号。

如果你接触过COM里面的BSTR,应该对这种处理比较熟悉了。

接收方收到该字段后,它知道ISO8583规定第2个字段“帐号”是变长的,所以会先取前面的2位出来,获取其值,此时为长度,然后根据该长度值知道应该拷贝该字段后面哪几位数据,才是真正的帐号。

如果你觉得长度如果只有两位最多只能表示99位长,不太够,我们也定义可以允许前面3位都为长度的变长字段,这样就有999位长,应该够了吧。

在规范里面如果我定义某个字段的属性是“LLV AR”,你注意了,其中的LL表示长度,V AR表示后面的数据,两个LL 表示两位长,最大是99,如果是三位就是“LLLV AR”,最大是999。

这样看我们定义的ISO8583规范文档时直接根据这几个字母就理解某个变长字段的意思了。

该解决的几个问题到这里都解决了,我们来回顾下自己设计的ISO8583规范。

其实没有什么,无非是把金融行业可能出现的数据分门别类,排好顺序,接着把它们连接起来,组成一个报文发送出去而已。

其中针对该报文的设计进行了一些优化,引入了bit map位图的概念,也算是一个不错的想法。

剩下的工作就简单了,我们就直接收集金融行业可能出现的数据字段类型,分成128个字段类型,如果没有到128个这么多就先保留一些下来,另外考虑到有些人有特殊的要求,我们规定可以将128个字段中的几个字段你自己来定义其内容,也算是一种扩展了。

这样,最后我们就得到了ISO8583规范的那张字段描述表了。

想要详细的知道每个字段的含义直接对着表看就可以,比较简单。

全文完8583协议编辑词条摘要ISO8583包(简称8583包)是一个国际标准的包格式,最多由128个字段域组成,每个域都有统一的规定,并有定长与变长之分。

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

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

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

相关文档
最新文档