各种报文的格式
L2TP报文格式
IP报文头 20 报文头 公网地址) (公网地址)
UDP 8 报文头
L2TP 8 报文头
PPP 4 报文头
IP报文头 报文头 私网地址) (私网地址)
Data
GRE报文格式
链路层
IP
GRE
IP/IPX
Payload
当IP层接收到GRE报文,此时IP报文头中的下一协议号是47,IP层输入入口函 数会根据协议开关表调用GRE的解封装处理函数.GRE解封装完成后将数据 报文送入IP输入队列. GRE报文长度8Byte
MPLS报文格式
0 20 23 24 31
标标
EXP S
TTL
32比比
2层头头
2层 头 头
MPLS头头
M P LS 头
IP头头
M PLS头 IP 头 头
数数
数数
通常,MPLS包头有32Bit,其中有: 20Bit用作标签(Label),0到15系统保留 3个Bit的EXP, 协议中没有明确,通常用作COS 1个Bit的S,用于标识是否是栈底,表明MPLS的标签可以嵌套. 8个Bit的TTL
PPPOE报文格式
版本 类型 Code Session ID 长度 Payload
PPPOE报文格式: 总长6Byte | VER 4bit| TYPE4bit | CODE8bit |SESSION_ID16bit || LENGTH16bit | |payload(从ppp的pro字段开始) 发现阶段:PADI,PADO,PADR,PADS,PADT(PPPoE Active Discovery Initiation,Offer,Request,Session-confirmation,Terminate 会话阶段:
数据包的格式
以太网14 以太网14 TCP20 Data CRC
IP20
以太网14 以太网14
IP20
UDP8
Data
CRC
VLAN的帧格式
DA SA Type Data
标准以太网帧
CRC
DA
SA
tag
Type
Data TCI
CRC
TPID
Priority
CFI
VLAN ID
带有IEEE802.1Q标记的以太网帧 带有IEEE802.1Q标记的以太网帧
A RP : 报 报 报 报 ( 以 以 以 )
前两个字段是以太网的源地址和目的地址 帧类型:两个字节长的以太网帧类型表示后面数据的类型.对于A R P 请求或应答来说, 该字段的值为0 x 0 8 0 6 ; 硬件类型:表示硬件地址的类型.它的值为1 即表示以太网地址; 协议类型:表示要映射的协议地址类型.它的值为0 x 0 8 0 0 即表示I P 地址.它的值与包 含I P 数据报的以太网数据帧中的类型字段的值相同; 硬件地址长度和协议地址长度分别指出硬件地址和协议地址的长度,以字节为单位.对于 以太网上I P 地址的A R P 请求或应答来说,它们的值分别为6 和4 . 操作类型:1--A R P 请求),2--A R P 应答,3--R A R P 请求,4--R A R P 应答 接下来的四个字段是发送端的硬件地址(在本例中是以太网地址),发送端的协议地址 (I P 地址),目的端的硬件地址和目的端的协议地址.这里有一些重复信息:在以太网 的数据帧报头中和A R P 请求数据帧中都有发送端的硬件地址. 对于一个A R P 请求来说,除目的端硬件地址外的所有其他的字段都有填充值.
协议字段含义:
8021 C021 C023 C223
Internet Protocol Control Protocol Link Control Protocol Password Authentication Protocol Challenge Handshake Authentication Protocol
以太网帧结构
前序 DA SA Type Data CRC
--------------------------------------------------------------------------------------------| 前序 | 目的地址 | 源地址 | 类型 | 数据 | FCS | ---------------------------------------------------------------------------------------------| 8 byte | 6 byte | 6 byte | 2 byte | 46~1500 byte | 4 byte|
配置BPDU(Configuration BPDU)的封装与内容 配置 ( )
Protocol Identifier 01-80-C2-00-00-00 Protocol Version Identifier BPDU Type DMAC SMAC Length Data FCS LLC BPDU Bridge ID Flags Root Identifier Root Path Cost Bridge Identifier Port Identifier Message Age Max Age HelloTime Forward Delay Message Age随时间增长 而变大 Max age 默认20秒 Hello Time 默认2秒 Forward Delay 默认15秒 用于检测 最优配置 BPDU 0x0000 0x00 0x00 0x00 四部分 设置为 全 0
PPP帧结构
协议 信息 CRC 标志 控制 标志 地址 --------------------------------------------------------------------------------------------| 标志 | 地址 | 控制 | 协议 | 数据 | FCS | 标志| --------------------------------------------------------------------------------------------| 1 byte | 1 byte | 1 byte | 2 byte | 1500 byte | 2 byte | 1byte|
IP报文格式
版本4 报文长度4 服务类型 标志3 总 长 度16 片 偏 移13
标 识 符16
生存时间
协 议 源 IP 地 址 目 的 IP 地 址 IP 选 项
报头校验和
DNS报文格式
�
各种报文的格式
PPP帧结构
标志 地址 控制 协议
信息
CRC 标志
---------------------------------------------------------------------------------------------
| 标志 | 地址 | 控制 | 协议 |
数据 | FCS |
01-80-C2-00-00-00
DMAC SMAC Length Data FCS
Bridge ID
LLC BPDU
Protocol Identifier Protocol Version Identifier
BPDU Type Flags
Root Identifier Root Path Cost Bridge Identifier Port Identifier Message Age
以太网帧结构
前序
DA
SA Type
Data
CRC
---------------------------------------------------------------------------------------------
| 前序 | 目的地址 | 源地址 | 类型 | 数据
| FCS |
PPPOE报文格式
版本 类型 Code Session ID 长度
Payload
PPPOE报文格式: 总长6Byte
| VER 4bit| TYPE4bit | CODE8bit |SESSION_ID16bit || LENGTH16bit | |payload(从ppp的pro字段开始) 发现阶段:PADI、PADO、PADR、PADS、PADT(PPPoE Active Discovery Initiation、Offer、Request、Session-confirmation、Terminate 会话阶段:
船图报文BAPLIE格式-上海华港国际船舶代理有限公司
船图(BAPLIE)平台文件
1.单证概述
发送方→接收方:进口:卸港船代→码头、理货
出口:装港码头预配→理货→装港船代
报文功能:本报文提供一个航次的船舶装载集装箱和货物的有关信息及其集装箱在船上贝位,是船方进行下一挂港装、卸的重要资料,也是港方安排装船、卸船作业的依据。
相应业务单证:进口船图,出口船图
业务备注:1.该平文件是根据上海地区航运业务情况制定的,比交通部标准少记录01,记录51(本报文中的51记录是根据业务需求由亿通平台添加的),记录55;
2.进口船图要求船舶进港前24小时传输,出口船图在装船作业完成后6小时内发送;
3.对实际业务中一货多贝位的情况,目前的处理方法是由代理书面或电话通知码头;
4.码头以第一次收到的电子数据为准,且不接收船代的电子更改,船代如要更改电子数
据,必须以口头通知、纸面传真的形式通知码头,由码头人工控制电子数据的更改、
删除。
5.在发给码头的进口船图中,只要存在成箱组的框架箱,必须填写51副箱记录,且50
记录中主箱的箱型尺寸代码必须填写95码中框架箱的代码,如22P1、42P1、L2P1。
2.记录说明
注:温度中,除正(+)负(-)号及小数点外,最多只能三位数字。
注:拼箱货时可用此记录描述其中关键货物的危险品信息。
3.文件结构
00 头记录M 1
10 描述船舶有关的基本数据项目M 1
11 描述船舶有关的补充信息M 1
50 集装箱信息M9999
51 副箱信息C99
52 地点信息M 1
53 可选卸货港信息 C 1
54 危险品信息(指关键货物) C 1
99 尾记录M 1 4.版本信息。
银行u开头的报文
银行u开头的报文银行U开头的报文是指银行在业务流程中使用的一种标准格式的通信方式。
它是银行与客户、银行与其他金融机构之间进行信息交流的基本工具,具有统一的格式和规范,以确保信息的准确性、安全性和可追溯性。
以下是对银行U开头报文的详细介绍。
一、概述银行U开头报文是由银行业务系统生成的一种标准报文格式,用于银行的内部处理和与其他金融机构之间的信息传输。
它采用了统一的报文结构和字段定义,并遵循国际标准和行业规范,以确保信息在不同系统之间的互通性。
二、报文结构银行U开头报文的结构包括报文头部和报文体两部分。
报文头部用于存放报文的基本信息,包括发送方和接收方的标识、报文类型、报文长度等。
报文体是实际的业务数据,根据具体业务需求可以包含不同的字段和数据项。
三、报文类型银行U开头报文根据不同的业务需求可以分为多种类型,常见的有支付报文、查询报文、通知报文等。
每种报文都有特定的报文代码和约定的数据格式,以便接收方正确地处理和解析报文内容。
四、报文字段银行U开头报文的字段定义了报文中各个数据项的意义和取值范围。
每个字段都具有唯一的标识符和数据类型,以及必要的约束条件。
银行通过约定的字段来传递各种业务数据,例如账号、金额、交易类型等。
五、报文传输银行U开头报文的传输方式可以是同步或异步的。
在同步模式下,发送方会等待接收方的回应,以确保报文的安全和可靠传输。
而在异步模式下,发送方只发送报文,不等待回应,适用于一些不需要实时确认的业务场景。
六、报文安全银行U开头报文在传输过程中需要保证数据的机密性和完整性。
为了实现报文的安全传输,银行通常会采用加密和签名等技术手段,对报文进行加密处理和数字签名,以防止报文被篡改或伪造。
七、报文标准银行U开头报文的标准由银行协会或相关行业组织制定和管理,以确保报文的一致性和互操作性。
不同的报文标准可以根据业务需求进行扩展和定制,满足银行各种复杂的业务场景。
总结:银行U开头报文作为银行业务流程中的基本通信方式,对于银行的信息交流和协作具有重要意义。
报文分析,技术介绍,OSPF的报文格式,报文类型及含义
PROFIBUS-DP站点可分为主站和从站,开发从站设备要比开发主站设备容易得多,因为从站只需要响应来自主站的请求即可。
从站接收总线上的每条报文,如果与自己无关,则忽略不处理,如果是发给自己的则按照下图给出的状态机进行响应。
该状态机中有四个状态:1、Power_On(上电)状态在上电后从站进入Power_On状态,在这个状态下从站首先需要进行初始化,设置各项参数如站地址和报文缓冲区等等。
2、Wait-Prm(等待参数化)状态初始化完毕后,从站进入Wait-Prm状态,等待来自一个主站的Set_Prm报文。
通俗地讲,参数化相当于一个主站告诉一个从站,你是属于我的,同时也指定了从站的一些运行参数。
主站只对被它参数化的从站进行数据轮询。
3、Wait_Cfg(等待组态)状态在进行正确的参数化后,从站进入Wait_Cfg状态,等待Check_Cfg报文。
Check_Cfg 报文规定输入和输出字节数,也就是主站和从站每次交换的数据量。
4、Date_Exchange(数据交换)状态当进行正确的参数化和组态后,从站进入Date_Exchange状态,这个时候从站才可以和主站进行正常的数据交换。
下面是我从一个PROFIBUS-DP网络中采集下来的部分报文数据,该网络中有一站地址为1的主站和站地址为3的从站。
我结合有关报文解释一下从站3的工作机制。
(报文数据为16进制)......(从站已经完成初始化)......10 03 01 49 4D 16(该报文为主站1发给从站3的请求帧,查询从站3的FDL状态,即从站3是否“活着”。
)10 01 03 00 04 16(该报文为从站3对主站1的应答帧,告诉主站1“我活着呢”。
).....68 05 05 68 83 81 6D 3C 3E EB 16(该报文为主站1发给从站3的请求帧,读取查询从站3的诊断报文,以获取从站3的进一步信息。
)68 0B 0B 68 81 83 08 3E 3C 02 05 00 FF 00 08 94 16(该报文为从站3对主站1的应答帧,其中包含6个字节的诊断数据:02 05 00 FF 00 08,具体含义可参阅协议,其中第四字节为FF表明从站3尚未被任何主站所参数化。
cip协议报文格式
cip协议报文格式【原创版】目录1.CIP 协议简介2.CIP 协议报文格式概述3.CIP 协议报文结构4.CIP 协议报文示例5.总结正文1.CIP 协议简介CIP(Common Industrial Protocol)协议,即通用工业协议,是一种在工业自动化领域广泛应用的通信协议。
它主要用于各种工业控制器、传感器和执行器之间的数据交换和通信。
CIP 协议具有开放性、可扩展性和可靠性等特点,能够满足各种工业场景的需求。
2.CIP 协议报文格式概述CIP 协议报文格式是指在 CIP 协议中,数据传输时所采用的报文结构。
它包括报文头、报文长度、控制域、地址域、应用数据单元(ASDU)和校验和等部分。
3.CIP 协议报文结构CIP 协议报文结构如下:- 报文头:包括帧头(Start Frame Delimiter, SFD)和帧尾(End Frame Delimiter, EFD)字段,用于标识报文的开始和结束。
- 报文长度:表示整个报文的字节数。
- 控制域:包括传输协议标识符(TPID)、数据长度指示器(DLI)和控制域扩展(CIDX)字段,用于表示报文的传输协议、数据长度和控制域扩展信息。
- 地址域:包括源地址(SRC)和目标地址(DST)字段,用于表示报文的发送方和接收方。
- 应用数据单元(ASDU):是报文的主要内容,包括数据项(Data Item, DI)和数据描述符(Data Description, DD)字段,用于表示实际的数据传输。
- 校验和:用于检测报文在传输过程中的错误。
4.CIP 协议报文示例假设有一个 CIP 协议报文,其报文头为 0x01 0x03,报文长度为 10 字节,控制域为 0x01 0x03 0x00 0x01,地址域为 0x01 0x02 和 0x02 0x01,应用数据单元为“0x01 0x02 0x03”,校验和为 0x04,则该 CIP 协议报文的完整表示为:0x01 0x03 0x01 0x03 0x00 0x01 0x02 0x01 0x02 0x01 0x02 0x03 0x045.总结CIP 协议报文格式是 CIP 协议数据传输的基础,其结构包括报文头、报文长度、控制域、地址域、应用数据单元和校验和等部分。
ICMP报文的格式和种类
ICMP报文的格式和种类rague | 13 九月, 2007 16:41--------------------------------格式------------------------------------- 各种ICMP报文的前32bits都是三个长度固定的字段:type类型字段(8位)、code代码字段(8位)、checksum校验和字段(16位)8bits类型和8bits代码字段:一起决定了ICMP报文的类型。
常见的有: 类型8、代码0:回射请求。
类型0、代码0:回射应答。
类型11、代码0:超时。
16bits校验和字段:包括数据在内的整个ICMP数据包的校验和,其计算方法和IP头部校验和的计算方法是一样的。
下图是一张ICMP回射请求和应答报文头部格式对于ICMP回射请求和应答报文来说,接下来是16bits标识符字段:用于标识本ICMP进程。
最后是16bits序列号字段:用于判断回射应答数据报。
ICMP报文包含在IP数据报中,属于IP的一个用户,IP头部就在ICMP报文的前面一个ICMP报文包括IP头部(20字节)、ICMP头部(8字节)和ICMP报文IP头部的Protocol值为1就说明这是一个ICMP报文ICMP头部中的类型(Type)域用于说明ICMP报文的作用及格式此外还有代码(Code)域用于详细说明某种ICMP报文的类型所有数据都在ICMP头部后面。
RFC定义了13种ICMP报文格式,具体如下:类型代码 类型描述0 响应应答(ECHO-REPLY)3 不可到达4 源抑制5 重定向8 响应请求(ECHO-REQUEST)11 超时12 参数失灵13 时间戳请求14 时间戳应答15 信息请求(*已作废)16 信息应答(*已作废)17 地址掩码请求18 地址掩码应答其中代码为15、16的信息报文已经作废。
下面是几种常见的ICMP报文:1.响应请求我们日常使用最多的ping,就是响应请求(Type=8)和应答(Type=0),一台主机向一个节点发送一个Type=8的ICMP报文,如果途中没有异常(例如被路由器丢弃、目标不回应ICMP或传输失败),则目标返回Type=0的ICMP报文,说明这台主机存在,更详细的tracert通过计算 ICMP报文通过的节点来确定主机与目标之间的网络距离。
xml报文格式
xml报文协议1.清除缓存命令1.1发送<?xml version="1.0" encoding="UTF-8"?><request id=”clear” version=”0.1”><!—要清除缓存域名--><domain></domain></request>1.2回应<?xml version="1.0" encoding="UTF-8"?><response id =”ping” version=”0.1” flag=”1”><!—1成功,0失败> </response>2.ping命令1.1发送报文<?xml version="1.0" encoding="UTF-8"?><request id=”ping” version=”0.1”><!—要ping的域名或者ip--><name></name></request>1.2返回报文注:ping只返回四包数据<?xml version="1.0" encoding="UTF-8"?><response id =”ping” version=”0.1” flag=”1”><!--1成功,0失败--> <source>源报文<source><ip>121.14.0.18</ip><send>4</send>发送次数<received>4</received>接收次数<minimum>45</minimum>最短响应时间<maximum>151</maximum>最长响应时间<average>88</average>平均响应时间</response>3.traceroute命令2.1发送报文<?xml version="1.0" encoding="UTF-8"?><request id =”traceroute” version=”0.1”><name></name></request>2.2返回报文1<?xml version="1.0" encoding="UTF-8"?><response id =”traceroutstart” version=”0.1” flag=”1”><!--1成功,0失败--> <endIp>114.80.212.230 </endIp>路由终点<max>30</max>节点上限</response>2.3返回报文2<?xml version="1.0" encoding="UTF-8"?><response id =”tracerout” version=”0.1” flag=”1”><!--1成功,0失败--> <no>1</no>节点序号<ip>114.80.212.129</ip><time1>24.258 ms</time1>响应时间1<time2>25.332ms</time2>响应时间2<time3>23.32ms</time3>响应时间3</response>2.4 返回报文3<?xml version="1.0" encoding="UTF-8"?><response id =”traceroutefinish” version=”0.1” flag=”1”><!--1成功,0失败--> <source>源报文<source></response>4.各节点访问网站速度3.1发送报文<?xml version="1.0" encoding="UTF-8"?><request id =”domainSpeed” version=”0.1”><url></url></request>3.2返回报文<?xml version="1.0" encoding="UTF-8"?><response id=”domainSpeed” version=”0.1” flag=”1”><!--1成功,0失败--> <downloadTime>下载时间</downloadTime><speed>下载速度</speed><size>网页大小</size></response>5.网页元素列表4.1发送报文<?xml version="1.0" encoding="UTF-8"?><request id =”domainElementList” version=”0.1”><url></url></request>4.2返回报文1<?xml version="1.0" encoding="UTF-8"?><response id =”domainElementList” version=”0.1” flag=”1”><!--1成功,0失败--> <url> /gtone.gif </url><type>元素类型</type><size>元素大小</size><time>下载时间</time><speed>下载速度</speed></response>4.3返回报文2<?xml version="1.0" encoding="UTF-8"?><response id =”elementfinish” version=”0.1” flag=”1”><!--1成功,0失败--></response>6.元素下载时间5.1发送报文<?xml version="1.0" encoding="UTF-8"?><request id =”elementSpeed” version=”0.1”><url>/gtone.gif</url></request>5.2返回报文<?xml version="1.0" encoding="UTF-8"?><response id =” elementSpeed” version=”0.1” flag=”1”><!--1成功,0失败--><element><url>元素地址</url><type>元素类型</type><size>元素大小</size><time>下载时间</time><speed>下载速度</speed></element></response>7.网页各元素下载速度6.1发送报文<?xml version="1.0" encoding="UTF-8"?><request id =”AllElementSpeed” version=”0.1”><url></url></request>6.2返回报文<?xml version="1.0" encoding="UTF-8"?><response id =” AllElementSpeed” version=”0.1” flag=”1”><!--1成功,0失败--> <element><url>元素地址</url><type>元素类型</type><size>元素大小</size><time>下载时间</time><speed>下载速度</speed></element>... ...<element>... ...</element></response>。
OSPF报文格式
要理解OSPF路由协议的工作原理,特别是路由更新机制,首先就要对它的各种报文格式有一个全面的了解。
OSPF报文主要有5种:Hello报文、DD (Database Description,数据库描述)报文、LSR (LinkState Request,链路状态请求)报文、LSU(LinkState Update,链路状态更新)报文和LSAck(LinkState Acknowledgment,链路状态应答)报文。
它们各自在OSPF路由更新中所担当的用途不一样,报文格式也存在比较大的差别。
9.2 OSPF报头及各种报文格式OSPF报文直接封装为IP协议报文,因为OSPF是专为TCP/IP网络而设计的路由协议。
以上所说到的五种OSPF报文使用相同的OSPF报头格式,如图9-9所示。
图9-9 OSPF协议报头格式l Version版本字段,占1个字节,指出所采用的OSPF协议版本号,目前最高版本为OSPF v4,即值为4(对应二进制就是0100)。
l Packet Type报文类型字段,标识对应报文的类型。
前面说了OSPF有5种报文,分别是:Hello报文、DD报文、LSR报文、LSU报文、LSAck报文。
具体将在下面各小节介绍。
l Packet Length:包长度字段,占2个字节。
它是指整个报文(包括OSPF报头部分和后面各报文内容部分)的字节长度。
l Router ID:路由器ID字段,占4个字节,指定发送报文的源路由器ID。
l Area ID:区域ID字段,占4个字节,指定发送报文的路由器所对应的OSPF区域号。
l Checksum:校验和字段,占2个字节,是对整个报文(包括OSPF报头和各报文具体内容,但不包括下面的Authentication字段)的校验和,用于对端路由器校验报文的完整性和正确性。
l AuType:认证类型字段,占2个字节,指定所采用的认证类型,0为不认证,1为进行简单认证,2采用MD5方式认证。
HTTP的报文格式
POST /itx/itxsvc/param HTTP/1.1<0DH><0AH>HOST: 127.0.0.1:9080<0DH><0AH>Accept: */*<0DH><0AH>Accept-Language: zh-cn<0DH><0AH>User-Agent: XAgent<0DH><0AH>Connection: Keep-Alive<0DH><0AH>Content-Type: application/x-www-form-urlencoded<0DH><0AH>Content-Length: 929<0DH><0AH><0DH><0AH>requestMessage=%3C%3Fxml+version%3D%221.0%22+encoding%3D%22UTF-8%22%3F%3E%3CTXLife%3E%3CUser AuthRequest%3E%3CUserLoginName%3Echangzhou%3C%2FUserLoginName%3E%3CUserPswd%3E%3CPswd%3Epass word%3C%2FPswd%3E%3C%2FUserPswd%3E%3C%2FUserAuthRequest%3E%3CTXLifeRequest%3E%3CTransRefGUID %3E0000010001%3C%2FTransRefGUID%3E%3CTransType+tc%3D%22208%22%3E%E8%B4%A6%E5%8D%95%E4%BF%A1% E6%81%AF%E6%9F%A5%E8%AF%A2%3C%2FTransType%3E%3CTransExeDate%3E2012-09-12%3C%2FTransExeDate%3 E%3CTransExeTime%3E09%3A38%3A04%3C%2FTransExeTime%3E%3COLifE%3E%3CHolding+id%3D%22Holding_1% 22%3E%3CPolicy%3E%3CApplicationInfo%3E%3CHOAppFormNumber%3E1234567890%3C%2FHOAppFormNumber%3 E%3C%2FApplicationInfo%3E%3C%2FPolicy%3E%3C%2FHolding%3E%3C%2FOLifE%3E%3COLifEExtension+Vend orCode%3D%221%22%3E%3CPartnerCode%3ECZ%3C%2FPartnerCode%3E%3C%2FOLifEExtension%3E%3C%2FTXLif eRequest%3E%3C%2FTXLife%3E&transType=208&tradingPartner=CZ&documentProtocol=CPIC_ECOM&bytesL ength=591其中<0DH><0AH>实际是换行符(有ComView程序为了显示,自动将回车换行转成的<0DH><0AH>的。
大额支付系统报文格式汇总
大额支付系统MESG报文格式汇总版本号:V2.3中国人民银行科技司二○○六年七月目录1 概述 (4)1.1 说明 (4)1.2 数据格式描述 (4)1.3 属性符号 (5)1.4 x-字符集 (6)1.5 英文简称命名规范 (6)2 报文结构 (7)2.1 报文块的说明 (7)2.1.1 系统信息块(sysInfoB) (7)2.1.2 报头块(basHeadB) (7)2.1.3 批量支付业务头块(batAppHeadB) (7)2.1.3 业务头块(appHeadB) (8)2.1.4 正文块(textB) (8)2.1.5 基本数据块 (8)2.1.6 报尾块(trailerB) (8)2.2 报文块之间的关系 (9)2.3 报文块结构规则 (10)3 报文块格式描述 (12)3.1 系统信息块 (12)3.2 报头块 (12)3.3 批量支付业务头块 (13)3.4 业务头块 (14)3.5 正文块 (15)3.6 报尾块 (15)4 报文分类 (17)4.1 报文功能分类 (17)4.2 报文结构分类 (23)4.2.1系统信息 (23)4.2.2实时支付指令 (23)4.2.3批量支付业务指令 (24)4.2.4无编押应用报文 (24)5处理码说明 (25)附录A TAG与域名 (27)A1各种TAG值类型的格式说明 (27)A2 TAG与域名一览表 (28)附录B 处理码一览表 (56)B1涉及处理码的报文列表 (56)B2处理码一览表 (57)B3涉及处理码的报文列表 (66)CMT253 大额或即时转账清算结果返回报文 (66)CMT910 通用回应报文 (68)CMT420 登录返回报文 (72)CMT422 退出登录返回报文 (72)CMT683 排队情况查询返回报文 (73)CMT682 余额查询模块返回报文 (73)CMT686 预期头寸查询模块返回报文 (74)CMT687 账户信息查询模块返回报文 (74)CMT684 同城轧差净额查询模块返回报文 (75)CMT685 小额轧差清算情况查询模块返回报文 (75)CMT448 单边及错账冲正业务查询回应报文 (75)CMT660 小额拒绝报文 (75)CMT404 人工质押融资回复报文 (76)B4新增处理码列表(2002-06-02) (76)附录C 支付系统报文正文 (78)报文编号:CMT100 报文名称:汇兑支付报文 (78)报文编号:CMT101 报文名称:委托收款(划回)支付报文 (80)报文编号:CMT102 报文名称:托收承付(划回)支付报文 (81)报文编号:CMT103 报文名称:国库资金汇划(贷记)支付报文 (82)报文编号:CMT104 报文名称:定期贷记支付报文 (84)报文编号:CMT105 报文名称:银行间同业拆借支付报文 (85)报文编号:CMT108 报文名称:退汇支付报文 (86)报文编号:CMT109 报文名称:电子联行专用汇兑报文 (87)报文编号:CMT110 报文名称:银行汇票支付报文 (88)报文编号:CMT112 报文名称:旅行支票支付报文 (89)报文编号:CMT113 报文名称:国库资金汇划(借记)支付报文 (90)报文编号:CMT114 报文名称:定期借记支付报文 (91)报文编号:CMT119 报文名称:通用借记支付报文 (92)报文编号:CMT221 报文名称:同城轧差净额清算报文 (93)报文编号:CMT222 报文名称:小额轧差净额清算报文 (94)报文编号:CMT223 报文名称:大额或即时转账清算报文 (95)报文编号:CMT253 报文名称:大额或即时转账清算结果返回报文 (95)报文编号:CMT301 报文名称:查询报文 (96)报文编号:CMT302 报文名称:查复报文 (98)报文编号:CMT303 报文名称:自由格式报文 (99)1 概述1.1 说明报文是支付系统与银行系统交换业务、控制数据的基本单位。
