王炸——自研 DWG 图纸解析

副标题：摆脱高授权与版本锁死，把图纸数据握在自己手里

---

有位客户曾想采购我们的宇星在线CAD 产品，方案谈到最后，卡在一件很具体的事上：DWG 相关能力用了某类商业授权，对方的合规与采购链路过不去，这单只能作罢。

那之后我才下决心把 DWG 解析走自研。借助 AI，前前后后大约一个月；主要用 Cursor，总花费大概一千元量级——换来的不是「省了多少钱」这种账，而是产品还能不能按自己的节奏报价、交付、被采购。

下面写的背景与技术，多半是从这件事里长出来的：不把命门押在别人的授权条款上。

---

在工程设计、制造与基础设施领域，CAD 图纸至今仍是事实上的交付标准。把图纸数据做进产品里，也不止我一家会遇到授权与版本问题。真正决定你能不能把业务做深的，往往不是「能不能打开一张图」，而是系统能否稳定、完整、可追溯地理解图纸里的对象与关系——这就是 DWG 解析能力成为「基础设施」的原因。

下文先从三条行业现实谈起，说明为什么自研 DWG 解析不是口号，而是面向成本、版本与国产化交付的结构性选择；再按本仓库实现梳理技术路径；随后单设一章做 ODA / LibreDWG / 自研 的竞品与路线对照；最后列举可落地场景并收束结语，供同行与甲方读者参考。

---

一、背景：行业为什么卡在 DWG 上

1. ODA：能力成熟，但授权与路线约束明显

Open Design Alliance（ODA）相关技术栈在工业软件生态里覆盖广、成熟度高，但对产品与团队而言，现实约束同样清晰：

• 授权费用高昂：按产品形态、分发渠道、席位数等维度计费，对多端产品、SaaS、OEM 集成或大规模部署场景，成本曲线陡峭。
• 国产化与可控性要求高：在信创、关键行业与供应链审计语境下，“能集成”与“源码级可控、可审计、可持续演进”不是同一件事。外部商业授权一旦与政策、采购周期或版本策略绑定，技术路线容易被非技术因素牵制。

因此，许多团队会在战略上预留一条自主解析与自主数据链路，以降低长期不确定性。

2. LibreDWG：开源标杆，但二开与“写 DWG”仍是硬骨头

在开源侧，LibreDWG 常被视作重要选择，社区贡献值得尊重。需要先说清定位：它是 DWG 编解码库，不提供渲染——没有内置视口、画布或光栅化管线；要在产品里“看图、改图”，渲染与交互必须全部自建。若以产品级底座标准衡量，通常会再碰到两类问题：

• 二次开发与工程化成本高：对象覆盖、边界用例、文档与工具链与商业方案不在同一量级；团队需要投入大量精力补齐“从能读到能跑在生产环境”之间的鸿沟。
• 写入与高版本链条弱：业界常见现象是——对 DWG 的写入（生成/回写）往往只覆盖较低版本，高版本写入或完整兼容链条不足；而真实业务里，“只读不写”往往不够：归档回写、批处理、插件链路、与业务系统的闭环都会触及写能力与版本一致性。

一句话：开源能救命，但很难直接当“长期可演进的工业底座”。

3. 国产化趋势：从替代工具到替代“数据链路”

国产化不仅是 CAD 软件的替代，更包括图纸数据如何进入平台、如何被检索、如何被审计、如何与业务流程耦合。若缺少自主解析能力，即便上层应用国产化，仍可能在枢纽处被图纸进不来、字段出不齐、结果不可追溯卡住。

当“高授权成本 + 弱写入/版本锁死 + 国产化交付”三件事叠加，自研 DWG 解析就从可选项变成了许多团队的必答题。

---

二、技术：代码里在解决什么、难在哪里

下面对齐本仓库自研解析模块及其与上下游的衔接，说明自研栈实际承担的工作与主要难点；不展开教科书式的 DWG 史，只回答两件事：产品链路里哪一段被接上了，以及为什么读出来不等于能写回去、写出来还要被别的库认可。

下图仍是「读入 → 共享 IR → 写出」主链路；实现上 IR 落在内存中的文档对象图，产品侧几何与业务仍落在既有业务图纸模型上，由桥接层把两者对齐。

