Emotiona 轻尘干这行这么多年，我一直没想过一个看起来简单的富文本粘贴需求能让我折腾这么久，直到碰到“xhEditor复制Word图片到信创平台”这个组合。xhEditor本身不算新东西，很多老项目甚至政务、教育、金融类系统里到今天还在用，信创平台的浏览器环境又跟普通Chrome有差异，想把Word里图文混排的内容整整齐齐粘进编辑器里，图片还能正常显示并提交，中间全是坑。这篇文章就把我实际踩过的路、写过的代码、改过的适配逻辑完整记录下来，给还在维护这类老前端项目的朋友做个参考。
1. 项目背景与需求拆解：到底卡在哪里
1.1 一个老编辑器碰上一个新环境
xhEditor是一款基于jQuery的轻量级富文本编辑器，优点是体积小、部署简单、接口直观，很多早期系统都是用它做内容发布、通知公告、公文编辑之类的功能。它的机制很简单：初始化后把原来的textarea隐藏，替换成一个设计模式的iframe文档，用户在里面编辑内容，提交时再把iframe里的HTML同步回textarea。这套逻辑在IE时代很成熟，但放到今天的信创环境里，问题就一个接一个冒出来。
信创平台最大的特点是什么？从浏览器层面看，用户用的往往不是标准版Chrome，而是各类国产浏览器，有些默认走的是极速模式，底层是Chromium内核，有些会切到兼容模式，内核版本参差不齐。从后端接口看，平台的文件上传、鉴权、返回值格式都有定制要求，不是随便给个上传地址就能用的。从用户场景看，这类平台的日常操作大量依赖Word文档，用户习惯直接从Word里复制一段带截图、带表格、带排版的内容粘贴到网页编辑器里。
问题最集中的地方就是图片：用户从Word里复制一张截图或图表，粘贴到xhEditor之后图片不显示，或者只有一个红叉，再或者显示成一个本地文件路径。直接从系统旧逻辑看，好像是xhEditor没开启图片粘贴功能，但深入排查就会发现，这根本不是编辑器功能开关的事，而是浏览器剪贴板数据处理机制的问题。
1.2 从Word复制图文时，剪贴板里到底装了什么
要解决图片丢失，必须先搞清楚用户点下“复制”那一刻发生了什么。当你在Word里选中一段文字加图片，按Ctrl+C，这张图片并不是以独立文件的形式存在于内存里，而是会被Word封装成多种格式的数据，一起塞进剪贴板。
剪贴板里至少会有以下几种格式：纯文本text/plain、富文本text/html，有可能还有text/rtf、图片原始位图image/bmp或image/png等。我们真正关心的是text/html这一份，因为浏览器粘贴时主要解析它。Word生成的text/html片段会用一些特殊标记描述图片，常见的有img标签，src可能是file:///C:/Users/xxx/AppData/Local/Temp/xxxx.png这种本地临时路径，也可能被写成v:shape、o:OLEObject等VML格式，图片被包装成Word私有对象。更特殊的情况是，如果用户只复制了图片本身而不带文字，剪贴板会在Files里挂一个图片文件对象。
浏览器拿到这些HTML并尝试在我们页面上渲染时，出于安全限制，页面处于http或者https环境，不可能去加载一个file:///开头的本地文件。浏览器要么静默丢弃这张图，要么显示一个裂图。这就是“复制Word图片到xhEditor里看不到”的最根本原因，跟xhEditor没有直接关系，但问题刚好就出在这个使用路径上。
1.3 为什么平时从网页上复制图片没问题，从Word复制就不行
很多人会问，为什么我从浏览器网页里复制一张图片到xhEditor就能显示，从Word复制就不行？原因在于剪贴板封装格式不一样。网页复制图片，浏览器往往会在剪贴板里放一个标准的image/png或者Files对象，粘贴时能直接拿到文件内容；而Word为了让图文排版在Word自己的体系里完整还原，输出的HTML是“Word风格”的HTML，里面有大量命名空间、VML对象、Office特有的样式，图片引用还是本地绝对路径，这套东西放到浏览器的富文本环境里基本无法直接识别。
另外需要注意的一点是，Word复制出来的HTML还夹杂着大量对浏览器来说无意义的标签，比如<o:p>、<xml>、<!--[if gte mso 9]>注释、<span style="mso-xxx:...">等。如果直接允许浏览器粘贴，编辑器里会留下大量乱糟糟的隐藏节点，后续提交数据、回显、打印都会出问题。这也意味着我们不能直接靠浏览器默认的paste行为来处理Word内容，必须自己拦截剪贴板事件，从中提取有效数据，做完清洗和图片处理，再把最终HTML插入编辑器。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 方案选型：base64内嵌还是先上传再引URL
2.1 两条技术路线的核心差异
想明白图片为什么丢之后，接下来要考虑的是：图片既然无法从本地路径加载，那应该用什么方式让它在最终提交的HTML里也能正常显示。两条路线都很常见，一条是把图片转成base64字符串直接内嵌在img的src里，另一条是把图片上传到服务器得到一个新的网络URL，再把img的src替换成这个URL。
第一眼看上去base64最简单，前端把图片文件用FileReader读成DataURL，往HTML里一塞就算完事，不用增加后端接口，也不用考虑跨域、鉴权，小批量图片特别省事。但它有几个天然的弱点。一是base64会让HTML体积膨胀一截，原始图片越大膨胀越明显；二是一旦提交的HTML很长，里面塞着几十张base64图片，后端存储、列表页加载都会变慢；三是某些平台的数据接口对提交内容长度有限制，图文特别多的文章可能直接提交失败。
上传方案则要围绕后端文件服务做一层适配。前端截取到图片文件后，用FormData发起一个POST请求，把文件交给平台的文件上传接口，接口返回一个可访问的URL，我们再用这个URL替换掉HTML里的img。这条路的好处是最终库里存的是干净的网络图片地址，内容体积可控，图片管理、删除、CDN加速都有空间，更符合一套正经内容管理平台的预期。代价是联调成本更高，要处理鉴权头、接口返回结构差异、失败重试。
2.2 不同场景下的取舍判断
做技术选型最忌讳的就是不分场景无脑套方案。信创平台项目通常有几个典型特点：网络环境可能不慢但链路复杂，上传接口往往统一走网关鉴权；内容发布后图片需要被其他模块引用，甚至要支持导出、打印、微信公众号同步；发布历史数据需要保留图片资源，不能轻易丢。这些特点决定了长期维护的项目应该优先走“上传后替换URL”的方案。
但我也保留了一个兜底机制：如果上传接口正好挂掉，或者图片文件格式