当前位置：文档之家 › 交通一卡通通信信息规范传输通讯控制协议V1.0.0

交通一卡通通信信息规范传输通讯控制协议V1.0.0

  • 格式：pdf
  • 大小：261.47 KB
  • 文档页数：9

下载文档原格式

  / 9

合集下载

城市一卡通系统交易协议(高效版)

城市一卡通系统交易协议(高效版)

城市一卡通系统交易协议（高效版）本合同目录一览第一条协议定义与范围1.1 定义1.2 范围第二条协议双方2.1 甲方权益2.2 乙方权益第三条交易内容3.1 卡的种类与功能3.2 交易方式3.3 交易流程第四条卡的发行与激活4.1 发行条件4.2 激活流程第五条充值与消费5.1 充值方式5.2 充值有效期5.3 消费规则第六条费用与结算6.1 费用标准6.2 结算周期6.3 结算方式第七条退卡与挂失7.1 退卡条件7.2 退卡流程7.3 挂失流程7.4 挂失费用第八条客服与技术支持8.1 客服渠道8.2 技术支持内容第九条信息安全与隐私保护9.1 信息安全措施9.2 隐私保护原则第十条违约责任10.1 甲方违约10.2 乙方违约第十一条争议解决11.1 协商解决11.2 调解解决11.3 法律途径第十二条法律适用与管辖12.1 法律适用12.2 管辖法院第十三条合同的生效、变更与终止13.1 生效条件13.2 变更程序13.3 终止条件13.4 终止后的处理第十四条其他条款14.1 通知与送达14.2 合同附件14.3 未尽事宜14.4 合同修订第一部分：合同如下：第一条协议定义与范围1.1 定义1.2 范围本协议适用于甲方在使用城市一卡通系统进行充值、消费、退卡、挂失等各项交易活动时与乙方之间的权利义务关系。

除非本协议另有规定，乙方提供的系统及相关服务均受到本协议的约束。

第二条协议双方2.1 甲方权益甲方作为持卡人，享有使用乙方提供的城市一卡通系统的权利，包括但不限于充值、消费、查询、退卡、挂失等功能。

甲方应遵守本协议的约定，按照规定的流程进行操作。

2.2 乙方权益乙方作为城市一卡通系统的运营方，有权对甲方使用系统进行管理和监督，确保系统的正常运行。

乙方应按照本协议的约定提供各项服务，保障甲方的合法权益。

第三条交易内容3.1 卡的种类与功能乙方提供多种类型的城市一卡通，包括但不限于普通卡、学生卡、老年卡等。

《北京一卡通用户协议》(2024两篇)

《北京一卡通用户协议》(2024两篇)

《北京一卡通用户协议》（二）北京一卡通用户协议（二）1. 引言2. 用户注册和账号管理2.1 用户注册要求用户应提供真实、准确且完整的个人信息，并保证不会以他人的身份注册使用北京一卡通。

用户需对在注册和使用过程中产生的全部行为承担法律责任。

2.2 账号安全保护用户在注册时将获得一个账号和密码，用户需妥善保管账号和密码，不得将账号或密码透露给他人。

用户需对账号和密码下的行为负责。

如您发现账号被盗或存在其他安全问题，请立即联系北京一卡通客服中心。

3. 北京一卡通的使用3.1 使用范围北京一卡通可用于公共交通、商业购物、停车缴费等多个领域。

用户应在合法范围内使用北京一卡通，不得进行非法活动或违反公共秩序的行为。

3.2 充值和消费用户可通过指定途径为北京一卡通充值，并可在规定的商户处使用账户余额进行消费。

用户需保证充值和消费行为的合法性。

3.3 账户余额用户可通过绑定银行卡或进行线下充值等方式向北京一卡通账户充值，亦可将账户余额提现至指定银行账户。

用户应保证充值和提现时所提供的银行卡账户信息真实有效。

3.4 停车缴费支持北京一卡通可用于停车缴费，用户需遵守停车规定，并在规定时间内支付停车费用。

4. 用户隐私保护4.1 个人信息的收集和使用为了提供服务和保障用户的合法权益，北京一卡通可能会收集用户的个人信息。

用户的个人信息将仅用于提供服务、改善用户体验、防止欺诈行为和满足法律要求等合法目的。

4.2 信息安全保护北京一卡通将采取各种必要的安全技术和措施，保障用户的账户和个人信息安全，防止被未经授权的访问、使用、修改或泄露。

但用户需注意，互联网环境下，不存在绝对的安全措施，用户需自行小心谨慎保护个人账户和信息。

