结论：公开 CAN/DBC 数据集的核心不是「收了多少文件」，而是「每个文件能不能溯源、能不能分级、能不能再分发」。本次整理收录 2,330 个 DBC 文件副本，来自 294 个 DBC 来源集合，收录日期为 2026-10-03 并扩至 2026-10-05；其中相当一部分条目只有「研究用途」而没有明确许可证，只能离线留存，不能当成可直接商用的车型字典。.dbc 只描述 CAN 标识符、位域、缩放、单位与枚举，它不是适配保证书。
一次整理到底收了多少东西
这次收录的主体是 DBC 文件：.dbc 与 .DBC 合计 2,330 个副本，分布在 294 个 DBC 来源集合里。之所以把「文件副本数」和「来源集合数」分开记，是因为同一份定义会在不同快照里反复出现；只看文件总数会高估真实覆盖度。
DBC 之外还附带了一批原始数据，用来在信号定义之外做交叉验证：Renault Mascott 的 6 份 CAN 日志、Mitsubishi Outlander PHEV 的 11 份 CSV 抓包与 8 份 CMU 记录、Fiat Ducato X250 的 5 份 SLCAN 抓包、BMW PHEV BMS 的 7 份 CSV 日志、Volvo V50 的 3 份 CSV 抓包、RAM ProMaster 的 2 份 CAN-B 抓包，以及 Jeep/Dodge 的 3 份 ODS CAN 映射。
另一部分是 opendbc/ 的本地副本，共 119 个 .dbc，包含 model/platform 定义与品牌级 generator 源文件，随附的许可证是 MIT。来源快照之间存在文件重叠，因此目录被刻意分开保存，而不是合并成一个扁平库——分开保存是为了保住每个文件的来源路径。
| 类别 | 数量 | 说明 |
|---|---|---|
| DBC 文件副本 | 2,330 | .dbc 与 .DBC，来自 294 个来源集合 |
| opendbc 本地副本 | 119 | 相邻工作区快照，含模型/平台与品牌 generator，MIT 许可 |
| 原始 CAN 日志 / 抓包 | 数十份 | Mascott 6、Outlander PHEV 11+8、Ducato X250 5、BMW PHEV BMS 7、Volvo V50 3、ProMaster 2、Jeep/Dodge ODS 3 |
| 分析 / 转换工具 | 若干 | 抓包查看、格式转换与信号反推类工具 |
为什么同一款车会出现多个 DBC 版本
整理时最容易被误解的一点是「同车型为什么有好几份 DBC」。原因大多不是数据变多，而是来源重叠：一批 fork 里 77 个上游 DBC 与已归档文件字节完全相同，被直接省略；另一归档省略了 68 个上游重复文件与 1 个 parser 测试夹具；还有若干「仅行尾不同」的副本被判定为重复而不重复收录。
因此整理用的计数口径是字节不同（byte-distinct），而不是「文件名不同」。真正的版本差异还包括：更新的信号定义、字段增删，甚至只是一处注释错别字。每个来源条目都记录了本地文件、车型覆盖、来源 Git 修订号和许可证，这样后续才能回答「这份 DBC 到底来自哪一次提交」。
许可证决定「能不能再分发」
收录不等于可用。公开来源里许可证状态差异很大：有的是 MIT、Apache-2.0、GPL-3.0、CC BY 4.0、CC BY-SA 4.0、CC0，也有大量条目写着「未找到许可证，仅作离线研究副本」。后者可以离线分析，但不代表可以再分发给第三方，更不代表可用于商业产品。
| 许可证状态 | 可否再分发 | 整理时的处理 |
|---|---|---|
| MIT / Apache-2.0 | 可以 | 保留版权与署名声明 |
| GPL-3.0 | 可以（具传染性） | 衍生作品需沿用同协议 |
| CC BY 4.0 / CC BY-SA 4.0 | 可以（需署名 / 同协议） | 保留原作者署名 |
| CC0 1.0 | 可以 | 无附加限制 |
| 未找到许可证 | 不可以 | 仅离线研究，不重分发；部分来源仅保留发现链接 |
还有一层坑：上游仓库带 MIT，不代表其中每一份车辆定义都干净。「上游 MIT 但个别车辆定义可能另有来源或第三方权利」是明确写在质量说明里的，需要单独核查。个别来源的 LICENSE 甚至明确禁止复制，整理时只保留发现链接、不归档文件本体。
DBC 只描述信号，不保证适配
质量说明里有几条必须原样保留的边界：DBC 解码的是 CAN 标识符、位域、缩放、单位与枚举，它不构成通用适配保证，必须针对目标车辆的年款、市场、动力总成、ECU 与总线拓扑逐一核实；社区推导出的信号名与缩放往往不完整，在拿到只读抓包与独立测量之前，只能当作假设。
此外，opendbc/ 副本是一份工作区快照，其原始 Git 提交号未被记录，其他下载来源则钉住了具体修订号。整理说明也明确划出红线：本目录不包含绕过防盗器、安全访问或操纵安全关键车辆控制的说明。安全研究类数据集（如带标签注入流量的车联网数据集）虽然也是公开来源，但性质是安全研究数据集而非信号 DBC，必须在隔离、离线的轨迹上实验。
整理时留下的四条纪律
- 目录按来源分开，不按车型合并。来源路径是溯源链，合并即丢失。
- 用字节不同计数，不用文件名计数。行尾差异与上游重复要被识别并剔除。
- 许可证随文件一起记。没有许可证的只做离线研究，不进入可分发集合。
- 信号当假设，不当事实。DBC 与原始抓包并存，等待只读验证。
常见问题
有了公开 DBC 就能直接上车解码吗？
不能直接等同。DBC 只给出标识符、位域、缩放、单位与枚举的解释方式，是否匹配还要按目标车辆的年款、市场、动力总成、ECU 和总线拓扑逐一核对；社区信号在通过只读抓包与独立测量验证前只能视为假设。
为什么同一车型会出现多个 DBC 版本，哪个才对？
多数是来源重叠造成的：同一份定义在不同快照里重复出现，或仅行尾不同。整理按「字节不同」计数，并保留每个来源的 Git 修订号；真正的版本差异要看字段增删与信号定义变化，不能只看文件名。
没有许可证的 DBC 可以商用吗？
不可以。收录里明确标注「未找到许可证，仅作离线研究副本」的条目，只能离线分析，不能重分发；个别来源的 LICENSE 甚至直接禁止复制，整理时只保留发现链接、不归档文件。
DBC 数量能当作覆盖度指标吗？
不能。2,330 个文件副本里存在大量上游重复与行尾差异副本，数量会被重复计数放大；更有意义的指标是「字节不同的定义数」加上「已验证车型 / 总目标车型」的比例。
延伸阅读
- 84% 的 PID 没有公开证据：OBD 私有协议解析的现实边界 —— 同样是「公开数据缺证据」的问题，讲私有 PID 的可验证边界。
- 同一个「转向灯」在三家车厂是三种实现：车辆状态归一化的坑 —— 说明为什么同名信号在不同车厂语义不同，正是 DBC 不能通用适配的原因。
- 竞品功能点数据库：怎么量化 Car Scanner 的字段覆盖度 —— 讨论「字段覆盖度」应如何量化，与本文的去重口径互补。
- 车协议与指纹：一份 DBC 如何绑定到具体车型 —— 从指纹匹配角度补全 DBC 与车型的对应关系。
参考资料
- 项目 01 ——
car-scanner-research/public-can-dbc-datasets/README.md（收录规模、来源清单、许可证与质量说明、其他公开来源） - 项目 01 ——
car-scanner-research/public-can-dbc-datasets/opendbc/dbc/README.md（opendbc 本地副本的项目说明与生成器结构）
说明：本文为对固定素材快照的静态整理分析，未逐份打开并验证全部 DBC、未连接车辆、未验证目标车型的真实信号组合。文中所有数量、许可证与来源信息均出自源文档，标注为未验证的结论保留其原有边界。
更新记录
首次发布 2026-10-11 最近核对：2026-10-11
发表回复