sACN 两个发送端名称不同却像同一个源，怎样核对 CID

sACN源身份应看CID，不能只看Source Name或IP。两个进程复制了同一个CID时，即使名称与地址不同，也可能被按同一源追踪；相反，同名但CID不同可以是两个不同源。先把身份重复与名称重复分开，再讨论优先级。

先固定输入与适用条件

附件包含四条虚构源记录，其中两条CID相同、名称不同，另两条名称相同而CID不同。地址使用文档示例网段，不代表现场设备。这里的审计只提出冲突候选；同一源的合法多网卡观测也可能呈现同CID多地址，必须结合进程与部署关系确认。

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. 从接收记录取CID、Source Name、观测地址与时间窗口。若只拿到显示名称，需要补原始字段，不能用名称hash伪造一个CID来继续分析。

2. 按UUID标准形式归一化CID，保留原始字节来源。格式不合法与身份重复是两类问题，应分别报告，避免把文本大小写差异误当不同源。

3. 按CID分组，列出每组出现的名称和地址，再按名称分组列出不同CID。前者供身份冲突复核，后者提示界面可能难以区分。

4. 向部署方确认重复CID来自同一逻辑源多接口，还是复制配置后的独立发送进程。需要修改身份时按目标软件公开方法操作并复测，不由脚本代改真实设备。

用具体样例核对结果

合成记录alpha与beta使用同一个1111开头CID，报告将它们列入同CID多观测候选；两个都叫preview的源分别使用2222与3333开头CID，报告归为同名不同源。脚本使用UUID解析验证文本，再输出两种不同维度的分组，不凭名称或地址作最终设备身份结论。

通过条件是CID格式可解析、分组规则稳定、重复候选有部署解释。看到同CID两地址并不自动证明违规，因为可能是同一源在多接口出现；看到两条不同名称也不证明身份独立。若目标软件从镜像配置恢复后沿用了旧CID，应记录进程重启及身份生成策略，但不要把随机换名作为修复身份冲突的方法。

下载与复现

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

input和result没有客户名称或实际网络信息。现场版本可以用脱敏地址，但CID相等关系应保留，交接时说明是否脱敏以及记录窗口，避免跨天记录被误合并成同时冲突。

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

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

对接下一步与一级来源

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

• source结构分开CID与name。
• 2.0.2实现E1.31-2018。

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