ISO8583开发注意事项和心得体会

本文分享了ISO8583开发中的一些注意事项,包括使用Moss测试工具时遇到的问题,如无线接入限制、主密钥配置、通信密钥的存储与校验、MAC校验失败的原因分析,以及Moss覆盖的业务功能。强调了通信安全,如密钥长度匹配、密钥灌入、加密算法和BCD码转换的重要性。
摘要由CSDN通过智能技术生成
前阵时间, 有幸参与公司的社保类项目. 其中, 本人负责的是银联对接的部分接口, 主要参考协议为ISO8583, 而银联就此提供了<多渠道平台接入接口规范>等接口文档供开发参考. 鉴于本人忘性较大, 悟性也较低, 所以整理记录下来以便后续开发维护, 希望能对后来者也提供些许帮助. 
本文全文原创, 可供参考和引用, 仅希望引用者注明出处, 已是不甚感激; 如果能在引用的时候, 再适当添加自己的见解并帮助更多童鞋获取知识, 就是对本人的最大褒奖. 
支持开源,谢绝伸手. 尊重作者就是尊重自己. 

一. 全局概述
1. <多渠道平台接入接口规范>这个标准规定了各种接入端(主要包括直联多渠道平台的终端, 包括这里主要关注的POS机)与中国银联多渠道平台之间进行联机交易时使用的报文接口, 包括联机交易报文的结构/格式以及报文域. 
2. 报文结构说明
报文长度 TPDU头 拨号监控数据 报文头 应用数据
2字节十六进制表示的报文长度(不包括本身) 5字节 33字节 12字节 交易数据(不定长度)
3. 报文长度
0x2B: 整个报文(不包括TPDU/拨号监控数据/报文头)的长度为: 0x2 * 256 + 0xB = 512 + 11 = 523字节.
4. TPDU头
Transport Protocol Data Unit,传输协议数据单元, 包括ID项(一个字节, 用于标识报文类型), Destination Address项(NII, 两个字节, 标识该报文的目的地址, 一般情况下, 用来标识不同银行的前置机), Originator Addreess(两个字节, 标识该报文从哪一个POS接入端口收到的报文). 一般需要根据实际情况来设置, 这个具体可以在跟收单行洽谈并设置前置机的过程中获取.
5. 拨号监控数据
LRI首标志 ANI DNIS LRI尾标志
5个字节, 固定取值为: \x4C\x52\x49\x00\x1C 8个字节(数字) 8个字节(数字) 12个字节, 固定取值为: \x58\x00\x09\x49\x00\x06\x00\x00\x00\x22\x00\x30
拨号监控数据又称拨号监控头, 如果TPDU中指明有拨号监控要求, 需要添加, 拨号监控头的报文格式参见标准. 因为本次开发并未使用, 所以无需填入, 暂不加以总结.
6. 报文头
总长度为12字节, 压缩时用BCD码表示为6个字节长度的数值. 相对固定, 具体的设置可以参考银联接口文档, 不多做解释.
7. 重点难点
7.1 TPDU头
TPDU头是报文中容易被忽视的地方, 银联接入测试环境时, 会详细对TPDU头/拨号监控头和报文头进行校验. 如果匹配不上或解析失败, 会直接将该报文丢弃不做任何处理, 难以获取调试信息.
7.2 BCD码的理解. 
BCD为二进码十进数或二-十进制代码, 用4位二进制数来表示1位十进制数中的0~9这10个数码; 是一种二进制的数字编码形式, 用二进制编码的十进制代码. 这里采用的是8421编码的BCD码.
例如, 一条十进制数据的字符串"1234567890", 十六进制字节为\x31\x32\x33\x34\x35\x36\x37\x38\x39\x30, 压缩BCD码为\x12\x34\x56\x78\x90. 反之, 从BCD到ASCII再到十进制数字, 逆向处理即可.

二. 报文域属性和数据格式
1. 报文整体描述
ISO8583终端报文一共包含64个报文域, 报文域属性/数据格式和压缩前后的数据长度, 在标准中都有说明. 
最近在做中国银行的一个快捷支付渠道,使用的是 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
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值