8583报文详细分析

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域, 指示哪些域存在, 容易计算出, 下面几个域存在: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 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>

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.


原文地址:http://blog.csdn.net/pony_maggie/article/details/6568192

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Android 8583解析是指在Android开发中,对8583进行解析的过程。8583是一种用于金融交易的通信协议,常用于ATM机、POS机等设备的通信。在Android开发中,我们可以使用一些开源的库或者自己编写代码来实现对8583的解析。 在csdn中,我们可以找到一些相关的博客或者章,介绍如何在Android中解析8583。这些章通常会提供一些示例代码和详细的解释,帮助开发人员理解和掌握8583解析的过程。 一般来说,8583解析的过程包括以下几个步骤: 1. 接收:首先,我们需要获取到发送给Android设备的8583。这可以通过Socket连接、HTTP请求或者其他方式实现。 2. 解析:接下来,我们需要解析的各个字段。8583通常由多个域组成,每个域都有特定的含义和格式。我们可以使用Java的字符串处理方法,根据各个域的长度和数据类型,将分解成各个字段。 3. 字段解析:每个字段都有自己的说明和格式要求。在解析过程中,我们需要根据字段的定义,把中的数据按照规定的格式进行处理和转换。例如,日期字段可能需要转换成标准的日期格式,金额字段可能需要进行数值转换。 4. 结果返回:完成解析后,我们可以将解析得到的各个字段的值返回给调用方,供后续的业务逻辑处理。通常情况下,我们会将解析得到的数据封装成一个对象,方便程序的使用。 总结来说,Android 8583解析是一种将金融交易的通信按照规定的格式进行解析的过程。通过在csdn上查找相关章和学习相关的库,我们可以掌握这一技术,为开发金融应用提供支持。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值