企业官网建设流程全解析

做机械行业网站系统维护这些年，我被问得最多的不是服务器又挂了，而是“我在Word里排得整整齐齐的说明书，怎么一粘到后台的UEditor编辑器就乱成一锅粥”。UEditor，百度开源的那个老牌富文本编辑器，到现在还在大量机械行业官网、CMS和企业门户后台里服役；Word更是机械工程师离不开的生产工具。这俩凑到一起，问题就格外多：表格挤成一团、图片消失、公式变空白、字体行距全乱。这篇文章就围绕“机械行业UEditor处理本地Word文档”这个场景，把图片、表格、公式、段落样式这几个硬骨头逐一拆开，讲清楚问题出在哪、处理原理是什么、可落地操作怎么做，最后把编辑们常踩的坑整理成一份速查表，给同行直接抄作业。

1. 为什么机械行业的后台里，UEditor和Word这对组合拆不开

1.1 UEditor在机械行业内容生产中的实际地位

先说现状。UEditor是百度开源的项目，虽然官方维护节奏早就慢下来了，但机械行业里大量老系统——官网CMS、企业门户、设备档案系统、经销商管理平台——都在用1.4.3这个版本左右的UEditor。原因不复杂：稳定、部署简单、界面符合后台人员的使用习惯，而且技术团队一般没有动力为内容部门重写一套新编辑器。内容生产部门那边，从工程师到技术编辑，几十年来都是先写Word初稿、走审批、定稿，最后再把文本贴到后台发布。这个流程在公司内部已经固化，不是哪次技术升级就能轻易改变的。

机械行业的内容和互联网公司的“新闻稿式”内容不一样，它重度依赖结构化信息。设备参数表、验收单、BOM物料清单、安装尺寸图、扭矩对照表、材料牌号对照表，这些东西在Word里排版得整整齐齐，编辑的期望是原样搬进网页。但UEditor对Word粘贴的支持其实有自己的历史逻辑，它确实做了一批清洗工作，只是默认配置和机械行业文档的复杂程度完全不匹配。用默认配置去承接一篇动辄几十张图片、十几张大表格、好几个公式的设备说明书，不乱才怪。

1.2 本地Word内容进入UEditor的三条典型路线

第一条路线是直接复制粘贴，这也是用得最多、最让人挠头的一条路。在Word里Ctrl+C，到UEditor里Ctrl+V，浏览器会把剪贴板里的“HTML片段 + base64图片 + Word私有样式”一股脑塞进编辑器。这时候编辑器里看到的东西已经不是纯文本，而是一堆带Word私有标记的伪HTML。图片以base64数据流的形式存在，表格保留固定像素宽度，MathType公式通常是OLE嵌入对象，浏览器根本识别不了。这些因素叠加在一起，就成了大家口中那个“乱”。

第二条路线是UEditor工具栏自带的“Word粘贴”按钮。它本质上触发的是pastePlain事件，把粘贴内容先转成纯文本再插入。这个按钮适合那种只想要文字内容的场合，但机械行业技术文档一旦变成纯文本，表格结构、层级编号全部报废，编辑们真正想用它的场景其实很少。

第三条路线是后台提供“导入Word文件”功能，用户上传.doc或.docx，后端用Apache POI或docx4j解析后转成HTML填回编辑器。这条路听起来最理想，实际却很折腾。POI对复杂表格、公式、图片的处理能力有限，经常出现表格列宽错乱、图片偏移、公式丢失的情况，开发成本不低。我也试过用LibreOffice无头模式把Word转HTML，复杂文档一样一塌糊涂。所以最终，绝大多数机械行业站点还是回到了“直接粘贴 + 前后端脚本清洗”这条路上来，后面所有讨论也以此为主线。

2. 排版“硬伤”的源头：Word剪贴板里的伪HTML与机械文档特性

2.1 剪贴板中到底有什么

从Word里复制一段带表格、带图片的内容到浏览器，按F12看编辑器DOM，你会看到大量类似这样的结构：

<p class="MsoNormal" style="margin-bottom:0cm;line-height:150%;mso-pagination:widow-orphan;mso-margin-top-alt:auto"> <o:p>&nbsp;</o:p> </p> <table class="MsoNormalTable" style="width:486.0pt;border-collapse:collapse;margin-left:6.75pt" border="0" cellpadding="0"> <tr style="height:18.0pt"> <td width="128" style="width:96.0pt;border:solid windowtext 1.0pt;padding:0cm 5.4pt 0cm 5.4pt">

