1. 内容整体设计与思路拆解站群编辑的稿子门接手芯片制造站群的后台维护后我收到最多的投诉不是什么服务器高负载、数据库锁死而是编辑们一句从Word复制过去的稿子怎么一粘贴就全乱了这个问题听起来像是操作不当但当你面对几十个编辑、每天要处理上百篇从Word复制来的行业资讯、技术白皮书摘要、展会通讯稿时就会发现这不是偶发的小毛病而是一个实实在在地影响内容生产效率的系统性 bug。说得直白点站群的内容流转高度依赖 Word 作为初始载体编辑们习惯先在 Word 里拟定稿件、审核修改再复制进网站的富文本编辑器。一旦复制-粘贴这个动作在KindEditor上水土不服整个采编链条就会卡壳。1.1 核心需求解析站群采编场景为什么要较真 Word 兼容性先说一个事实富文本编辑器比如 KindEditor的核心定位是浏览器里的 Word 替代品但替代并不等于兼容。过去我会觉得 Word 兼容性问题无非是排版有点丑格式有点乱这样的小事可真正接入了垂直行业站群之后才意识到这个问题会直接拖累业务。以我们运营的芯片制造相关站群为例内容有相当大体量来自官方白皮书、协会刊物、供应链解决方案文档原始素材几乎全是 Word 文件。编辑的工作流是这样的在 Word 里把文章折好套上格式然后整篇复制进入后台 KindEditor 粘贴再补个标题、加个摘要、配个导语图。如果粘贴出来的内容是干净的纯文本最多是重新排一下段落问题不大。但实际情况是从 Word 复制出来的内容带着一个富文本炸弹——隐藏的样式标签、晦涩的命名空间、无厘头的行内样式、大量用不到的空段落。这些东西一进 KindEditor 的源代码模式就能看到天书在可视化模式下则表现为字号忽大忽小、行距参差不齐、表格扭曲、甚至整页出现灰色的不可删除边框。这个问题的严重性在单站时代还能靠编辑手工清理但站群化之后一个后台连八到十个垂直站点每个站点的模板宽度、字体基线、文章容器样式都不同同一篇 Word 稿子在 A 站显示正常在 B 站可能就直接冲出容器。所以说白了这是一个一次粘贴多处显示不可控的工程问题而不是简单的帮用户清理一下格式的体验优化。1.2 为什么必须自己动手而不是等官方补丁很多人会说KindEditor 不是有过滤机制吗不是可以开启 filterMode 吗直接打开不就完了坦白说我在接手初期也是这么想的。后来仔细翻了源码和数据才发现 KindEditor 的过滤器定位在通用净化它能拦住普通的 script、iframe、事件属性能剥离一些明显的非法标签但对 Word 那一套来自 OOXML 世界观的标记语言基本可以说是知道有这个事但没能力处理到位。毕竟 KindEditor 最初面对的编辑器环境简单多了那个年代的 Word 版本和现在跑在 Windows 11 上的 Microsoft 365 已经完全是两代人。再者说站群的发布时间窗口非常紧。芯片制造行业的内容有一个特点热点一出现比如产线扩产、设备禁令、材料涨价各站点要在几个小时内完成转载与二次创作。黄金时间一过流量就散了。这种情况下我根本没有耐心等官方或第三方插件来适配一个无限版本的 Word 粘贴内容。靠人不如靠己必须自己写一套覆盖面广、经得住实战的 Word 粘贴清洗方案而且要能跟 KindEditor 的现有 API 无缝集成。这套方案的设计目标拆开看有三条还原可读性让 Word 内容粘贴进来后至少在可视化编辑状态下看到一个干净且近似用户预期的版面而不是一堆乱糟糟的嵌套标签。保证存储一致性进入数据库的内容必须是最小化、语义化、可复用的 HTML不能每个编辑贴一次就存一份几十 KB 的垃圾代码否则后续全文检索、静态化生成、多站点推送都会深受其害。不影响编辑原有操作习惯编辑该复制就复制该粘贴就粘贴不应该逼着他们先去清除格式或纯文本粘贴绕一圈那是在降低内容团队的效率而不是解决问题。2. 核心细节解析Word 粘贴内容的真面目到底是怎样的在动手写清洗函数之前我先做了一件事把十几个不同版本的 Word 文件复制到浏览器里然后用 KindEditor 的源代码模式把粘贴结果导出来逐个标签去对。看完之后我只有一个感觉——Word 输出到剪贴板的 HTML不是给人看的是给 Word 自己看的。2.1 Word 的 mso- 样式体系和命名空间如果你从 Word 复制一段文字然后粘贴到任何能查看源码的编辑器中会看到大量以下这种结构!--[if gte mso 9]xml o:OfficeDocumentSettings o:AllowPNG/ /o:OfficeDocumentSettings /xml![endif]-- p classMsoNormalspan stylemso-spacerun:yesnbsp;nbsp;nbsp; /span b stylemso-bidi-font-weight:normal芯片产能/b span langEN-US stylemso-ansi-language:EN-US.../span/p这些o:p、w:...、mso-前缀的属性是 Word 内部文档模型的序列化产物。Word 需要它们来还原自己在文档中的排版、分页、修订、域代码等信息。但浏览器不需要KindEditor 更不需要你的 CSS 模板更不需要。问题在于这些标签和属性并不会被现代浏览器显示出来它们在大部分情况下是隐形的。于是用户在 Word 里看到的版面似乎正常复制粘贴到 KindEditor 的可视化区域后Word 的私有样式又被浏览器渲染引擎以可感知的方式部分呈现比如莫名的空格、多余的空行、奇怪的斜体、表格边框显示不出来之类的现象。这里有一个关键认知Word 转出的 HTML 里有很多双重保险冗余。例如它既能用一个style块里的.MsoNormal定义段落样式又会在每个p上重复写一遍margin-bottom、line-height等行内样式。浏览器虽然能在一定规则下解析但一旦这些规则被站点的模板 CSS 干扰呈现出来的观感就完全失控。为了让你直观体会一下我贴一段从 Word 2016 复制出的一小段样稿的原始 HTML做了脱敏精简内容不过一两行文字html xmlns:ourn:schemas-microsoft-com:office:office xmlns:wurn:schemas-microsoft-com:office:word xmlns:mhttp://schemas.microsoft.com/office/2004/12/omml xmlnshttp://www.w3.org/TR/REC-html40 head meta charsetutf-8 style font-face { font-family:等线; } font-face { font-family:宋体; } p.MsoNormal, li.MsoNormal, div.MsoNormal { margin:0cm; margin-bottom:.0001pt; text-align:justify; text-justify:inter-ideograph; font-size:10.5pt; font-family:等线,serif; } /style /head body div p classMsoNormal styletext-indent:21.0pt; span stylefont-size:12.0pt;font-family:微软雅黑,sans-serif; 半导体设备支出预计将在未来五年内持续增长 /span /p /div /body /html请注意这才两行字。要是你粘贴的是一篇五千字的技术分析这套冗余会成倍放大生成的 HTML 体积可能是正文的 10 倍以上。你可以想象一下站群后台每天涌入几十篇这类内容数据库里会积攒多少垃圾。2.2 自带的过滤模式到底挡不住什么KindEditor 的 filterMode 开启之后原则上会去掉script、style、on*事件属性也会把b换成strong之类的规范化处理。但它的策略是基于一个通用标签白名单它并不理解mso-前缀的含义。举个实际例子Word 列表粘贴过来经常会出现这样的结构ul stylelist-style-type: undefined; li stylemso-list: Ignore;.../li /ul这个list-style-type: undefined是 Word 典型的半吊子输出。浏览器解析到undefined的时候直接放弃列表符号于是编辑看到的是一组没有任何项目符号的伪列表KindEditor 的过滤器又认为list-style-type本身并不违规于是照单全收。最后清单变成了一坨没有层次感的文字。再比如表格。Word 表格看似严谨实际转出的 HTML 里充斥着td的width、height、valign以及 nestedtable结构。站点模板通常有自己的表格样式比如斑马纹、边框、圆角但 Word 的内联样式优先级更高一下就把模板的优先级压住了。结果就是表格在编辑器里看是一个样在前台页面又是另一个样。更麻烦的是行内图片。Word 里插入的图片粘贴到浏览器剪贴板时大多会转为 base64 编码的图片数据。如果编辑顺手粘贴了十张图编辑器里瞬间多了几十 KB 的 base64 数据这个时候 KindEditor 自带的过滤能力根本无法处理这些二进制内容它只知道这是img标签不关心 src 是 URL 还是 data。我见过最离谱的一次一篇三千字的稿子粘贴后HTML 源码足有 470KB光是 base64 图片占掉 90%整个后台响应都跟着变慢。2.3 为什么看似干净的粘贴会在渲染时突然崩掉这要从浏览器的 HTML 解析器说起。Word 输出的 HTML 带有大量o:p这样的标签在 HTML5 的解析规范里属于未知标签浏览器会把它当成内联元素或干脆按默认样式处理但它们的数量一旦多了加上嵌套不闭合、空白节点混乱渲染引擎会花费更多时间做布局计算。更关键的是KindEditor 编辑区域是一个 contenteditable 的 iframe。浏览器对contenteditable 区域的 DOM 变化非常敏感。当你一次性插入一个又深又杂的 DOM 树时编辑器的光标定位、撤销栈、选区状态都可能被搞乱。编辑可能一粘贴完发现光标不见了或者发现前一秒的撤销操作把整个页面清空了。还有一类是隐形字符问题。Word 里常见的弯引号 、短破折号–、不同断空格nbsp;等在 Word 内部有自己的 Unicode 编码。这些字符粘贴到网页后如果站点数据库是 GBK 编码或某个老的转码链路不完整就会变成问号乱码。站群后台为了兼容老数据经常是UTF-8 存储 GBK 页面输出的混合模式这时 Word 特殊字符就成了一颗定时炸弹。一句话总结根因Word 输出的是文档对象模型而网页需要的是语义化内容模型这两者之间的翻译工作KindEditor 干不了必须我们自己干。3. 工程化解决思路三层清洗架构是怎么回事动手写代码之前我最先明确的一点是不追求在所有环节都做到极致但必须在每个环节都设防。所以我设计了三层清洗架构每一层解决一类特定问题层层递进最终保证进入数据库的是干净的、能被站群任意模板消费的 HTML。3.1 第一层粘贴入口的前置拦截第一层也是最重要的一层发生在用户按下 CtrlV 的那一瞬间。KindEditor 本身没有提供粘贴前重写 HTML的高级钩子但我在实际开发中发现可以直接接管 iframe 所在文档的paste事件。思路是这样的内容不是浏览器自动粘进去的而是我们借过来的。在 paste 事件触发时获取剪贴板里的 HTML 内容先经过清洗函数处理处理完再用insertHtml或execCommand(insertHTML)手动插入到光标位置同时阻止浏览器的默认粘贴行为。这里的操作要点是event.clipboardData.getData(text/html)是一个纯字符串不是 DOM 对象。而字符串处理对HTML 解析来说是不靠谱的——正则表达式可以删标签但无法理解嵌套关系。所以我坚持先用 DOMParser 把字符串转成独立的 DOM 文档再在 DOM 树基础上做遍历和清洗。这样可以规避正则处理 HTML 的诸多坑比如注释节点、CDATA、实体编码。3.2 第二层结构归一化与白名单净化在拿到 DOM 树之后清洗就不是删几个标签那么随意了而是按照我们定义好的内容模型做归一化把b、i、u这类纯样式标签映射为strong、em等语义标签。把 Word 特有的o:p、o:...、w:...命名空间标签全部移除并保留内部文本。把p的样式扁平化只保留必要的对齐、缩进等极少数属性其余全部删除。把div包裹的非段落内容按需转换为p或保留为div避免出现只包一半的截断。白名单在这里扮演核心角色我规定了一组标签 属性的允许集合凡是出现在集合之外的一律剥离。标签层面保留标题、段落、列表、表格、图片、超链接、行内代码等基础结构属性层面只保留href、src、alt、title、colspan、rowspan等少量必要属性。这样就能保证内容从源头是干净的。这一层里还有一个容易踩的坑删除属性时不能直接在原 DOM 上操作style字符串。因为浏览器会自动把 Word 里的样式拆成 CSSStyleDeclaration 对象哪怕你只想删掉mso-开头的样式也可能因为遍历期间样式对象被动态计算而出现各种意外。稳妥的做法是不解析样式值直接清空style属性再按业务需求重新设置允许的那几个样式项。3.3 第三层后端存储兜底有了前端两层之后大多数编辑的日常粘贴已经不会出问题了。但作为长期维护站群后台的人我不会把赌注全押在浏览器端。原因很简单编辑可能使用老旧的浏览器某些浏览器对clipboardData支持并不稳定。后端接口是可以被直接调用或抓包模拟的不能假设所有提交都经过了 KindEditor。前端清洗是尽力而为后端清洗是必须兜底。所以我在服务端以 PHP 为例再加了一道过滤。其实不用多复杂的框架用 HTMLPurifier 这类库即可但我额外加了一个步骤在入库前对 HTML 字符串做一次关键词级的失血式剥离凡是mso-、xmlns:、o:p这类标志性内容再次确认全部清除不允许任何一个漏网之鱼进入正文表。这一层在站群场景下还有一个额外价值它是全站点通用的最后防线。不管某个子站后来换了什么前端技术栈只要内容是从这张表里出去的就不会出现因为编辑器残留导致的样式污染。4. 实操过程与核心环节实现手写一个 Word 粘贴处理器理论讲再多不如直接上一份能跑通的代码。下面就是我最终用到生产环境的清洗函数的核心逻辑你可以直接复制到一个独立 JS 文件里作为 KindEditor 的插件加载。4.1 实现一个可用的 cleanWordHTML 函数function cleanWordHTML(htmlStr) { if (!htmlStr || typeof htmlStr ! string) { return ; } // 使用 DOMParser 将 HTML 字符串转为独立 DOM 文档 const doc new DOMParser.parseFromString(htmlStr, text/html); const body doc.body; // 第一步移除 Word 特有的注释、命名空间、样式块 [...body.querySelectorAll(style, meta, link, title, o\\:p, xml)].forEach( (el) el.remove() ); // 第二步遍历所有元素节点按白名单做归一化处理 const ALLOWED_TAGS new Map([ [B, STRONG], [I, EM], [U, SPAN], // U 标签不推荐转成普通行内 [FONT, SPAN], [STRIKE, DEL], [S, DEL], [O:P, SPAN], // 实际不会到这里前面已经删除 ]); const walker doc.createTreeWalker(body, NodeFilter.SHOW_ELEMENT, { acceptNode(node) { const tag node.tagName.toUpperCase(); if (ALLOWED_TAGS.has(tag) || tag P || tag DIV || tag TABLE || tag TBODY || tag TR || tag TD || tag TH || tag UL || tag OL || tag LI || tag IMG || tag A || tag BR || tag H1 || tag H2 || tag H3 || tag H4 || tag H5 || tag BLOCKQUOTE || tag SPAN || tag CODE || tag PRE) { return NodeFilter.FILTER_ACCEPT; } return NodeFilter.FILTER_REJECT; } }); const nodesToRemove []; while (walker.nextNode()) { const el walker.currentNode; const tag el.tagName.toUpperCase(); // 标签映射 if (ALLOWED_TAGS.has(tag)) { const newTag ALLOWED_TAGS.get(tag); const newEl doc.createElement(newTag); while (el.firstChild) { newEl.appendChild(el.firstChild); } el.parentNode.replaceChild(newEl, el); continue; } // 清理样式与无效属性 [style, class, id, lang, dir].forEach((attr) el.removeAttribute(attr)); // 按标签类型保留必要属性 if (tag A) { const href el.getAttribute(href); if (!href || href.startsWith(javascript:)) { nodesToRemove.push(el); } else { el.setAttribute(rel, nofollow); } } else if (tag IMG) { const src el.getAttribute(src); if (!src) { nodesToRemove.push(el); } } else if (tag TD || tag TH) { // 表格单元格只保留合并属性 [colspan, rowspan].forEach((attr) { if (el.getAttribute(attr) 1) el.removeAttribute(attr); }); } } nodesToRemove.forEach((el) el.remove()); // 第三步移除空段落与空行但保留表格占位 [...body.querySelectorAll(p)].forEach((p) { const text p.textContent.replace(/\s/g, ); if (!text !p.querySelector(img, a, br)) { p.remove(); } }); return body.innerHTML; }这个函数的几个关键设计点我展开讲一下使用 TreeWalker 而不是 querySelectorAll的原因在于前者可以在遍历过程中实时替换节点如果替换的是被遍历到的当前节点只要continue不继续深入子节点就不会出现迭代器失效问题。后者一次性返回静态 NodeList而替换节点后 NodeList 并不会自动更新极容易在循环中操作被移除的节点产生各种离奇 Bug。为什么要nodesToRemove延迟删除在遍历过程中直接remove()会让 TreeWalker 的迭代边界发生偏移尤其在删除大量节点时会出现跳过同级节点的情况。统一标记、统一删除可以避免这种连锁问题。为什么不保留style属性里的text-indent等段落缩进因为每篇文章、每个栏目、每个站点模板对首行缩进的定义不同。与其保留 Word 里的硬缩进引发跨站样式冲突不如让纯前端模板控制。编辑如果确实需要特殊缩进可以在 KindEditor 里用工具栏单独设置不会增加额外成本。4.2 如何把它挂载到 KindEditor 上清洗函数有了接下来就是让它作用在粘贴这个动作上。我采用的方式是在 KindEditor 初始化完成后给编辑器所在的 iframe 文档对象绑定 paste 事件。KindEditor.create(#editor, { filterMode: true, afterCreate: function () { const iframeDoc this.edit.doc; iframeDoc.addEventListener(paste, function (e) { // 只在有 HTML 数据的情况下拦截处理 const html e.clipboardData e.clipboardData.getData(text/html); if (!html) return; e.preventDefault(); const cleaned cleanWordHTML(html); // 备用方案如果清洗后为空至少保留纯文本 if (!cleaned) { const plainText e.clipboardData.getData(text/plain); this.insertHtml(plainText.replace(/\n/g, br /)); return; } // 插入清洗后的 HTML this.insertHtml(cleaned); }.bind(this)); } });这里有一个容易忽略的细节KindEditor 的insertHtml方法内部会再次经过自己的 filterMode 白名单。这意味着我们在清洗中保留的标签到了 insertHtml 这层还会被再过滤一次。为了让两层过滤不打架我建议把 KindEditor 的 filterMode 配置从默认改为更精细的设置比如filterMode: true, allowFileManager: false, allowedTags: [ p, div, br, span, strong, em, u, del, h1, h2, h3, h4, h5, ul, ol, li, blockquote, table, tbody, tr, td, th, img, a, code, pre ]设置完之后我实测下来发现filterMode对我们自定义内容的拦截率明显降低了尤其在表格和图片这两类高频场景上不再出现清洗完又被删掉的奇观。4.3 参数与性能调优的实际观察这里要特意说一个性能问题如果你的文章很长比如超过一万字DOMParser 处理本身并不慢慢的是 TreeWalker 对上千个节点逐个遍历。我最初写的版本在遍历每个元素时都会getAttribute多次实测一篇一万字的稿子清洗耗时接近 800ms虽然不至于卡死但用户会感觉到明显的粘贴停顿。后来做了两个优化把getAttribute的调用精简为一次el.attributes收集判断是否存在再取值减少 API 往返。把对style的removeAttribute操作改为统一在最后阶段做避免遍历过程中反复触发 style 属性重算。优化后同样的稿子清洗耗时降到 120-150ms 左右体感上已经接近秒粘。如果仍然嫌慢还有一个降级方案在粘贴后先用requestAnimationFrame延迟一下先插入纯文本内容再异步替换为清洗后的 HTML。但这样做会让编辑看到一次闪跳反倒不自然我个人不推荐在生产环境使用。5. 站群场景的工程化落地一次改造、多处复用单点解决只是第一步。站群的复杂性在于不同子站的配置文件、模板环境、编辑器初始化参数可能都不同。如果只在某一个后台页面上加了代码其他站点的编辑打开自己的发布后台还是会遇到同样的问题。所以得把它做成一个可复用的公共模块并经过足够全面的测试。5.1 封装成公共模块的四个要点我这边是把清洗函数 paste 拦截器抽成一个独立的 JS 插件命名为kindeditor.wordfix.js在引入 KindEditor 核心之后、创建编辑器之前加载。插件的对外接口只有一个KE.plugin[wordfix]内部用afterCreate钩子完成注入。模块化的好处是显而易见的各站点统一升级以后不管新增多少个子站只要引用同一个公共静态资源路径就自动获得 Word 兼容能力不需要每个站点单独改代码。问题快速回滚如果清洗规则出了偏差导致部分内容异常直接回滚这一个 JS 文件就能恢复不用动后端。开发一次多处受益同一套逻辑还可以复用在我们其他的富文本编辑器场景比如评论后台、邮件模板编辑不仅仅是 KindEditor。便于单独测试插件本身可以独立在测试页面上运行不依赖某个站点的业务逻辑。模块化落地时我还建议加一个开关配置比如在初始化参数里增加wordfix: true/false。主要用于紧急情况下能关闭这套自定义清洗回退到 KindEditor 默认行为。这在大型站群运营中是必要的应急手段。5.2 多模板适配需要什么样的测试矩阵站群后台的发布页面虽然都叫编辑器但前端模板却各有各的脾气。有的站点文章容器宽度是 720px有的是 960px还有的是 100% 自适应。Word 表格粘贴进来后在窄容器和宽容器下的表现差异很大。我建议在做多模板适配之前先准备一份标准的Word 测试稿包含以下几类内容中英文混排段落含弯引号、破折号、不同断空格二级/三级标题项目符号列表与多级编号列表三行三列以上、带合并单元格的表格一张小于容器宽度的图片一段加粗、斜体、下划线、删除线混合文本大段引文然后把这份测试稿分别在 Word 2013、Word 2016、Microsoft 365 的 Windows 和 Mac 版本中复制粘贴到每一个子站后台检查以下指标粘贴后可视化区域是否出现异常空行或灰底表格是否溢出容器或被压缩标题层级是否变成无差别样式图片是否变形或带边框编辑器源代码里是否还有mso-残留标签保存后前台页面显示是否正常这项工作听起来繁琐但整理成测试清单后大概半天就能跑完一次。之后每改动一次清洗规则都建议快速回归一遍这张清单避免出现修好表格、搞坏列表的打地鼠式问题。5.3 历史数据清洗与批量重建解决完新内容之后还得回头看看历年积累的老内容。站群后台运行久了正文表里大量历史文章的 HTML 都是一坨坨 Word 垃圾代码。不清理的话这些文章在做全站静态化或跨站推送时依然会把样式问题带到前台。历史数据清洗不能在线直接跑风险太大。我的做法是写一个离线脚本从数据库逐条取出历史正文套用同一套清洗规则处理后写入一个临时表核对数据量、抽样预览无误后再在低峰期一次性替换原表。这里有几个操作上的提醒先备份原始表替换失败可以随时回滚。只清洗正文主体不要动摘要、标题、标签避免影响搜索引擎已经收录的页面信息。清洗后比对 HTML 长度如果清洗后长度接近于零很有可能是这条数据里只包含了图片或特殊嵌入内容需要人工复核。站群场景下机器的自动化必须配得上人的可控性宁可慢一点也不要把数据搞丢。6. 常见问题与排查技巧实录这节要分享的是我在反复测试和生产环境运行中遇到的真实问题。每一个都是不撞南墙不知道的坑整理出来供大家参考。6.1 表格撑破容器的经典问题现象从 Word 复制一个表格粘贴后表格宽度直接超出内容区域右侧多出一截横向滚动条。原因Word 转出的表格通常带有width100%或具体的像素宽度比如width623同时每个单元格还有固定的width: 76pt之类的内联样式。当容器宽度小于表格设定宽度时浏览器会优先按内联样式渲染于是表格溢出。解决思路清洗表格时强制移除table上的width属性并让表格默认使用width: 100%这个可以由站点模板控制但为了编辑器预览不出偏差我在清洗时直接给表格加>function normalizeDivToP(divEl, doc) { const hasBlockChild [...divEl.children].some((child) { const tag child.tagName.toUpperCase(); return [P, DIV, TABLE, UL, OL, H1, H2, H3, BLOCKQUOTE].includes(tag); }); if (!hasBlockChild divEl.textContent.trim()) { const pEl doc.createElement(p); pEl.innerHTML divEl.innerHTML; divEl.parentNode.replaceChild(pEl, divEl); } }实测下来这套逻辑能覆盖 Word 2010 到 Microsoft 365 的绝大部分粘贴场景。6.5 特殊字符与乱码问题现象粘贴的中英文混排文章里引号、破折号全部变成?或â€之类的乱码。原因这个问题的根因不在清洗逻辑而在后端的数据存储与页面输出编码不一致。Word 转出的 HTML 里弯引号是 UTF-8 字节序列如果你的数据库连接字符集是 GBK 或 latin1这些字符就变成乱码。反之如果数据库存的是 UTF-8但页面输出时 header 却是 GBK同样会乱。解决方式首先在清洗函数中统一做一次实体化处理把转为quot;、转为#039;、–转为ndash;让字符不再依赖数据库编码链路。其次后端在写入前强制mb_convert_encoding到目标编码。双管齐下之后这类问题基本绝迹。写在最后的几句实在话能把 Word 兼容性问题做成一个站群级的工程化方案踩过最深的坑就是我总想用一段代码解决所有问题但事实上每一次兼容性异常都可能来自不同版本的 Word、不同操作系统的剪贴板行为、甚至不同浏览器对 contenteditable 的解析差异。我个人在实际操作中的体会是清洗规则永远要留余地尤其是对不可控的外部输入宁可多保留一点语义化结构也不要把内容强行压扁成纯文本。毕竟你做的是站群内容在编辑和前端之间还要经历多道工序每一步都可能消费掉一部分信息。最后再分享一个小技巧在正式上线前把一个 Word 稿子分别从 Windows 和 Mac 复制再分别从 Chrome 和 Edge 粘贴得到的四份原始 HTML 对比着看一遍。你会对Word 兼容性问题这件事产生新的敬畏也会更明白为什么它值得被当成正儿八经的工程来做。