报文解析
http协议请求响应报文格式及状态码详解
HTTP协议报文格式 HTTP协议（Hypertext Transfer Protocol――超文本传输协议）浏览器端（客户端）向WEB 服务器端访问页面的过程和HTTP协议报文的格式。 基于HTTP协议的客户机访问包括4个过程，分别是建立TCP套接字连接、发送HTTP请求报文、接收HTTP应答报文和关闭TCP套接字连接： 1. 创建TCP套接字连接 客户端与WEB服务器创建TCP套接字连接，其中WEB端服务器的地址可以通过域名解析确定，WEB端的套接字侦听端口一般是80。 2. 发送HTTP请求报文 客户端向WEB服务端发送请求报文，HTTP协议的请求报文格式为： 请求消息= 请求行（实体头信息）CRLF[实体内容] 请求行= 方法URL HTTP版本号CRLF 方法= GET|HEAD|POST|扩展方法 URL = 协议名称＋宿主名＋目录与文件名 其中"CRLF"表示回车换行。 "请求行"中的"方法"描述了对指定资源执行的动作，常用的方法"GET"、"HEAD"和"POST"等3种，它们的含义如表15-8所示： 请求报文 一个HTTP请求报文由请求行（request line）、请求头部（header）、空行和请求数据4个部分组成，下图给出了请求报文的一般格式。 （1）请求行 请求行由请求方法字段、URL字段和HTTP协议版本字段3个字段组成，它们用空格分隔。例如，GET /index.html HTTP/1.1。 HTTP协议的请求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。这里介绍最常用的GET方法和POST方法。 GET：当客户端要从服务器中读取文档时，使用GET方法。GET方法要求服务器将URL定位的资源放在响应报文的数据部分，回送给客户端。使用GET方法时，请求参数和对应的值附加在URL后面，利用一个问号（“?”）代表URL的结尾 与请求参数的开始，传递参数长度受限制。例如，/index.jsp?id=100&op=bind。POST：当客户端给服务器提供信息较多时可以使用POST方法。POST方法将请求参数封装在HTTP请求数据中，以名称/值的形式出现，可以传输大量数据。 表15-8 HTTP请求方法
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报文
常用http响应报文分析
一、HTTP响应码由三位十进制数字组成，它们出现在由HTTP服务器发送的响应的第一行。 响应码分五种类型，由它们的第一位数字表示： 1xx： 信息，请求收到，继续处理 2xx： 成功，行为被成功地接受、理解和采纳 3xx： 重定向，为了完成请求，必须进一步执行的动作 4xx： 客户端错误，请求包含语法错误或者请求无法实现 5xx： 服务器错误，服务器不能实现一种明显无效的请求 下表显示每个响应码及其含义： 100继续 101分组交换协 200 OK 201被创建 202被采纳 203非授权信息 204无内容
205重置内容206部分内容300多选项 301永久地传送302找到 303参见其他304未改动 305使用代理307暂时重定向400错误请求401未授权 402要求付费403禁止 404未找到 405不允许的方法406不被采纳407要求代理授权408请求超时409冲突 410过期的 411要求的xx
412前提不成立 413请求实例太大 414请求URIxx 415不支持的媒体类型 416无法满足的请求范围 417失败的预期 500内部服务器错误 501未被使用 502网关错误 503不可用的服务 504网关超时 505 HTTP版本未被支持 二、HTTP头标由主键/值对组成。它们描述客户端或者服务器的属性、被传输的资源以及应该实现连接。 四种不同类型的头标： 1.通用头标： 即可用于请求，也可用于响应，是作为一个整体而不是特定资源与事务相关联。 2.请求头标： 允许客户端传递关于自身的信息和希望的响应形式。 3.响应头标：
服务器和于传递自身信息的响应。 4.实体头标： 定义被传送资源的信息。即可用于请求，也可用于响应。 头标格式：
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自带的计算器计算出它对应的二进制是
实验12 HTTP报文分析
实验12 HTTP 协议分析实验 一、实验目的 在PC 机上登录Web 页面，截获报文，分析HTTP 协议的报文格式和HTTP协议的工作过程。 二、实验说明 独立完成各自实验 三、实验内容 在一台计算机上截获不同类型HTTP报文进行分析。 四、实验步骤 1.在PC 机上运行Sniffer，设置过滤器，开始截获报文； 2.从浏览器上访问Web 界面，如http://202.202.4 3.125。打开网页，待浏览器的状 态栏出现“完毕”信息后关闭网页。 3.停止截获报文，将截获的报文命名为http1-座号-姓名保存。 4.分析截获的报文，回答以下几个问题： ?在截获的HTTP 报文中，任选一个HTTP 请求报文和对应的 HTTP 应答报文， 仔细分析它们的格式，填写下面两个表格。 ? ?
表2 HTTP 应答报文格式 分析在截获的报文中，客户机与服务器建立了几个连接？服务器和客户机分别使用了哪几个端口号？ 建立了10个连接，服务器使用率1281，1282，1283，1284，1285，1286，1287，1288，1289端口，客户端使用80端口 1.获取长文件 (1)启动浏览器，将浏览器的缓存清空。
(2)启动Sniffer，设定过滤器HTTP，在浏览器地址栏中输入以下网址：https://www.360docs.net/doc/a28973109.html,/wireshark-labs/HTTP-wireshark-file3.html 浏览器将显示一个相当大的美国权利法案。
(3)停止Sniffer，保存为：http2-座号-姓名，回答以下问题。 ?一共发出了多少个HTTP GET请求？ 4个GET请求 ?承载这个HTTTP响应报文需要多少个data-containing TCP报文段？ 一共需要4个TCP报文段 ?与GET请求相对应的响应报文状态码和状态短语是什么？。 状态码：302 状态短语：Found ?在被传送的数据中共有多少个HTTP状态行与TCP-induced continuation有 关？ 有，对于一个大的HTML文件会被TCP分为若干个独立的小包传输，他们是连 续的，如下图 2.嵌有对象的HTML文档 (1)启动浏览器，将浏览器的缓存清空。 (2)启动Sniffer，设定过滤器HTTP，在浏览器地址栏中输入以下网址： https://www.360docs.net/doc/a28973109.html,/wireshark-labs/HTTP-wireshark-file5.html 浏览器将显示一个具有两个图片的短HTTP文件。
[原创]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。
HTTP请求报文格式
HTTP报文是面向文本的，报文中的每一个字段都是一些ASCII码串，各个字段的长度是不确定的。HTTP有两类报文：请求报文和响应报文。 请求报文 一个HTTP请求报文由请求行（request line）、请求头部（header）、空行和请求数据4个部分组成，下图给出了请求报文的一般格式。 （1）请求行 请求行由请求方法字段、URL字段和HTTP协议版本字段3个字段组成，它们用空格分隔。例如，GET /index.html HTTP/1.1。 HTTP协议的请求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。这里介绍最常用的GET方法和POST方法。 GET：当客户端要从服务器中读取文档时，使用GET方法。GET方法要求服务器将URL定位的资源放在响应报文的数据部分，回送给客户端。使用GET方法时，请求参数和对应的值附加在URL后面，利用一个问号（“?”）代表URL 的结尾与请求参数的开始，传递参数长度受限制。例如， /index.jsp?id=100&op=bind。 POST：当客户端给服务器提供信息较多时可以使用POST方法。POST方法将请求参数封装在HTTP请求数据中，以名称/值的形式出现，可以传输大量数据。 （2）请求头部 请求头部由关键字/值对组成，每行一对，关键字和值用英文冒号“:”分隔。请求头部通知服务器有关于客户端请求的信息，典型的请求头有：User-Agent：产生请求的浏览器类型。 Accept：客户端可识别的内容类型列表。 Host：请求的主机名，允许多个域名同处一个IP地址，即虚拟主机。 （3）空行 最后一个请求头之后是一个空行，发送回车符和换行符，通知服务器以下不再有请求头。 （4）请求数据
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},