ArtDmx 抓包有数据但被丢弃，怎样核对混合字节序与长度

ArtDmx不是所有字段都用同一种字节序。OpCode低字节在前，协议版本及长度字段按各自高低字段排列；如果统一按一种整数打包，很可能生成看似有数据但不被识别的包。应先核对固定头、字段序和总长度，再讨论灯光输出。

先固定输入与适用条件

本例固定四个槽位10、20、30、40，Port-Address为1，协议版本字段为14。仅在本地生成UDP负载字节，不创建socket。ArtDmx数据长度为二到五百一十二之间的偶数；它与ArtNzs等其他包型的长度规则不同，不能从相邻表格直接抄过来。

Art-Net字段按官方4版Release V1.4、Revision 1.4dp核对。sACN例子限定ETC sACN v2.0.2所声明的E1.31-2018兼容字段及IPv4样本；现行ESTA目录已列E1.31-2025，2018亦含IPv6。本文不声称旧库实现新版全部功能。

按字段与边界执行

1. 核对前八字节为Art-Net标识及NUL，再按低字节在前解释OpCode。ArtDmx的0x5000应在字节中显示00 50，交换为50 00会变成另一数值。

2. 分别读取协议版本、Sequence、Physical、SubUni和Net。Physical是来源物理输入信息，不要把它当作完整Universe替代字段。

3. 从第十六与十七字节读取高低长度，核对范围、偶数及负载实际字节数。短包或声明长度与实际不一致，应在解析报告中明确标记。

4. 用正确包、交换OpCode包和错误Length包做离线对照。真实接收器是否接受还需要目标设备证据，不能只因本地解析器通过就声称协议认证。

用具体样例核对结果

正确负载总长为18加4，即22字节；长度字段为00 04。附件错误例把OpCode交换后解析为0x0050，另一个把长度写成4的高字节后变成1024，均被本地校验拒绝。所有槽位值都只是合成数字，脚本没有发送灯光指令。

通过条件包括固定头正确、包型正确、字段版本可解释、长度与有效数据一致。仅凭Wireshark把包标成Art-Net还不够，具体包型及槽位范围仍可能有问题。也不要在长度错误时直接补到512字节来“让灯亮”，应先确认发送端本来想表达多少槽位及接收端的通道用途，避免掩盖编码错误。

下载与复现

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

input保留槽位与地址，result输出三份完整hex和每项检查结果。交接时可以只分享脱敏负载而不含真实网络地址；现场输出证据需另采，本文不包含任何设备执行效果。

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

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

对接下一步与一级来源

基础背景可看Art-Net 灯光控制协议速查（DMX over Ethernet）。相关流程收在展厅中控专题；需要项目对接时，带上本文输入及结果向SoftControl核对实际能力。

• ArtDmx字段的字节序、长度和协议版本。

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