5. 服务的中断和终止5.1 服务中断5.2 服务终止6. 免责声明6.1 服务故障和中断北京一卡通将尽力保障服务的稳定性和正常运行，但不对服务故障或中断承担责任，包括但不限于由于技术故障、意外事件、黑客攻击等原因导致的服务中断或数据丢失。

市政交通一卡通技术规范第1部分：总则

市政交通一卡通技术规范第1部分：总则

引言.................................................................................. 6
1 范围............................................................................... 1
11.1 11.2 11.3 11.4
业务类型..................................................................... 13 应用领域..................................................................... 13 交易模式..................................................................... 14 应用方式..................................................................... 15
10 安全要求......................................................................... 12
11 业务规范......................................................................... 13
---- 更新了规范性引用文件中部分已过期标准的日期； ---- 在规范性引用文件中增加了“GB/T 22239-2008 信息系统安全等级保护基本要求”、“GB
50174-2008 电子信息系统机房设计规范”； ---- 删除了规范性引用文件中的“DB11/T 171-2002党政机关信息系统安全评测规范”； ---- 增加了信息系统安全等级保护的要求； ---- 对“5、应用分类”进行结构调整，从：业务类型、应用领域、交易模式和应用方式四个方面

协议V1.0

协议V1.0

城市出租车管理服务信息系统电召平台对外开放技术协议V1.0交通运输部公路科学研究院二〇一四年三月目录1概述 (1)2常用术语............................................................ 错误！未定义书签。

3业务流程定义说明 ........................................... 错误！未定义书签。

3.1订单号约定 .............................................. 错误！未定义书签。

3.2经纬度约定 .............................................. 错误！未定义书签。

3.3召车模式约定 .......................................... 错误！未定义书签。

3.4关键叫车业务流程 .................................. 错误！未定义书签。

4通信连接.. (1)4.1连接的建立 (1)4.2连接的维持 (1)4.3连接的断开 (1)5通讯协议 (2)5.1消息组成 (2)5.2数据类型定义 (3)6消息体定义 (3)6.1SASS -> VSS（第三方运营商至电召平台）错误！未定义书签。

6.2VSS -> SASS（电召平台-->第三方运营商）错误！未定义书签。

7常用的数据结构 (6)7.1DriverInfo驾驶员数据结构 .................... 错误！未定义书签。

7.2PassengerInfo乘客数据结构................... 错误！未定义书签。

7.3OrderInfo 订单数据结构 (6)1概述netty是JBoss提供的一个java开源框架。

提供异步的、事件驱动的网络应用框架和工具，用以快速开发高性能、可靠的网络服务器和客户端。

计费控制单元与读卡器通信协议8篇

计费控制单元与读卡器通信协议8篇

计费控制单元与读卡器通信协议8篇篇1甲方：XXX公司乙方：XXX公司鉴于甲方需要与乙方进行计费控制单元与读卡器之间的通信，经双方友好协商，达成如下合同协议：一、合作内容1.1 甲方负责提供计费控制单元，乙方负责提供读卡器。

1.2 双方需确保各自提供的设备符合国家相关标准和双方约定的技术要求。

1.3 双方需共同开发和维护计费控制单元与读卡器之间的通信协议，确保通信的稳定性、安全性和高效性。

二、技术要求2.1 通信协议需支持高速、稳定的数据传输，确保计费控制单元与读卡器之间的信息传输及时、准确。

2.2 通信协议需具备强大的加密功能，保障数据传输的安全性，防止数据泄露和非法访问。

2.3 双方需共同制定通信协议的技术规范和接口标准，确保不同设备之间的互操作性和兼容性。

三、开发进度3.1 双方需共同制定开发计划，明确各阶段的开发任务和时间节点。

3.2 甲方需提供必要的支持和配合，确保开发进度顺利进行。

3.3 乙方需按照开发计划按时完成各项开发任务，并及时向甲方反馈开发进展情况。

四、维护与支持4.1 双方需共同承担通信协议的维护责任，确保通信协议的稳定运行和持续改进。

4.2 甲方需提供必要的维护和支持，包括但不限于故障排查、问题解决和技术升级等。

4.3 乙方需提供及时的技术支持和响应，确保通信协议在出现问题时能够及时得到解决。

五、知识产权5.1 双方在合作过程中产生的所有技术成果和知识产权归双方共同所有。

5.2 双方需尊重彼此的知识产权，不得擅自使用或泄露对方的技术成果和商业机密。

