8583报文的使用和解析

ISO8583报文(简称8583包)又称8583报文是一个国际标准的包格式,最多由128个字段域组成,每个域都有统一的规定,并有定长与变长之分。

8583包前面一段为位图,用来确定包的字段域组成情况。

其中位图是8583包的灵魂,它是打包解包确定字段域的关键,而了解每个字段域的属性则是填写数据的基础。在POS机的开发上时经常要用到,例如回头客会员管理系统在POS机上的应用就是采用8583报文。

“消费”类型报文的测试和组8583报文的过程,说明一下,这里是针对我们日常使用POS机系统来说的,这里主要是模拟的POS终端发向POSP系统的8583报文。其基本业务流程图如下所示

基础知识:

1byte = 8bit

1byte = 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 7020048020c08811

600016000060220000000002007020048020c08811165477666265921222000000000000014959555556022000375477666265921222d25085060000012600000033333333333333333232323232323232323232323232323135361000000000000000000822000001001500000100100000103133394343433842

青色背景:报文长度 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个字节的主账号。

(7)     3域

000000 交易处理码

(8)     4域

000000014959 (149.59CNY 49域可以看出来)

(9)     11域

555556 (系统跟踪号 定长3个字节)

(10) 22域

0220 (服务点输入方式码 刷卡无PIN)

(11) 25域

00 (服务点条件码 00正常提交)

(12) 35域

375477666265921222d250850600000126000000

2磁道数据(Track 2 Data)

2个字节的长度值+最大37个字节的第二磁道数据(数字和分隔符)

压缩时用BCD码表示的1个字节的长度值+用左靠BCD码表示的最大19个字节的第二磁道数据

(13) 41域

受卡机终端标识码

3333333333333333  (33333333 BCD码)

(14) 42域

受卡方标识码

323232323232323232323232323232 (222222222222222 BCD码)

(ANS15,15个字节的定长域)

(15) 49域

交易货币代码

313536(AN3)     (156 BCD码)

(16) 53域

安全控制信息

1000000000000000 (16 BCD个字节)

(17) 60域

60.1交易类型码  22:消费类型

60.2批次号         000001

长度:8个字节

000822000001

压缩时用右靠BCD码表示的2个字节的长度值+用左靠BCD码表示的最大7个字节的数据

(18) 64域

报文鉴别码(Message Authentication Code) MAC

B64,8个字节的定长域

3133394343433842

时间: 2024-10-09 15:42:42

8583报文的使用和解析的相关文章

8583报文(转)

1 8583报文 1.1 数据包格式 ISO 8583金融交易信息数据包由信息类型(MSG_TYPE_ID).一个或多个位图(BIT_MAP)和按位图描述的顺序排列的数据元序列(ELEMENTS)等三段组成. 信息类型是一个4位数字的数字型字段,用来描述每一个交易信息的类别和功能,其中前两位数字标明信息类别,如授权信息.金融交易信息.管理信息,等等.在一个金融系统中,信息类型的定义应该是唯一的,无二义性的.网间交易具有不同的信息类型定义时应在交换报文的发送前和接收后完成类型转换处理. 位图由64

转:8583报文手动组包——详细分析每个示范域

8583报文作为一种应用较广的报文,有它独特的格式. 网上有关8583报文的说明很多.但涉及到每个域的详细例子就较少了.这里列出各个域的详细例子,供参考. 8583报文: 报文组成: 报文头[长度(2字节)+TPDU(5字节)+报文版本号(2字节)]+信息类型+位图+数据 TPDU: 6000100000 报文长度:整体报文长度 -报文头中的2字节长度.如8583整体报文长度为100,那么报文长度为98.用两字节的BCD码表示(16进制)为0062.手动组装的8583报文: 0072600010

Jmeter+8583报文压力测试

