JT808协议里有一条规则，写在标准文档最不起眼的位置：

消息体中如果出现0x7e，需要转义为0x7d 0x02；出现0x7d，转义为0x7d 0x01。

看起来很简单。我第一次实现的时候，也是这么想的。

Bug是怎么出现的

去年做一个运输车辆平台，JT808解析跑了一段时间都正常。直到接了某厂商的一批终端，问题来了：大约5%的位置上报消息解析失败，校验码不匹配。

抓包看原始数据，帧头和帧尾的0x7e都在，校验码也对得上。但解析出来的消息体内容是乱的。

我把转义还原的代码翻来覆去看了几遍，逻辑没问题：遍历字节，遇到0x7d就看下一个字节，如果是0x01还原成0x7d，0x02还原成0x7e。

代码长这样：

func Unescape(data []byte) []byte {
var out []byte
for i := 0; i < len(data); i++ {
if data[i] == 0x7d && i+1 < len(data) {
if data[i+1] == 0x01 {
out = append(out, 0x7d)
i++
continue
}
if data[i+1] == 0x02 {
out = append(out, 0x7e)
i++
continue
}
}
out = append(out, data[i])
}
return out
}
逻辑上，这没问题。但为什么解析失败？

三天排查过程

第一天，我怀疑是终端发送数据有误。联系厂商，厂商说设备没问题，是平台解析错误。扯皮了半天，没结果。

第二天，我把失败的那几条原始数据单独拿出来，手动做转义还原，发现还原出来的数据长度不对。原始消息体属性里的长度是42字节，但还原后只有40字节。

少了2个字节。

哪里少的？我逐字节对比，发现有两个相邻的0x7d 0x01，被还原成了一个0x7d，但后一个0x01被吃掉了。

等等，不对。0x7d 0x01应该还原成0x7d，后面的0x01是独立的字节，不应该被吃掉。

我重新看代码，发现问题了：

if data[i+1] == 0x01 {
out = append(out, 0x7d)
i++ // 这里跳过了下一个字节
continue
}
当遇到0x7d 0x01时，还原成0x7d，然后i++跳过下一个字节。但如果下一个字节本身也是数据的一部分，就被跳过了。

举个例子：原始数据里有 0x7d 0x01 0x7d 0x01。按照标准，第一个0x7d 0x01还原成0x7d，第二个0x7d 0x01也还原成0x7d。但我的代码在处理第一个0x7d 0x01后，i++跳到了第二个0x7d 0x01的位置，继续循环时i又加1，直接跳过了第二个0x7d。

结果就是：还原后的数据少了后面的0x7d。

正确的实现

修复方式很简单：在跳过下一个字节之前，先记录当前字节，然后i只加1（因为for循环本身会加1）。

func Unescape(data []byte) []byte {
var out []byte
for i := 0; i < len(data); i++ {
if data[i] == 0x7d && i+1 < len(data) {
if data[i+1] == 0x01 {
out = append(out, 0x7d)
i++
continue
}
if data[i+1] == 0x02 {
out = append(out, 0x7e)
i++
continue
}
}
out = append(out, data[i])
}
return out
}
看起来和之前一样？其实关键在for循环的条件。Go的for循环每次迭代后自动i++。当我们在循环体内执行i++时，实际上跳过了两个字节。

正确的做法是：如果当前字节是0x7d，并且下一个字节是0x01或0x02，那么消费两个字节，还原成一个字节。但i应该只加1，而不是加2。

我之前的代码在i++之后，for循环又执行一次i++，导致多跳了一个字节。

修复后的代码应该是：
func Unescape(data []byte) []byte {
var out []byte
i := 0
for i < len(data) {
if data[i] == 0x7d && i+1 < len(data) {
if data[i+1] == 0x01 {
out = append(out, 0x7d)
i += 2
continue
}
if data[i+1] == 0x02 {
out = append(out, 0x7e)
i += 2
continue
}
}
out = append(out, data[i])
i++
}
return out
}
用i += 2明确表示消费了两个字节，就不会出现多跳的问题。

这个Bug给我的启示

转义逻辑看起来简单，但在边界条件下容易出错。特别是当转义字符连续出现、或者转义字符出现在数据末尾时，必须仔细处理。

JTE在pkg/jt808的转义实现中，专门写了单元测试覆盖这些边界场景。如果你也在写JT808解析，建议至少测试以下几种情况：

连续多个0x7d 0x01

0x7d 0x01紧跟着0x7d 0x02

数据以0x7d结尾

数据以0x7d 0x01结尾

一个小小的转义Bug，让我排查了三天。你猜我第三天晚上在想什么？不是愤怒，是庆幸——庆幸问题出在开发环境，不是生产环境。如果是生产环境，5%的位置数据丢失，客户早就炸了。

项目仓库：

Gitee：suoten/jt-engine
GitHub：suoten/JTEngine



消息体中如果出现0x7e，需要转义为0x7d 0x02；出现0x7d，转义为0x7d 0x01。

JT808转义处理的一个致命Bug，让我排查了三天

编程语言

网络与通信

开发工具

JT808转义解析Bug源于循环体内i++与for循环自动递增叠加，导致连续0x7d0x01时跳过字节。修复需用i+=2明确消费两个字节，并覆盖连续转义、末尾转义等边界测试。该问题警示转义逻辑需严谨处理边界条件，避免数据丢失。

数据丢失

单元测试

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

JT808转义处理的一个致命Bug，让我排查了三天-腾讯云开发者社区-腾讯云

JT808转义处理的一个致命Bug，让我排查了三天

JT808转义处理的一个致命Bug，让我排查了三天

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