这些mso开头的属性、o:p标签、windowtext颜色、pt单位的固定宽度，就是“乱”的根源。UEditor的filterInput固然会过滤掉一部分危险标签和危险属性，但对样式清理来说，它的处理程度远远不够，尤其是老版本1.4.3的UEditor，几乎是把大部分Word私有样式直接保留。

分页符和分节符在Word里有自己的XML结构，到了剪贴板里经常变成object标签或空的position标记，粘贴进来后页面会出现莫名其妙的空白行。批注内容和修订痕迹也可能残留成黄色背景标记。这些都属于只有靠人工或脚本清理才能解决的东西，单靠编辑器内置过滤根本压不住。

2.2 机械行业文档的三个典型特征及带来的麻烦

机械行业技术文档最典型的就是表格密集。设备参数表、检验记录表、材料对照表，动不动就是十几行十几列，还大量存在单元格合并。Word里做好的固定列宽，粘贴到UEditor后，再宽的表格也会被浏览器按容器宽度压缩，整个表格挤成一团；反过来，有的表又会把页面直接撑出横向滚动条。之前一个项目里，客户把一张A3幅面的设备总装履历表粘贴进来，表格横向占了一千多像素，手机端直接崩掉，这就是没做表格清洗的结果。

其次是图片多且种类杂。CAD截图、三维模型渲染图、现场照片、扫描件、设备铭牌照片，五花八门，图片尺寸也参差不齐。Word粘贴时，这些图片会变成一行行base64串。一张手机拍的照片动辄几MB，贴完编辑器卡半天，保存时整篇HTML里全是data:image，数据库字段很快就顶不住，前端页面打开更是慢如蜗牛。

最后是公式特殊。机械行业不像数学论文那样堆满公式，但公差配合、形位公差、强度校核、齿轮参数计算这些场景，经常要动用公式工具。不少工程师习惯用MathType或AxMath。这类公式在Word里是OLE嵌入对象或者域代码，不是普通文本。直接复制，浏览器根本不认，粘贴到UEditor后往往变成空白或一段乱码，这就是很多人说“公式贴没了”的真实原因。热词里那句“在word内用axmath插入公式，跳出的是math”，其实是工具冲突——两台公式工具都装了，OLE对象的默认宿主被某一个抢占，插入公式时弹窗错乱。但不管弹出的是哪个，到了UEditor这里待遇都一样：必须转成图片或LaTeX文本，否则一定丢。

3. 实操：让Word内容在UEditor里“活过来”的完整处理流程

3.1 图片处理：base64数据必须转成真实文件

先说原理。Word粘贴进来的图片，在浏览器端会变成以data:image开头的base64数据。base64的好处是自包含、不依赖服务器，坏处是体积比原始二进制膨胀约33%，而且无法走缓存。机械行业文章图片本来就多，一篇设备说明书三四十张图不稀奇，如果全部以base64形式存进数据库，数据库和页面都扛不住。

我的处理方式分两步。第一步，在编辑器配置里限制单张图片体积：

UE.getEditor('container', { wordImageSizeLimit: 1024 * 1024, pastePlain: false });

把wordImageSizeLimit设为1MB，超过这个大小的粘贴图片会被编辑器拦截并提示“图片过大无法粘贴”。这个配置对直接从剪贴板来的data:image不总是生效，但能拦掉一部分大图，已经能缓解不少压力。

第二步最关键，表单提交前统一做一次“base64转文件”处理。遍历文章HTML中所有img标签，凡是src以data:image开头的，全部提取出来，用Blob方式批量上传到服务器，拿到新URL后替换原来的img。这一步强烈建议机械行业站点必做。

function dataURLtoBlob(dataUrl) { var arr = dataUrl.split(','); var mime = arr[0].match(/:(.*?);/)[1]; var bstr = atob(arr[1]); var n = bstr.length; var u8arr = new Uint8Array(n); for (var i = 0; i < n; i++) { u8arr[i] = bstr.charCodeAt(i); } return new Blob([u8arr], { type: mime }); } function contentImagesToServer(editor) { var html = editor.getContent(); var reg = /<img[^>]+src=["'](data:image\/[^"']+)["']/gi; var list = []; var match; while ((match = reg.exec(html)) !== null) { list.push({ src: match[1], tag: match[0] }); } if (!list.length) { return Promise.resolve(html); } var form = new FormData(); var stamp = Date.now(); list.forEach(function(item, index) { form.append('files', dataURLtoBlob(item.src), 'paste_' + stamp + '_' + index + '.png'); }); return fetch('/api/upload', { method: 'POST', body: form }).then(function(res) { return res.json(); }).then(function(result) { result.urls.forEach(function(url, index) { var placeholder = 'ueditor_site_paste_img_' + index; html = html.replace(list[index].tag, '<img src="' + placeholder + '" alt="" />'); }); result.urls.forEach(function(url, index) { html = html.replace('ueditor_site_paste_img_' + index, url); }); return html; }); }

