银联8583理解
交易时卡片与终端产生的数据按照一定规律组成一个数据包，这个规律即是8583规范。该数据包被终端用来与银行系统通信，银行与银行之间的通信。
目前国内金融用的是银联8583规范，与ISO8583稍微有些出入。它规定了报文结构，格式，内容以及数据元的位置和数据元的值。
一些概念：
1.报文：用于机构之间交换信息的数据元集合；
2.报文结构：按如下顺序排列
报文类型标识符| 一个或两个位元表| 数据元序列
3.报文类型标识符：四位数字型数据字段，1位2位表示报文类别，当它们都在1到8之间时，3/4位表示报文传输方式和功能
4.位元表：分为基本位元表和扩展位元表
基本位元表的01位取值1则表示扩展位元表存在，为0则表示基本位元表；
位元表结构如下：
基本位元表：
01 位元位置64
数据元
扩展位元表：
01 64 128
数据元
举例：
位元位置也叫位图
20 00 38 00 00 00 00 34
把它解开，排列一下
20 = 1010 0000
00 = 0000 0000
38 = 0011 1000
依次类推，得到一串数字
0010 0000 0000 0000 0011 1000 0000 0000 0000 0000 0000 0000 0000 0000 0011 0100然后从左到右数一下里头含有1的是那几位，上面的例子我们得到
3 19 20 21 59 60 62 ,这几位含有1。也就是说接下来的报文包含有这几个域。
数据元的数据存放则是按顺序依次存放，查询时按照位图的位置将数据元的数据依次对应相应的域。
数据元格式为：长度+数据（该长度不包含长度字节，仅仅是数据的长度）
V AR：表示可变字段的长度
LL：表示长度小于100
LLL：表示长度小于1000
做一个简单的例子比如消费交易，需要上送交易类型，卡号等等，定义如下
卡号第2域LLV AR BCD 5309987876545342
交易类型第3域长度6 BCD 900000
金额第4域长度12 BCD 100分
时间第7域长度8 BCD 20030802
2磁道信息第35域LLV AR ASCII 123456
3磁道信息第36域LLLV AR BCD 123456001
商户号第41域LLVAR ASCII 98765432
现在开始打包，首先按照长度和类型把上面的数据处理一下
卡号165309987876545342
交易类型900000
金额000000000100
时间20030802
2磁道06313233343536
3磁道0009123456001
商户号083938373635343332
接下来按照域信息生成位图
因为有第2域，所以第二个位置是1，由第三域，所以第三个位置
是1，。。。
依此类推得到一串数字
0111 0010 0000 0000 0000 0000 0000 0000 0011 0000 1000 0000 0000 0000 0000 0000
转换过来，就是
72 00 00 00 30 80 00 00 这个就是BITMAP了
然后把上面的数据按照BITMAP+每个域的内容，依次排列
就得到这个包的内容了7200000030800000165309987876545342900000000000000100 20030802063132333435360009123456001083938373635343332
前头再加上TPDU和MSGID就是最后的数据包
104规约报文详解(解剖麻雀_最快速掌握_强力推荐)
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- IEC-60870-5-104：应用模型是：物理层，链路层，网络层，传输层，应用层 物理层保证数据的正确送达，保证如何避免冲突。（物理层利用如 RS232上利用全双工） 链路层负责具体对那个slave的通讯，对于成功与否，是否重传由链路层控制（RS485 2线利用禁止链路层确认） 应用层负责具体的一些应用，如问全数据还是单点数据还是类数据等（网络利用CSMA/CD等保证避免冲突的发生） --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 基本定义：端口号2404，站端为Server 控端为Client，平衡式传输，2Byte站地址，2Byte传送原因，3Byte信息地址。 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 注：APDU 应用规约数据单元（整个数据）= APCI 应用规约控制信息（固定6个字节）+ ASDU 应用服务数据单元（长度可变） --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- APDU长度（系统-特定参数，指定每个系统APDU的最大长度）APDU的最大长度域为253（缺省）。视具体系统最大长度可以压缩。 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 【1个例子】 104报文分析 BUF序0 1 2 3 4 5 6 7 8 9 .10 11 12 13 14 15 16 17 18 19 20 21 22 M->R：68 1510 0002 001E 01 03 0001 0079 00 00 01 10 01 24 13 D2 0A 02分析的结果是I （主动上报SOE，主动上报是因为104是平衡式规约）报文头固定为0x68，即十进制104 长度15字节（不是6帧的，都是I帧） 发送序号=8【控制字节的解析10 00 02 00 ，发送序号：0010H/2=16/2=8】 接收序号=1 【控制字节的解析10 00 02 00 ，接收序号：0002H/2=2/2 =1】 0x1E=30 即M_SP_TB_1 带长时标的单点信息 01 -> SQ:0 信号个数:1 03 00 -> 传送原因:[ T=0 P/N=0 原因=3 | 突发] 01 00 -> 公共地址:1 79 00 00 -> 0x79=121 信息体地址: 121 01 -> 状态: 1 IV:0 NT:0 SB:0 BL:0 10 01 24 13 D2 0A 02 ->低位10 高位01，即0x0110=1*16*16+16=272 时标: 2002/10/18 19:36:00.272 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 每个字节都为unsigned char类型，如果是2个字节表示1个short型，则都是低位在前，高位在后。 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 【字节0】0x68即十进制数104，68做为BUF第0个字节，下面的说明依次向后排 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 【字节1】15即从字节2到最后的所有字节数（长度） --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 【字节2、3、4、5】这4个字节是4个控制域，对应不同类型的格式（I帧、U帧、S帧），意义和格式都不相同
报文模拟测试(含8583)工具介绍
回归测试工具用户手册 目录 目录 (1) 工具描述 (2) 功能特点 (3) 适用范围 (3) 文件目录结构说明 (3) case目录 (3) file目录 (4) ini目录 (4) log目录 (4) report目录 (4) 主界面 (4) 使用说明 (4) 密钥配置界面 (4) 通讯参数配置界面 (5) 修改案例界面 (5) 文本模式修改界面 (6) 设置案例集界面 (6) 报文属性设置 (6) 常量设置界面 (6) 发送案例 (6) 发送次数 (6) 清空 (6) 终止发送 (6) 清空日志 (7) 文件格式说明 (7)
config.ini 例子 (7) Case.ini 例子 (8) iso.ini 例子 (8) 交易文件的配置 (9) 正交易配置 (9) 反交易配置 (10) 可选配置 (10) 支持函数列表 (11) String (11) time (11) Req (11) Rev (11) Def (12) Tlv (12) Tlvasc (12) 更新计划 (12) 修改记录 (13) 工具描述 系统用Visual C++软件开发而成，数据存储采用文本文件进行保存，便于开发测试人员修改、共享测试案例。 本软件可以模拟不同类型的交易报文，可以对交易测试案例进行统一管理，并可以进行简单时间统计和成功率统计。 使用本软件可以减轻传统测试过程中的修改-编译-测试-的循环等待时间，在测试过程中可以根据需要随时更改报文内容。 本软件支持任意格式的报文，可以模拟不同格式的报文，如定长，变长，XML,8583等报文。每个域的内容可以是常量，也可以支持约定的表达式。 本软件可以根据需要设置对应答相关域进行合法性检查，可以校验应答报文和请求报文的匹配关系，可以校验域的长度，校验域的内容等。 本软件支持MAC的生成、校验以及PIN加密处理，同时可以根据需要调整是否需要进行MAC和PIN加密。 本软件运行程序无需安装，只需将相关程序和测试案例文件拷贝到相应的文件夹下即可执行。 本系统目前局限性如下： 目前仅对8583格式报文进行了解包处理，显示应答报文的各个域和内容；而对于其他非8583的报文仅仅列出发送报文和接收报文的实际内容。
报文结构
报文结构
1.以太网的报文结构 DA SA TYPE DATA CRC 6 6 2 46-1500 4(单位： Bytes) DA：目的Mac地址 SA：源Mac地址 Type：指示Mac层的上层协议类型 DATA：数据字段 CRC：校验字段 Vlan的帧格式 DA SA Tag TYPE DATE CRC 6 6 4 2 46-150 0 4（单位：Bytes） Tag：包括TPID（Tag Protocol Identifier--是IEEE定义的新的类型，表明这是一个加了802.1Q标签的帧）和TCI（含帧的控制信息，包括Priority-优先级；CFI-值为0说明是规范格式，1为非规范格式；Vlan ID） 2.HUB解决的问题 共享带宽的设备，可以实现多台电脑同时使用一条数据总线来上网或组成局域网 3.交换机接的的问题
HUB产生的广播问题 4.Vlan解决的问题 Vlan是为解决以太网的广播问题和安全性而提出的，它在以太网帧的基础上增加了Vlan头，用Vlan ID把用户划分为更小的工作组，限制不同工作组间的用户二层互访，每个工作组就是一个虚拟的局域网。虚拟局域网的好处是可以限制广播范围，并能够形成虚拟工作组，攻台管理网络 5.路由器和二层交换机的区别 路由工作在第三层，交换机工作在第二层 路由有包交换过滤功能。所有端口分别属于不同的广播和冲突域 交换机没有包交换和过滤功能。所有端口共享一个广播域，每个端口是一个冲突域 6.OSPF的几种报文 HELLO：周期性发送，用来发现和维持OSPF 的邻居关系 DD：描述了本地LSDB的摘要信息，用于两台路由器进行数据同步 LSR：向对方请求所需的LSA，只有在双方成功交换DD报文后才会向对方发出LSR报文
ISO8583金融报文详细分析
ISO8583金融报文详细分析 2011-08-26 14:23 转载至网络，自己编辑了一下。向原作者表示感谢，写的很详细。 不要以为我这篇文章是告诉你什么是8583，告诉你map的原理,然后分析各个域是什么意思，格式如何, 再有详细一点的甚至告诉你如何写程序等等. 不是, 之所以不写上面这些，基于两点: 1 太多的人写这些了, 网上一搜8583,出来的文章都是关于这些的. 2 作用不大, 因为这些规范上都有, 大家一看规范就明白了, 我写了也是无用. 我篇文章适合两类人看: 1 对8583报文非常熟悉，属于这一领域的资深工程师, 为什么这一类人要看呢, 因为他们看了，可以给我提一些意见和建议. 2 看了很多遍规范，但是还有一些细节不是很明白. 好，我要开始了. 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域, 指示哪些域存在, 我们用windows自带的计算器计算出它对应的二进制是
[原创]java创建ISO8583报文字符流
[原创]java创建ISO8583报文字符流 /* * 创建日期2005-8-26 * * TODO 要更改此生成的文件的模板，请转至 * 窗口－首选项－Java －代码样式－代码模板*/ package com.trade;import java.util.HashMap;/** * @author GYGT * * TODO 要更改此生成的类型注释的模板，请转至 * 窗口－首选项－Java －代码样式－代码模板*/ public class ProduceTradeMessage { //域号字长属性 private HashMap fieldPro; //域号最大字长 private HashMap fieldLen;
//输入域值 private HashMap inputField = new HashMap(); private HashMap hexmap = new HashMap(); //报文字长 private String TradeLength; //报文类型长度 private String TradeType; //64位域号 private String Field64; //128位域号 private String Field128; //域值 private String FieldContent; //报文字符流 private String TradeMessage; public ProduceTradeMessage(){ inputField();
hexmap(); } /** * 对参数进行设置 ------------------------------------------------------------------------------------------------ * */ private void inputField(){ inputField.put("2","22"); // 两位变长，最大长度22位 inputField.put("3","aaaaaa"); // 6位定长 inputField.put("4","aaaaaaaaaaaa"); // 12位定长 inputField.put("7","aaaaaaaaaa"); // 10位定长
ISO8583各域详解--整理版
ISO8583各域详解 8583协议的报文域编码格式分为： BINARY、CHAR、NUMERIC、LLVAR、LLLVAR、LLLVAR_NUMERIC这几种格式。 BINARY采用二进制编码(8位二进制数编码为一个字节)。 CHAR、LLVAR、LLLVAR为ASC（即正常的getBytes(Encoding)）编码。NUMERIC、LLLVAR_NUMERIC采用BCD(半个字节表示一个10进制数，每两位编码为一个字节)编码。 CHAR、BINARY、NUMERIC都需要指定长度。 CHAR类型左对齐、右补空格。 NUMERIC右对齐、左补零。 LLVAR域前加一个字节的字节长度（采用bcd编码）。 LLLVAR域前加两个字节的字节长度（采用bcd编码）。 LLLVAR_NUMERIC域前加两个字节的长度(注：非字节长度，而是数字的长度，即字节长度的两倍)（采用bcd编码）。代码中会在IsoField setValue时进行格式化，组装报文时计算LLVAR等域长。 ISO8583域说明 ATM、前置机间通讯采用ISO8583 包格式。以下是位元、报文等的定义。
1、信息类型（message type)定义 位图位置：－ 格式：定长 类型：N4 描述： 数据包的第一部分，定义数据包的类型。 数据类型由数据包的发起者设定，应遵循以下要求： 数据包开始部分必须是信息类型； 对不支持的信息类型能给出拒绝应答。 0100授权交易 0110授权交易答复 0200金融交易 0210金融交易答复 0240查询交易 0250查询交易答复 0400冲正交易 0410冲正交易答复 0800管理交易 0810管理交易答复 2、位图(Bit Map) - 基本位图和扩展位图 位图位置：01 格式：定长 类型：B16 描述： 如将位图的第一位设为'1'，表示使用扩展位图，否则表示只使用基本位图。 如使用某数据域，应在位图中将相应的位设位'1'，如使用41域，需将位图的41位设为'1'。选用条件：如使用65到128域，需设位图域为'1'
报文解析学习——8583设计原理
8583报文设计原理 ISO8583报文（简称8583包）又称8583报文是一个国际标准的包格式，最多由128个字段域组成，每个域都有统一的规定，并有定长与变长之分。 8583包前面一段为位图，用来确定包的字段域组成情况。其中位图是8583包的灵魂，它是打包、解包确定字段域的关键。而了解每一个字段域的属性则是填写数据的基础。 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 （蓝线标注） 应用数据占用两个字节，即02 00 也就是"0200"。应用数据部分指定消息类型（例如余额查询、消费等交易等消费类型）（黑线标注） 应用数据之后的若干个字节表示位图。 首先取第十四个字节，即0x30，转化为二进制00110000，在该字节的第一位为0（从左往右）表示当前报文中只需要包括64个域（用8个字节表示），也就是从当前字节开始连续8个字节为位图（包括当前字节），如果要包括128个域（用16个字节表示），该位为1。 《1》位图分析：(bit map 域指定了哪些域存在。域是从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位。 《2》具体对域进行分析 3域。查看银联规范可知，3域为交易处理码，压缩成BCD码后占定长3个字节（参考银联规范可知）。从位图所占的8个字节以后（第22个字节）开始连续取3个字节，即00 00 00 解压后即为“000000”，具体代表的含义可以参考中国银联规范的第八节消息域说明。 4域为交易金额，压缩成BCD码后占定长6个字节，同理（从上文3域的三个字节以后开始）取六个字节，即00 00 00 00 00 01也就是金额为0.01元（如果币种为人民币，单位是人民币的分） 11域为受卡方系统跟踪号（流水号），压缩成BCD码占定长3个字节，同理取3个字节，即00 03 49，即000349。
8583位图
8583位图 8583是这样的，我举一个简单的例子。以64个域的报文来举例，域是什么我也说不清楚，你可以把它想象为医院放药的抽屉，一个抽屉预先定义好要放什么东西，比如伟哥，或者感冒冲剂，一般情况下定义放伟哥的抽屉最好永远放伟哥，不要放别的东西，当然你也可以放板蓝根，但这样的话容易出错，也不太规范。 数量是这么规定的，有三种情况： 首先是定量，也就是说定义好这个抽屉放30瓶伟哥，就放30瓶一瓶也不能多，一瓶也不能少。 其次是LLVAR，也就是说用1位字节定义数量，比如0x12表示里头放12瓶，当然你也可以理解为16+2=18瓶。但要是0x12表示12，那0x13就等于13，不要0x12=12 ，0x13=19 最后是LLLVAR,是2位字节表示数量，比如0x01,0x04 = 104 域也就是这样的，一共有64个域，每个域预先定义了内容和长度 有一个叫做BITMAP的，也就是位图，定义了一个数据包里包含 了几个域。举个例子 20 00 38 00 00 00 00 34 你把它解开，排列一下 20 = 0010 0000 00 = 0000 0000 38 = 0011 1000 依次类推，得到一串数字 0010 0000 0000 0000 0011 1000 0000 0000 0000 0000 0000 0000 0000 0000 0011 0100 然后从左到右数一下里头含有1的是那几位，上面的例子我们得到 3 19 20 21 59 60 62 ,这几位含有1。也就是说接下来的报文包含有这几个域。 好了说了那么多，我们来做一个简单的例子比如消费交易，需要上送交易类型，卡号等等，定义如下 卡号第2域LLVAR BCD 5309987876545342 交易类型第3域长度6 BCD 900000 金额第4域长度12 BCD 100分 时间第7域长度8 BCD 20030802 2磁道信息第35域LLVAR ASCII 123456 3磁道信息第36域LLLVAR BCD 123456001 商户号第41域LLVAR ASCII 98765432 好了我们现在开始打包，首先按照长度和类型把上面的数据处理一下 卡号165309987876545342 交易类型900000 金额000000000100 时间20030802 2磁道06313233343536 3磁道0009123456001 商户号083938373635343332 接下来我们按照域信息生成位图 因为有第2域，所以第二个位置是1，由第三域，所以第三个位置 是1，。。。 依此类推得到一串数字 0111 0010 0000 0000 0000 0000 0000 0000 0011 0000 1000 0000 0000 0000 0000 0000
全面掌握ISO8583报文协议
全面掌握ISO8583报文协议 我刚进入金融行业时，就知道了IS08583报文协议，我想可能我还没进入这个行业都已经听过了，可知ISO8583的影响力有多大了。最初刚接触它时，确实对其中的一些细节概念不是很清晰，对有些地方比较迷惑。鉴于此，我想很多同行也必然会经历同样得阶段，所以我写下本文，以便大家能够少走一些弯路。同时，我在网上写下我要写“全面掌握ISO8583报文”和“符合CEN/XFS（即WOSA/XFS）规范的SP编写”两篇文章时，很多人都询问我什么时候能够写出来，可知许多人是需要了解这方面的知识的，即使我时间不是很多，也得尽量将这两篇文章写出来，给需要的人提供一些参考。 如果单纯的讲IS08583那些字段的定义，我觉得没有什么意思，标准中已经对每个字段解释的非常详细了，如果你觉得理解英文版的ISO8583规范有些困难，网上也有同行为我们翻译好的中文版ISO8583规范，所以我的目的是达到阅读本文后能够对ISO8583知其然，亦知其所以然，使以前基本没有接触它的人也能够达到掌握ISO8583报文规范。 好了，我们该转入正题了。 最开始时，金融系统只有IBM这些大的公司来提供设备，象各种主机与终端等。在各个计算机设备之间，需要交换数据。我们知道数据是通过网络来传送的，而在网络上传送的数据都是基于0或1这样的二进制数据，如果没有对数据进行编码，则这些数据没有人能够理解，属于没有用的数据。起初的X.25、SDLC以及现在流行的TCP/IP网络协议都提供底层的通讯编码协议，它们解决了最底层的通讯问题，能够将一串字符从一个地方传送到另一个地方。但是，仅仅传送字符串是没有太大意义的，怎样来解析字符串代表什么内容是非常重要的，否则传送一些“0123abcd”的字符串也是无用的乱码。 让我们随着时光回到几十年前的某个时刻，假设我们被推到历史的舞台上，由我们来设计一个通用报文协议，来解决金融系统之间的报文交换，暂且称该协议叫做ISO8583协议。此时，技术是在不断的前行，当初IBM一支独秀的局面好像已经不妙了，各种大小不一的公司都进入金融行业以求能有所斩获，呈一片百花齐放的局面。我们怎样来设计一个报文协议，能够将这些如雨后春笋般出现的所有公司都纳入进来，其实也不是一件很简单的事。 我们还是先一步步的来考虑吧。金融行业其实涉及到的数据内容并不是成千上万，无法统计，恰恰相反，是比较少的。我们都可以在心底数得过来，象交易类型、帐号、帐户类型、密码、交易金额、交易手续费、日期时间、商户代码、2磁3磁数据、交易序列号等，把所有能够总结出来的都总结起来不过100个左右的数据。那我们可以首先简单的设计ISO8583，定义128个字段，将所有能够考虑到的类似上面提到的“帐号”等金融数据类型，按照一个顺序排起来，分别对应128个字段中的一个字段。每个数据类型占固定的长度，这个顺序和长度我们都事先定义好。这样就简单了，要发送一个报文时，就将128个字段按照顺序接起来，然后将接起来的整串数据包发送出去。 任何金融软件收到ISO8583包后，直接按照我们定义的规范解包即可，因为整个报文的128个字段从哪一位到哪一位代表什么，大家都知道，只要知道你的数据包是ISO8583包即
拆解报文
报文的拆解 1、发送方式 pos 机发送一个16进制的报文8个字节一组进行发送 2、报文的机构 一个报文有三部分组成：TPDU 、报文头、应用数据 3、BCD码（压缩码) Char buf []="123456"; 采用BCD 码存储: char buf [0]=0x12; char buf[1]=0x34; char buf [2]=0x56; 4、对TPDU和报文头拆解 TPUD ：占10个字节，，BCD可以压缩一般 5 个字节长度 报文头：12个字节、压缩之后是6个字节。 所以报文的前11个字节为TPUD 和报文头60 00 01 01 00 00 00 00 00 00 00 两个数字为一组，为一个字节。 5、对数据域进行拆解 [1] 对消息类型拆解 四个字节压缩后是两个字节既两组：02 00
[2] 对位元表拆解 B BINARY 位图格式 64 位一个字节8位所以是8个字节没有压缩所以是8组数据 将这8组数据16进制转换成2进制 0 ：0000 8 ：1000 1 ：0001 9 ：1001 （8+1） 2 ：0010 10（a）：1010 （8+2） 3 ：0011 11（b)：1011 （8+3） 4 ：0100 12（c）：1100 （8+4） 5 ：0101 13（d）：1101 （8+5） 6 ：0110 14（e）：1110 (8+6) 7 ：0111 15（f）：1111 （8+7） 转换成2进制后，有1 的那位代表该域有值,然后去报文规范中找到该域，[3] 对各个域的拆解 M 为强制域若没有则证明该消息有错。 BCD 码为压缩码n6数字类型6个字节，压缩后为三个字节，取三组00 00 00 再找下一个域，对余下报文分析 注意类型为ASCII 不需要压缩an 12 表示该字段由字母和数字组成，12 个字节取12组 LLVAR ：V AR 可变长度LL 两位 ans .. 25 ：数字、字母、下划线 .. 这个字段的长度例如长度为7 （25个字节之内都可以）则为07 ，在报文中会显示出来07 00 00 00 00 00 00 00 00 一共7组
ISO8583报文协议详解
ISO8583报文协议详解 ISO8583包（简称8583包）是一个国际标准的包格式，最多由128个字段域组成，每个域都有统一的规定，并有定长与变长之分。 8583包前面一段为位图，用来确定包的字段域组成情况。 其中位图是8583包的灵魂，它是打包解包确定字段域的关键，而了解每个字段域的属性则是填写数据的基础。 1、位图描述如下： 位图位置：1 格式：定长 类型：B16（二进制16位，16*8=128bit） 描述： 如将位图的第一位设为'1'，表示使用扩展位图（128个域），否则表示只使用基本位图（64个域）。 如使用某数据域，应在位图中将相应的位设位'1'，如使用41域，需将位图的41位设为'1'。 选用条件：如使用65到128域，需设位图域第一位为'1' 2、每个域的定义如下： typedef struct ISO8583 { int bit_flag; /*域数据类型0 -- string, 1 -- int, 2 -- binary*/ char *data_name; /*域名*/ int length; /*数据域长度*/ int length_in_byte;/*实际长度（如果是变长）*/ int variable_flag; /*是否变长标志0：否2：2位变长, 3：3位变长*/ int datatyp; /*0 -- string, 1 -- int, 2 -- binary*/ char *data; /*存放具体值*/ int attribute; /*保留*/ } ISO8583; ISO8583 Tbl8583[128] = { /* FLD 1 */ {0,"BIT MAP,EXTENDED ", 8, 0, 0, 2, NULL,0}, /* FLD 2 */ {0,"PRIMARY ACCOUNT NUMBER ", 22, 0, 2, 0, NULL,0}, /* FLD 3 */ {0,"PROCESSING CODE ", 6, 0, 0, 0, NULL,0}, /* FLD 4 */ {0,"AMOUNT, TRANSACTION ", 12, 0, 0, 1, NULL,0}, /* FLD 5 */ {0,"NO USE ", 12, 0, 0, 0, NULL,0}, /* FLD 6 */ {0,"NO USE ", 12, 0, 0, 0, NULL,0}, /* FLD 7 */ {0,"TRANSACTION DA TE AND TIME ", 10, 0, 0, 0, NULL,0}, /* FLD 8 */ {0,"NO USE ", 8, 0, 0, 0, NULL,0}, /* FLD 9 */ {0,"NO USE ", 8, 0, 0, 0, NULL,0}, /* FLD 10 */ {0,"NO USE ", 8, 0, 0, 0, NULL,0}, /* FLD 11 */ {0,"SYSTEM TRACE AUDIT NUMBER ", 6, 0, 0, 1, NULL,0},
8583报文39域对照码
对应答码的处理 交易返回POS终端时都有39 域，POS终端和终端操作员根据应答码要采取相应的操作，可以把操作分为以下几类： A：交易成功 B：交易失败，可重试 C：交易失败，不需要重试 D：交易失败, 终端操作员处理 E：交易失败,系统故障，不需要重试 注1：如果 39 域的内容不能在下表中找到，就显示“交易失败” 注2：如果POS交易的批次号和网络中心批次号不一致时应答码会填“77”，此时POS机应当提示操作员重新签到，再作交易。 表 C.1 应答码表 代码意义类别原因/采取的措施POS显示的内容 00 承兑或交易成功 A 承兑或交易成功交易成功 01 查发卡行 C 查发卡行交易失败，请联系发卡行 02 查发卡行的特殊条件 C 可电话向发卡行查询交易失败，请联系发卡行 03 无效商户 C 商户需要在银行或中心登记商户未登记 04 没收卡 D 操作员没收卡没收卡，请联系收单行 05 不予承兑 C 发卡不予承兑交易失败，请联系发卡行 06 出错 E 发卡行故障交易失败，请联系发卡行 07 特殊条件下没收卡 D 特殊条件下没收卡没收卡，请联系收单行 09 请求正在处理中 B 重新提交交易请求交易失败，请重试 12 无效交易 C 发卡行不支持的交易交易失败，请重试 13 无效金额 B 金额为0 或太大交易金额超限，请重试 14 无效卡号 B 卡种未在中心登记或读卡号有误无效卡号，请联系发卡行 15 无此发卡行 C 此发卡行未与中心开通业务此卡不能受理 19 重新送入交易 C 刷卡读取数据有误，可重新刷卡交易失败，请联系发卡行 20 无效应答 C 无效应答交易失败，请联系发卡行 21 不做任何处理 C 不做任何处理交易失败，请联系发卡行 22 怀疑操作有误 C POS状态与中心不符，可重新签到操作有误，请重试 23 不可接受的交易费 C 不可接受的交易费交易失败，请联系发卡行 25 未能找到文件上记录 C 发卡行未能找到有关记录交易失败，请联系发卡行 30 格式错误 C 格式错误交易失败，请重试 31 银联不支持的银行 C 此发卡方未与中心开通业务此卡不能受理 33 过期的卡 D 过期的卡，操作员可以没收过期卡，请联系发卡行 34 有作弊嫌疑 D 有作弊嫌疑的卡，操作员可以没收没收卡，请联系收单行 35 受卡方与安全保密部门联系 D 有作弊嫌疑的卡，操作员可以没收没收卡，请联系收单行 36 受限制的卡 D 有作弊嫌疑的卡，操作员可以没收此卡有误，请换卡重试 37 受卡方呼受理方安全保密部 门(没收卡) D 有作弊嫌疑的卡，操作员可以没收没收卡，请联系收单行 38 超过允许的PIN试输入 D 密码错次数超限，操作员可以没收密码错误次数超限
8583报文及各域详解
[精彩] 8583问题 https://www.360docs.net/doc/aa1426881.html, 作者:lcunix发表于：2006-02-19 00:03:51 【发表评论】【查看原文】【C/C++讨论区】【关闭】 各位高手能否详细的解释一下8583协议 htldm回复于：2003-08-31 22:15:18 ISO8583包（简称8583包）是一个国际标准的包格式，最多由128个字段域组成，每个域都有统一的规定，并有定长与变长之分。8583包前面一段为位图，用来确定包的字段域组成情况。 其中位图是8583包的灵魂，它是打包解包确定字段域的关键，而了解每个字段域的属性则是填写数据的基础， 1、位图描述如下： 位图位置：1 格式：定长 类型：B16（二进制16位，16*8=128bit） 描述： 如将位图的第一位设为'1'，表示使用扩展位图（128个域），否则表示只使用基本位图（64个域）。 如使用某数据域，应在位图中将相应的位设位'1'，如使用41域，需将位图的41位设为'1'。选用条件：如使用65到128域，需设位图域第一位为'1' 2、每个域的定义如下： typedef struct ISO8583 { int bit_flag; /*域数据类型0 -- string, 1 -- int, 2 -- binary*/ char *data_name; /*域名*/ int length; /*数据域长度*/ int length_in_byte;/*实际长度（如果是变长）*/ int variable_flag; /*是否变长标志0：否 2：2位变长, 3：3位变长*/ int datatyp; /*0 -- string, 1 -- int, 2 -- binary*/ char *data; /*存放具体值*/ int attribute; /*保留*/ } ISO8583; ISO8583 Tbl8583[128] = { /* FLD 1 */ {0,"BIT MAP,EXTENDED ", 8, 0, 0, 2, NULL,0},
数据报文解码详解
数据报文解码详解 本章主要对：数据报文分层、以太报文结构、IP 协议、ARP 协议、PPPOE 协议、Radius 协议等的解码分析做了简单的描述，目的在于介绍Sniffer 软件在协议分析中的功能作用并通过解码分析对协议进一步了解。对其其他协议读者可以通过协议文档和Sniffer 捕获的报文对比分析。 1.1 数据报文分层 如下图所示，对于四层网络结构，其不同层次完成不通功能。每一层次有众多协议组成。 Telnet FTP 和e-mail 等TCP 和UDP IP ICMP IGMP 设备驱动程序及接口卡 如上图所示在Sniffer 的解码表中分别对每一个层次协议进行解码分析。链路层对应“DLC ”；网络层对应“IP ”；传输层对应“UDP ”；应用层对对应的是“NETB ”等高层协议。Sniffer 可以针对众多协议进行详细结构化解码分析。并利用树形结构良好的表现出来。 1.2 以太报文结构 EthernetII 以太网帧结构 Ethernet_II
Ethernet_II 以太网帧类型报文结构为：目的MAC 地址（6bytes ）＋源MAC 地址＋（6bytes ）上层协议类型（2bytes ）＋数据字段（46-1500bytes)＋校验（4bytes ）。 添加时间戳目的上层协议 Sniffer 自动 MAC 地址 源MAC 地址类型 Sniffer 会在捕获报文的时候自动记录捕获的时间，在解码显示时显示出来，在分析问题时提供了很好的时间记录。 源目的MAC 地址在解码框中可以将前3字节代表厂商的字段翻译出来，方便定位问题，例如网络上2台设备IP 地址设置冲突，可以通过解码翻译出厂商信息方便的将故障设备找到，如00e0fc 为华为，010042为Cisco 等等。如果需要查看详细的MAC 地址用鼠标在解码框中点击此MAC 地址，在下面的表格中会突出显示该地址的16进制编码。 IP 网络来说Ethertype 字段承载的时上层协议的类型主要包括0x800为IP 协议，0x806为ARP 协议。 IEEE802.3以太网报文结构 IEEE802.3帧结构
测试socket协议的loadrunner脚本(8583协议)8583报文解析
Pos机收单系统性能压力测试实战 Socket协议测试Loadrunner脚本+8583报文解析Action: #define _EOF '#' #include "lrs.h" Action(){char *recvbuf; int recvlen=0; int rc; lr_start_transaction("Trans_1"); lrs_set_recv_timeout (60,0); lr_start_transaction("Conn_1"); rc=lrs_create_socket("socket0","TCP","LocalHost=0","RemoteHost= 192.168. 205.150:7001",LrsLastArg);//RemoteHost处填入被测程序所在服务器IP lr_output_message("%d",rc); if (rc != 0 ) { lr_end_transaction("Conn_1", LR_FAIL); lr_end_transaction ("Trans_1", LR_FAIL); return 0;}lr_end_transaction("Conn_1", LR_PASS);//判断socket是否链接成功的事务lr_rendezvous("集合点"); lrs_send("socket0","buf0", LrsLastArg); lrs_receive ("socket0","buf1",LrsLastArg); lrs_get_last_received_buffer("socket0",&recvbuf,&recvlen);