解析ISO8583报文实例

http://www.cnblogs.com/1971ruru/archive/2012/12/10/2811549.html

本篇文章参考了中国银联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。

现在进入关键的位图分析,现在我们取到了表示位图的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位。

域长度说明

N: 数字,有几位就是几位

字符 含义 
a 字母字符,A至Z,a至z,向左靠,右边多余位填空格 b 数据的二进制表示,后跟数字表示位(bit)的个数 
B 用于表示变长的二进制数,后跟数字表示二进制数据所占字节(Byte)的个数 n 数值,0至9,右靠,首位有效数字前填零。若表示人民币金额,则最右二位为角、分 p 填充字符,如空格 s 特殊符号 
an 字母和数字字符,左靠,右边多余位填空格 as 字母和特殊字符,左靠,右边多余位填空格 cn 压缩数字码,即BCD码 
ns 数字和特殊字符,左靠,右边多余位填空格 ans 字母、数字和特殊字符,左靠,右边多余位填空格 
ansb 字母、数字、特殊字符和二进制数,左靠,右边多余位填空格 MM 月份,01至12 DD 日期,01至31 YY 年份,00至99 hh 时,00至23 mm 分,00至59 ss 秒,00至59 
LL 后面跟随数据元的可变长度值,01至99 LLL 后面跟随数据元的可变长度值,001至999 VAR 可变长度数据元 3 3字符的固定长度 
..17 最大17个字符的可变长度。所有可变长度字段在数据元的前面应另外包含2个或3个位置, 以表示后面到数据元结束时的位置数。 
X 借贷符号,贷记为“C”,借记为“D”,并且总是与一个数字型金额数据元相连,例如, 净对账金额中X+N16含义为前缀“C”或“D”和净对账金额的16位数字。 Z 
ISO 4909和ISO 7813中定义的磁卡第二、三磁道的代码集

下面开始这些域中的数据,

首先分析

3域(N6),3域为交易处理码,压缩成BCD码后占定长3个字节,我们从位图所占的8个字节后开始连续取3个字节,即 00 00 00,解压后即为“000000”,具体代表含义这里就不叙述了。

4域为交易金额,压缩成BCD码后占定长6个字节,同理取6个字节,即00 00 00 00 00 01,也就是金额0.01元,具体转换参考银联规范。

11域为受卡方系统跟踪号(流水号),压缩成BCD码占定长3个字节,同理取3个字节,即00 03 49,即000349。

22域为服务点输入方式码,压缩成BCD码占定长2个字节,同理取2个字节,即02 10,由于22域本身只占3个字节,压缩时左靠,右补0,所以转换为“021”,具体含义不再叙述。

25域为服务点条件码,压缩成BCD码占定长1个字节,同理取1个字节,即00,转换为“00”,“00”代表正常提交。

26域为服务点PIN获取码,压缩成BCD码占定长1个字节,同理取1个字节,即12,转换为“12”,表示服务点设备所允许输入的个人密码明文的最大长度为12。

解下来的35域由于不是定长,所以处理方法不同,先取一个字节,即30,转换为“30”,表示第二磁道的数据占用30个字节,取连续15个字节即62 25 82 21 12 99 63 01 5D 15 11 10 10 00 00,这里不对这串数据进行说明了。

41域为受卡机终端标识码,占8个字节的定长域,取35 36 38 35 32 33 31 34。

42域为受卡方标识码,占15个字节的定长域,取32 33 35 32 31 34 35 32 36 38 35 39 32 33 36。

49域为交易货币代码,占3个字节的定长域,取31 35 36。

52域为个人标识码数据,占8个字节的定长二进制数域,取C6 24 83 4D 36 7E 9E 9E。

53域为安全控制信息,压缩成BCD码占8个字节定长域,取20 00 00 00 00 00 00 00。

60域为自定义域,为不定长域,先取长度(压缩成BCD码占两个字节),即00 13,转换为13即占60域占13个字节,压缩成BCD码占7个字节,取22 00 00 08 00 05 00。

64域为报文鉴别码,占定长8个字节,取最后八个字节36 37 41 32 32 39 39 41。

时间: 2024-11-02 01:54:02

