ISO8583各域详解--整理版
Iso-8583协议与磁条卡
ISO-8583
将打包压缩的数据发送 给下一层
ISO-8583的下一层
Copyright 2005 Prochip Electronics Co，ltd. All Rights Reserved. ， 2 Not to be reproduced by any means without prior written consent.
2012-4-21
磁条卡的时序图
Copyright 2005 Prochip Electronics Co，ltd. All Rights Reserved. ， 14 Not to be reproduced by any means without prior written consent.
Copyright 2005 Prochip Electronics Co，ltd. All Rights Reserved. ， 7 Not to be reproduced by any means without prior written consent.
2012-4-21
表1 第1磁道信息格式
Copyright 2005 Prochip Electronics Co，ltd. All Rights Reserved. ， 4 Not to be reproduced by any means without prior written consent.
2012-4-21
报文得内容(重点是如下几个问题):
nottobereproducedbyanymeanswithoutpriorwrittenconsent201851表1第1磁道信息格式字段d动态s静态字段长度备注序号名称1起始标志s1见712格式代码s299见723主账号s1319见734字段分隔符s1见745姓名s226见756字段分隔符s1见747失效日期s4yymm见768服务代码s3见779附加数据s可变见7810结束标志s1
银行卡和ISO8583要点
银联IC卡借贷记应用
对于银联芯片卡的联机交易，收单机构应将卡片给出的应答作为交易确认的基 本信息； 对于银联芯片卡的脱机交易，收单机构应将卡片给出的交易证书(TC)作为交易 确认的基本信息。 收单机构应妥善保管TC及其参与计算TC的数据，因为交易证书（TC）是交易是 否被发卡机构认可的凭证，一旦出现差错或争议时，TC及其计算数据是重要处 理依据。
借记/贷记应用联机处理流程
联机处理
双向认证 发卡行认证数据 发卡行脚本命令 发卡行 •解密ARQC来认证卡片 •授权响应密文ARPC， 授权响应码ARC •发卡行脚本 ARC、ARPC 发卡行脚本 授权请求密文ARQC等
终端发给发卡行 • 授权请求密文ARQC • 生成ARQC的数据
银联IC卡借贷记应用
银联IC卡借贷记应用
银联芯片卡终端应支持正常的芯片卡交易和降级使用交易。终端应首先尝 试进行芯片交易，当芯片或芯片读卡器不能正常工作时方可进行降级使用 交易。 降级使用交易必须联机处理, 如果联机不能则拒绝交易。
不允许终端设备主动提示使用磁条而跳过芯片认证控制。
应正确标识芯片卡交易及降级使用交易。 发卡机构对受理机构正确标识并且经发卡机构授权的降级使用交易承担责 任。
-2-
第1磁道信息格式
%4761739001010010^VISA ACQUIRER TEST CARD 08^10122011143878089?
1 2 3 4 5 6 7 8 9 10 11 起始标志 格式代码 主账号 字段分隔符 姓名 字段分隔符 失效日期 服务代码 附加数据 结束标志 纵向冗余校验位 1 0~2 13~19 1 2~26 1 4 3 可变 1 1 %，见7.1 见7.2 4761739001010010，见7.3 ^，见7.4 VISA ACQUIRER TEST CARD 08，见7.5 ^，见7.4 1012，YYMM见7.6 见7.7 见7.8 ？，见7.9 见7.10
8583协议
ISO8583报文协议最开始时，金融系统只有IBM这些大的公司来提供设备，象各种主机与终端等。
在各个计算机设备之间，需要交换数据。
我们知道数据是通过网络来传送的，而在网络上传送的数据都是基于0或1这样的二进制数据，如果没有对数据进行编码，则这些数据没有人能够理解，属于没有用的数据。
起初的X.25、SDLC 以及现在流行的TCP/IP网络协议都提供底层的通讯编码协议，它们解决了最底层的通讯问题，能够将一串字符从一个地方传送到另一个地方。
但是，仅仅传送字符串是没有太大意义的，怎样来解析字符串代表什么内容是非常重要的，否则传送一些“0123abcd”的字符串也是无用的乱码。
让我们随着时光回到几十年前的某个时刻，假设我们被推到历史的舞台上，由我们来设计一个通用报文协议，来解决金融系统之间的报文交换，暂且称该协议叫做ISO8583协议。
此时，技术是在不断的前行，当初IBM一支独秀的局面好像已经不妙了，各种大小不一的公司都进入金融行业以求能有所斩获，呈一片百花齐放的局面。
我们怎样来设计一个报文协议，能够将这些如雨后春笋般出现的所有公司都纳入进来，其实也不是一件很简单的事。
我们还是先一步步的来考虑吧。
金融行业其实涉及到的数据内容并不是成千上万，无法统计，恰恰相反，是比较少的。
我们都可以在心底数得过来，象交易类型、帐号、帐户类型、密码、交易金额、交易手续费、日期时间、商户代码、2磁3磁数据、交易序列号等，把所有能够总结出来的都总结起来不过100个左右的数据。
那我们可以首先简单的设计ISO8583，定义128个字段，将所有能够考虑到的类似上面提到的“帐号”等金融数据类型，按照一个顺序排起来，分别对应128个字段中的一个字段。
每个数据类型占固定的长度，这个顺序和长度我们都事先定义好。
这样就简单了，要发送一个报文时，就将128个字段按照顺序接起来，然后将接起来的整串数据包发送出去。
任何金融软件收到ISO8583包后，直接按照我们定义的规范解包即可，因为整个报文的128个字段从哪一位到哪一位代表什么，大家都知道，只要知道你的数据包是ISO8583包即可，我们都已经定义好了。
报文解析学习——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协议理解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个字节的主账号。
ISO8583各域详解--整理版
ISO8583各域详解--整理版ISO8583各域详解8583协议的报文域编码格式分为：BINARY、CHAR、NUMERIC、LLVAR、LLLVAR、LLLVAR_NUMERIC这几种格式。
BINARY采用二进制编码(8位二进制数编码为一个字节)。
CHAR、LLVAR、LLLVAR为ASC（即正常的getBytes(Encoding)）编码。
NUMERIC、LLLVAR_NUMERIC 采用BCD(半个字节表示一个10进制数，每两位编码为一个字节)编码。
CHAR、BINARY、NUMERIC都需要指定长度。
CHAR类型左对齐、右补空格。
NUMERIC右对齐、左补零。
LLVAR域前加一个字节的字节长度（采用bcd编码）。
LLLVAR域前加两个字节的字节长度（采用bcd编码）。
LLLVAR_NUMERIC域前加两个字节的长度(注：非字节长度，而是数字的长度，即字节长度的两倍)（采用bcd编码）。
代码中会在IsoField setValue时进行格式化，组装报文时计算LLVAR等域长。
ISO8583域说明ATM、前置机间通讯采用ISO8583 包格式。
以下是位元、报文等的定义。
1、信息类型（message type)定义位图位置：－格式：定长类型：N4描述：数据包的第一部分，定义数据包的类型。
数据类型由数据包的发起者设定，应遵循以下要求：数据包开始部分必须是信息类型；对不支持的信息类型能给出拒绝应答。
0100授权交易0110授权交易答复0200金融交易0210金融交易答复0240查询交易0250查询交易答复0400冲正交易0410冲正交易答复0800管理交易0810管理交易答复2、位图(Bit Map) - 基本位图和扩展位图位图位置：01格式：定长类型：B16描述：如将位图的第一位设为1，表示使用扩展位图，否则表示只使用基本位图。
如使用某数据域，应在位图中将相应的位设位1，如使用41域，需将位图的41位设为1。
8583报文及各域详解
[精彩] 8583问题 作者: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长度为６是个定长域必须填满６位。
8583各域详解
8583各个域详解收藏1，信息类型（message type)定义位图位置：－格式：定长类型：N4描述：数据包的第一部分，定义数据包的类型。
数据类型由数据包的发起者设定，应遵循以下要求：数据包开始部分必须是信息类型；对不支持的信息类型能给出拒绝应答。
0100授权交易0110授权交易答复0200金融交易0210金融交易答复0240查询交易0250查询交易答复0400冲正交易0410冲正交易答复0800管理交易0810管理交易答复2，位图(Bit Map) - 基本位图和扩展位图位图位置：1格式：定长类型：B16描述：如将位图的第一位设为'1'，表示使用扩展位图，否则表示只使用基本位图。
如使用某数据域，应在位图中将相应的位设位'1'，如使用41域，需将位图的41位设为'1'。
选用条件：如使用65到128域，需设位图域为'1'3，Bit02主帐号(Primary Account Number )位图位置：02格式：变长,LLVAR类型：N..22描述：唯一的确认一个用户交易的基本帐号。
由于银行电子服务系统涉及多个应用系统，而帐号长度最多为22位，故将原标准的19长度改为22位。
Bit03 处理代码（Processing Code )位图位置：03格式：定长类型：N6描述：用于描述交易对客户帐户造成何种影响的代码。
处理代码和信息码一起可唯一定义一种交易的类型。
处理代码由以下三部分组成：位置描述1－2交易动作码3－4付出帐户类型，用于借记类，如查询、代收费、转场交易。
5－6收入帐户类型，用于代收费、转帐等。
其中：ff : 付出帐户tt：收入帐户* 视主机而定5，Bit04 交易金额（Amount, Transaction)位图位置：04格式：定长类型：N12描述：帐户人要求交易的交易金额，不含任何处理和交易费用。
金额的表示和货币代码有关，应能表示相应货币的最小单位。
ISO8583报文解包和组包
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简介一、定义与说明二、报文类型1、报文的分类与标识2、报文重复3、报文类型的说明三、位元表和数据元目录四、数据元详解五、拆包举例说明引言金融行业的业务包括有关金融交易的电子信息交换。
应用规范的约定通常局限在专业级别上。
ISO8583国际标准设计了一个保证在采用不同应用规范的系统间能够进行信息交换的界面规范。
各应用规范可保持在专用级别上。
在信息可以转换成能够进行国际交换的界面格式这一总的约束条件下，各应用系统的设计者可享有完全的灵活性。
ISO8583标准使用一个称为“比特图”的概念，在此，对每个数据元在控制字段或比特图中分配一个位置标记。
在一个具体信息中，数据元存在则在指定的位置上用“1”标明，数据元不存在则用“0”标明。
各个系统所采用的信息格式取决于个系统签约双方的商务关系。
ISO8583标准定义的数据格式能构保证符合标准的个系统总是兼容的。
一、定义与说明本节给出简介中涉及的部分术语的解释和定义。
1、版本版本是对交换报文格式的说明，用于区别根据不同标准或同一标准的不同版本所定义的报文格式，如GB/T15150－94或ISO8583－1993。
报文定义所依据的规范不同，其数据元的含义、组成和数据格式也不尽相同。
本规范的蓝本是国际标准ISO8583－1993《产生报文的银行卡交换报文规范金融交易内容》，并根据国家金卡网络的实际业务需求做了相应的裁剪和补充完善。
与全国银行卡中心连接的各节点机应统一采用本规范所定义的报文格式。
2、位元表用来标识报文中各数据元存在（用1表示）或不存在（用0表示）的一个64比特位序列，包括基本位元表和扩展位元表。
3、报文用于机构或其代理之间交换信息的一个数据元集合，不包括任何用于通信控制或其它目的的标识数据。
4、报文前缀指交换信息包中位于报文之前的一段固定长度和格式的数据序列，用于通信控制、报文流向控制等用途。
5、报文类别指一组报文的集合，描述被执行的一种特定活动。
8583数据解析
8583数据解析1、8583为国际卡组织发明的交易报⽂传输。
加强了交易的安全性、⼀致性、失效性⼀直沿⽤⾄今。
2 、谈⼀下银⾏卡收单流程。
银⾏卡——pos机具——收单机构——银联——发卡⾏——银联——收单机构——pos机。
（完整流程完成⼀笔交易）从传统pos收单通道、再整个流程中数据是以8583形式传输。
当然现在银联也推出了全渠道、apple pay 等通道。
3 、报⽂传输都是以字节流进⾏传输。
作为开发⼈员、⾸先接触8583感觉很迷茫。
银联8583报⽂是以128域组成。
pos机具发送和传输则以64域组成。
中间转换曾则为收单机构进⾏转换。
具体⼦域有相关接⼝⽂档进⾏详细说明。
4 、8583报⽂组成报⽂头+TPDU+交易码+位图+⼦域值组成。
⾸先我们得到⼀串8583报⽂不知道如何进⾏解析。
⼀般是剔除报⽂头和TPDU开始（长度固定）下⾯举个例⼦如何⼿动拆解8583下⾯是⼀串⼿动解析出来的pos发送的8583报⽂。
0200702406C020E09A3116|622252**********0000000000005800000000432106 ----14域07100003001227|622252**********D210620603703635333433303932343833323531353539393930303030 30303120202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020 31353657A893D87A857D9126000000000000000151|9F2608F4263027C03F06FC9F2701809F101307011703A00000010A0100000000007592C3559F37046B3E7A179F36020048950500000000009A031710219C01009F02060000005800005F2 ------55域特殊域----长度位单倍长计数。
8583报文详解
全面掌握ISO8583报文最开始时，金融系统只有IBM这些大的公司来提供设备，象各种主机与终端等。
在各个计算机设备之间，需要交换数据。
我们知道数据是通过网络来传送的，而在网络上传送的数据都是基于0或1这样的二进制数据，如果没有对数据进行编码，则这些数据没有人能够理解，属于没有用的数据。
起初的X.25、SDLC以及现在流行的TCP/IP网络协议都提供底层的通讯编码协议，它们解决了最底层的通讯问题，能够将一串字符从一个地方传送到另一个地方。
但是，仅仅传送字符串是没有太大意义的，怎样来解析字符串代表什么内容是非常重要的，否则传送一些“0123abcd”的字符串也是无用的乱码。
让我们随着时光回到几十年前的某个时刻，假设我们被推到历史的舞台上，由我们来设计一个通用报文协议，来解决金融系统之间的报文交换，暂且称该协议叫做ISO8583协议。
此时，技术是在不断的前行，当初IBM一支独秀的局面好像已经不妙了，各种大小不一的公司都进入金融行业以求能有所斩获，呈一片百花齐放的局面。
我们怎样来设计一个报文协议，能够将这些如雨后春笋般出现的所有公司都纳入进来，其实也不是一件很简单的事。
我们还是先一步步的来考虑吧。
金融行业其实涉及到的数据内容并不是成千上万，无法统计，恰恰相反，是比较少的。
我们都可以在心底数得过来，象交易类型、帐号、帐户类型、密码、交易金额、交易手续费、日期时间、商户代码、2磁3磁数据、交易序列号等，把所有能够总结出来的都总结起来不过100个左右的数据。
那我们可以首先简单的设计ISO8583，定义128个字段，将所有能够考虑到的类似上面提到的“帐号”等金融数据类型，按照一个顺序排起来，分别对应128个字段中的一个字段。
每个数据类型占固定的长度，这个顺序和长度我们都事先定义好。
这样就简单了，要发送一个报文时，就将128个字段按照顺序接起来，然后将接起来的整串数据包发送出去。
任何金融软件收到ISO8583包后，直接按照我们定义的规范解包即可，因为整个报文的128个字段从哪一位到哪一位代表什么，大家都知道，只要知道你的数据包是ISO8583包即可，我们都已经定义好了。
ISO8583各域详解
ISO8583各域详解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各域详解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各域详解--整理版知识讲解
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报⽂解析过程主密钥：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各域详解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金融报文详细分析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、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
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'。
选用条件：如使用65到128域，需设位图域为'1'3、Bit02主帐号(Primary Account Number )位图位置：02格式：变长,LLVAR类型：N..22描述：唯一的确认一个用户交易的基本帐号。
由于银行电子服务系统涉及多个应用系统，而帐号长度最多为22位，故将原标准的19长度改为22位。
4、Bit03 处理代码（Processing Code )位图位置：03格式：定长类型：N6描述：用于描述交易对客户帐户造成何种影响的代码。
处理代码和信息码一起可唯一定义一种交易的类型。
处理代码由以下三部分组成：位置描述1－2交易动作码3－4付出帐户类型，用于借记类，如查询、代收费、转场交易。
5－6收入帐户类型，用于代收费、转帐等。
其中：ff : 付出帐户tt：收入帐户* 视主机而定5、Bit04 交易金额（Amount, Transaction)位图位置：04格式：定长类型：N12描述：帐户人要求交易的交易金额，不含任何处理和交易费用。
金额的表示和货币代码有关，应能表示相应货币的最小单位。
参ISO4217有关货币代码定义。
如“000000000100”用于表示美元，表示1.00元；如用于表示意大利货币，则表示100里拉。
对于查询等交易，应设交易金额为“000000000000”。
6、Bit06交易日期和时间Transmission Date and Time位图位置：07格式：定长，MMDDhhmmss类型：N10描述：本地交易日期和时间7、Bit11系统跟踪号（Systems Trace Audit Number)位图位置：11格式：定长类型：N6描述：终端交易的跟踪号码。
交易发起终端填写，和“交易日期、时间”、信息类型等合在一起可唯一定义某一个终端的唯一一笔交易。
即是说，在同一天，对一终端，同一类交易的系统跟踪号应保证不同。
系统跟踪号在交易过程中不能修改。
使用此域来匹配请求和通知类交易的返回。
应用系统使用此域来检查收到的授权、金融、自动冲正、结算、管理和网管等类交易的应答包是否是其请求包的应答。
系统跟踪号不用于匹配自动冲正交易，也不用于在预授权消费时匹配前面的预授权交易。
参90域。
对于银行电子服务系统，其系统跟踪号是交易流水号。
8、Bit12本地交易时间（Time ,Local Transaction）位图位置：12格式：定长，hhmmss类型：N6描述：交易在终端上发生的时间。
本地交易时间在交易处理过程中不能改变。
在自动冲正，存贮转发时，本地交易时间不能改变。
9、Bit13本地交易日期(Date ,Local Transaction)位图位置：13格式：定长,MMDD类型：N4描述：交易在终端上发生的时间。
本地交易时间不能改变，在自动冲正、存储转发交易时，本地交易时间也不能改变。
10、Bit14有效期(Date ,Expiration)位图位置：14格式：定长,YYMM类型：N4描述：卡的有效期，年年月月由于卡类写磁格式不同，收单行可能提不出卡的有效期，授权机构从卡的二磁道中提取卡的有效期。
如卡，无二磁道，收单行应要求手工录入卡的有效期。
选用条件：100、200、400等交易如没有2、3磁道时，一定要有此域。
11、Bit15结算日期(Date ,Settlement)位图位置：15格式：定长，MMDD类型：N4描述：银行电子服务系统和主机结算的时间，格式月月日日。
结帐日期前发生的交易参加当天结算。
在结算时，结帐日期也用于计算处理、交易费用。
12、Bit17获取日期(Date ,Capture)位图位置：17格式：定长，MMDD类型：N4描述：从主机获取交易的记帐日期。
通常用于主机和商户清算。
13、Bit18商户类型（Merchant's Type)位图位置：18格式：定长类型：N4描述：定义商户产品和服务类型的代码商户类型用于金融、授权交易，用于指定服务点的类型。
它主要有以下用途：决定预授权交易得到确认的最长时间；控制合法限额；为交易授权处理，控制网络操作规则；欺诈检测；用于商户分类报表；交易费用处理。
根据ISO8583标准，应使用相应的国家标准。
商户类型代码表如下：商户类型代码行业类型说明4215邮递服务4511民航4722旅游4782过桥费4789其他运输服务4614电信服务5542加油站5812餐馆5999购物6010金融机构－人工现金支付6011金融机构－自动现金支付6012金融机构－各类服务7011酒店、旅馆7299各类个人服务：洗衣、美容、7399各类商业服务：停车场、租车、广告、其他服务7699各类维修服务：维修、洗车、拖车7996娱乐：电影、剧院、体育、游戏8099医疗服务8111法律服务8999各类专业服务：会计、教育、装修、工程选用条件：服务点终端发起的交易一定要有此域。
14、Bit22服务点输入方式(Point-of-Service Entry Mode) 位图位置：22格式：定长类型：N3描述：在服务终端上定义PIN和PAN的输入方式。
服务点输入方式包含以下两个方面组合而成：位置描述1－2在服务终端上PAN有效期输入方式3－3在服务终端上PIN的输入方式PAN的输入方式编码如下：PAN输入方式描述00不知01手工02读磁卡03条码扫描仪（BAR）04光学符号阅读器（OCR）05集成电路卡（IC卡）PIN的输入方式编码如下：PIN输入方式描述0不知1终端能接收PIN2终端不能接收PIN选用条件：服务点终端发起的交易一定要有此域。
15、Bit25服务点条件代码(Point-of-Service Condition Code) 位图位置：25格式：定长类型：N2描述：定义交易发生的服务点类型用法说明：下面是CYBERBANK支持的服务点条件代码。
服务点条件代码服务点终端类型2自动柜员机（ATM）10银行终端（10）14POS20电话银行16、Bit32收单机构标识码(Acquirer institution Identification) 位图位置：32格式：LLVAR类型：N..11描述：在金融交易中此域表示交易发生的银行机构的标识码应答数据包必须和请求数据包此域相同。
17、Bit33向前机构标识码(Forwarding Institution Identification Code) 位图位置：33格式：LLVAR类型：N..11描述：在金融交易中此域表示帐户所在的银行机构的标识码在网管交易800/810中，本域含有交易发起机构的代码。
应答数据包必须和请求数据包此域相同。
18、Bit35二磁道数据(Track 2 Data)位图位置：35格式：LLVAR类型：Z..37描述：写在卡二磁道的数据。
数据组成遵循ISO7811－1985标准，数据中包含域分隔符，但不包含卡启始、结束符、LRC等。
收卡行应检测卡的二磁道是否符合国际标准。
为支持国际交换收单行应将二磁道中的分隔符换为“＝”。
除此外不能对二磁道数据进行任何修改，如修改PAN的校验字、有效期、服务码等。
19、Bit36三磁道数据(Track 3 Data)位图位置：36格式：LLLVAR类型：Z (104)描述：写在卡三磁道的数据。
数据应组成遵循ISO4909标准，数据中包含域分隔符，但不包含卡启始、结束符、LRC等。
注意：长度说明为3位数字长。
20、Bit37检索索引号(Retrieval Reference Number)位图位置：37格式：定长类型：AN12描述：检索索引号用来在任何时间标识一个金融、授权、自动冲正交易。
检索索引号不要求打印在持卡人的帐单上。
它的主要目的是在收单行和授权行之间定义一个数据项用于跟踪和检索交易。
授权机构可以将检索索引号打印在客户的对帐单上。
检索索引号由收单行分配。
选用条件：可包含在收单机构的交易请求中。
如在交易请求中有，则应答数据中一定应原样返回。
21、Bit38授权码(Authorization Identification)位图位置：38格式：定长类型：AN6描述：交易授权机构返回的返回代码。
授权码用于在服务点终端上信用卡授权；授权机构按网络操作规定，可选使用本域。
22、Bit39返回码(Response Code)位图位置：39格式：定长类型：AN2描述：对一交易定义其处理结果的编码。
返回码用于说明授权机构对金融（授权）交易的处理状态；也用来指明自动冲正交易的冲正原因；还用来指出目标主机已接收到文件修改、结算、管理、网管等交易请求。
返回码应尽可能准确，应尽可能描述清楚所遇到的问题和状态。
网络交换主机、收单行主机有可能会按不同的返回码收取不同的交易处理费用，并执行不同的处理过程。