六三门前阵子一个做半导体厂信息化建设的同事来找我，说他们内部的知识库系统用的是TinyMCE，工程师从CAD里复制一张版图或设备布局图，粘贴进去看着没什么问题，可一旦输出PDF或者放大检查细节，线条边缘全是锯齿，标注数字稀碎。芯片厂对图纸质量要求又卡得死，这种图根本没法放进变更单和工艺文件里。这就是典型的CAD图纸在网页富文本编辑器中被位图化的案例。这篇就围绕CAD图纸、TinyMCE、矢量输出这三个核心，把问题根源、技术选型和可落地的几套方案完整拆开讲一遍，给正在做企业文档系统、知识库或无纸化办公的团队一个可以直接参考的路线图。
1. 为什么芯片企业的CAD图纸进了TinyMCE就变成马赛克：剪贴板里的数据争夺战
1.1 剪贴板里不止一张图，而是多种格式的容器
很多人以为在CAD软件里选中图形按Ctrl+C，剪贴板里就只有一份"数据"，其实完全不是。Windows剪贴板是一个多格式容器，一份内容可以同时携带纯文本、位图、增强图元文件（EMF）、HTML片段等好几份数据。AutoCAD复制对象时，会同时塞进去CF_UNICODETEXT（命令文本信息）、CF_BITMAP（屏幕位图）、CF_ENHMETAFILE（增强图元文件）等。
EMF这个格式很关键，它是Windows系统级矢量图元标准，保留直线、圆弧、填充、文字等矢量信息。可它有一个硬伤：浏览器不认识EMF。Chrome、Edge、Firefox的粘贴处理根本不会去读这个格式，它们只认text/plain、text/html、image/png这几类。
所以工程师从CAD里复制一段图纸，再切到浏览器里Ctrl+V时，浏览器在剪贴板里翻了一圈，发现HTML片段通常是空的或只有路径文本，能用的只剩位图，于是就把那张屏幕截图似的位图塞进了TinyMCE。这就是粘贴后变糊、变马赛克的根本原因。
1.2 TinyMCE粘贴机制：为什么矢量数据会被主动丢弃
TinyMCE本身不直接读剪贴板，它依赖浏览器暴露的paste事件。浏览器触发paste时，event.clipboardData里放着它认为可用的数据项。关键是：浏览器在放入clipboardData之前，就已经把不认识的格式过滤掉了。
我用Chrome做过验证：从AutoCAD复制一段包含圆、标注文字、虚线的内容，粘贴到TinyMCE的textarea里，最终得到的是一个base64编码的PNG图片，宽高就是当前视口里看起来的大小。原始图纸里那条弧线的半径、文字的字高、图层归属，全部丢了，只剩下一堆像素点。
TinyMCE默认的粘贴过滤规则还会进一步处理：比如遇到file://协议的本地产物会直接丢弃，遇到没有width/height属性的图片会自动补上，遇到不认识的标签会剥离。它的一切设计都偏向"安全、标准、干净"，但恰恰是这种安全机制，对CAD矢量数据形成了二次打击。
1.3 芯片制造企业为什么更怕这种"糊"
消费类产品文档里，图纸糊一点很多人能忍，但半导体行业完全不同。芯片制造涉及的图纸包括厂房动力管道布局、光刻机台基础图、掩膜版框图纸、封装基板设计图、CMP工艺腔体结构图等。这些图纸本身精度要求高，放大看细节是常态。更重要的是，芯片企业普遍有严苛的质量体系和审计要求，图纸上的标注、尺寸、版本号必须是可检索、可追溯、清晰的矢量文本，而不是嵌入在像素里的痕迹。
还有一个容易被忽略的问题：位图图纸无法被知识库搜索引擎索引。工程师想检索"某某机台的冷却水管道口径是多少"，如果图是位图，OCR做得再好也有误差；如果图是SVG，文字节点可以直接被全文检索命中。这是芯片厂IT建设里的一个隐藏需求，但实际价值很高。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 三个能拿到矢量结果的路线：SVG剪贴板、EMF中转、DXF前端解析怎么选
2.1 路线A：让CAD复制时就带出SVG数据
理想状态下，如果能直接从CAD复制出SVG格式的数据，浏览器自然能识别。Windows剪贴板确实支持自定义格式，理论上可以注册一个image/svg+xml格式，让剪贴板里同时携带SVG。
但现实很骨感：AutoCAD本身不会主动往剪贴板里写SVG格式。而且浏览器何时读取剪贴板里的哪些格式，不是我们能完全控制的，即便新版Chromium通过navigator.clipboard.read()能读取更多MIME类型，也要求页面处于聚焦状态、用户明确授权，企业环境下还受浏览器版本和组策略限制。让所有工程师都升级到特定浏览器版本，这个推广成本在芯片厂里极高。
这条路线我尝试过，最后的结论是：可以作为探索方向，但不适合作为主方案落地。它更适合Electron一类由企业完全控制的桌面壳子里做，纯网页端走不通。
2.2 路线B：EMF中转，后端转换后注入SVG
这是我能落地且最推荐的一条路。思路是：不跟浏览器的粘贴限制对着干，而是在中间加一个转换层。工程师还是从CAD里复制，但剪贴板里那份EMF被一个常驻的剪贴板辅助程序捕获，辅助程序调用转换服务把EMF变成SVG，然后把SVG作为text/html格式写回剪贴板。等工程师切到浏览器里Ctrl+V时，浏览器发现HTML片段里有一段inline SVG，直接就能显示成矢量图。
这条路线最大的好处是：工程师的操作习惯完全不变，还是复制粘贴两步；TinyMCE端只需要加一个插件，在粘贴事件里放行SVG标签即可。
中转方案可以做桌面级（系统托盘程序），也可以做服务级（文档系统后台转换）。根据企业网络架构选型即可，下文会展开两套落地实现。
2.3 路线C：前端DXF解析，直接在浏览器里渲染
有人会想，既然CAD的本质数据是DXF/DWG，能不能前端直接解析然后输出SVG？比如用dxf-parser这种JavaScript库，把DXF里的实体转成SVG路径。
这条路轻量、无后端依赖，适合做一个"CAD预览器"或小工具，但作为企业级方案有几个坑：首先是DWG格式是闭源的，前端解析基本只支持DXF；其次芯片厂图纸往往包含大量自定义实体、代理实体、超级填充，前端解析器很容易烂尾；再有就是性能，一张动辄几万条线段的版图，纯前端解析加DOM渲染，浏览器直接卡死。
所以我的判断是：路线C适合做"快速预览"和"轻量上传"，不适合做"粘贴输出"的核心链路。真正要