ISO8583金融报文详细分析

合集下载

8583协议

8583协议

8583协议
8583协议采用了一种类似于TLV(Type Length Value)的数据结构,数据包含了消息类型、位图、各种域以及域值。

其中,消息类型用于标识交易的类型,位图用于标识数据域的存在与否,各种域则包含了交易的具体信息,比如交易金额、交易时间、交易参与方等。

通过这种结构,8583协议可以灵活地适应各种不同类型的金融交易,同时也能够满足不同金融机构和系统的需求。

在实际应用中,8583协议的具体实现可能会有所不同,但其基本原则和数据结构是一致的。

金融机构和系统需要严格按照8583协议的规定来进行数据交换和处理,以确保交易的准确性和安全性。

同时,由于8583协议的灵活性,金融机构和系统也可以根据自身的需求对协议进行定制和扩展,以满足特定的业务需求。

除了在金融领域,8583协议也被广泛应用于其他领域的数据交换中,比如电信行业、交通行业等。

这是因为8583协议具有通用性和灵活性,可以适应不同领域的数据交换需求。

同时,由于8583协议的成熟和稳定,各种相关的技术和工具也得到了广泛的支持和应用,使得8583协议成为了一种通用的数据交换标准。

总之,8583协议作为一种通用的金融交易通信协议,具有重要的意义和价值。

它不仅规范了金融交易数据的格式和规则,保障了金融交易的安全性和准确性,而且也为各种金融机构和系统提供了一种灵活和通用的数据交换标准。

随着金融科技的发展和金融业务的不断创新,8583协议也将继续发挥重要作用,为金融交易的高效、安全和便捷提供坚实的技术支持。

报文解析学习——8583设计原理

报文解析学习——8583设计原理

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

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

其中位图是8583包的灵魂,它是打包、解包确定字段域的关键。

而了解每一个字段域的属性则是填写数据的基础。

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 (蓝线标注)应用数据占用两个字节,即02 00 也就是"0200"。

应用数据部分指定消息类型(例如余额查询、消费等交易等消费类型)(黑线标注)应用数据之后的若干个字节表示位图。

首先取第十四个字节,即0x30,转化为二进制00110000,在该字节的第一位为0(从左往右)表示当前报文中只需要包括64个域(用8个字节表示),也就是从当前字节开始连续8个字节为位图(包括当前字节),如果要包括128个域(用16个字节表示),该位为1。

《1》位图分析:(bit map 域指定了哪些域存在。

域是从1开始的)取表示位图的8个字节即30 20 04 C0 20 C0 98 11转化为二进制为:00110000 00100000 00000100 11000000 00100000 11000000 10011000 00010001位图中为1的位置即代表相应的域,在上面的二进制位中从左往右有第3位、第4位、第11位、第22位、第25位、第26位、第35位、第41位、第42位、第49位、第52位、第53位、第60位、第64位。

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报文解析实例

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

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

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。

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报文交易的异常处理
刘新迂
【期刊名称】《金融科技时代》
【年(卷),期】1998(000)002
【摘要】银行卡跨行互联网络的每一笔交易,都至少跨越终端、代理行主机、交换中心和发卡行主机4个网络节点,包括交易请求和响应的6段网络路径,同时又工作在联机实时交易状态下。

因而存在着故障出现的必然性和交易要求的实时性、正确性的矛盾,处理不当将直接影响到客户的利益和银行的信誉。

这类应用系统的正常交换功能并不复杂,而网络交易异常处理的问题则十分突出。

有人说,银行卡互联网络技术的一大特点是:用5%的工作量处理95%的
【总页数】3页(P55-57)
【作者】刘新迂
【作者单位】
【正文语种】中文
【中图分类】F830.49
【相关文献】
1.用互联网方式建立银行卡跨行交易差错处理平台 [J], 张春玲;郝义泉
2.SAF技术在邮政金融联网交易异常处理中的应用 [J], 无
3.银行卡自助交易中的差错交易成因及发现方法 [J], 刘晓亮
4.开展银行卡境外交易信息采集完善银行卡跨境交易统计 [J],
5.英国银行卡月交易次数首超10亿交易额137亿英镑 [J],
因版权原因,仅展示原文概要,查看原文内容请购买。

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

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自带的计算器计算出它对应的二进制是
111000000100000000000000000000000100000110000001000001000000000, 由此可以看出下面几个域存在: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 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>
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.。

相关文档
最新文档