Jmeter一般被用来测试HTTP协议,我第一次拿来测试socket协议,pos机传输报文为8583,协议属于socket,也是TCP协议的一种,网上有LR怎么测试8583报文,我就研究了一下怎么用Jmeter来测试,以下是我的研究结果,供大家参考 1.先打开\apache-jmeter-3.1\bin\jmeter.propertles文件,修改jmeter.propertles中的"TCP Sampler configuration"内容,见附图,添加"tcp.handl

转载:8583报文简单分析

http://blog.csdn.net/pony_maggie/article/details/6568192 不要以为我这篇文章是告诉你什么是8583,告诉你map的原理,然后分析各个域是什么意思,格式如何, 再有详细一点的甚至告诉你如何写程序等等. 不是, 之所以不写上面这些,基于两点:1 太多的人写这些了, 网上一搜8583,出来的文章都是关于这些的. 2 作用不大, 因为这些规范上都有, 大家一看规范就明白了, 我写了也是无用. 我篇文章适合两类人看:1 对8583报文非常熟悉,属于这

iOS POS之8583报文组装工具

在组装8583报文时会遇到各种转码,比如:ASCII转Hex , data数据转相应的16进制字符串. 在这里我把代码贴出来,当然了,我这份代码也是在各处搜集而来,并不是自己开发的. @interface NSString (Trans) /** *  十六 进制字符串转换为 data *  24211D3498FF62AF  -->  <24211D34 98FF62AF> * *  @param str 要转换的字符串 * *  @return 转换后的数据 */ + (NSData

python input()键盘输入8583报文带有\x单反斜杠自动转义问题解决办法

用input()输入的字符串是8385报文比如:\x30\x30\x30\x30...,但是输入后,代码把8583报文字符串中多加了一个\,类似\\x30. 但是我把input()代码注释掉,把8583报文在变量中写死,就没有这个问题,我想应该是编码问题造成的. input输入和变量固定,难道还有什么不一样吗? 代码如下: 输入的单反斜杠,被系统自动转义双反斜杠\\x,代码中增加了依据判断: 1 if "\\x" in input_a1: 在input()键盘输入时,增加decode(

移动支付平台间接口报文解析技术核心架构实现、及平台交易处理项目全程实录教程

<基于移动支付平台间接口报文解析技术核心架构实现.及平台交易处理项目全程实录>课程讲师:MoMo 课程分类:Java框架适合人群:中级课时数量:52课时用到技术:JavaBean .Spring3.X. SpringMVC. Hibernate3.X.Apache HttpClient 3.x.JUnit4.x.自定义Annotation + java反射技术涉及项目:移动支付平台间接口咨询QQ:1337192913 课程介绍:   本课程抛开理论.以项目为驱动,适用于初次接触报文收发.组装解

移动支付平台间接口报文解析核心架构及平台交易全程实录

移动支付平台间接口报文解析核心架构及平台交易全程实录 (HttpClient+SpringMVC+Spring3+Hibernate3+自定义Annotation) 课程分类:Java框架 适合人群:中级 课时数量:52课时 用到技术:JavaBean .Spring3.X. SpringMVC. Hibernate3.X.Apache HttpClient 3.x.JUnit4.x.自定义Annotation + java反射技术 涉及项目:移动支付平台间接口 咨询qq:1840215592

通用轻量级二进制格式协议解析器

在通信协议中,经常碰到使用私有协议的场景,报文内容是肉眼无法直接看明白的二进制格式.由于协议的私有性质,即使大名鼎鼎的 Wireshark,要解析其内容,也无能为力. 面对这种情况,开发人员通常有两个办法:第一,对照报文内容和协议规范进行人工分析(假设内容没有经过加密.压缩):第二,编程实现协议报文的解析(源于程序员的懒惰 ^_^). 很明显,第二条道路是主流.目前比较常见的实现方式是开发对应的 Wireshark 插件,包括 C.Lua 等插件.当然,插件完成后需要运行 Wireshark 才