JT905实现（一）：协议的简单讲解

背景

主线

协议

1、各方关系

2、协议简介

背景

最近在做905协议，本想着靠着度娘扒拉下代码参考一下，发现资源非常有限，于是就只有自己动手实现了一番，也踩了几个坑。

本着开源共享的精神，分享下我实现的过程，也做一个分享记录。这就是我写 JT905 的初衷。

主线

一、协议的简单讲解（本篇）；

二、整体设计与协议实现；

三、netty简单讲解与接收端实现；

四、保存端实现；

协议

版本：JT/T 905.4-2014

1、各方关系

在建设实现 905 协议服务之前，需要明确各个系统间的关系，除非是终端承建平台，业务平台都是属于上级平台，只接收 905 协议的数据，所以建设的都是上级平台（接收端）；而只有少数的项目，例如大数据中心等才有可能会作为下级平台推送数据。各方关系如下图：

2、协议简介

在协议的 4.3 章节规定了链路流程：

下级平台登录上级平台
心跳（链路保活）
数据交互
连读断开

心跳需要注意时间规定：

4.3.1.2 链路保持流程链路保持流程应遵循以下规定:

a) 下级平台登录成功后，在与上级平台之间如果有应用业务数据包往来的情况下，不需要发送链路保持数据包；否则，下级平台应每隔 1min 发送一个链路保持请求数据包到上级平台以保持链路连接；

b) 在没有应用数据包往来的情况下，上级平台连续 3min 未收到下级平台发送的链路保持请求数据包，则认为与下级平台的连接中断，将主动断开数据传输链路；

c) 在没有应用数据包往来的情况下，下级平台连续 3min 未收到上级平台发送的链路保持应答数据包，则认为与上级平台的连接中断，将主动断开数据传输从链路。

即空闲时每分钟下级平台需要发一次心跳包，而上级平台需要回复心跳包；超时时间为3分钟。心跳包有规定，不需要携带数据体，但是依然由头标志、消息头、CRC校验码、尾标志，详见协议规定。

在 4.4.3 章节规定了协议包的结构，4.4.4 到 4.4.7 章节规定了数据的含义和长度，总体如下图：

（本图请结合协议规定的结构观看会更容易理解）

消息头和消息体中的数据，只需要按照协议的规定进行解析即可，因为协议中规定了顺序和每个数据长度，复杂度不高。

需要注意的点是：消息头中的 msg_id 是消息类型，但代表的是一级类型，其值的规定在 5.1 章节中；而在 4.5.3 章节中的动态数据业务类中又规定了 子业务类型 ，这个子业务类型是消息体的 DATA_TYPE ，其值的规定在 5.2 章节中，需要注意不要搞混了。

需要吐槽的是：4.5.3.1 章节规定的实时车辆定位消息体报文中，DATA_TYPE 在最前面，是很利于数据解析的，但是在 4.5.3.3 章节规定的车辆定位信息自动补报消息体报文中，DATA_TYPE 既然被规定在了第3位，导致需要特殊处理，放在第1位难道不好么？

CRC16-CCITT 校验码

定义：CRC即循环冗余校验码（Cyclic Redundancy Check）：是数据通信领域中最常用的一种查错校验码，其特征是信息字段和校验字段的长度可以任意选定。

我本来想深入学习一下，但是通过度娘找到的资料有限，没有真正弄明白，在这里就不过多的讲解。并且通过度娘找到的 CRC 计算实现代码有坑，不准确。无奈找到在线计算器，扒拉里面的逻辑写出了 CRC 校验码。

比较有用的博客（是C语言的实现）：C语言版CRC-16系列校验算法_我伴你度过明天的博客-优快云博客_crc16校验

在线计算器：CRC（循环冗余校验）在线计算_ip33.com

数据的转义和传输的格式

由于头标志和尾标志已经固定规定为：0x5b 和 0x5d ，在 4.4.4 章节中就规定了字符转义

4.4.4 标示位

头标识为字符 0x5b。

尾标识为字符 0x5d。

若校验码、消息头以及消息体中出现头尾标识字符，则要进行转义处理，转义规则如下：

a) 若数据内容中有出现字符 0x5b 的，需替换为字符 0x5a 紧跟字符 0x01；

b) 若数据内容中有出现字符 0x5a 的，需替换为字符 0x5a 紧跟字符 0x02；

c) 若数据内容中有出现字符 0x5d 的，需替换为字符 0x5e 紧跟字符 0x01；

d) 若数据内容中有出现字符 0x5e 的，需替换为字符 0x5e 紧跟字符 0x02。

所以实现的时候一定要注意转义。

并且从这个规定中可以看出协议中没有说明的点：数据在传输前，需要转换为16进制字符串的 byte 数组再传递，并且协议中规定的每个字段占用的 byte 数，也是指的16进制的数据，而不是原数据。