“JT/T 808 已经过时了？”——当我同时对接 808 和 GB/T 32960 时，才发现工具选错了
这个问题在车联网圈子里几乎每年都要吵一次。做道路运输的坚持 JT/T 808，做新能源的力推 GB/T 32960。去年我接了一个混合项目：既要对接道路运输车辆，又要接入新能源车。两个协议都要支持，而且要在同一个平台上调试。
一开始我们想得简单：JT/T 808 和 GB/T 32960 各写各的解析器，各调各的设备。结果调试阶段直接崩溃。JT/T 808 用 7E 转义，GB/T 32960 用 7E 但字段定义完全不同。一个终端手机号是 12 位 BCD，一个是 18 位字符串。团队里两个人分别负责两个协议，联调时发现消息 ID 冲突、时间格式不一致、校验方式不同。
更麻烦的是，没有统一的仿真工具。JT/T 808 用一套脚本，GB/T 32960 用另一套，设备管理、报文构造、压测全是割裂的。
后来换成 JT-Simulate，才发现它同时支持 JT/T 808、JT/T 809、JT/T 1078、JT/T 905、JT/T 1045、JT/T 1253、GB/T 32960 七种协议。报文工坊可以切换协议，设备管理可以创建不同协议的仿真设备，压测和合规检查也是统一的。
虽然不能说一个工具解决所有问题，但至少不用在多个工具之间来回倒腾。我们在这个项目里用 JT-Simulate 构造了 JT/T 808 的注册、鉴权、位置上报，也构造了 GB/T 32960 的登入、实时信息上报、补发信息上报。消息监控里 [UP] 和 [DOWN] 一目了然。
所以回到争议：JT/T 808 过时了吗？我的答案是，协议没有过时，过时的是“只学一个协议”的思维。而工具的选择，也不该被协议站队绑架。能同时支持多协议、能统一调试、能降低切换成本的工具，才是好工具。
项目地址：
GitHub：suoten/JT-Simulate
Gitee：suoten/jt-simulate
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/70050062/viewspace-3184432/ ，如需转载，请注明出处，否则将追究法律责任。
