【JT交通运输标准】 道路客运联网售票系统第3部分:数据交换

中华人民共和国交通运输行业标准 JT/T979.3—2015 道路客运联网售票系统 第3部分：数据交换 发布日期：2015-07-11 实施日期：2015-11-01 发布单位：中华人民共和国交通运输部 前言 JT/T979《道路客运联网售票系统》分为12部分：第1部分：服务接口规范；第2部分：信息数据元；第3部分：数据交换；第4部分：部级联网售票平台接入技术要求；第5部分：乘车凭证技术要求；第6部分：生物特征识别技术要求；第7部分：网络售票服务系统技术要求；第8部分：客运信息监测服务系统技术要求；第9部分：移动智能终端售票系统技术要求；第10部分：自助售票终端技术要求；第11部分：自助取票终端技术要求；第12部分：自助检票终端技术要求。本部分为JT/T979的第3部分。 本部分按照GB/T1.1-2009给出的规则起草。本部分由交通运输信息通信及导航标准化技术委员会提出并归口。 本标准起草单位：中国交通通信信息中心、江西省公路运输管理局、北京盛威南凌信息科技有限公司、深圳市汉亿科技有限公司。 本标准主要起草人：王林、关笑楠、李聪、褚伟、林榕、王永明、康红霞、刘建、沈兵、郭祥、沈凯龙、李普、刘文革、李为、印贤文、无明洲、由士海、江伟。 1 范围 JT/T979.3—2015规定了票源地与道路客运联网售票系统，以及道路客运联网售票系统与省级平台之间数据交换的技术要求和数据采集交换信息。本部分适用于票源地与道路客运联网售票系统，以及道路客运联网售票系统与省级平台之间所涉及的道路客运数据的交换与共享。 2 规范性引用文件 下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。引用文件：JT/T979.2-2015。 3 术语、定义和缩略语 3.1 术语和定义 下列术语和定义适用于本文件： 3.1.1 上级平台 (superior platform)：道路客运联网售票系统中的省级联网售票系统。 3.1.2 下级平台 (inferior platform)：接入省级联网售票系统的票源地售票系统、区域级道路客运联网售票系统。 3.1.3 链路 (link)：在上下级平台之间采用两条基于TCP协议的虚拟通道。 3.2 缩略语 下列缩略语适用于本文件： FTP——文件传输协议 (File Transfer Protocol) HTTP——超文本传输协议 (HyperText Transfer Protocol) IP——网络互联协议 (Internet Protocol) URI——统一资源标识符 (Uniform Resource Identifier) URL——统一资源定位符 (Uniform Resource Locator) XML——可扩展标记语言 (Extensible Markup Language) 4 技术要求 4.1 通信方式 上级平台与下级平台之间应采用面向连接的链路通信方式，具体要求如下： - 支持FTP、WebServices、消息队列等通信方式，保证对不同系统的适应性，并应提供可靠的信息传输，支持断点续传、消息压缩传输和SSL传输； - 上下级平台间通信方式采用HTTP协议短连接方式； - 上级平台作为服务器端，提供服务的IP地址、端口号以及用户名、密码等信息，供下级平台接入。 4.2 安全认证 根据4.1中规定的通信方式，上级平台对下级平台的接入请求进行安全认证，确保建立可靠、可信的通信链路。上级平台对下级平台的安全验证流程应遵循以下规定： a) 上级平台为下级平台分配相应的接入码、接入用户名、密码等相关参数； b) 下级平台与上级平台连接时，发送“登录请求”消息，上级平台收到后，首先验证请求的IP地址，如果请求IP地址与约定的接入IP地址不一致，则返回验证失败结果；其次，上级平台对下级平台的接入码、用户名以及密码进行验证，根据验证结果向下级平台返回相应的结果值。 4.3 业务流程 4.3.1 下级平台向上级平台上传数据流程 4.3.1.1 下级平台初次连接上级平台时需进行道路客运联网售票数据的上报，上级平台接收到该信息后，进行入库记载并给下级平台应答。 4.3.1.2 当道路客运联网售票数据中某些数据项发生变化时，下级平台即可上报道路客运联网售票数据，上级平台接收到该信息后，进行入库更新并给下级平台应答。 4.3.2 上级平台向下级平台请求补报数据流程 4.3.2.1 当道路客运联网售票数据中发现数据缺失时，上级平台即刻向下级平台发送补报道路客运联网售票数据请求。 4.3.2.2 下级平台在收到请求后，即刻将相应道路客运联网售票数据补报给上级平台。 4.3.2.3 上级平台接收到道路客运联网售票数据后，进行入库记载并给下级平台应答。 4.4 协议消息格式 4.4.1 消息说明 每条信息应包含消息头和消息体两部分。数据流应遵循大端 (big-endian，即高字节在前，低字节在后) 排序方式的网络字节顺序。未使用的数据位皆填0x00。 4.4.2 数据类型 表1 基本数据类型： - time_t: 64位无符号整型，占8byte - BYTE: 单字节 - BYTES: 多字节 - Octet String: 定长字符串，位数不足时，右补十六进制0x00，汉字采用GBK编码 - BCD[n]: 8421码，占nbyte - UINT16: 16位无符号整型，占2byte - UINT32: 32位无符号整型，占4byte 4.4.3 数据结构 在两个平台之间进行数据交换时，所交换消息的数据结构由五部分组成： 1. Head Flag (头标识) 2. Message Header (消息头) 3. Message Body (消息体) 4. CRC Code (CRC校验码) 5. EndFlag (尾标识) 4.4.4 标识位 每条信息的标识位应包含头标识和尾标识两部分：头标识为字符0x5b，尾标识为字符0x5d。 若消息头、消息体以及校验码中出现头标识或尾标识字符，应按照以下转义规则进行处理： - 数据内容中出现字符0x5b的，将其替换为字符0x5a紧跟字符0x01； - 数据内容中出现字符0x5a的，将其替换为字符0x5a紧跟字符0x02； - 数据内容中出现字符0x5d的，将其替换为字符0x5d紧跟字符0x01； - 数据内容中出现字符0x5e的，将其替换为字符0x5e紧跟字符0x02。 4.4.5 消息头 消息头格式如下： - MSGLENGTH: UINT32，数据长度（包括头标识、消息头、消息体、CRC校验码和尾标识） - MSG_SN: UINT32，消息序列号，用于检测是否有信息丢失。从0开始计数，达到最大数后自动归零。 - MSG_ID: UINT16，业务数据类型的标识 - MSG_CENTERID: UINT32，下级平台接入码，上级平台给下级平台分配的唯一标识号 - VERSION FLAG: BYTES，协议版本号标识。 4.4.6 数据校验 使用CRC16-CCITT校验，遵循大端排序方式。CRC16-CCITT码生成多项式为x16+x12+x5+1，简记式为1021。 5 数据采集交换信息 5.1 运输企业信息 数据项要求包括：企业名称、企业代码、所属行政区划、网址、负责人、联系电话、传真。