java 8583报文解析_8583报文解析实例

以下是主机从网控器收到的消费数据包(用二位十六进制数表示一个字节):

0201 06 60 00 07 08 08 |02 00 30 20 05 00 20 c0

02 0100 40 00 00 00 00  00 99 80 00 00 01 00 21

00 0337 62 14 02 10 00  07 41 50 78 d1 56 07 12

20 10 00 00 00 0031 32  33 34 35 36 37 38 30 34

33 20 20 20 20 20 20 20  20 20 20 20 20c5 8e b2

00 18 03 1e 9a00 06 30  30 30 30 30 31 00 06 30

30 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

消费信息码为0200

30 20 05 00 20 c0 02 01是数据包的位图,8个字节,64位,3的二进制0011

第一位为0,所以没有扩展位图,二进制展开后如下域

有信息:   3 4 11 22 24 35 41 42 52 60 61 62

03是数据结束  ??

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”

最近在做中国银行的一个快捷支付渠道,使用的是 ISO8583 协议,一开始用的是JPOS框架,但是感觉框架比较臃肿,而且文档也比较少。在等待银行专线的过程中,自己闭门造车做了一个简单的8583报文解析框架 —— Simple8583,将程序重写了一遍,渠道中的代码量少了不少,这几天中行的接口在测试环境终于调试完成了。抽空分享一下这段时间自己学到的知识。 数据类型与编码格式: 根据接触到的数据类型将数据分为如下几种类型:          CHAR(asc编码,直接使用字符串的getBytes(ENCODING)方法获取字节数)   BINARY(二进制编码,在打包时将8位01值装为一个字节),             NUMERIC(BCD编码,即8421码),                LLVAR(变长,采用ASC编码,每个LLVAR类型的前会有1字节的字节长度,表示长度的字节用BCD编码表示)                LLLVAR(变长,与LLVAR类似,不同之处在于每个LLLVAR前会有2字节的字节长度,长度同样以BCD编码表示)             LLVAR_NUMERIC(变长,采用BCD编码,前有1字节的长度,长度为值的长度,而非字节长,如值为123456,编码后长度为3字节,但是表示长的字节值为6)       如果用到其它数据类型可以在IsoType中进行添加,并在IsoField中添加处理操作 BitMap:        BitMap是ISO8583报文的精髓所在,ISO8583报文支持64和128两种,但是并非每次请求都会将所有都请求过去,BItMap就起到了标识哪些是有效的请求,接收方也会根据BitMap中约定的值对进行解析。   那么BitMap又是如何工作的呢?          首先,BItMap分为8字节和16字节两种情况,分别表示支持64和128,其第一位值为1,表示BitMap为16字节,否则为8字节。       其次,BitMap中的每一位对应数据的第几,有效会置为1,比如01001000表示第二和第5为有效位。 在Simple8583中具体的实现是通过BitMap类实现的,具体可参考源码。 mti:            mti即 message type identifier消息类型标识,为4位bcd编码的数字标识符,用于描述信息的类型。 同一个mti可以用于标识多个不同的交易,比如一般常用的0200可以用来表示消费交易,消费撤销,分期付款消费和分期付款撤销,但是对于同一个mti标识的数据类型定义是类似的。           具体的实现,我将Simple8583的xml文件设置为了两部分,一部分为公用的报文头,如msgLength,tpdu,bitmap等,另外一部分分按照mti的不同分为多个package体。 粗略的实现流程:          1)装请求的Map数据(只装需要的数据,key值为对应的数据或包头的值)          2)请求数据进入SimpleClient代理,SimpleClient根据传入的值解析xml文件(jaxb实现,做了缓存)          3)根据传入值的mti寻找对应的IsoPackage类,对找到的IsoPackage类进行clone(避免污染),对clone值中的进行值处理和格式化         4)生成BitMap,计算Mac值(如有)          5)使用ByteArrayOutputStream将装成的IsoPackage值进行拼装成为一个大的byte数,在byte前拼装两个字节的长度          6)通过Socket将数据发送并接受响应(读取前两个字节长度,根据长度获取其剩余报文),根据IsoPackage解析报文解析得到BitMap后根据BitMap对数据进行解析,并将值都放入到对应的field中          7)将数据都放在Map中返回,并进行MAC校验(如有) 标签:Simple8583
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值