这里有几个实际开发中容易踩的点。第一，用占位符替换再统一换回URL是必要的，否则连续对HTML字符串做replace时，早期替换的结果可能污染后续匹配的原始img标签。第二，上传接口一定要校验文件类型和大小，防止有人绕过前端直接调接口塞恶意文件。第三，图片后缀按原mime决定，后端最好重新生成文件名，不要直接存客户端传上来的文件名，避免路径穿越和重复名覆盖。第四，站点访问量大就考虑把图片单独存目录或对象存储，不要一直堆积在应用服务器的临时目录里。

另外还有一个经验：Word里的图片经常是“缩放显示”的，图片实际像素很大但显示尺寸小。转存成真实文件后，前端最好统一给内容区图片加max-width:100%，防止大图撑破版面。

3.2 表格清洗：去掉Word锁定的宽度与内联样式

表格是机械行业文档的重灾区。处理思路不是删表格里的数据，而是把Word强加的固定宽度、私有样式、奇怪边距全部清掉，再按网页标准重新定义样式。我写过一个清洗函数，每次粘贴后或保存前跑一遍：

function cleanTables(html) { var doc = new DOMParser().parseFromString(html, 'text/html'); var tables = Array.prototype.slice.call(doc.querySelectorAll('table')); tables.forEach(function(table) { table.removeAttribute('width'); table.style.cssText = ''; table.style.width = '100%'; table.style.maxWidth = '100%'; table.style.borderCollapse = 'collapse'; var cells = Array.prototype.slice.call(table.querySelectorAll('td, th')); cells.forEach(function(cell) { cell.removeAttribute('width'); cell.removeAttribute('height'); cell.style.cssText = ''; cell.style.border = '1px solid #888'; cell.style.padding = '6px 10px'; cell.style.textAlign = 'center'; cell.style.verticalAlign = 'middle'; }); }); return doc.body.innerHTML; }

用的时候注意，别以为删掉td上的width属性就完事，内联style残留的宽度仍然会生效，所以style.cssText要一并清空再重设。机械行业参数表几乎都是“短数据对齐排列”，单元格内容如果顶在左上角，整体看上去非常业余，这正是热词里“word中粘贴的表格，单元格中的内容未居中”的根源。统一设置text-align:center和vertical-align:middle能解决九成问题，少数长文本列再单独改成左对齐即可。

处理跨页续表这个热词时要说清楚：Word里的“跨页续表”是表格分页时的表头重复，但网页没有分页概念，表格在页面里是连续滚动的。所以从Word粘贴过来的续表只是多了一堆重复表头行，清洗时人工把后续重复的表头行删掉、只保留第一组表头即可，脚本很难百分之百识别，需要人工判断。

关于“word表格列宽无法拖动”这个热词，其实不是拖不动，而是Word粘贴过来的td带有固定width属性加内联width样式，UEditor可视化的拖拽改列宽操作会被旧值覆盖。把旧宽度清掉后，拖拽功能基本恢复正常。如果表格确实多且复杂，建议给表格外面套一个overflow-x:auto容器，这样在窄屏下也不会把页面顶爆：

var wrapper = doc.createElement('div'); wrapper.style.overflowX = 'auto'; table.parentNode.insertBefore(wrapper, table); wrapper.appendChild(table);

至于热词“poi设置word表格单元格宽度”，那是用Apache POI在Java后端读取和生成docx文件的场景。POI 4.x以后，老式doc用HWPF，docx用XWPF，设置单元格宽度是cell.setWidth("2000")，单位是Twips。但说实话，POI生成的HTML同样存在样式兼容问题，我一般不建议用POI做排版级转换，顶多用它抽取纯文本和图片列表，真正的排版清洗还是交给前端来做更灵活。

3.3 公式处理：OLE对象转图片或LaTeX的取舍

