4、固定长度拆包法：定义固定报文长度，不足补位，实现拆包。
聊到拆包，很多新手第一反应就是「加个长度头」。这当然没错，但今天我想先聊聊另一种思路——固定长度拆包法。
说白了，就是通信双方约定好：每个报文都是 N 个字节。发送方如果数据不够，就补位填满；接收方每次只读 N 个字节，读完一个就是一个完整的包。
你可能会问：「这方法是不是太死板了？」嗯，我当年也这么想。直到我在一个嵌入式项目里，遇到一个内存只有 2KB 的传感器设备……
4.1 固定长度拆包的核心思想
固定长度拆包法，本质上是一种空间换时间的策略。
- 约定长度：双方协商一个固定值，比如 1024 字节。
- 发送方：数据不足 1024 字节时，用特定字符（比如 '\0' 或空格）填充到 1024 字节。
- 接收方：每次从缓冲区读取 1024 字节，直接解析。
这样做的好处很明显：解析逻辑极其简单。没有长度头，没有分隔符，不需要状态机。你想想看，对于资源受限的设备，这简直是福音。
适用场景：物联网传感器上报、金融交易报文（如 FIX 协议中的固定字段）、老旧系统对接。
4.2 我踩过的坑：补位字符的选择
我曾经在一个智能水表项目里，用了 '\0' 做补位。结果呢？水表上报的数据里，某个字段恰好是 0x00，接收端直接截断了字符串……
所以，补位字符一定要选对。我个人习惯用空格（0x20）或者自定义的填充字节（比如 0xFF）。如果你传输的是二进制数据，千万别用 '\0'。
| 补位字符 | 优点 | 缺点 | 推荐场景 |
|---|---|---|---|
| '\0' (0x00) | 字符串友好 | 二进制数据中可能误判 | 纯文本协议 |
| 空格 (0x20) | 可视化友好 | 占用空间 | HTTP 类文本协议 |
| 0xFF | 二进制安全 | 不直观 | 二进制协议 |
4.3 实战：Python 实现固定长度拆包
下面我写一个简单的例子。假设我们约定每个报文固定 8 字节，不足补空格。
import socket
# 固定报文长度
FIXED_LENGTH = 8
# 补位字符
PAD_CHAR = b' '
def pack_message(data: bytes) -> bytes:
"""打包：数据不足补位，超出截断"""
if len(data) > FIXED_LENGTH:
# 我建议这里记录日志，避免静默截断
print(f"[WARN] 数据长度 {len(data)} 超过固定长度 {FIXED_LENGTH}，将被截断")
return data[:FIXED_LENGTH]
return data.ljust(FIXED_LENGTH, PAD_CHAR)
def unpack_message(buffer: bytes) -> list:
"""拆包：按固定长度切分，去除补位"""
packets = []
# 按固定长度切分
for i in range(0, len(buffer), FIXED_LENGTH):
chunk = buffer[i:i+FIXED_LENGTH]
if len(chunk) < FIXED_LENGTH:
# 不完整的包，留到下次处理
break
# 去除补位字符（strip 会去掉两端的空格）
packets.append(chunk.rstrip(PAD_CHAR))
return packets
# 模拟粘包场景
data1 = b"hello"
data2 = b"world!"
data3 = b"hi"
# 发送方连续发送
stream = pack_message(data1) + pack_message(data2) + pack_message(data3)
print(f"发送的字节流: {stream}")
# 接收方拆包
received = unpack_message(stream)
for pkt in received:
print(f"拆出的包: {pkt}")
小技巧：实际项目中，我习惯在接收缓冲区里维护一个偏移量。每次拆包后更新偏移量，避免重复解析。
4.4 固定长度拆包的优缺点
任何技术都有两面性。固定长度拆包法也不例外。
- 优点：
- 解析逻辑极简，CPU 开销低
- 不需要状态机，不容易出错
- 非常适合硬件实现（FPGA、单片机）
- 缺点：
- 带宽浪费：即使只发 1 字节，也要填满固定长度
- 灵活性差：报文长度变化时，需要重新协商
- 补位字符可能和真实数据冲突
避坑指南：我曾经在一个项目中，把固定长度设成了 4096 字节。结果设备上报频率高，带宽全被补位字符占满了。后来改成了 128 字节，配合分包机制才解决问题。所以，固定长度不是越大越好，要根据实际数据分布来定。
4.5 知识体系：固定长度拆包的核心逻辑
下面我用一张 SVG 图，把整个流程串起来。你一看就明白了。
4.6 什么时候该用固定长度拆包？
说实话，现在很多互联网项目已经很少用纯固定长度了。但我觉得，它依然有不可替代的价值。
- 嵌入式设备：MCU 资源有限，固定长度解析几乎不消耗额外内存。
- 高频交易：每微秒都很宝贵，固定长度省去了解析长度头的开销。
- 老旧系统升级：有些 20 年前的协议就是固定长度，你改不了，只能适配。
我记得有一次，帮一个工厂调试 PLC 数据采集。PLC 那边死活只发固定 32 字节的报文，多一个字节都不行。我当时就想，嗯，固定长度拆包法，就是为这种场景准备的。
我的建议：如果你在设计新协议，优先考虑「长度头+变长体」的方式。但如果你的数据包长度变化不大（比如 GPS 坐标、传感器读数），固定长度反而更省心。
好了，固定长度拆包法就聊到这里。下一节我们聊聊另一种经典方案——分隔符拆包法。到时候我会分享一个用换行符拆包时踩过的坑，保证让你印象深刻。