ISO8583金融报文详细分析

合集下载

8583协议

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

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

通过这种结构，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报文实例

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报文解析实例：以下是主机从网控器收到的消费数据包（用二位十六进制数表示一个字节）：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问题作者: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},};３、变长，定长域说明如第二域：域名为主帐号，数据类型为string长度为22（是长长度不得超过此数）是个２位变长域由于是２位变长，在打包时需在数据域前加上数据的实际长度，如为１９位，则表示为：１９＋数据值（即前两位为长度）如第三域：域名为处理码，数据类型为string长度为６是个定长域必须填满６位。

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报文解包和组包

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报文交易的异常处理
刘新迂
【期刊名称】《金融科技时代》
【年(卷),期】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],
因版权原因，仅展示原文概要，查看原文内容请购买。

全面掌握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报文实例（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。

8583协议

8583协议8583协议是一种用于金融交易的通信协议，广泛应用于ATM、POS机等终端设备。

该协议定义了数据交换的格式和规则，确保了交易数据的安全和准确性。

本文将介绍8583协议的基本原理和常用字段，以及在实际应用中的一些注意事项。

一、8583协议的基本原理8583协议采用了二进制的格式进行数据交换，通讯双方通过数据包的方式进行通信。

数据包由消息类型、位图和数据域组成。

1. 消息类型消息类型用来表示不同的交易类型，如消费、撤销、余额查询等。

消息类型由4个字节组成，分为三个部分：类别标志、服务标志和功能标志。

其中，类别标志表示交易类型的大类，服务标志和功能标志共同表示具体的交易类型。

2. 位图位图用来表示数据域的存在情况。

位图由64个二进制位组成，每个位代表一个数据域。

如果某个数据域存在，则对应位图中的相应位为1；反之，为0。

位图按照从左到右、从上到下的顺序排列，即第一个二进制位表示第一个数据域。

3. 数据域数据域是真正存放交易数据的地方。

数据域根据位图的设置情况而存在或不存在。

每个数据域由类型、长度和内容三部分组成。

类型表示数据的类型，如数字、字符、二进制等；长度表示数据的长度；内容表示具体的交易数据。

二、常用字段8583协议定义了多个常用的数据域，用于存放交易中常见的数据。

以下为一些常用字段的介绍：1. 主账号（PAN）主账号是唯一标识一个账户的号码，通常是银行卡号或信用卡号。

主账号的长度可以根据实际情况而定，一般为16到19位。

2. 交易金额（Amount）交易金额表示本次交易的金额数目，一般以分为单位。

该字段的长度通常为12位，包括小数点后两位。

3. 交易日期和时间（DateTime）交易日期和时间用来记录交易发生的具体日期和时间。

该字段的长度为14位，格式为年月日时分秒。

4. 交易类型（Transaction Type）交易类型表示本次交易的具体类型，如消费、撤销、预授权等。

该字段的长度为3位。

8583报文详解

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

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

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

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

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

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

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

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

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

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

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

任何金融软件收到ISO8583包后，直接按照我们定义的规范解包即可，因为整个报文的128个字段从哪一位到哪一位代表什么，大家都知道，只要知道你的数据包是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各域详解--整理版知识讲解

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各域详解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简介一、定义与说明二、报文类型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各域详解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描述：数据包的第一部分，定义数据包的类型。

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

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

银联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值。

报文模拟测试(含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加密。

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

1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
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.。