公式问题确实是机械行业文档独有的“老大难”。Word里的MathType、AxMath公式不是普通文本，而是OLE嵌入对象加一段域代码。复制到剪贴板时，浏览器拿不到可展示的HTML，粘贴到UEditor自然就是一片空白，少数情况会残留一个object占位符，宏观上看就是“公式丢了”。

我们项目里实际用过三套方案，按成本和效果排序如下。

第一套是轻量人工方案。文档量不大的时候，让编辑在Word里直接把公式截图成图片，再连同正文一起复制粘贴。操作上先调整Word显示比例到100%，截图粘贴，或者用MathType工具栏自带的导出图片功能。这个方案解决“丢失”问题，公式呈现清晰，排版也稳定，缺点是不能在网页里重新编辑公式。但对机械行业大部分固化公式来说，这个缺点可以接受。

第二套是批量转LaTeX方案，适合公式数量大、编辑愿意做一次性转换的团队。MathType支持批量导出LaTeX，AxMath也有类似功能。操作路径一般是MathType的“Convert Equations”或“Export to LaTeX”，把选中公式全部转成LaTeX字符串。转换后，把LaTeX代码连同文字一起粘进编辑器，前端再配合UEditor的公式插件（kityformula）或MathJax渲染。要特别注意，MathType导出的LaTeX通常包含较多上下文，比如基础的\frac、\sqrt这些，而机械行业常用的公差配合符号、几何公差符号（位置度、同轴度等）不一定能被公式插件原生支持，需要额外处理符号映射。

第三套是前端交互式公式录入。如果站点本身就有“编辑要频繁录入公式”的需求，不如直接在UEditor里集成公式录入插件，编辑用工具栏按钮打开公式编辑面板，录完插入正文，存储时统一用LaTeX文本。后续维护成本最低，但历史Word文档迁移时还是得先做一次转图片或转LaTeX的批量处理。

我的实际感受是，最省心的还是图片化方案。公式肉眼看起来清晰、排版稳定，不依赖前端渲染，改动时重新截图替换就行。机械行业设备说明书里的大部分公式其实是固定的，比如材料强度校核、齿轮模数计算这类内容，出了问题重截图的成本很低。如果团队决定走LaTeX化路线，收益在远期：内容可搜索、可复用、渲染可控，但前提是前端公式渲染方案稳定，不要出现公式变成一行LaTeX源码堆在页面上的尴尬。

3.4 段落样式清理：清除Word私有标记，恢复可读排版

表格、图片、公式解决后，还剩下看起来不起眼却很影响观感的段落样式。Word复制过来的段落大量带p标签的class和style，像MsoNormal、line-height:150%、mso-pagination、文本底纹，不清理的话，正文呈现一种“编辑器里像Word、页面上又不像Word”的四不像状态。

我常用的清洗策略包括：把style里所有mso开头、windowtext这类Word私有颜色值清掉；把o:p标签连同内部空格替换成普通空格；杀掉条件注释块，比如 和 ，这些是Word域代码的残留；清理后让正文继承CSS里预设的p、table、img样式，而不是依赖页面里那份内联样式。

