DWG 文件是 AutoCAD 的原生图纸格式工程、建筑、机械领域几乎每天都在跟它打交道。但凡是尝试用 Python 直接去读 DWG 的人大概率都经历过同一个场景装了个库跑了一行代码然后被一堆二进制乱码或者一句“不支持该版本”怼回来。标题里这个“python dwg 文件 读取”的实例本质上要解决的就是一件事——怎么用 Python 把 DWG 里的图形数据图层、实体、坐标、块信息稳定地取出来而不是对着二进制文件干瞪眼。这篇内容适合两类人一类是刚接触工程数据处理、想批量提取图纸信息的新手另一类是已经写过脚本、但被版本兼容和格式转换卡住的老手。我会把 DWG 读取的底层逻辑、库的选型取舍、完整可跑的代码链路以及我实际踩过的那些坑一次性讲透。1. 先搞清楚 DWG 到底难在哪别急着写代码很多人上手第一反应是pip install一个名字里带 dwg 的库然后import就完事。结果十有八九是失败的。这不是你代码写错了而是 DWG 这个格式本身的封闭性决定的。在动手之前把下面这几件事想明白能省掉你至少半天的折腾。1.1 DWG 是二进制私有格式不是文本也不是开放标准DWG 从诞生起就是 Autodesk 的私有二进制格式它的内部结构对象字典、句柄表、段表、压缩方式并没有一份完全公开、权威的规范文档。相比之下DXF 是 Autodesk 官方公开的交换格式本质上是带结构标记的文本或二进制变体解析起来友好得多。这就导致一个现实纯 Python 从零解析 DWG几乎是不现实的因为你要逆向的东西太多而且每个版本R14、2000、2004、2007、2010、2013、2018的内部编码还不一样。所以业界通行的做法不是“直接解析 DWG”而是“先把 DWG 转成可解析的中间格式再解析中间格式”。这个中间格式通常就是 DXF。理解这一点你就明白为什么很多所谓“Python 读取 DWG”的实例代码里第一步其实是调用外部转换器。提示如果你看到某个教程号称纯 Python 一行代码读 DWG先看它底层是不是偷偷依赖了 ODAOpen Design Alliance的转换组件或者某个商业 SDK。纯靠 Python 标准库是做不到的。1.2 版本兼容是第一个拦路虎DWG 的版本号藏在文件头的前 6 个字节里形如AC1015对应 2000、AC10182004、AC10212007、AC10242010、AC10272013、AC10322018。不同版本的压缩算法和对象编码差异很大。一个只支持到 2007 的解析库遇到 2018 的文件会直接报错或者读出垃圾数据。我在实际项目里遇到过最典型的情况客户给的一批图纸是 2018 格式本地装的老版本转换工具读不了脚本跑一半全挂。后来统一在转换前先读文件头判断版本再决定走哪条转换路径才把问题摁住。判断版本的代码很简单def get_dwg_version(file_path): with open(file_path, rb) as f: header f.read(6) version_map { bAC1015: 2000, bAC1018: 2004, bAC1021: 2007, bAC1024: 2010, bAC1027: 2013, bAC1032: 2018, } return version_map.get(header, unknown)这段代码不依赖任何第三方库先跑一遍你就能知道手里的文件到底能不能被目标工具处理避免后面白忙活。1.3 你要的到底是“图形”还是“数据”在写代码前必须明确需求边界。DWG 里能提取的东西分好几个层次最浅的是图层列表和实体类型统计往深一层是每个实体的几何坐标直线端点、圆心半径、多段线顶点再深是块参照的嵌套关系、属性文字、扩展数据XData。不同层次对工具的要求完全不同。如果你的目标只是“统计这张图有多少个图层、每层有多少个圆”那用轻量的 DXF 解析库就够了如果你要还原完整的几何拓扑、做碰撞检测或者生成加工路径那就得用更重的 CAD 内核级工具。先定需求再选工具这个顺序反了后面全是返工。2. 工具选型三条路线各有各的适用场景Python 生态里处理 DWG 的路线大致分三类我把它们的优缺点和适用场景列清楚你对号入座就行。这里不吹某个库“最好”因为选型永远取决于你的具体约束。2.1 路线一ezdxf 解析 DXF推荐作为主力方案ezdxf是目前 Python 里最成熟的 DXF 读写库纯 Python 实现文档齐全社区活跃。它的定位很明确只处理 DXF不碰 DWG。所以用它读 DWG 的前提是先把 DWG 转成 DXF。它的优势在于能读能写、支持图层/块/实体/标注的完整对象模型、能拿到实体的精确几何数据、还能做简单的渲染导出。对于绝大多数“提取图纸信息”的需求ezdxf 完全够用。缺点是它不负责 DWG 转换转换那一步得你自己解决。安装很直接pip install ezdxf读一个 DXF 并遍历实体的最小示例import ezdxf doc ezdxf.readfile(sample.dxf) msp doc.modelspace() for entity in msp: print(entity.dxftype(), entity.dxf.layer)这段代码跑通说明你的 DXF 解析链路是通的。接下来所有复杂逻辑都建立在这个基础上。2.2 路线二调用 ODA File Converter 做格式转换ODAOpen Design Alliance提供的 File Converter 是一个免费的命令行工具能把 DWG 在各版本之间互转也能转成 DXF。它是目前最靠谱的免费 DWG 转换方案支持到较新的版本。用法是命令行调用Python 里用subprocess包一层就行。它的价值在于转换质量高、版本覆盖全、批量处理方便。缺点是需要单独安装这个工具它不在 pip 里而且它的命令行参数有点绕路径里有中文或空格时容易出问题。我一般会在调用前把路径规范化并且给转换过程加超时保护。2.3 路线三商业 SDK 或 CAD 内核重需求才上如果你的需求涉及复杂实体解析、精确的几何运算、或者要处理大量异常图纸那前面两条路线可能会在边角案例上翻车。这时候考虑商业 CAD 内核比如某些提供 Python 绑定的 CAD 组件是合理的。它们能直接读 DWG几何精度和兼容性都有保障。但代价也明显授权成本高、部署复杂、学习曲线陡。除非你的业务真的靠这个吃饭否则不建议一上来就上重武器。我见过不少团队为了“读个图层”去接商业 SDK最后发现 ezdxf 加转换器就解决了纯属杀鸡用牛刀。下面这张表帮你快速决策路线能否直接读 DWG成本上手难度适用场景ezdxf 转换器需先转 DXF免费低信息提取、批量统计、轻量几何ODA File Converter转换后读免费中版本兼容、批量转换商业 CAD 内核可直接读高高复杂几何、高精度、异常图纸3. 完整链路实操从 DWG 到结构化数据这一节是核心我把从拿到一个 DWG 文件到最终输出结构化数据的完整链路拆开讲。每一步都给出可复现的代码和背后的取舍理由你照着改改就能用在自己的项目里。3.1 第一步版本探测与预处理前面已经给了版本探测的代码。这里补充一个实操细节批量处理时先做一轮版本扫描把文件按版本分组再针对每组走对应的转换参数。这样比逐个文件试错效率高得多也能提前发现“无法识别版本”的异常文件避免它们卡在批处理中间。预处理还包括路径规范化。Windows 下路径里的反斜杠和中文经常让subprocess调用失败我习惯统一转成绝对路径并且用列表形式传参而不是拼字符串import os def normalize_path(p): return os.path.abspath(p).replace(\\, /)别小看这一步路径问题是我在批处理脚本里遇到频率最高的失败原因之一。3.2 第二步DWG 转 DXF 的稳定调用方式用 ODA File Converter 转换时命令行参数大致是输入目录、输出目录、输出格式、版本、递归标志这一串。不同版本的参数顺序略有差异建议先手动在命令行跑通一次确认参数顺序再固化到脚本里。调用时我通常会加三样东西超时控制、返回码检查、输出文件存在性校验。因为转换器偶尔会“静默失败”——返回码是 0但输出目录里啥也没有。代码骨架如下import subprocess import os def convert_dwg_to_dxf(input_path, output_dir, converter_exe, timeout120): input_path normalize_path(input_path) output_dir normalize_path(output_dir) cmd [ converter_exe, input_path, output_dir, ACAD2018, DXF, 0, 1, *.DWG, ] try: result subprocess.run(cmd, capture_outputTrue, timeouttimeout) except subprocess.TimeoutExpired: return None, timeout if result.returncode ! 0: return None, freturncode{result.returncode} base os.path.splitext(os.path.basename(input_path))[0] expected os.path.join(output_dir, base .dxf) if not os.path.exists(expected): return None, output_missing return expected, ok这段代码的关键在于不信任返回码一定要校验输出文件是否真的生成。这个习惯帮我拦下过大量“看起来成功、实际没转出来”的坑。3.3 第三步用 ezdxf 提取图层与实体信息拿到 DXF 之后ezdxf 的用法就很顺了。先看图层清单再看实体分布这是最常用的两个维度。import ezdxf from collections import Counter doc ezdxf.readfile(sample.dxf) msp doc.modelspace() # 图层清单 layers [layer.dxf.name for layer in doc.layers] print(图层数量:, len(layers)) # 实体类型统计 type_counter Counter(entity.dxftype() for entity in msp) print(实体类型分布:, dict(type_counter))这段代码能让你快速摸清一张图的“骨架”。实际项目里我经常先用它做一轮数据画像看看图纸里到底有什么再决定后续提取哪些字段。先画像、再提取比一上来就写复杂解析逻辑要稳得多。3.4 第四步几何数据的精确提取真正有价值的是几何数据。以直线和圆为例提取端点和圆心半径for entity in msp: if entity.dxftype() LINE: start entity.dxf.start end entity.dxf.end print(f直线: ({start.x},{start.y}) - ({end.x},{end.y})) elif entity.dxftype() CIRCLE: center entity.dxf.center radius entity.dxf.radius print(f圆: 圆心({center.x},{center.y}) 半径{radius})多段线LWPOLYLINE稍微复杂一点它的顶点是带凸度bulge的凸度不为 0 意味着这一段是圆弧。如果你只取顶点坐标而忽略凸度还原出来的形状会变成折线精度直接丢失。这一点在做加工路径或者面积计算时特别致命务必注意。3.5 第五步块参照与属性文字的展开工程图纸里大量信息藏在块参照INSERT和属性ATTRIB里比如图框信息、零件编号、材料标注。块参照本身只是个“引用”真正的几何在块定义BLOCK里。要拿到完整信息需要先取块定义再按插入点和缩放、旋转做坐标变换。for entity in msp: if entity.dxftype() INSERT: block_name entity.dxf.name insert_point entity.dxf.insert # 遍历块内实体 block doc.blocks.get(block_name) for sub in block: print(block_name, sub.dxftype())属性文字则通过entity.attribs获取每个属性有 tag 和 text 两个关键字段。很多图纸的标题栏信息就是靠这个提取的做批量归档时非常有用。4. 那些文档里不会写的坑我替你踩过了代码能跑通只是开始真正决定项目成败的是边角情况的处理。下面这些坑几乎每一个我都实际遇到过写出来让你少走弯路。4.1 中文路径与编码问题ODA 转换器对中文路径的支持时好时坏尤其是路径里同时有中文和空格时失败率明显上升。我的做法是在转换阶段把文件复制到纯英文的临时目录转换完再挪回去。虽然多了一步 IO但稳定性提升非常明显。另外DXF 里的文字编码在不同版本里可能是 ANSI 也可能是 UTF-8ezdxf 读取时如果遇到乱码可以尝试指定编码参数或者先用文本编辑器确认文件实际编码。4.2 大文件的内存与性能一张复杂的总装图转成 DXF 后可能几百 MBezdxf 全量加载会吃掉大量内存。如果只是做统计可以用ezdxf.readfile的迭代模式或者分图层、分块处理。我处理过一张上百万实体的图纸全量加载直接把内存打满后来改成按块定义分批读取内存占用降了一个数量级。大文件不要贪图一次性加载这是血泪教训。4.3 转换器的静默失败与脏数据前面提过返回码不可信。还有一种更隐蔽的情况转换成功了但 DXF 里有部分实体丢失或者坐标错乱。这通常发生在源 DWG 本身有损坏、或者用了转换器不支持的代理实体proxy entity时。应对办法是在解析阶段做数据校验比如统计实体数量是否和预期量级吻合、坐标是否落在合理范围内。发现异常就标记出来人工复核而不是盲目相信转换结果。4.4 版本降级的副作用有时候为了兼容老工具会把高版本 DWG 转成低版本 DXF。这个过程中一些高版本才有的特性比如某些标注样式、动态块行为会被降级或丢失。如果你的下游逻辑依赖这些特性降级就会引入隐性 bug。我的建议是尽量保持转换版本和源文件一致或接近只在确实需要兼容时才降级并且降级后做一轮对比验证。5. 把脚本工程化从能跑到好用单文件脚本跑通之后下一步是让它能稳定地处理成百上千张图纸。这一步的差距往往比“会不会写解析代码”更能体现工程能力。5.1 批处理的任务编排批量处理的核心是任务队列加失败重试。我会把每个文件当成一个任务记录它的状态待处理、转换中、解析中、成功、失败及原因。失败的进重试队列重试仍失败的单独归档附上错误日志。这样即使中间有几十个文件出问题也不会阻塞整体流程事后还能精准定位。import json def save_task_state(state, pathtask_state.json): with open(path, w, encodingutf-8) as f: json.dump(state, f, ensure_asciiFalse, indent2)用 JSON 存任务状态简单直接中断后能续跑比内存里维护状态可靠得多。5.2 日志与可观测性批处理脚本最怕“跑完了不知道哪里出了问题”。我的习惯是每个关键步骤都打日志文件开始处理、版本探测结果、转换耗时、解析到的实体数量、异常堆栈。日志按天切分出问题时能快速回溯。别嫌日志多真出问题时一条清晰的日志能省你半小时排查。5.3 输出格式的选择解析出来的数据往哪存小规模用 CSV 或 JSON 就够需要做空间查询的可以考虑存进支持几何类型的数据库需要给前端展示的导出成 GeoJSON 或者自定义的 JSON 结构。输出格式要服务于下游消费方别为了“看起来专业”硬上复杂方案。我见过把简单图层统计塞进图数据库的纯属给自己找麻烦。6. 几个容易被忽略的细节补充最后补几个零散但很实用的点都是实际做项目时积累下来的。第一DWG 里的单位不一定是毫米。有些图纸用的是英寸或者无单位提取坐标前最好确认一下$INSUNITS系统变量否则算出来的尺寸会差 25.4 倍。这个错误非常隐蔽因为数值本身看起来是“正常”的。第二图层可能是关闭或冻结状态。ezdxf 能读到这些图层但如果你做可视化或者统计“可见实体”需要额外判断图层的开关和冻结标志否则会把不该算的算进去。第三块参照可能有嵌套。一个块里引用另一个块坐标变换要逐层累乘。只处理一层的话嵌套块里的几何位置会全错。写递归展开逻辑时注意加深度限制防止循环引用导致死循环。第四测试样本要覆盖极端情况。空图纸、只有图框没有内容的图纸、超大图纸、损坏图纸这几类都要准备样本跑一遍。我一般会专门维护一个小型“刁钻样本集”每次改完脚本都过一遍比事后在生产数据上发现问题强太多。这套链路我在多个工程项目里反复用过从最初的单文件调试到后来的批量流水线核心逻辑没变过先探版本、再转格式、然后解析、最后校验。工具会更新库的 API 会变但这个分层思路是稳的。真正拉开差距的从来不是会不会调某个函数而是对格式边界和异常情况的理解深度。