OSC 字符串后参数错位，怎样逐字节检查四字节补齐

OSC参数从第二项开始错位，常见原因是漏算字符串终止字节或blob尾部补齐。每段都应落在四字节边界；blob长度字段只表示有效数据字节，不包含它自己的四字节长度字段，也不包含尾部padding。

先固定输入与适用条件

附件限定OSC 1.0的ASCII字符串，使用abc、三个二进制字节及整数9作为三个参数。地址和类型标签也各自是OSC-string，需要独立补齐。这里的空字节是结构的一部分，不能在运输或日志预处理中全部删除；看见很多00不代表报文多发了无用数据。

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

按字段与边界执行

1. 从地址开始顺序定位，找到终止NUL后，向上补齐到四字节边界，再读类型标签。不要从可见字符长度直接跳到第一个参数。

2. 对字符串参数再次执行终止加补齐。abc有三个可见字符，加一个终止字节后刚好四字节，不需要额外再补四字节。

3. 读取blob的四字节大端长度3，只消费三个有效数据字节，再跳过一个padding。下一个整数应从新的四字节边界开始。

4. 用正确包和把blob长度写成4的反例核对解析报告。反例可能仍可被解析成另一份数据，因此也必须检查有效内容和接口约定，不能只看解析器不报错。

用具体样例核对结果

本例地址/sample占8字节，类型标签,sbi连同终止与补齐占8字节。参数abc占4字节，blob的长度字段与数据及padding共8字节，整数9占4字节，总长32字节。脚本逐段输出起点与结束点，断言末项整数仍等于9；这样可以看见错位发生在结构的哪一段。

正确结果应能从第一个字节走到包尾，且每个结构起点都为四的倍数。若日志中的字符串含内嵌NUL，应检查它是不是提前结束了OSC-string；不能把任意字节都当普通文字。对中文等非ASCII文本，需要双方明确采用的扩展编码约定，本篇不会用UTF-8示例反过来改写OSC 1.0的原子字符串定义。

下载与复现

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

下载的输入含原始blob hex，解析器生成整包和段边界表，不依赖第三方OSC库。交接时把边界表与原始hex并列提供，避免只发一串无法辨认padding位置的十六进制。

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

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

对接下一步与一级来源

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

• OSC-string与blob的终止、长度、补齐。

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