前年接了一个道路运输平台的项目，需要解析 JT/T 808-2019 的位置上报报文。我当时的想法很简单：协议文档又不复杂，自己写一个解析器，可控、可定制、不依赖第三方。
于是我花了 3 天，写了转义处理、校验码计算、BCD 解码、大小端转换，还写了一套单元测试。本地跑了几十条构造报文，全部通过。我当时觉得自己挺牛。
然后真实终端接进来了。
第一条报文就把我的解析器干崩了。终端手机号解析出来是乱码。我查了半天，发现我的 BCD 解码写的是“高低位 nibble 互换”，但这家终端厂商的 BCD 编码顺序和我的假设正好相反。我改了一版，通过了。
第二条报文，校验码不对。我又查了半天，发现我的转义处理在遇到 0x7E 和 0x7D 时，只处理了消息体，没有处理消息头。改完，通过了。
第三条报文，位置附加信息解析越界。因为厂商在附加信息里塞了一个协议文档没定义的字段，我的解析器直接按固定长度读，读飞了。
三天写了 1200 行代码，接了 5 家终端厂商，改了 7 版。我开始怀疑人生。
后来同事丢给我一个工具，叫 JT-Simulate。我抱着试试看的心态，把那条把我打崩的报文 Hex 粘进它的报文工坊，点了一下「分析」。秒出结果，字段一项项列得清清楚楚，纬度、经度、速度、方向、时间、报警标志，全部解析正确。
我不服气，又把我踩过坑的几条报文全丢进去。包括那个带未定义附加字段的，它也没崩，直接跳过了未知字段。
然后我用它的合规检查跑了一遍。纬度范围、经度范围、速度范围、方向范围、时间格式，一项项给我标出来。我那条“速度 3200 km/h”的报文，问题一目了然。
再然后，我用它的 Fuzz 测试生成了 19 个异常用例：空帧、超长帧、非法字段、随机突变。我的解析器在第三个用例就崩了。JT-Simulate 自己跑完了全部 19 个，没有崩溃。
那天晚上我想了很久。我花 3 天写的解析器，功能不如一个开源工具 10 分钟能干的事。我的时间到底花在了哪里？花在了重复造轮子上。
我不是说解析器不该自己写。如果你的业务需要深度定制、需要和内部系统深度集成，自己写没问题。但如果你的目标只是“把报文解析出来”，那自己写就是浪费生命。
争议留给你们： 协议解析器，到底该自己写，还是用现成工具？欢迎在评论区吵。
项目地址：
GitHub：suoten/JT-Simulate
Gitee：suoten/jt-simulate
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/70050062/viewspace-3185163/ ，如需转载，请注明出处，否则将追究法律责任。
