sACN Universe 256 应订阅哪个 IPv4 组：怎样用边界值核对地址

sACN的IPv4多播组可由Universe的高低字节计算，Universe 256对应239.255.1.0，不是把256硬塞进最后一个八位字段。先验证Universe有效范围，再分解整数；不要以IP地址字符串能被拼出来就认为配置有效。

先固定输入与适用条件

本题是E1.31-2018兼容的IPv4地址核对，并不说明该版本只有IPv4，也不涉及交换机加入组或网络变更。输入覆盖1、255、256、63999以及非法边界0、64000。端口、网卡和路由是否正确是另一个层面的证据，本例只输出应有组地址。

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. 把Universe按整数读取，拒绝浮点、小数文本及超范围值。不要对64000简单取低十六位后继续生成地址，那会掩盖配置错误。

2. 用整除256取得高字节，对256取余取得低字节，固定前缀239.255。255到256是最容易漏测的进位边界。

3. 为每项保存原始Universe、两个字节和最终地址，再做逆向计算，确认恢复值与输入一致。地址字符串正确不代表接收端已经订阅。

4. 把计算结果与实际接收程序的Universe配置和网络证据比较。需要现场排查时另取对应接口的组成员与流量记录，不把离线地址表当作网络连通证明。

用具体样例核对结果

Universe 1得到239.255.0.1，255得到239.255.0.255，256得到239.255.1.0，63999得到239.255.249.255。附件脚本使用IPv4地址解析器检查字符串，并把0与64000列为拒绝输入；整个过程没有发出多播流，也没有改变本机组成员。

通过条件是范围、进位和往返计算都正确，且实际项目使用的是这里限定的IPv4路径。若同一发送端涉及多个Universe，不能只订阅第一项就宣称整套灯光接通。若实际采用IPv6，应按目标版本的IPv6组地址规则另建证据，不把IPv4结果套到另一地址族；软件版本与IP族要一起记录。

下载与复现

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

下载结果是有具体边界值的地址清单，可作为配置核查输入。现场交付应追加网卡身份、订阅观察和实际流量，而不是在本表“计算通过”旁直接勾选“设备在线”。

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

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

对接下一步与一级来源

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

• Universe有效范围。
• 固定2.0.2的IPv4多播映射。

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