5.3 在涉及第三方知识产权时，双方需事先取得对方的书面同意，并妥善处理相关事宜。

六、保密条款6.1 双方需对合作过程中涉及到的所有保密信息严格保密，不得擅自泄露或向第三方披露。

6.2 保密信息包括但不限于技术资料、产品信息、客户信息以及价格信息等。

6.3 双方需采取合理的保密措施，确保保密信息的安全性和完整性。

七、付款与结算7.1 双方需明确约定付款方式和结算周期，确保双方的权益得到保障。

北京一卡通2024年版用户服务协议版A版

北京一卡通2024年版用户服务协议版A版

20XX 专业合同封面COUNTRACT COVER甲方：XXX乙方：XXX北京一卡通2024年版用户服务协议版A版本合同目录一览第一条用户服务协议的说明和定义1.1 用户协议的适用范围1.2 定义与解释第二条用户资格与使用条件2.1 用户资格2.2 使用条件第三条北京一卡通的功能与服务3.1 基本功能3.2 增值服务第四条用户账户的开设与管理4.1 账户开设4.2 账户管理第五条充值与消费5.1 充值方式5.2 消费规则第六条退卡与挂失6.1 退卡流程6.2 挂失流程第七条费用与收费标准7.1 费用构成7.2 收费标准第八条隐私保护与信息安全8.1 隐私保护8.2 信息安全第九条用户投诉与咨询服务9.1 投诉渠道9.2 咨询服务第十条免责条款10.1 不可抗力10.2 用户原因10.3 其他免责情况第十一条违约责任11.1 用户违约11.2 运营商违约第十二条争议解决12.1 协商解决12.2 调解解决12.3 法律诉讼第十三条合同的生效、变更与终止13.1 合同生效13.2 合同变更13.3 合同终止第十四条附则14.1 名词解释14.2 合同修订14.3 其他条款第一部分：合同如下：第一条用户服务协议的说明和定义1.1 用户协议的适用范围1.2 定义与解释（1）北京一卡通：指北京城市公共交通卡片，是由北京一卡通公司发行的，适用于北京地区公交、地铁、郊区铁路等多种交通工具的支付工具。

（2）用户：指购买、使用北京一卡通的用户。

（3）充值：指用户向北京一卡通充值账户充入人民币，以增加卡内余额的行为。

（4）消费：指用户使用北京一卡通进行支付公共交通费用的行为。

第二条用户资格与使用条件2.1 用户资格（1）年满18周岁的自然人；（2）具有完全民事行为能力；（3）同意遵守本协议的所有条款。

2.2 使用条件（1）用户需按北京一卡通公司的规定购买、充值和使用；（2）用户在使用北京一卡通时，需遵守相关法律法规及北京一卡通公司的相关规定；（3）用户在使用北京一卡通进行消费时，需遵守相关交通工具的乘车规定。

联通一卡通IC卡系统卡片应用规范

联通一卡通IC卡系统 卡片应用规范（版本： 1.00）属性 描述客户名称项目名称 联通一卡通IC卡系统项目编号文档主题 卡片应用规范文档类别 规范文档编号文档状态 5 完成 已审核 提交客户 归档日期姓名版本更新记录V1.00 初始版本。

2011-9-26 张良付吕立峰目录封面 (1)1 卡片规划设计 (4)1.1卡片相关技术要求 (4)1.2卡片受理环境的要求 (4)1.3密钥算法 (4)1.4卡片容量要求 (4)1.5其它相关因素 (4)2 RFUIM卡空间 (6)3 卡结构 (7)3.1卡内存结构 (7)3.2扇区目录 (7)3.3应用标识目录区 (8)3.4钱包区(1扇区) (8)3.5明细区(2、3、4扇区) (9)3.6公共信息区(5扇区,含交易明细块) (9)3.7发行区定义(6扇区) (10)3.8个人信息区(7扇区) (11)3.9校企内部管理基础信息区(8扇区) (11)3.10累计交易区及校企内部辅助区(9扇区) (12)3.11校企补贴区(10扇区) (12)3.12扇区控制位 (12)4 密钥及安全算法 (14)4.1卡片认证码 (14)4.2消费密钥 (14)4.3充值密钥 (14)4.4TAC计算 (14)5 非消费类应用标示的定义 (17)5.1考勤业务应用标示（考勤卡号） (17)5.2门禁应用标示（门禁卡号） (17)1 卡片规划设计1.1卡片相关技术要求（1）符合《中国金融集成电路(IC)卡应用规范（V2.0电子钱包应用）》、《社会保障(个人)卡规范》等其他专属行业制定的应用规范；（2）接触式界面符合ISO/IEC7816规范；（3）非接触式界面支持ISO/IEC 14443中TYPE-A或TYPE-B通信协议规范；（4）支持线路加密、线路保护功能，防止通讯数据被非法窃取或篡改；（5）支持一个保密模块上实现多个不同应用，各应用之间相互独立（多应用、防火墙功能）；（6）兼容支持国际主流密码算法和国产有关算法；（7）支持多种文件类型，包括二进制、定长记录、变长记录、循环、钱包文件；（8）支持ISO7816－3 T=0（字符传送）和T=1（块传送）通讯协议；（9）行业对卡片交易速度的不同，希望支持多种通讯速率，接触方式可支持9600bps、38400bps、56000bps等不同的通讯速率；非接触方式支持106Kbps通讯速率。

