百度UM粘贴Word图片不支持国密加密？三种改造方案让它合规

先回答标题里那个问题：原生百度UM不支持国密加密传输，但这件事可以改成支持，而且改完不会有明显使用差异。

我是在一个信创适配项目里遇到这个需求的。用户从Word复制图文，贴到百度UM编辑器里，图片会自动传到服务器。一开始大家只关心“能不能贴”，没人关心“图片在链路里是怎么走的”。等等保和密评要求下来，发现“粘贴图片上传”这个动作也属于网络传输，得满足国密合规要求。于是我开始追链路、翻源码、做改造，今天把整个过程完整复盘一遍。

这个内容适合两类人看：一类是正在做信创环境下Web系统适配、被“图片上传要不要国密”卡住的开发；另一类是维护老系统、编辑器用了百度UM但没想过传输加密的产品或运维。我会把原理、方案、代码和坑都写清楚。

1. 先看百度UM从Word粘贴图片时到底发生了什么

1.1 粘贴动作背后的事件链

用百度UM编辑器的时候，用户在Word里复制一段图文，然后到编辑器里按Ctrl+V，看上去是“粘贴”，实则发生了一系列事情。

浏览器会弹出一个paste事件，剪贴板数据放在clipboardData里。Word里复制的内容通常包含三种数据类型：纯文本text/plain、带格式的HTMLtext/html、还有图片文件本身Files。UM编辑器监听了这个事件，拿到text/html之后会做解析，把里面的<img>标签找出来。

这里有个关键点：如果图片是Word里的截图，复制粘贴到浏览器的时候，Chrome、Firefox这些现代浏览器不会自动把图片读成本地file://路径，而是以一个blob:开头的对象URL或者data:base64字符串出现在剪贴板里。UM拿到这些图片数据后，会交给内部的uploadImage逻辑，通过Ajax把图片POST到你配置的serverUrl上。

服务端收到图片后返回一个URL，UM再把正文里的<img>的src替换成这个URL，完成整条链路。

也就是说，从Word粘贴图片到编辑器的过程，本质上是一次图片文件异步上传。只要走网络上传，就会出现“传输内容可不可见”的问题。

1.2 图片数据在哪个环节可以被截获

图片从用户电脑到服务器，通常经过三个环节：

第一个环节是浏览器构造上传请求。这里使用的是multipart/form-data，图片的二进制内容被放在请求体里。如果网站没有启用HTTPS或国密SSL，那么客户端到服务器的请求报文就是明文，网络抓包工具能直接看到图片。

第二个环节是请求到达服务器。如果服务器前端有负载均衡、Nginx等代理层，图片数据在代理层也会被解包处理。代理日志如果记录了请求体，图片内容也会被写进日志，这个位置经常被忽略。

第三个环节是服务端把图片写入磁盘或OSS。如果没有落盘加密，数据库或文件系统里存的就是原始图片，数据库或磁盘泄露就等于图片泄露。

明白这三个环节之后，就知道所谓“支持国密加密传输”不是一个简单的开关问题，而是要确定在哪一层做国密、哪一层做应用层加密、哪一层做存储加密。

2. 国密算法在信创环境里到底卡了什么

2.1 国密体系与图片上传的对应关系

信创环境里经常说“国密”或“商用密码”，这里涉及的最基础的算法是SM2、SM3、SM4。

图片传输加密这个场景，最常用的是SM4。因为图片文件是二进制大对象，需要对称加密算法来做高效加解密，SM4的128位分组密码足够用来对文件数据流进行加密。

传输层的国密SSL也和这些算法相关。国密SSL的密码套件里会同时用到SM2、SM3、SM4，例如握手阶段用SM2做身份认证和密钥协商，用SM3做摘要，用SM4做加密通信。所以“国密加密传输”通常指的不是拿某个算法单独把报文里的图片加密，而是整个通道就是国密TLS通道。

2.2 信创合规里对图片传输的实际要求

在很多信创项目里，客户不是要求“前端用SM4加密图片再发送”，而是要求“网络传输必须符合GB/T 38636-2020《信息安全技术 传输层密码协议规范》”。翻译过来就是，建议你在TLS层使用国密密码套件。

但浏览器对国密TLS的支持一直是痛点。标准Chrome、Edge、Firefox默认不支持国密TLS套件，只有一些国密浏览器，比如密信浏览器、360国密浏览器，或者安装了国密客户端证书环境的终端才能正常工作。

这就导致很多系统即使上了国密SSL网关，管理员用Chrome一访问还是打不开页面，批评一句“信创不行”，其实不是系统不行，是浏览器没有国密功能。

