前阵子给产线做文档追溯系统遇到一个听着不大、折腾起来够劲的问题工程师要把 CAD 夹具图粘到 TinyMCE 的工艺表单里可粘贴进去的图要么糊成一片要么干脆丢了更别提后期做尺寸标注和坐标提取了。要解决的本质是 CAD 图纸的矢量输出而不是简单贴一张截图。如果你也在做芯片制造企业内部的知识库、SOP 文控或者 MES 工单系统这篇应该能帮你少走不少弯路。1. 场景先还原为什么芯片制造企业的表单里必须有矢量CAD图1.1 从一张失真的截屏说起在芯片制造环节工艺文档系统里最常见的插图需求来自封装与夹具设计。工程师手里是结构设计部门的 DWG 文件需要在系统里说明定位方式、吸附区域、探针接触点。最省事的办法是截一张图贴进去因为 TinyMCE 本身就是网页编辑器截图粘贴是所有人条件反射式的操作。但这个做法在量产线是灾难。显示屏是 1920 分辨率截图贴在客户工程师、质量审核员的屏幕上缩放一放大字就虚了。打印出来更明显一条细线可能变成两条圆也变成了多边形。更麻烦的是审核人员想确认一个孔距、一个圆角半径截图上根本没有原始坐标只能去翻 CAD 源文件。一次两次可以多来几次工艺人员就烦了。所以当“CAD 图纸粘贴到 TinyMCE”这个需求被提出来时核心并不在于“粘贴”这个动作而是粘贴之后那张图能不能保持矢量属性。矢量输出的意思是无论用户如何缩放、打印到多少 DPI图形边界和文字都保持锐利并且图形元素内部的坐标、图层、线型信息仍然可以被前端解析和利用。这个差异在芯片制造这种高精度场景里不是体验问题而是工程数据能不能流通的问题。1.2 所谓矢量输出到底解决了什么不同的人对“矢量输出”的期待完全不同。对工艺工程师来说矢量输出意味着文控系统里那张图可以当作正式图纸使用不用再附一份 DWG 原文件。对质量审核来说矢量输出意味着可以在网页上做精确的图形批注而不是在图片上画箭头。对 IT 系统开发来说矢量输出意味着 CAD 图能成为 Web 页面可以控制的 DOM 元素而不是一个无法访问像素的铁壳。我的经验是把需求拆成三层第一图形必须还原准确线型、图层、文字、坐标都不能丢第二编辑器内可以正常渲染同时不能因为 SVG 产生 XSS 漏洞第三图形在导出 PDF 或打印时保持清晰。这三层每一层都有不少坑后面会详细讲。在这里先给一个结论性的方向芯片制造企业内部如果 CAD 设计端和文档系统之间没有专门的 PDM 集成最稳妥的路径是“约定 DXF 作为交换格式后端转换 SVGTinyMCE 内嵌 SVG”。这不是唯一方案却是兼容性、成本、可控性比较平衡的方案。2. CAD图纸和TinyMCE之间的“格式真空带”2.1 一次把格式血统说清楚聊方案之前必须先把格式血缘搞清楚。DWG 是 AutoCAD 的私有格式本质是数据库文件解析它需要逆向工程规范开源库不是没有但正确率不敢保证。DXF 是 AutoCAD 提供的老牌交换格式用文本或二进制描述图元、图层、线型、文字等浏览器里没有任何原生 API 能直接解析 DXF。SVG 则是 Web 端的矢量标准浏览器可以直接渲染还能用 JavaScript 操作。中间的 EMF/WMF 是 Windows GDI 时代的矢量格式。如果你在 CAD 里选中图元按 CtrlC然后在网页里按 CtrlVWindows 剪贴板里实际上有一堆格式CF_HDROP 文件列表、CF_BITMAP 位图、CF_ENHMETAFILE EMF 矢量等。TinyMCE 的默认粘贴处理程序会优先取 HTML 格式它拿到的不是 CAD 原始图元而是编辑器自动生成的 HTML 片段这个片段里往往是位图而且经过了从 CAD 软件渲染到剪贴板位图的分辨率折损。所以要解决“CAD 图纸粘贴到 TinyMCE”一定要先分清是从 CAD 窗口直接复制图元后再粘还是把文件传入系统后由系统解析。前者走过的链路太暗EMF 在 Chrome、Firefox 里根本不能作为图片直接显示。后者是干净可控的用户上传 DWG 或 DXF 文件系统负责转换成 SVG再把 SVG 塞进 TinyMCE。2.2 剪贴板粘贴时CAD到底给了浏览器什么我们用了一个比较笨但有效的实验来摸清粘贴链路。打开记事本从 CAD 里复制一个矩形粘贴出来是乱码其实那就是 EMF 流打开画图粘贴得到的是位图打开网页编辑器粘贴大部分情况得到的是浏览器根据剪贴板 HTML 生成的img或内联样式底层数据是位图。更麻烦的是不同 CAD 软件AutoCAD、中望 CAD、浩辰 CAD 等的剪贴板行为不完全一致。有的会额外放一段 DWG 二进制进去有的只放 EMF 加位图。所以如果期望从前端剪贴板截获矢量数据并还原几乎是无底洞。真正成熟的方案是放弃“粘贴即转换”的幻想把文件上传作为主通道把粘贴作为快捷入口用户粘贴时如果检测到文件内容就走上传解析接口。还有一个被忽视的问题CAD 软件经常默认不联网企业的 Windows 环境也常禁用外网这让一切依赖在线转换服务的方案都走不通。所以整个转换管线必须部署在局域网内。2.3 位图方案为什么屡屡被否决有人会说既然粘贴场景复杂为什么不干脆统一用高分辨率 PNG 导出普通 Office 文档这样做完全够了但芯片工厂的文档往往要过严格审核图纸上的最小字符、最小线宽都有标准。一套很复杂的夹具图导出成 4000 像素宽 PNG放大到 200% 时标注尺寸的两位小数其实已经糊了。到了打印环节4000 像素宽也就是刚够 A3碰到大幅面图纸就露馅。而且位图方案丢失了“图层”这一个关键资产。CAD 图纸的每一根线都挂在图层上颜色、线宽、是否打印都是工艺转移的依据。位图把这些全部压平成 RGB 像素。后期你想在图片上按图层筛选某些信息完全没有办法。这些都是我们放弃位图、选择矢量输出这个方向的原因。现在回到正面战场到底怎么把 DWG/DXF 转换成 TinyMCE 能用的 SVG。3. 我的做法DWG先归拢成DXF再用ezdxf转成SVG3.1 为什么不开一个CAD服务直接渲染DWG一开始确实想过直接把 DWG 放到服务端渲染但每个产线装 AutoCAD 成本太高而且 AutoCAD 的服务器授权、并发限制都不适合 Web 后端。开源层面LibreDWG 能读一些 DWG但面对版本更新较快的 DWG 文件经常出问题。而 ODA File Converter 能高质量地实现 DWG 转 DXF但又多了个跨平台进程管理负担。最终我们选择要求工程设计端统一输出一份 DXF 用于文控流转。DXF 是公开格式Python 的 ezdxf 库可以稳定读取这比在 DWG 的黑盒上摸索省太多事。这个决定有业务前提芯片制造企业的设计团队通常就是 AutoCAD 或中望 CAD另存为 DXF 的成本很低设计习惯稍微改一下就能接受。如果你们企业内部 DWG 版本极其不统一或者设计团队不愿意配合也可以预留一条 ODA File Converter 批处理路径定时把新版 DWG 批量转成 DXF。我们实际做法是鼓励“主动交 DXF”同时提供一个定时扫描工具发现只有 DWG 没有 DXF 的图纸自动转一份。3.2 转换管线的四个关键步骤转换管线用 Python 写成核心库就是 ezdxf 加 svgwrite。下面把四个关键步骤讲清楚。第一步是读文件和归一化。ezdxf 读取 DXF 后把模型空间里的实体遍历出来。在这个环节一定要先处理 INSERT 块引用因为块引用可以嵌套、旋转、缩放不展开的话后面坐标全是错的。展开时要用矩阵变换实体本身的坐标乘上块的 Insert 向量和 Rotate 角再叠加嵌套块的变换。第二步是实体映射。LINE、LWPOLYLINE、CIRCLE、ARC、ELLIPSE、SPLINE、TEXT、MTEXT、HATCH挨个转成对应的 SVG 元素。最偷懒的做法是直线和轻量多段线对应 path圆和弧对应 circle 和 path文字用 text 和 tspan。但有一个细节圆和弧建议统一转成 path因为 SVG 的 circle 虽然有圆心半径但圆弧起始方向、椭圆弧都不好表达统一用 path 记录绝对坐标最保险。第三步是坐标变换。DXF 的世界坐标系以 Y 轴向上为正向SVG 和 CSS 的坐标系是 Y 轴向下为正。如果不翻转 Y 轴图纸会上下颠倒。还需确定缩放因子DXF 图纸通常以毫米为单位给 SVG 设置一个合理的 viewBox 和宽度比如 1 毫米等于 3.7795 像素96 DPI 下的换算值但不必真的去整除因为 SVG 会根据 viewBox 等比缩放。第四步是图层和样式处理。遍历 DXF 的图层表把每个图层的颜色、线型映射为 SVG CSS 类。不要直接给每个元素写死颜色而是定义类似lay-layerName的类便于前端按图层筛选。隐藏图层和 defpoint 图层直接跳过不要进 SVG这样文件体积能小不少。3.3 转换结果为什么是SVG而不是Canvas/图片在 TinyMCE 里嵌入图形理论上也可以用 Canvas但 Canvas 是位图编辑器保存时还得额外导出一张快照丢失可检索性。SVG 是 DOM 的一部分用户可以用浏览器选中 SVG 里的文本检索系统也能索引更重要的是前端可以用 JavaScript 读取 SVG 上的坐标属性这对芯片制造企业非常有用。举个例子封装基板的 Mark 点位置在 DXF 里是严格坐标。转成 SVG 后前端可以遍历所有图形的>tinymce.init({ selector: #docEditor, extended_valid_elements: svg[*],defs[*],g[*],path[*],rect[*],circle[*],ellipse[*],line[*],polyline[*],polygon[*],text[*],tspan[*],use[*],marker[*],linearGradient[*],stop[*], paste_data_images: true, content_style: svg { max-width: 100%; height: auto; } });注意svg[*]的写法是允许所有属性听起来省事但会给 XSS 留下口子后面会讲怎么收紧。另外必须允许defs和use因为 SVG 里大量使用defs定义箭头 marker用use做块引用。如果漏掉这两个标签箭头标记会全部消失图面变得非常难认。4.2 粘贴、拖拽、上传三条路径分别怎么处理TinyMCE 接受外部图形一共有三条路径直接粘贴、拖拽文件、点击上传按钮。我建议三条路径统一进入同一个“转换接口”。直接粘贴在粘贴事件里做拦截如果剪贴板里有文件对象说明用户是“把 CAD 图元复制后粘贴”或“复制了文件图标再粘贴”把文件交给后端转换接口。不要试图在浏览器端解析 EMF这是浪费时间。如果剪贴板里只有位图可以给出一个提醒“请上传 DXF/DWG 文件以获得矢量输出”。拖拽文件监听 drop 事件拿到 File 对象后拦截默认行为同样交给转换接口。TinyMCE 自带的图片上传接口可以直接处理图片但对 DXF/DWG 不友好所以要在 editorEvent 拦截。点击上传按钮用file_picker_callback挂一个自定义文件选择器限制扩展名为 dwg/dxf/svg上传成功后直接把后端返回的 SVG HTML 插入编辑器。这里有个顺序问题是先转 SVG 再插入还是插入后转我强烈建议后端先转返回一段干净的 SVG HTML插入编辑器即可。浏览器端再转一次只会引入不可控性让 Python 转换逻辑在前端重写一遍也不现实。4.3 防XSS和防“图纸泄露”的边界控制SVG 真的能执行脚本svg onload...、a hrefjavascript:...都是经典攻击向量。图纸文件又经常来自外部供应链不能信任。所以后端转换服务必须做一个清洗层删除所有on*事件属性。删除a、foreignObject、script等危险标签。只允许有限的 SVG 元素和属性颜色、坐标、几何属性可以过style 保留但限制白名单属性。处理好命名空间不要使用xmlns:xlink以外的外部实体引用。企业内部还要考虑图纸安全。我们的系统里转换服务接收 DXF 后在隔离区完成解析SVG 里的文字会被策略性栅格化一部分比如涉及关键工艺参数的标题块或者对转换记录做审计谁在什么时间上传了哪个文件。不要小看这一点芯片厂内工艺文件本身就是核心资产。5. 芯片制造场景下的工程语义保留5.1 坐标不丢才能在SVG上做测量和批注因为 SVG 保留了坐标信息前端可以做很多“图片做不到”的事。我们的文控系统有一个测量工具用户鼠标在 SVG 上划一条线前端读取 SVG 的 viewBox 和坐标矩阵换算成毫米直接显示两个点之间的实际距离。审核人员可以在线核对孔间距、定位销距离不用再打开 CAD。实现不复杂拿到 SVG 的getScreenCTM()把屏幕坐标转成 SVG 用户坐标再乘上图纸比例系数。批注系统也从“在图上画个圈”变成了“记录一个坐标点”。以前审核意见是“第三个圆孔上方有个毛刺”现在直接点击图形任意位置系统记录的是精确 X/Y 坐标。后面工艺人员拿着这个坐标去 CAD 里定位效率提升一个量级。5.2 图层结构映射成CSS后文档系统能做什么DXF 的图层转换成 CSS 类前端就能根据图层做显示开关。比如“尺寸标注层”和“中心线层”在确认装配关系时通常不需要看用户一键隐藏。这个功能在 CAD 里司空见惯但放到网页文档系统里就少见多了。我们的做法是在 TinyMCE 外面套一个“图层面板”但注意 TinyMCE 的内容是 iframe 隔离的外部 CSS 不能直接作用于编辑器内部。解决办法是用content_style把图层 CSS 注入进 iframe然后再用编辑器实例的 dom 方法去切换类名或者直接操作editor.contentDocument里的样式。另一个应用是异常检测。系统可以统计 SVG 里的图层种类对照企业标准图层命名规范如果出现“临时画线层”或者图层颜色不在标准色表内就自动打一个提醒标签。这等于把 CAD 审核的规则前置到了文控环节。5.3 打印、PDF、下游系统的兼容经验矢量 SVG 在浏览器打印时通常表现很好但如果文档系统导出的 PDF 不是由浏览器直接打印而是通过后端把 HTML 转 PDFSVG 支持程度就因转换器而异。我们用的是 Chromium 无头浏览器的 print to PDF渲染 SVG 没问题。如果用 itext 或老式 PDF 库SVG 支持会很痛苦。需要特别设置 SVG 的尺寸信息。给svg标签加上width、height、viewBox并确保比例关系与源图纸一致。否则在导出 PDF 时会出现图形被拉伸、单位被忽略的情况。对于芯片制造企业常用的 A4/A3 文档建议在上传时就让用户选择“图纸幅面”或在转换时自动识别给出一个基础物理尺寸。如果在系统里还要继续做数值分析最好同时保留一份 JSON 格式的“图元摘要”包含关键点坐标、图层、尺寸标注值跟 SVG 一起存库。后面要生成坐标文件、检查表直接从 JSON 取不用再解析 SVG。6. 实施中踩过的坑和替代方案6.1 SHX字体乱码文字映射和转路径CAD 图纸里的文字字体很让人头疼。AutoCAD 的 SHX 字体是矢量字体但浏览器不认识DXF 转 SVG 时TEXT 实体的字体名会直接变成arial、romans.shx这样的名字浏览器找不到字体只能 fallback中文很容易变成豆腐块。解决思路有两个。一个是维护一张企业字体映射表把常用的 .shx 字体名映射到浏览器或系统中安装的字体比如simplex.shx映射到Arialhzfs.shx映射到仿宋。另一种是彻底根治把所有 TEXT/MTEXT 文字转成 path用轮廓替代字形。这样做文件体积会变大而且文字无法被检索但在图纸审核场景下保证“印出来和 CAD 里一样”比检索更重要。我们最终的选择是折中标题栏、技术要求等大段文字保留可检索 text带引用的尺寸文字和包含特殊线型的文字转成 path。具体是哪些文字可以通过正则匹配字体名来区分。6.2 插入块旋转、圆弧方向、科学计数法这几个坑单独拿出来说。块引用的旋转方向DXF 里 INSERT 的旋转角以度为单位逆时针为正而 SVG 的transform rotate也是以度为单位但在 Y 轴向下坐标系里以顺时针为正这个负号只要漏掉整个装配图就会歪着。圆弧方向DXF 的 ARC 实体有起始角、终止角且默认逆时针为正。SVG 的 path 画弧时必须知道弧的大弧标志和方向。做得不严谨看到的圆弧会变成优弧整个图面目全非。建议在转换层做一个圆弧路径生成函数统一处理方向。科学计数法DXF 文件里坐标可能写成2.1616e4这样的科学计数法在 SVG 里其实是合法数字但如果你拿这个数字去做字符串拼接、做坐标归一化程序可能因为你假设了固定小数点位数而出错。我们遇到过前端拿到坐标数组后 parseFloat 过一遍才发现没问题但某些代码里用正则取数字就炸了。处理方法是所有数字统一用Number()解析不要按字符串操作。6.3 图纸合并、图层提取、离线部署等周边杂事经常有人搜“CAD 图纸合并”“cad 如何提取图层信息”在我们这个场景里也躲不开。如果一张 SOP 图里想放多个零件图纸直接把两张 DXF 的实体塞进同一个 SVG 会导致坐标重叠、看不到东西。正确做法是在转换接口里提供一个“图纸合并”参数用户指定每张子图的插入点系统先把子图移动到插入点再写入同一个 SVG。插入点一般选子图自身包围盒的中心或左下角这样叠加比较可控。图层提取则是把“只保留某个图层”变成一个参数。很多设备说明书只需要“定位层 标注层”不需要“水电气路层”转换时做一次图层过滤能省一半体积也减少阅读干扰。离线部署的问题前面提过这里再补一句整个转换服务不开外网访问依赖的 Python 包在内网用私有源安装SVG 里的字体也全部本地化。不要图省事引用在线字体库产线网络环境不一定允许而且慢。最后我再分享一个小的操作经验在正式上线前拉出 50 张不同年代、不同版本 CAD 导出过的 DXF 图纸做回归测试。不要只测自己画的图因为设计工程师导出 DXF 的习惯可能完全不一样——有人导出时把图纸空间当模型空间用有人把所有线都画在 0 层。每发现一个解析问题就在转换模块里加一个兼容分支。这活儿不性感但就是这些边边角角决定了系统在产线上能不能真正用起来。