RSSP-I 铁路信号安全通信协议

3.2 时间戳
3.2.1.1 由两个 32 位长的伪随机数表示，用于确认在每个系统周期时的强制增 量。 3.2.1.2 时间戳与序列号保持同步递增。
Safety Verify Code
通信方的安全校验码，每个计算通 道有一个实时演算的取值参数（32 位长）
System Check Word
系统校验字（32 位长），用于标识 安全层协议的正确特性
Sequence Initialisation
序列初始作为启动安全数据信息交 换过程前的通信建立要求生成的结 果。每个计算通道有一个预定的标 记参数（32 位长）
4.
报文定义....................................................................................................... 12
5.
安全通信交互协议 ...................................................................................... 16
数据帧重复；
数据帧丢失；
数据帧插入；
数据帧次序混乱；
数据帧错误；
数据帧传输超时。 2.1.1.3 为降低上述威胁风险，RSSP-I 采用从接收端角度设计的保护算法，要 求接收端必须对接收到的信息做出以下检查:
发送端的源信息(真实性)；
信息帧的正确性(完整性)；
信息帧的时效性(实时性)；
Cyclic Redundancy Check
循环冗余码校验，以循环码为基 础，用于保护报文免受数据损坏的 影响
LFSR Linear Feedback Shift Register 线性反馈移位寄存器

广东省一卡通区域互联的技术规范


一、一卡通规范概述--- PBOC标准规范 1. PBOC1.0标准规范 • 作用：真正意义的单纯PBOC1.0电子钱包银行卡几乎没有 怎么发行，但是基于PBOC1.0电子钱包的行业应用芯片卡 的确发行了不少，比如公交卡、机动车驾驶员IC卡、用于 商户的购物卡或者VIP积分卡。 • 所以PBOC1.0的作用并不在于银行发行符合该规范的卡片 究竟有多少，PBOC1.0的重要意义在于它奠定了中国CPU卡 应用的基本模式，包括安全体系、多级密钥分散机制、基 本文件结构都被其他的行业应用规范参考和借鉴。
按通信协议：接触卡
—— ISO 7816
一般的银行借贷记IC卡
非接触卡—— ISO 14443-A 公交卡 ISO 14443-B 身份证、新加坡公交卡 Felica 按编程技术：Native卡，Java卡 按实现形态： Simpass、NFC、异型卡、RFsim、SD 八达通卡
二、一卡通体系结构----终端设备原理图
一、一卡通规范概述--- PBOC标准规范 1.人行PBOC3.0规范 为适应我国社会安全支付的需要，推动金融IC卡的健 康发展，2011年3月15日，中国人民银行发布《中国人民银 行关于推进金融IC卡应用工作的意见》，同时也提出了IC卡 受理环境改造和银行发卡的时间表。 2013年2月,人民银行正式颁布实施PBOC3.0规范，是在 PBOC2.0基础上，经业内专家多次研讨并不断修订、补充完 善而成，适应了银行卡业务发展的新要求。
二、一卡通体系结构----系统运营模式
岭南通系统体系结构
清算、结算系统 密钥管理系统
地市管 理平台 消 费 系 统
报表统计
系统管理
卡管理
联机充值管理平 台
报表管理
客服系统

交通一卡通通信信息规范解读说明V1.0.2

交通一卡通通信信息规范解读说明交通一卡通通信信息规范解读说明（初稿）中国交通通信信息中心2015年12月21日交通一卡通通信信息规范解读说明文档控制页文档说明：由于引用的《交通一卡通技术规范第4部分：信息接口》文档尚未正式出版，因此本文档为初稿，待引用文档出版后定稿。