实现层大致关系如下（与代码结构一致）：对外适配层负责打开与保存；读取器经文档装配器把段流收成内存中的文档对象图，再经读结果桥接写入业务侧的图纸数据库；保存路径则从同一份对象图交给写入器序列化回二进制。

1. 读路径：多版本文件头与段流 → 文档对象图 → 业务图纸库

在解决什么

• 不依赖宿主 AutoCAD / ODA，把磁盘上的 DWG 变成产品里已经在用的显示与业务对象（图层、线型、块、实体等），上层地图、审图、业务字段映射不用改数据模型。
• 解码完成后仍持有一份完整文档对象图供后续落盘，而不是只生成“看一眼就丢”的临时几何。

实现要点

• 打开文件时读入全文件，经读取器解析：先按代际解析文件头，再依次处理头信息、对象体、句柄等逻辑段，对象解码层按版本逐位读字段。
• 装配器把分散对象收成一张可遍历的文档图；桥接层把头信息、符号表、实体回填进业务图纸库，完成“进产品库”的最后一步。

难点

• 同一套逻辑要扛多个代际：对象解码里大量按版本分叉的条件，漏一处往往表现为“能打开但某类实体缺属性”或某段直接解析失败。
• 流与压缩：不同版本段组织、校验与解压方式不同；读错一个字节，后面句柄与对象偏移会级联错位，排查要回到段边界与原始 hex，而不是只看上层几何。

2. 写路径：文档对象图 → 写入器 → 被外部工具认可的 DWG

在解决什么

• 支持 读—改—存 闭环：保存时在需要时通过写回桥从业务图纸库反建文档对象图，设好目标 DWG/AutoCAD 代际版本，再由写入器写回内存并落盘。
• 目标不仅是“自己再能读”，而是 AutoCAD 生态里常见读者（含其他开源/商业解析器）不把文件判为损坏——否则归档与对外交换仍不可信。

难点（本仓库已单独成文）

• 写的难度通常高于读：对象正文之外，还有一整层 文件容器（R18 一代典型的分页、LZ77 AC18 压缩、页图/段图、固定布局的元数据区等）。这里若与参考实现差几个字节，现象往往是：ODA 勉强宽容能开、自研读段头失败、第三方开源读写库在解压阶段崩溃——表现不一致时，根因常在容器层而非某个实体画了一条线。
• 仓库内 R18 写入兼容性修复笔记记录了一次完整排障：例如文件标识长度与元数据块对齐导致页图目录地址读偏、32 字节页头字段宽度与校验顺序、整页再压缩与尾页分页、目录里应写实际落盘长度等——这类问题无法靠“调几个对象字段”蒙过去，只能与成熟参考写入端逐字段对拍，并用多读者交叉打开验证。

3. 双轨数据：为什么既要业务图纸库又要文档对象图

在解决什么

• 业务图纸库：与现有产品（地图、编辑、渲染入口）一致，避免为 DWG 再造一套业务 API。
• 文档对象图：与读、写两侧共用，保证“从文件读出的语义”和“写回文件的语义”是同一张对象图，减少两套模型手工对齐带来的隐性 bug。

难点

• 读结果桥接等任一环节字段遗漏或顺序与 DWG 句柄约定不一致，都会表现为写回文件在第三方软件里对象丢失或引用断裂；这类问题比“画布上少画一根线”更难直觉定位。

4. 与渲染、导出、WASM 产品线的衔接（同仓，不等于全自动）

在解决什么

• 文档对象图 / 业务图纸库与 WebGPU 渲染子系统、浏览器侧 WASM 画布在同一产品树内编译集成（详见仓库编译与部署说明中的模块关系），避免“解析在一套几何、画布在另一套几何”的长期分裂。
• 数据库抽象层上仍保留矢量/栅格导出的统一出口，供图纸库、服务端交互、桌面导出流程等调用；版式导出在产品里还可与既有 ODA 集成链路或渲染线程组合，与“先把 DWG 语义吃准”分工不同、可并行演进。

难点

• 解析正确性与 屏幕呈现、分页打印仍是不同子问题：坐标系、视口、块变换、线型比例等与 DWG 字段一一对应工作量大；WASM 侧还有构建体积、字体渲染依赖等工程约束。

5. 仍在持续投入的方向（实话）

