OSC 走 TCP 时半包和两包连在一起，怎样按长度前缀还原

OSC通过TCP传输时，需要按约定的四字节长度前缀重建包边界，不能假定一次recv就得到一个OSC包。半个长度字段、一个包分多次到达、两个包连在一起都属于正常字节流情况；应用必须先缓存，再按长度消费。

先固定输入与适用条件

本篇限定OSC 1.0说明的int32长度前缀约定，输入是离线分片数组，并不连接任何端口。与其他使用SLIP等分帧约定的应用对接时，应先确认双方实际协议，不能把本例直接强套。长度校验要在分配大缓冲之前执行，最大包长属于本地可配置约束。

本篇的OSC内容限定1.0规范，MIDI内容限定1.0字节消息；未涉及MIDI 2.0的UMP编码。桥接动作属于接收应用约定，不能从协议格式推断产品已经支持。

按字段与边界执行

1. 维护持久缓冲，把收到的字节追加进去。少于四字节时继续等待，不读取残缺长度，也不因为暂时没形成包就清空缓存。

2. 取得四字节后按大端有符号整数读包长，拒绝非正数、非四倍数与超过上限的值。本例上限4096字节只是离线解析器配置。

3. 缓冲未达到四加包长时保留已有内容；达到后只消费这一个包，再循环检查余下数据，直到没有完整包。

4. 连接结束仍有残留时报告不完整输入，记录预期长度与现有字节。不要把残留拼到下一次新连接中，也不以补零方式伪造完整报文。

用具体样例核对结果

附件把两条OSC消息组成字节流后，按1、3、7、2等不整齐长度切片。解析器连续接收这些分片，最后还原两条与原始hex完全一致的包，缓存为空。反例分别使用负长度、长度3及长度8192，均在读取负载前拒绝。脚本没有建立TCP连接，测试的是流重组逻辑而不是传输可达性。

判断应同时看包数量、每包原始字节和最终残留；只验证“解析出两条”可能漏掉尾部污染。一个包完整到达后还要独立检查OSC内部类型与对齐，长度前缀正确不代表内容有效。若实际对接双方用了不同分帧方法，应修正契约，反复调TCP接收缓冲大小不会把协议差异消除。

下载与复现

analyze.py、input.json、result.json。

输入保存消息地址和切片长度，结果列出重建包与拒绝原因。交接时附实际分帧约定、最大包长和连接结束策略；UDP对应天然数据报边界，不应额外套用这里的TCP前缀。

把输入与脚本保存到同一个本地目录后执行 python analyze.py，脚本只读取输入、计算并重写同目录的结果文件。先保留原始附件副本，再将自己的脱敏输入另存为新版本，记录输入摘要与执行日期；不要把合成字段覆盖成看似真实的现场日志。

已用 Python 3.12.4 实际运行附件算法并检查断言。结果来自同目录合成输入；没有接入真实NDI源、控制器、灯具、接收卡或LED屏，不能据此填写现场验收通过。

对接下一步与一级来源

基础背景可看OSC（Open Sound Control）协议速查。相关流程收在展厅中控专题；需要项目对接时，带上本文输入及结果向SoftControl核对实际能力。

• 1.0在TCP流上的int32长度前缀。

一级来源核对日期：2026-10-24。原始协议规则、本文原创运算和目标系统行为应分别留证；附件计算正确，不等于设备已经按该参数工作。