解析ISO8583报文实例的相关文章

(转载)解析ISO8583报文实例

本篇文章参考了中国银联POS终端规范,所以如有不明白的可以去我的资源里面下载. 现在我们有ISO8583报文如下(十六进制表示法): 60 00 03 00 00(前五个字节为TPDU) 60 31 00 31 07 30(报文头占用六个字节) 02 00(应用数据占用2个字节) 30 20 04 C0 20 C0 98 11(8个字节是位图) 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 5

轻松掌握ISO8583报文协议

http://www.itpub.net/thread-419521-1-1.html 我刚进入金融行业时,就知道了IS08583报文协议,我想可能我还没进入这个行业都已经听过了,可知ISO8583的影响力有多大了.最初刚接触它时,确实对其中的一些细节概念不是很清晰,对有些地方比较迷惑.鉴于此,我想很多同行也必然会经历同样得阶段,所以我写下本文,以便大家能够少走一些弯路.同时,我在网上(http://blog.csdn.net/lysheng/archive/2005/03/03/309914.

ISO8583报文协议

最开始时,金融系统只有IBM这些大的公司来提供设备,象各种主机与终端等.在各个计算机设备之间,需要交换数据.我们知道数据是通过网络来传送的,而在网络上传送的数据都是基于0或1这样的二进制数据,如果没有对数据进行编码,则这些数据没有人能够理解,属于没有用的数据.起初的X.25.SDLC以及现在流行的TCP/IP网络协议都提供底层的通讯编码协议,它们解决了最底层的通讯问题,能够将一串字符从一个地方传送到另一个地方.但是,仅仅传送字符串是没有太大意义的,怎样来解析字符串代表什么内容是非常重要的,否则传

ISO8583报文协议-入门

文章转自 https://blog.csdn.net/yuan_hong_wei/article/details/49148721, 感谢原作者! 我刚进入金融行业时,就知道了IS08583报文协议,我想可能我还没进入这个行业都已经听过了,可知ISO8583的影响力有多大了.最初刚接触它时,确实对其中的一些细节概念不是很清晰,对有些地方比较迷惑.鉴于此,我想很多同行也必然会经历同样得阶段,所以我写下本文,以便大家能够少走一些弯路.同时,我在网上(http://blog.csdn.net/lysh

全面掌握ISO8583报文协议

最开始时,金融系统只有IBM 这些大的公司来提供设备,象各种主机与终端等.在各个计算机设备之间,需要交换数据.我们知道数据是通过网络来传送的,而在网络上传送的数据都是基于0或 1这样的二进制数据,如果没有对数据进行编码,则这些数据没有人能够理解,属于没有用的数据.起初的X.25.SDLC以及现在流行的TCP/IP网络协 议都提供底层的通讯编码协议,它们解决了最底层的通讯问题,能够将一串字符从一个地方传送到另一个地方.但是,仅仅传送字符串是没有太大意义的,怎样来解 析字符串代表什么内容是非常重要的

SAX解析XML文件实例代码

import java.io.File; import java.io.IOException; import java.util.ArrayList; import java.util.List; import javax.xml.parsers.ParserConfigurationException; import javax.xml.parsers.SAXParser; import javax.xml.parsers.SAXParserFactory; import org.xml.s

DNS查询报文实例

2.2 DNS查询报文实例 以www.baidu.com为例,用Wireshark俘获分组,结合2.1的理论内容,很容易看明白的,DNS请求报文如下: 图7 DNS请求报文示例 2.3 DNS回答报文实例 DNS回答报文示例 .embody { padding: 10px 10px 10px; margin: 0 -20px; border-bottom: solid 1px #ededed } .embody_b { margin: 0; padding: 10px 0 } .embody .

1:银联ISO8583报文解析过程

主密钥: aabbccddeeff11223344556677889900 1.从签到报文中获取工作密钥,包括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 3

Document -->XML报文传输与解析,简单实例

import java.io.StringReader; import org.dom4j.Document; import org.dom4j.DocumentException; import org.dom4j.DocumentHelper; import org.dom4j.Element; import org.dom4j.io.SAXReader; public class TestA { public static String test(){ Document document