function cleanWordStyle(html) { return html .replace(/style="[^"]*(?:mso-|windowtext|topline|bottomline)[^"]*"/gi, '') .replace(/<o:p[^>]*>[\s\S]*?<\/o:p>/gi, ' ') .replace(/<!--\[if[^>]*>[\s\S]*?<!\s*\[endif\]-->/gi, '') .replace(/class="Mso[^"]*"/gi, ''); }

这段正则不能在生产环境一刀切，因为有些样式确实要保留，比如用户手动加的加粗、斜体、颜色。我的做法是：编辑器工具栏保留一个“清除格式”按钮，让编辑在粘贴后先点一次全部清除，再用编辑器自带功能重新排版。这种方式看起来“笨”，但对机械行业最可控。因为Word文档来源五花八门，有老工程师用了十年的模板，有外部传过来的扫描版OCR文本，颜色、字体、底纹千奇百怪，一律清掉再排版比智能保留更靠谱。

热词里提到的“word目录生成后，1级标题和2级标题最右边页码没有对齐”，这本质是Word排版端的问题，不是UEditor的问题。但机械行业技术编辑经常遇到，这里顺手说一句。目录页码不齐大多是目录的制表位设置问题，在Word里右键目录选择“调整目录”，或者直接更新整个目录，让Word重新按各级标题的制表位分配页码位置；如果是手动敲空格和点线做出来的伪目录，那基本只能重排。这和UEditor无关，但既然不少人被折磨，说明它确实是文档处理链路里的一环。

4. UEditor配置与后端接口的配合调优

4.1 值得关心的几个关键配置项

UEditor的配置长年躺在ueditor.config.js里，很多机械行业站点从部署之日起就没动过。这里挑几个和Word使用体验直接相关的：

配置在脚本初始化时传入：

UE.getEditor('container', { wordImageSizeLimit: 1048576, pastePlain: false, maximumWords: 100000, catchRemoteImageEnable: true });

需要提醒的是，老版本UEditor的catchRemoteImageEnable只对http开头的远程图片有效，对data:image的base64无效，所以base64转文件还是要靠自己写提交前处理。

4.2 粘贴预处理与提交时二次清洗

光配置不够，还要在代码层面给编辑器加上粘贴预处理。UEditor有监听器，可以在粘贴事件后立刻拦截并修改内容。比如粘贴后马上调用cleanTables和cleanWordStyle：

editor.addListener('afterpaste', function() { setTimeout(function() { var html = editor.getContent(); html = cleanWordStyle(html); html = cleanTables(html); editor.setContent(html); }, 50); });

这招虽然粗暴，但很有效。有一个细节要提醒：afterpaste里使用setContent会重置编辑器光标位置，用户刚粘贴完，光标可能跳到文章开头。更精细的做法是在粘贴前记录光标位置，粘贴后用range恢复，但对普通编辑来说，粘贴完点一下正文重新定位成本很低，多数能接受。

保存前再跑一次完整清洗是最稳妥的。前端提交表单时，用editor.getContent()拿到HTML，依次执行图片转文件、表格清洗、样式清理三个函数，把最终HTML作为表单值提交。后端再对img标签做一次安全校验，比如检查src是否是白名单内的域名、是否带http或https协议，防止XSS注入。这一步不能省略，前端脚本可能被绕过，后端一定要有白名单校验。

4.3 后端图片落库与URL替换

后端主要工作就是接收前端批量上传的图片，校验后存储并返回可访问的URL列表。

@PostMapping("/api/upload") public Map<String, Object> upload(@RequestParam("files") MultipartFile[] files) { List<String> urls = new ArrayList<>(); for (MultipartFile file : files) { String ext = FilenameUtils.getExtension(file.getOriginalFilename()); if (!"png,jpg,jpeg,gif,webp".contains(ext.toLowerCase())) { return error("非法文件类型"); } if (file.getSize() > 5 * 1024 * 1024) { return error("单张图片不能超过5MB"); } String fileName = UUID.randomUUID().toString().replace("-", "") + "." + ext; file.transferTo(new File(uploadDir, fileName)); urls.add("/uploads/" + fileName); } return success(urls); }

注意字段名files要和前端FormData里的append名一致。URL替换完成后，前端建议给返回的img统一加class，比如content-img，方便后期统一做懒加载、灯箱预览、图片统计等功能。我还建议后端在保存正文HTML时，顺手把正文里的图片URL抽出来插入一张图片关联表，这样以后做文章配图管理、缩略图裁剪都方便，不用每次都全文正则去抓。

5. 常见问题与排查实录

5.1 机械行业编辑踩坑速查表

下面这张表是我在多个机械行业项目里反复验证过的，基本覆盖内容编辑日常能遇到的绝大多数问题。

5.2 我这些年固定下来的几条工作习惯

第一，永远保留“纯文本粘贴”入口。即使已经有清洗脚本，总会遇到各种无法预料的意外格式，让编辑在特殊情况下能一键回到最原始的状态，这比任何智能解析都可靠。第二，每次上线新的清洗规则，先用一批老文档做回归测试，确认常见排版能正常通过，别直接在生产环境冒风险。UEditor版本太老，很多正则和DOM操作在不同浏览器上表现不一致，哪怕项目里清一色Chrome也会有细微差异。第三，如果公司预算允许，后台发布系统最好能把Word文档先统一转成PDF再由编辑人工核对一遍。PDF格式固定，作为中转稿比直接拿Word反复粘贴更靠谱，这个动作能省掉大量跨部门扯皮。

顺带提一个最能“偷懒”的动作：让Word里的内容在复制前先全选、点一次清除格式，再粘贴进UEditor。这个动作能过滤掉至少一半的坑。我见过最顺的内容编辑，每次都是在Word里先把字体统一、行距统一再复制，后台几乎不用改。反过来，越是在Word里精心排版的文档，粘贴到网页后往往越是惨不忍睹。所以处理UEditor和Word这对组合，最大的技巧其实是：别让Word替网页做排版。