目录1范围 (1)2文件传输约定 (1)3基本约定 (1)3.1文件体系说明 (1)3.1.1文件打包说明 (1)3.1.2文件命名规则 (1)3.1.3文件结构 (1)3.1.4记录结构 (2)3.1.5符号定义基本约定 (2)3.1.6金额单位说明 (2)3.2文件编码格式 (3)4参数文件的交换 (3)5清算说明 (3)5.1脱机文件处理流程-先清算后验证 (3)5.2脱机文件处理流程-先验证后清算 (4)6顺序文件接口 (5)6.1接口文件类型 (5)6.2文件中I/O标识的说明 (5)6.3文件头记录 (5)6.4文件尾记录 (6)6.5文件记录格式 (6)6.5.1 CD消费明细数据记录格式 (6)6.5.2 CQ消费验证请求数据记录格式 (8)7流水文件接口 (8)7.1接口文件类型 (8)7.2接口文件说明 (8)7.2.1清算类接口文件 (8)7.2.2其他类接口文件 (16)8异地交易机构代码实例 (25)8.1涉及两个城市之间交易 (25)8.2涉及三个城市之间交易 (25)附录A（规范性附录）标准代码定义 (25)A.1入网机构标识码 (25)A.2入网机构标识码定义 (26)A.3 TLV定义 (26)A.3.1 1000指示标签 (26)A.3.2行业数据信息标签 (26)A.4业务类型定义 (28)1 范围本标准规定了清算中心各联网机构与清算中心之间的文件交换关系，包括文件的存取方式、文件名及记录格式的约定。

2 文件传输约定参考《GC_TEH_020-交通一卡通通信信息规范传输通讯控制协议V1.0.0》3 基本约定3.1 文件体系说明文件按照文件的内容，可以分为：交易明细文件、交易明细清算结果文件、清分结果文件、争议处理请求及结果文件。

  1. 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
