大概两个月前我接手了一个旧项目的数据迁移需求。车间里积压了一大批DWG图纸需要把里面的设备信息、尺寸和备注提取出来整理成结构化数据方便后续的管理系统调用。一开始我天真地以为DXF是纯文本写个解析脚本就行结果花了三四天死在版本差异和块嵌套上。后来换成了Teigha一个跨平台的CAD文件解析内核终于把这条路走通了。这篇文章就是记录这次选型、开发到落地验收的完整过程尤其那些容易反复踩的坑希望给同样要和DWG打交道的朋友一点参考。Teigha这个库在CAD开发圈子里其实很有名它封装了DWG和DXF的底层二进制结构你不需要关心一个圆在文件里到底存成几个字节只需要调用接口就能拿到圆心、半径、图层这些常规属性。它也能把老版本图纸转换成新版本或者反过来降级保存。对于做数据提取、批量转换、图纸预览的开发者来说这套东西比从零开始解析二进制靠谱得多。下面按我的实际使用顺序来写先讲为什么选型再讲怎么搭环境接着是核心读写的实现最后是批量处理时遇到的坑和性能优化方法。1. 项目背景与核心需求解析1.1 为什么绕不开TeighaDWG是CAD行业的事实标准但它不是完全开放的格式。它的二进制布局在不同年代版本里变化很大光版本代号就有十几种。每个版本里又包含对象图、词典、扩展记录、代理实体、外部参照这些复杂结构。直接解析最可怕的是遇到嵌套块一个设备可能是由几百个基础实体组成的块块里还能包含另一个块而且块引用还带着变换矩阵坐标得一层层换算回世界坐标系。如果全靠自己写算法很容易在一个边界情况下翻车。我最早试过用某个开源解析库普通的直线、圆、文本能读出来但遇到有动态块或者扩展字典的图纸数据就缺失了。更麻烦的是很多图纸是十几年前的老文件字符编码五花八门用错了会导致文本乱码。Teigha把这些历史包袱都接住了它内置了对多版本DWG、DXF的支持也提供了统一的对象模型。所以你只需要学会一套接口就可以兼容不同年代的图纸这是它最大的价值。1.2 项目里真正要解决的问题这个项目不只是把图纸读出来那么简单具体有三个硬性要求批量处理每天可能要解析几百个DWG文件不能人工手动处理。提取的内容包括设备编号、尺寸标注、文字备注以及图元所在的图层。最终结果要存入数据库供后台管理系统做检索和展示。为了满足第三点我需要把每个实体的几何信息转换成JSON数据再批量写入数据库。这里就牵扯到坐标系的处理、单位的换算、特殊字符的转义。用Teigha之后这些问题都被框在了合理的范围内坐标系可以直接通过接口获取单位和图纸的设置相关转换逻辑也相对固定。我当时列了一个技术选型对比表归根到底就是三条支持老版本格式、能在Linux服务器上跑、可以嵌入到现有的C服务里。Teigha正好对应上了。2. 开发环境搭建与工程配置2.1 版本选择和SDK获取Teigha的版本迭代有点特殊早期叫Teigha后来整体平台化了但目录结构和大部分API依然沿用老名字。下载SDK后一般能看到Include、Lib、Docs、Examples这些目录。选版本的时候一定要看它支持哪一代DWG文件格式。比如R18系列对应比较老的一批DWGR21覆盖中间几年R24以上支持更新的图纸。高版本SDK通常能读低版本文件但反过来就不行。所以做通用工具时我建议直接选支持代号最高的SDK同时保留降级保存到老版本的能力。这里有个容易忽略的地方SDK的许可文件。Teigha初始化时会检查许可证许可文件一般是一个自定义格式的授权文件缺少它的话程序虽然能编译但运行时会在初始化阶段报错。最开始我在测试环境把许可文件放错目录查了很久才发现是授权文件没被加载。2.2 编译链接时的三个常见坑第一个坑是字符集设置。Teigha的接口要支持中文路径和中文内容最好把工程设置成Unicode在Windows下使用宽字符入口在Linux下确保文件路径按UTF-8传递。有一个很典型的场景图纸名包含中文用窄字符打开会失败改成宽字符就好了。第二个坑是动态库依赖。Teigha的库不是只有一个静态库而是一组动态库和对应的导入库。编译能通过运行时容易提示找不到某个动态库。检查一下执行目录是不是包含了所有依赖最好能在CMake里写一个自动拷贝依赖的步骤。第三个坑是运行库的匹配。Teigha的库通常是使用动态运行时编译的你的工程必须也使用相同的运行时选项否则会出现堆损坏或者偶发崩溃。在Windows上尽量统一使用Release版本的动态运行库不要混着Debugg和Release。下面是一个常用的CMake配置片段cmake_minimum_required(VERSION 3.16) project(CadParser) set(CMAKE_CXX_STANDARD 14) include_directories(${TEIGHA_ROOT}/Include) link_directories(${TEIGHA_ROOT}/Lib) add_executable(CadParser main.cpp) target_link_libraries(CadParser TeighaCore TeighaDb TeighaGeometry )这里的TeighaCore、TeighaDb等库名会随具体SDK版本变化以你拿到的实际导入库为准。2.3 初始化和许可证验证无论你的程序多简单使用Teigha前都必须先初始化。初始化和释放成对出现一般长这样#include OdaCommon.h int main(int argc, char* argv[]) { ::odInitialize(); // 在这里处理你的图纸文件 // 不要在任何数据库对象创建前跳过了初始化 ::odUninitialize(); return 0; }初始化时它会读取系统环境里的许可证也可能需要你在代码里显式指定许可路径。如果初始化失败后续调用大多会直接抛异常。建议在初始化代码周围加上日志方便排查问题。我在项目里还会判断许可的剩余时间许可证快到期时提前邮件告警避免半夜批量任务突然失败。这个细节虽然简单但很实用。3. 核心功能实现从打开到遍历3.1 打开DWG文件并选择空间读取一个DWG文件最直接的方式是调用静态方法打开#include OdaCommon.h #include DbDatabase.h OdDbDatabasePtr openDrawing(const std::string path) { return OdDbDatabase::readFile(path.c_str()); }这样返回的是一个数据库对象它代表整张图纸。注意路径在Linux下是UTF-8在Windows下可能需要转成宽字符。如果你用QT的QString或者其他框架记得先统一编码。打开后要读取图形数据通常从模型空间开始。模型空间就是图纸上所有图形实体所在的逻辑空间对应的接口是OdDbBlockTableRecordPtr pModel pDb-getModelSpaceId().openObject();打开对象时要注意打开模式。Teigha里对象有只读和写两种模式如果只是遍历用只读模式就够了要修改实体再改成写模式。3.2 遍历模型空间实体拿到模型空间后遍历里面所有实体void traverseEntities(OdDbBlockTableRecordPtr pModel) { OdDbObjectIteratorPtr pIter pModel-newIterator(); int count 0; for (; !pIter-done(); pIter-step()) { OdDbEntityPtr pEntity pIter-entity(); if (pEntity.isNull()) continue; count; } }这里pIter-entity()返回的是基类实体指针。Teigha几乎把所有的图形元素都抽象成了实体比如直线、圆、圆弧、多段线、标注、文字都继承自OdDbEntity。要想拿到具体类型需要用isKindOf或运行时类型转换。在遍历时强烈建议把所有指针都用智能指针保存比如OdDbEntityPtr。Teigha的引用计数机制和常见的shared_ptr不太一样但思路类似。如果你用裸指针保存很容易在批量任务里造成内存泄漏或悬空指针。3.3 处理常见实体类型对于一个数据提取工具最常用到的几种实体要熟悉OdDbLine直线主要属性是startPoint和endPoint。OdDbCircle圆主要属性是center和radius。OdDbArc圆弧除了圆心和半径还有起始角度、终止角度。OdDbText和OdDbMText单行文本和多行文本读取内容用textString。OdDbPolyline多段线可以拿到顶点数组和宽度。举个例子判断一个实体是圆可以这样if (pEntity-isKindOf(OdDbCircle::desc())) { OdDbCirclePtr pCircle OdDbCircle::cast(pEntity); OdGePoint3d center pCircle-center(); double radius pCircle-radius(); }文本实体的处理稍微特殊。有些多行文本的内容存储在扩展数据里直接用textString可能拿到的是带格式控制的字符串需要清理一下控制字符。比如“\A1;”这种格式标记提取时得去掉。坐标都是从世界坐标系里取出来的单位是图纸单位一般是毫米。如果你最后要转成米记得统一乘以系数。这个很容易忘我之前就因为这个把几百个设备的坐标直接放大了一百倍。3.4 块引用的递归处理图纸里的设备很多是以块的形式存在的。块引用的本质是一次变换矩阵基础实体定义在块自己的坐标系里通过块引用放到图纸的某个位置、缩放和旋转。Teigha可以直接拿到块变换矩阵但如果你要把里面的子实体坐标转换成图纸坐标系需要自己乘一下变换矩阵。处理块引用的代码大致是这样OdDbBlockReferencePtr pRef OdDbBlockReference::cast(pEntity); if (!pRef.isNull()) { OdDbObjectId blockId pRef-blockTableRecordId(); OdDbBlockTableRecordPtr pBlockTable blockId.openObject(); // 递归遍历子实体 }这里一定要小心循环引用。虽然理论上块定义不会直接包含自己但某些复杂的图纸确实会出现深层嵌套。建议遍历时记录一下深度超过比如20层就直接跳过避免程序卡死。嵌套块很快成了一个高频需求。我写了一个递归函数接收当前实体和当前的变换矩阵每层块引用就把矩阵乘进去最后把子实体坐标转换到世界坐标系。这样提取出来的数据才有实际意义。4. 写入、转换和系统级问题4.1 修改内容并另存某些场景下不只要读还要把处理后的结果另存成新文件。例如给一个零件批量添加编号文本。这个过程分几步打开源数据库。把需要修改的实体打开成写模式。修改属性。调用saveAs保存。保存时可以指定文件版本pDb-saveAs(_T(output.dxf), OdDb::kDxf); pDb-saveAs(_T(output.dwg), OdDb::kDwg);这里要注意保存前所有打开的对象都应该关闭或者释放写锁。如果你在遍历过程中修改实体不能直接saveAs需要先完成迭代再保存。否则有可能出现数据库状态不一致。还有一个坑如果要另存成老版本有些特性在新版本中才有比如某些自定义实体、新的标注样式。这些在老版本格式里可能会变成代理实体甚至直接丢掉。所以降级保存前先确认一下你的图纸里有没有特殊对象。4.2 中文乱码与字体缺失中文乱码是数据处理工具最容易遇到的问题。原因主要有两个一是老图纸的代码页设置不正确二是系统里缺少对应的CAD字体文件。Teigha读文字时会尝试把文字内容转换成Unicode。但对于老的有码页的图纸如果字体定义有问题转换结果会有偏差。我遇到的情况是所有中文文本都能读出来但个别字符变成问号或者空字符比如钢构的“构”字在某些字体下会丢。解决办法有两个方向。第一在打开数据库前设置代码页pDb-setCodePage(_T(ANSI_936));第二如果文字内容本身没问题只是显示宽度不对那多半是缺少字体文件。Teigha在Linux服务器上常见缺少中文字体导致多行文本的内容正常但字体替代错误。这种情况不算严重至少数据还在。4.3 代理实体和外部参照DWG图纸里可以携带第三方软件的自定义实体。Teigha不是CAD原生产品所以无法百分之百还原这些自定义对象只能把它包装成一个代理实体。它能拿到的信息非常有限只有可视化快照或者部分属性。如果你的业务恰好需要读这些自定义实体的业务字段就比较难受了。解决办法是让提供方导出成标准实体或者通过扩展数据把必要信息提前写好。我在项目里就碰到过这种最后是跟设计师沟通让他们把设备编号统一写入到实体的扩展字典里Teigha可以正常读取扩展字典。外部参照是另一个常见的坑。Teigha打开主文件时并不会自动递归加载外部参照文件。你需要自己根据主文件里的外部参照路径去逐一打开被参照的文件然后把它们的内容合并进来。路径可能是相对路径也可能是绝对路径处理的时候注意拼接。4.4 内存泄漏与批量处理建议批量处理文件时最怕内存只涨不降。Teigha的对象模型是引用计数管理理论上所有智能指针释放后内存会回收但如果你在循环里长期持有某些数据库对象的引用内存就可能一直占着。我整理了两条经验每个文件处理完显式释放顶层数据库指针并调用一次::odClearAll()。不要在循环外缓存大量的实体指针只保留必要的基础数据。另外批量处理的程序最好是做成一个常驻进程每处理完一个文件就退出当前线程或者清空局部作用域。这样即使某个文件内部状态异常也不会影响下一个文件。5. 性能调优与结果验证5.1 用只读模式减少解析读取文件时可以指定只读模式避免把一些编辑用的状态加载到内存里。Teigha的readFile有重载传入打开模式参数时可以控制是否以只读方式打开。只读模式除了更安全速度上也会快一点因为不需要建立可回滚的编辑记录。如果只是做数据提取强烈建议用只读模式。很多时候你只是拿坐标和文本根本不需要写回原文件。5.2 在实体层做过滤遍历时可以先用实体的通用类型判断过滤掉不关心的数据。比如你只关心文本和块引用就可以对其它实体直接跳过。快速过滤可以用if (!pEntity-isKindOf(OdDbText::desc()) !pEntity-isKindOf(OdDbMText::desc()) !pEntity-isKindOf(OdDbBlockReference::desc())) continue;这样能避免对大量不需要的对象做类型转换性能提升非常明显。有一次我处理一个超大图纸有几万个多段线但只需要其中的设备编号文本。过滤前用时几十秒过滤后不到一秒。5.3 多线程处理不稳定但可用Teigha不是完全线程安全的。我在项目里没有直接多线程解析同一个文件而是用了最简单的策略多个进程每个进程处理一份文件。如果是多个线程同时解析不同的文件有可能会在同一模块内部产生冲突。建议每个线程独立初始化和清理Teigha环境避免共享全局状态。曲线救国的方案是把解析任务拆成多个独立进程由主进程统一调度。每个子进程处理一份文件把结果写入一个临时JSON文件主进程收集后入库。这个方案虽然重一点但稳定性和并发度都有保障。5.4 结果验证功能开发完之后结果验证最重要。我做了两层校验抽了10张典型图纸让设计师人工核对坐标和文本确认提取结果和原图一致。在数据库里做批量统计比如每个图层的实体数量、文本总条数和历史人工记录对比。这一步发现了一个隐藏问题有部分图纸里的圆实际上是退化后的圆弧半径是零。Teigha读取时也能正常返回但后续计算时除零导致整个任务崩溃。后来我在校验逻辑里额外加了一条规则半径小于0.001的圆直接忽略。6. 实际踩坑记录与经验心得6.1 三个印象深刻的坑第一个是版本不兼容。最开始用的旧版SDK打开一个较新的DWG时直接报“无效的文件版本”。后来统一升级到新版并把版本代号写进配置文件才彻底解决。以后凡是遇到打不开的图纸先确认SDK版本。第二个是许可证。Teigha的许可证是绑定机器信息的。我在一台测试服务器上生成的授权文件换到另一台机器就失效了。这个不是代码问题但要提前规划好服务器避免临时换机器导致整个服务不可用。第三个是自定义实体丢失。某个设备图纸用得是第三方插件绘制的专用对象用Teigha读取时变成了代理实体业务属性全部丢失。后来让设计人员在原始图纸里把这些专用对象全部文字化成标准文本才解决了问题。这个属于工作流程问题单靠代码绕不过去。6.2 给后来人的建议如果从零开始接触Teigha建议先把SDK自带的Examples编译一遍。每个示例对应一个核心功能比如自定义实体、文件转换、渲染都跑通之后再写自己的业务逻辑。这些示例代码本身是很好的参考能少走很多弯路。另外项目里所有依赖Teigha的功能都做成了独立的命令行工具方便单独调试。功能上线后我们把解析工具的版本号也写进了数据库方便追踪哪批数据是用哪个版本生成的。数据出问题时能很快定位到是不是解析逻辑变了。6.3 最后的经验技巧再分享一个小技巧。Teigha读多行文本时内容里经常混有格式控制符。在入库前我写了一个清洗函数把所有控制符去掉只保留纯文本。这个函数很不起眼但效果很好直接解决了后台搜索时关键词匹配不到的问题。还有一个心得是在批量处理时给每个图纸都加一个超时机制。某些巨大或损坏的图纸可能让解析进程卡住没有超时的话整个队列都会被拖死。我用的办法是每个解析子进程最长运行5分钟超过就杀掉重启并记录失败日志。这样即使遇到几个顽固文件也能保证整体进度不中断。这次项目做完之后我对“不要从零解析复杂格式”这个原则有了更深的体会。Teigha虽然学起来有点陡峭但一旦把环境搭好、接口摸熟后续的开发效率会高很多。如果你也正在被DWG文件折磨希望这篇使用记录能帮你省一点时间。