• 对象与版本覆盖：读侧已按版本分叉实现大量实体族；写侧要保证目标版本下句柄段、类、字典与容器格式一致，每抬高一档交换目标都要一轮 Golden DWG + 多读者回归。
• 现网脏图：异常 xref、缺损段、非标准扩展等，需要可诊断的失败路径（日志、最小复现图档）而不是静默吞错。
• 自研解析模块当前实现重心在 DWG 二进制读写闭环；矢量/栅格版式导出在抽象接口层已对齐产品调用方式，具体实现按路线接 渲染管线或既有 ODA 转换，避免把“解析器”和“印刷级 PDF”混成一件事叙述。

---

三、竞品分析：ODA、LibreDWG 与自研

第一节已从商业授权、开源编解码与国产化交付三条线做了定性叙事；本章用一张表做横向竞品 / 路线对照，便于产品与技术负责人在同一组维度下比较差异。表内为概括性结论，签约、法务与能力边界仍以各方案现行文档与许可条款为准。

共 七个维度：授权与成本、可控性、版本支持、导出（SVG/PDF 等）、二次开发、跨平台、扩展（渲染与编辑）。

维度	ODA 路线	LibreDWG	自研 DWG 解析
授权与成本	商业授权；费用与席位、分发形态、OEM/云打包等强相关，规模化时敏感	GPL 等开源许可，无授权费；与闭源产品、SaaS 组合需单独做法务与合规评估	无第三方 DWG 授权账单；成本主要在研发、测试、运维与算力
可控性	行为与缺陷修复依赖厂商节奏与合同范围，深度审计常止于公开接口	源码全开放，可 fork、可审计、可裁剪；能力边界由社区与自研补丁共同定义	源码与数据链路在己，信创/供应链审计、定制安全策略路径相对直
版本支持	主流代际与对象类型覆盖广，读写与高版本交换整体成熟	读相对活跃；写与部分高版本/对象组合仍弱，上生产需大量自有回归	按产品定义读/写版本矩阵（如押注主流读 + 目标写版本），用自有 Golden 图档固化承诺
导出（SVG / PDF 等）	常通过 SDK/组件或合作方转换链支持多格式，能力边界随采购 SKU 变化	无渲染、无版式引擎；库只做 DWG 读写，Svg/Pdf/Png 等导出均不提供，须自建几何→矢量/栅格流水线或再接第三方	DWG 语义在自研栈闭环；版式导出走统一数据库抽象接口，产品内可与 渲染管线 或仓库内 ODA 转换链路组合；自研解析本体以二进制读写为重心
二次开发	API 与示例成熟，集成快；扩展受许可条款（静态/动态链接、分发范围等）约束	可任意改内核，但从「能编译」到「扛现网图档」工程量大，缺省商业支持	支持Java、C#、C++、TypeScript二次开发。
跨平台支持	厂商提供 Windows/Linux 等预编译与商业支持，跟授权绑定	C 库形态，易移植至 Linux/嵌入式等；宿主语言与构建需自理	支持浏览器、windows、linux、信创环境。
扩展（渲染与编辑）	视口、交互编辑、高级建模等多在 SDK / 许可包内分档提供，能力与报价 SKU 强相关	不支持渲染：LibreDWG 不包含显示与编辑能力；画布、GPU 光栅化、拾取、命令栈、Undo/Redo 等均不在库职责内，须完全自建并与解码结果对齐	IR 直驱画布：GPU 渲染、端内编辑与 DWG 读写共用同一份文档对象图；本仓库已打通 WebGPU 渲染与 WASM 画布等与解析同栈的交付路径

效果图

四、可落地的场景

• 在线查看与端内编辑：同一套文档模型驱动 GPU 画布渲染与编辑命令，DWG 打开、改图与回写/导出不必再经第二套解析或私有中转，适合 Web/WASM 穿透式审图、标批与轻量改图。
• 图纸集中入库与检索：按项目、专业、图层、关键字等维度快速定位内容，减少“找图两小时”。
• 审图与协同：结构化字段支撑流程节点，而不是完全依赖人工对图与截图沟通。
• 归档与审计：版本链路与解析结果可追溯，满足交付与复盘要求。
• 与业务系统对接：与项目、档案、算量、构件库等系统做字段映射，形成数据闭环。

---