6 通信报文消息类型清单-消费报文类型清单 .................................................................................... 5 7 通信应答码定义 .................................................................................................................................. 6 8 测试环境 IP 和端口 ............................................................................................................................ 6
2015.3.26 2015.8.1
王琦 张淳
草稿 v1.0.0 初稿 v1.0.0
文档说明：由于引用的《城市公共交通 IC 卡技术规范 第 4 部分：信息接 口》文档尚未正式出版，因此本文档为初稿，待引用文档出版后定稿。
第 2 页 共 9 页
交通一卡通通信信息规范传输通讯控制协议
目录
1 数据类型说明 ...................................................................................................................................... 1 2 传输约定 .............................................................................................................................................. 1 3 通用消息报文格式 .............................................................................................................................. 2 4 FTP 文件传输 ....................................................................................................................................... 2 5 流文件传输 .......................................................................................................................................... 3 5.1 文件传输流程 .............................................................................................................................. 3
版本号定义规则： 版本号由清算中心维护。 使用阿拉伯数字，并由小数点分割成三部分。 第一部分（一位有效数字）：清算中心整体升级或改造时使用。 第二部分（一位有效数字）：本文档重大修改时使用。通常需要修改当前生产使用的 应用程序。 第三部分（位数不限）：本文档简单修改时使用。通常是增加说明、更加详细的描述， 不影响当前生产使用的应用程序。 第一部分和第二部分的有效数字需要在消息格式的版本号域、本文档标题和文件名中体 现。 日 期 姓 名 版 本 更 新 记 录
第 3 页 共 9 页
交通一卡通通信信息规范传输通讯控制协议
5.1.2 客户端下载文件流程 1. （客户端）建立连接 2. （客户端）发送文件下载请求（4002） 3. （服务端）验证身份 不通过则发送失败的文件数通知4006报文,响应码非00，并关闭连接，结束 下载； 通过则发送成功的文件数通知报文（4006）。 如果4006报文中需要下发的文件为0,则中心关闭连接，结束下载。 4. （客户端）发送应答报文（4008） 5. （服务端）发送文件信息通知报文（4003） 6. （客户端）发送断点通知报文（4005） 7. （服务端）发送应答报文（4008） 8. （服务端）发送数据报文（4004） 9. （客户端）发送应答报文（4008） 10. 重复8，9两步直到文件传输结束 11. （服务端）发送文件传输结束报文（4007） 12. （客户端）发送应答报文（4008） 13. （服务端）将成功传送的文件移到备份目录 重复5-13，直到所有的文件都传输完成 14. （客户端）关闭Socket连接 15. （客户端）断开拨号连接（有拨号的情况） 5.2 文件传输报文说明 各接入点应用系统与清算中心系统之间的文件是通过报文来传输的。报文分为控制报 文与数据报文两类、是文件传输的基本单元；控制报文包含传输数据报文所需的控制信 息； 一个文件需被按序拆成多个数据报文，每次传送一个数据报文。 5.2.1 文件上传请求--文件请求报文(4001) 请参照城市公共交通IC卡技术规范 第4部分： 信息接口——7.3.4.2文件请求报文(表43)
7. （服务端）发送断点通知报文（4005） 8. （客户端）发送数据报文（4004） 9. （服务端）发送应答报文(4008) 10. 重复8、9，直至文件传输完成 11. （客户端）发送文件传输结束报文（4007） 12. （服务端）发送应答报文(4008) 13. 转第6步，开始下一个文件的传输，如无文件则执行第14步 14. （客户端）关闭Socket连接 15. （客户端）断开拨号连接 （有拨号的情况）
第 2 页 共 9 页
交通一卡通通信信息规范传输通讯控制协议
具体路径为：/机构代码/upload、/机构代码/download、/机构代码/downbak、/机构 代码/tmp。机构每天从 download 目录获取未下载的文件，获取成功后移到 downbak。上传 文件时，文件先上传到 tmp 目录，传输结束后，再移到 upload 目录。 每个机构分配一个用户，每个机构只能访问自己机构目录下的文件及目录。 5 流文件传输 文件传输采用如下的流程进行，接收方在接收完每一个文件后，需要对文件大小，摘 要等信息进行验证处理等流程处理通过后，才能返回文件传输结束报文（4007）的成功应 答报文。验证不通过，则需要删除本地文件，返回失败，关闭连接，等待客户端重新上传 或重新下载。 传输过程中，如果有仍一方，发现通信接收或发送有问题，均需要主动关闭连接，不 得重新发送报文，避免接收方出现串包等问题。 5.1 文件传输流程 5.1.1 客户端上传文件流程 1. （客户端）建立连接 2. （客户端）发送文件上传请求报文（4001） 3. （服务端）验证身份，发送应答报文(4008) 4. （客户端）发送文件数通知报文（4006） 5. （服务端）发送应答报文(4008) 6. (客户端）发送文件信息通知报文（4003）
2 传输约定 为了使各类应用系统能够按照本标准规范接入清算中心系统，各类应用系统的开 发必须遵循以下约定：

各类应用系统与清算中心系统的通讯协议采用 TCP/IP 的 Socket 面向连接的通 讯。
交通一卡通通信信息规范传输通讯控制协议

传输信息需遵照 ISO2022，传输中文字符需遵照 GB2312。 各接入点应用系统与清算中心系统之间以文件/报文方式交换数据。应用系统 作为客户端，清算中心系统作为服务器端。
第 3 页 共 9 页
1 数据类型说明 为了方便维护和管理，报文头和报文体都采用自定义的 ASCII 码报文结构。 清算中心系统与各接入点应用系统之间的接口通过报文来约定，各种报文格式中的数 据类型描述一般遵循以下规定： 标示代码 A a N 说明 大写字母，左靠，右补空格 小写字母，左靠，右补空格 数值 0-9；右靠，左补零；负号（－）使用“0X2D”，靠左，如：－ 00001 表示“负一” S AN ANS AS H YY MM DD hh mm ss VAR 特殊符号，需要专门说明 字母和/或数字，左靠，右部多余部分填空格 字母、数字和/或特殊符号，左靠，右部多余部分填空格 字母和/或特殊符号，左靠，右部多余部分填空格 十六进制数 0-F； A-F 为大写字母 年 月 日 时 分 秒 可变长说明，需要专门说明 未定义或未使用的域默认全部填写为：0
5.1.1 客户端上传文件流程 ................................................................. 3 5.1.2 客户端下载文件流程 ................................................................. 4
5.2 文件传输报文说明 ...................................................................................................................... 4
5.2.1 文件上传请求--文件请求报文(4001) ..................................... 4 5.2.2 文件下载请求--文件下载报文(4002) ..................................... 5 5.2.3 文件信息通知报文（4003） ..................................................... 5 5.2.4 断点通知报文(4005) ................................................................. 5 5.2.5 文件数通知报文(4006) ............................................................. 5 5.2.6 文件传输结束报文(4007) ......................................................... 5 5.2.7 数据报文(4004) ......................................................................... 5 5.2.8 应答报文(4008) ......................................................................... 5