所以，当有人问“百度UM是否支持国产密码算法加密传输”时，我通常会反问一句：你是打算在传输层做国密，还是在应用层做国密？这两条路答案不一样。

3. 百度UM原生支持不支持？拆开源码看一下

3.1 上传请求里没有任何国密相关逻辑

百度UM是百度开源的一款富文本编辑器，全称是UEditor Mini，通常叫UM。它的源码不复杂，核心上传逻辑在umeditor.js里。

大致流程是，粘贴图片后，UM调用内部的uploadImage方法，收集图片文件，然后使用ajax方法发起请求。核心代码大概是这样的：

UM.api.uploadImage = function (editor, files) { var formData = new FormData(); each(files, function (file) { formData.append('upfile', file, file.name); }); editor.ajax.post(editor.options.imageUrl, formData, function (result) { // 解析返回url，插入编辑器 }); };

这里没有对表单数据做过任何加密处理，也没有给fetch或XMLHttpRequest设置什么特殊头，更不存在SM4加密或国密TLS套件。UM本身只负责组装FormData并POST出去，加密完全依赖浏览器所在的环境。

结论很明确：原生的UM代码不支持国密算法加密。

3.2 为什么不能在浏览器里面直接改出国密SSL

有朋友会问，既然UM源码不复杂，那我能不能改一下上传逻辑，在前端直接用国密TLS去发起请求？答案是不能。

因为TLS协议栈是做在浏览器内核里的，JavaScript运行在浏览器环境中，你没有办法通过JavaScript代码直接控制底层TCP连接和TLS握手。即使你用WebSocket或者fetch，底层走的还是浏览器内核支持的TLS版本和套件。

除非你自己写一个原生客户端，而不是浏览器页面——但在信创OA、门户网站这类应用场景里，前端就是浏览器，你不可能要求每个用户都装一个客户端。所以普通浏览器访问的系统，要做国密传输，只能用“国密浏览器+国密SSL网关”或者“国密安全客户端”这种方式。

4. 三条改造路径：网关、前端SM4、落盘加密

4.1 方案一：部署国密SSL网关，后端服务不动

这个方案的本质是“传输层改造”。在服务器前面加一个国密SSL网关，该网关支持国密TLS套件，接受浏览器的国密SSL握手，然后把请求翻译成后端能识别的普通HTTP/HTTPS请求，再转发给原来的Web应用。

用户侧必须使用国密浏览器，或者使用支持国密客户端的终端环境。浏览器通过国密SSL向网关发起请求，UM编辑器里的图片上传请求自然也会走这条国密通道。

这个方案的优势很明显：

• 不需要改动百度UM的任何代码
• 也不需要改后端接口
• 图片到达网关之后，网关上能看到明文图片，但网关之后的网络链路通常属于内网，风险可控

缺点是：

• 普通浏览器无法直接访问，需要国密浏览器
• 网关配置需要维护双向证书或预置信任链
• 如果用户从Word粘贴的图片里面含有敏感数据，网关本身成了敏感数据的汇聚点，日志和审计要做好

我在测试环境里部署过一次国密SSL网关，配置流程大概是生成SM2根证书、签发服务端证书、把证书装进网关、网关绑定443端口并启用国密套件。配置好以后，用360国密浏览器打开系统，在开发者工具里能看到TLS版本以及密码套件名称中带有SM4-SM3字样，此时从Word粘贴图片上传，请求体在Wireshark里就是密文，肉眼无法识别图片内容。

4.2 方案二：前端用SM4加密图片二进制后再上传

如果你不想被国密浏览器绑死，还希望应用本身具备“国密加密传输”的能力，可以在上传层做文章。做法是拦截UM上传图片的流程，在读取图片文件之后，先对其二进制数据做SM4加密，再放到FormData里发给后端。

UM提供了回调机制，可以自定义上传行为。比较灵活的方式是放弃使用UM内置的imageUrl上传，改用拦截beforeUpload事件，或者直接重写UM.api.uploadImage。

具体实现思路：

第一步，引入SM4加密库。如果项目支持ES Module，可以直接用sm-crypto，它提供sm4.encrypt方法，能够对字符串或字节数组进行加密。但要注意，sm-crypto本身处理字符串更多，处理图片二进制最好使用ArrayBuffer和Uint8Array。

第二步，读取图片文件并转换为二进制数组。

第三步，把二进制数组进行SM4加密，得到密文数组。

第四步，把密文数组转成Blob，再塞进FormData。

第五步，把FormData上传到后端。

关键代码大概长这样：

import { sm4 } from 'sm-crypto'; async function encryptFile(file) { const buf = await file.arrayBuffer(); const bytes = new Uint8Array(buf); const key = sessionStorage.getItem('sm4Key'); // 登录时下发 const encrypted = sm4.encrypt(bytes, key, { mode: 'cbc', iv: ivBytes, output: 'array' }); return new Blob([encrypted]); } // 重写UM的上传方法 UM.api.uploadImage = async function (editor, files) { const formData = new FormData(); const encryptedBlob = await encryptFile(files[0]); formData.append('upfile', encryptedBlob, files[0].name + '.enc'); // 继续走Ajax editor.ajax.post(editor.options.imageUrl, formData, function (result) { editor.execCommand('insertImage', result.url); }); };

这里有一个非常容易踩的坑：SM4加密操作针对的是原始二进制数据，不要再先把图片转成base64再去加密。因为Word粘贴产生的图片有时候是base64字符串形式，有些开发者图省事直接对base64字符串做SM4加密，结果是服务端解密之后得到的是base64字符串，还要再解码一次才能得到图片，不仅多一步，体积还会膨胀。直接加密原始ArrayBuffer是最干净的做法。

服务端收到.enc文件之后，需要先解密再执行原来的保存逻辑。后端如果用Java，可以使用Bouncy Castle或HuTool提供的SM4工具类解密。解密后得到原始图片字节流，再保存到存储介质。

这个方案看起来比较“国密”，但它有一个绕不过去的问题：SM4是对称加密，加密用的密钥必须先在前端可用。如果密钥是固定写死的，那么攻击者只要逆向前端代码就能拿到密钥；如果密钥是登录后通过接口下发的，那这个接口本身还是要靠TLS或国密SSL保护。

所以我在实际项目里通常建议：前端SM4加密作为“合规增强项”，而不是把传输安全完全押在它上面。传输层仍然建议走国密SSL或至少普通HTTPS。

4.3 方案三：服务端收到图片后立即SM4落盘加密

还有一种相对简单但容易被忽视的做法是“存储层国密加密”。

百度UM上传图片到服务器之后，服务端把文件保存到磁盘或OSS。如果没有加密，原始图片会以明文形式长期留在文件系统里。很多安全事件并不是网络传输中被抓走的，而是存储端被拖库、目录扫描发现文件、或者运维人员误操作导致泄露。

我们可以对保存的文件做SM4加密，文件名也可以改为由随机数生成的无规则名称。读取图片时再解密输出，或者通过一个专门的下载接口来提供图片，而不是直接暴露静态文件路径。

这种方式不改变UM的前端行为，也不影响用户粘贴图片，但是从数据的生命周期来看，图片在落盘之后得到保护，即使服务器磁盘被拷贝出去，也不会直接泄露图片内容。

4.4 我的最终组合方案

在我负责的信创系统里，实际落地采用了两层组合：

第一层，部署国密SSL网关，终端通过国密浏览器访问系统，网络链路本身是国密加密。

第二层，服务端对上传的图片文件做SM4落盘加密，让图片在存储介质上不呈现明文。

前端没有做应用层SM4加密。原因是国密SSL通道已经覆盖了传输层，前端再加一层SM4不仅增加开发量，还引入密钥管理问题，妥协会降低稳定性。这种组合既满足密评要求，又不影响UM的正常使用。

如果你的环境里不允许使用国密浏览器，只能强制普通Chrome，那么再考虑加上方案二，让UM上传图片前先做一次应用层加密。但要注意，这种情况下国密SSL网关就不适用了，你需要评估用普通HTTPS传输密钥的方案能不能通过合规审查。

5. 实操过程中的坑与排查技巧

5.1 从Word粘贴的图片可能是base64字符串

我在测试时发现，不同浏览器从Word复制图片，UM拿到的图片数据格式不一样。Chrome在剪贴板里会提供Files对象，UM可以正常转成FormData；但有些国产浏览器兼容模式或旧版本内核，复制出来的图片src是data:image/png;base64,xxxx，UM的旧逻辑并不总是能正确提取。

如果发现粘贴图片后编辑器里出现的是乱码或图片不显示，先用浏览器开发者工具看一下network面板，看看有没有上传请求发出。如果发现数据被拼到了HTML里而不是走上传，说明UM走的是“base64直接插入”的逻辑。这种情况下要加一个转换步骤：先把base64字符串转成Blob或File对象，再交给上传流程。

简单转File的代码：

function dataUrlToFile(dataUrl, filename) { const arr = dataUrl.split(','); const mime = arr[0].match(/:(.*?);/)[1]; const bstr = atob(arr[1]); let n = bstr.length; const u8arr = new Uint8Array(n); while (n--) { u8arr[n] = bstr.charCodeAt(n); } return new File([u8arr], filename, { type: mime }); }

5.2 前端SM4加密后服务端解密失败

这种情况多半是字节序问题。SM4加密标准里，分组宽度是128位，也就是16字节。如果你的图片文件大小不是16的倍数，加密库通常会做PKCS7填充。解密的时候，服务端也要用相同的填充模式。

sm-crypto库默认处理字符串时，编码方式可能和服务端不一致。建议前端加密时指定输入输出为array，后端用字节数组接收，再用SM4的ECB或CBC模式解密，并把明文编码设置为二进制流而不是UTF-8字符串。别用默认字符串模式去处理图片文件，否则会出现解密出来是乱码或者长度错误。

5.3 国密SSL网关下浏览器兼容性排查

国密SSL网关配置完成之后，最典型的表现是“普通浏览器无法打开页面”，但国密浏览器可以。此时先不要怀疑业务代码，先用浏览器访问网关的8443或其他国密端口，看TLS握手是否成功。

如果是国密浏览器打开失败了，检查一下服务端证书链是否包含SM2根证书，以及证书是否被信任。很多网关默认只装了叶子证书，根证书没有导入到系统信任区，导致握手失败。

还有一个容易忽略的点：国密SSL握手和普通TLS握手在SNI传递上可能有差异，如果网关后面挂了多个域名，务必把SNI和证书域名对齐，否则会报证书信息错误。

5.4 测试时如何确认图片真的加密了

要看图片在传输过程中是否加密，不要只在页面上点几下，最好抓包验证。

用Wireshark抓取客户端到服务器的流量。如果使用的是国密SSL，右键点击某个TLS数据包，查看握手阶段所选用的密码套件，里面会包含SM4-SM3或ECC_SM4_CBC_SM3。再找到POST上传请求对应的TCP流，看应用数据区域。如果是明文HTTP上传，可以直接看到Content-Disposition: form-data; name="upfile"以及图片文件头JFIF或PNG字样。如果是密文，则看到的是一串不可读的字节。

如果在前端做了SM4加密，抓包时即使不加密通道，也能在数据流里看到无法直接识别成图片的密文，但要注意FormData的文件名后缀和Content-Type仍然能泄露一些信息，所以文件名建议统一混淆。

6. 百度UM公文排版场景下的额外提醒

我们这个项目里，用户从Word粘贴的内容不只是纯图片，还经常带有下划线、公式、目录格式。这里要特别提醒一句：图片传输加密只是信创改造的一部分，公文排版内容的还原度同样影响上线效果。

比如Word里的一段带下划线的文字，复制到UM时，下划线样式通常会保留；但如果用户是在下划线上打字，希望“下划线保持不动”，UM的默认行为并不总是和Word一致。这种情况下，不能怪UM“不支持国密”，这是富文本编辑器对Word格式还原的固有限制。

另外，如果Word文档中包含MathType公式，复制到UM时也会被转成图片或特殊HTML，实际上这些公式图也会走图片上传逻辑。公式图片的传输加密和普通图片完全一样，如果你的系统里公式量很大，图片请求会很频繁，国密SSL网关的并发能力要提前压测。

我后来针对这类场景，单独做了一个预处理工具，在粘贴时检测到MathType对象或特殊占位符，就自动转成高清PNG上传，同时把图片的description字段写成公式的LaTeX源，这样既保留了公式信息，又让图片走上统一的加密上传链路。效果不错，有类似需求的话可以参考。

7. 常见问题速查表

这些坑不一定哪个都遇到，但只要涉及“百度UM + 图片上传 + 国密”，大概率绕不开其中两三个。

8. 最后说点个人体会

这个问题问的是“百度UM粘贴WORD图片时是否支持国产密码算法加密传输”，我现在的回答是：默认不支持，但完全可以通过网关、前端应用层SM4、存储加密三种方式的组合来让它支持。如果你正在做信创适配，千万别只盯着前端代码，要从传输链路整体去设计。

我会优先推荐“国密SSL网关 + 存储加密”的组合，因为改动小、稳定性高、合规性也最容易讲清楚。如果审核要求应用层也有国密痕迹，再叠加前端SM4加密。前端加密不是不能做，但一定要把密钥发放通道和算法库的字节处理细节想清楚，否则上线第一天就会收到“图片打不开”的工单。

另外，安全改造不只是技术活，还要跟测评机构确认他们的测评标准是看实际加解密效果，还是看部署形态。测评机构不同，理解也会有差异，提前沟通能省掉很多返工。最后提醒一句，别忘了做回归测试，尤其是粘贴大图、多图并发、慢网络丢包这些情况，别让合规改造影响了用户日常编辑的流畅度。