VideoCaptioner 全流程视频字幕处理实战指南：语音识别、字幕优化、翻译与配音合成一站式搞定
2026/9/21 19:29:44
军工项目里的ueditor，说来都是泪。内网系统还在用1.4.3的老版本，从Word复制一篇带公式的技术文档到编辑框里，公式要么变成一串天书，要么变成小方框，要么直接消失。这个问题我前后折腾了快两周，客户现场催得急，最后才把整条链路理顺。今天把这套方案完整写出来，给还在跟ueditor公式乱码死磕的朋友一个参考。
先给结论：Word公式在ueditor里乱码，本质是公式的原始结构（OMML）在粘贴过程中丢了，只剩下一堆Unicode残片。要根治，必须做三件事——粘贴时拦截剪贴板里的OMML数据、后端把OMML转成MathML、前端用MathJax渲染成可视化公式。这套方案我在几个军工内网项目里落地过，不依赖外网、不依赖第三方在线API，完全在客户机房内部跑通。
1. 乱象分析：Word公式在ueditor里到底是怎么变成乱码的
1.1 三种最常见的“乱码”现场
先说客户报障时最典型的三种情况，你一听描述就能判断出问题出在哪个环节。
第一种叫“上下标小字符满天飞”。公式从Word复制过去后，Sigma、积分号、上下标全部散架，变成一堆缩小的字符，比如“ᵢ₊₁”“ₙ²”这种。这种看起来像是编码问题，其实不是——这是Word把公式里的Unicode数学字体字符原样粘贴进了HTML，但公式的“结构”全丢了，分数和根号原本是有层级关系的，现在只剩字符堆叠。
第二种是“灰色方块方框阵”。粘贴后显示一列灰色小方框，每个框里有个叉号或者问号，这是典型的OLE对象丢失。老版本Word的公式编辑器（Microsoft Equation）生成的是OLE对象，浏览器不认这个二进制对象，ueditor过滤时直接把它踢了，剩下一堆无效引用。
第三种最坑，“内容整体消失”。你从Word复制一整段，文字过来了，公式位置空了一大块，好像从来没存在过。这种情况是因为公式被Word放进了剪贴板的一个独立的XML片段里，ueditor默认粘贴逻辑里根本没有读取这个片段的代码，所以公式自然就被丢弃了。
搞清楚这三类现象你再看解决方案，思路就清晰了——所有问题都指向同一个根源：粘贴时公式的原始结构数据没有进入ueditor内容区。
1.2 为什么不能拿“Word另存网页”的思路来做
有一种想法很朴素：既然Word公式乱码，那就让用户先在Word里“另存为网页”，把公式转成图片或者HTML再复制粘贴。这个方案我在早期项目里试过，实际跑不通。
Word另存网页有两种结果。一种是把公式转成图片，但图片引用的是本地磁盘路径，比如"file:///C:/Users/xxx/AppData/Local/Temp/xxx.png"，粘贴到浏览器后图片全裂。另一种是生成VML矢量标记，这玩意儿只在IE时代有效，现代浏览器和国产浏览器基本不渲染。再加上军工内网电脑普遍锁了保存路径、禁止写入临时目录，另存为网页这个操作在客户现场根本走不通。
还有一个更残酷的现实：你不能要求每个用户都会操作。客户那边的工程师打开Word，复制、粘贴，就完事了。如果你在操作流程上加任何一步“先把公式转成XX格式”，半年后工单还是会原样涌过来。
1.3 剪贴板里的秘密：Word到底给了浏览器什么
要解决问题，得先知道Word在我们点击“复制”的那一刻往系统剪贴板里塞了什么。
你用Word复制一段带公式的内容时，剪贴板里实际包含好几种格式的数据：纯文本、RTF格式文本、HTML片段、图片格式，还有一份OMML（Office Math Markup Language）格式的XML数据。浏览器拿到的是text/html这部分，就是你粘贴时看到的HTML。
浏览器能拿到的HTML片段大致长这样：
<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:m="http://schemas.openxmlformats.org/officeDocument/2006/math" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta name=ProgId content=Word.Document> <meta name=Generator content="Microsoft Word 15"> </head> <body> <p class=MsoNormal>这是一个公式：</p> <m:oMath> <m:r><m:t>f</m:t></m:r> <m:r><m:t>(x)</m:t></m:r> <m:d> <m:dPr></m:dPr> <m:e> <m:r><m:t> = </m:t></m:r> <m:f> <m:num><m:r><m:t>1</m:t></m:r></m:num> <m:den><m:r><m:t>2</m:t></m:r></m:den> </m:f> </m:e> </m:d> </m:oMath> </body> </html>注意看这段HTML里的<m:oMath>节点。这就是公式的结构化数据，它清清楚楚地描述了分数、上下标、根号等数学结构。ueditor要么把包含m:前缀的标签判定为非法标签过滤掉，要么在粘贴时只提取了纯文本部分，结构信息就此人间蒸发。
知道这个数据结构之后，方案就明确了：我们要做的不是“修乱码”，而是在粘贴过程中把<m:oMath>节点完整提取出来，走一条独立的公式渲染链路。
2. 思路定调：用“OMML提取 + XSLT转换 + MathJax渲染”打通公式链路
2.1 为什么选OMML作为中间格式
你可能想问，为什么不直接从剪贴板拿LaTeX或者MathML？原因很简单——Word复制时根本不提供这些格式。剪贴板里能拿到的公式结构化数据，有且只有OMML这一种。这是微软在Office 2007之后为公式打造的XML语言，只要用户在Word里用系统自带公式编辑器（或者MathType写入后转换过的公式）写的内容，复制时都会带上OMML数据。
OMML到MathML的转换，长期被忽略，其实是一个很成熟的技术路线。微软自己就提供了一份XSLT模板文件OMML2MML.XSL，专门负责把OMML转换成MathML。有了MathML，前端就可以用MathJax统一渲染，浏览器不用区分公式是从Word来的还是从其他编辑器来的。
中间的转换链就是：
Word复制 -> 剪贴板HTML（含OMML节点） -> 提取OMML -> XSLT转换 -> MathML -> MathJax渲染 -> 插入ueditor
2.2 军工内网环境下的方案约束
这套链路在普通公网项目里好做，但在军工内网环境里，要额外考虑三个硬约束。
第一是离线部署。内网机房不能访问外网，CDN不能用，MathJax的JS和字体文件必须全部打包成静态资源部署到本地。我一开始做的时候直接引了CDN的MathJax，到了客户现场一刷新页面公式全白，因为内网根本抓不了外网资源。
第二是涉密管控。系统里处理的文档可能涉及敏感内容，字节不能出内网。所以公式转换必须由服务器本地完成，任何依赖第三方在线公式识别API的方案，在立项评审阶段就会被安全部门毙掉。我们在技术方案里要明确写“全部处理在内网服务器完成，无外网调用”，有的客户还会要求做日志脱敏，转换过程中不能打印公式原文。
第三是软件环境杂。军工单位的终端五花八门，Windows 7配IE11、Windows 10配360安全浏览器、国产麒麟系统配奇安信浏览器都很常见。MathJax版本选型必须考虑这些老内核浏览器的兼容性，后面的部署章节我会细说。
2.3 方案对比：前端转换还是后端转换
OMML转MathML这件事，理论上可以写纯JavaScript在前端完成，也有别人做好的开源库，比如OMML2TeX那种。但我在项目里最终没有选前端转换，原因有两个。
第一个是浏览器兼容性。老内核浏览器（尤其是IE）对XML解析、XSLT处理的支持差异很大。IE的XSLT接口是ActiveXObject("MSXML2.DOMDocument")，Chrome用的是DOMParser和XSLTProcessor，为了兼容这些你得写一堆分支代码，测试成本极高。后端用Java的统一接口处理，浏览器只负责上传OMML字符串、接收MathML字符串，兼容问题只在后端存在一次。
第二个是性能和数据安全。后端可以预编译XSLT模板，避免每次转换都重新加载解析XSLT文件，前端转换做不了这种优化。后端还能在转换前做数据校验，避免恶意OMML进入系统。虽然军工内网不太担心XSS注入，但统一入口总归更可控。
3. 实操实现：前端粘贴拦截与公式提取
3.1 用捕获阶段监听粘贴事件，绕过ueditor默认过滤
ueditor的粘贴逻辑在底层源码里写死了，默认把剪贴板HTML塞进编辑器并走一遍filterTxtRules白名单过滤。我们没法优雅地在它处理完之后拿回OMML节点，因为节点已经被过滤掉了。
所以策略是：在document的捕获阶段监听paste事件，先于ueditor拿到粘贴内容。如果检测到内容包含OMML节点，就阻止默认粘贴行为，自己走公式处理流程；如果不包含公式，就放行，让ueditor按原逻辑处理。这样对正常粘贴操作完全无感，只有带公式的文档才走新链路。
核心代码如下：
document.addEventListener('paste', function (e) { var editor = window.currentEditor; // 提前拿到编辑器实例 if (!editor || !editor.body) return; // 判断粘贴目标是否在编辑器内 var target = e.target; var isInEditor = editor.body.contains(target) || editor.container.contains(target); if (!isInEditor) return; var html = getClipboardHtml(e); // 没有公式节点的内容，交给ueditor默认处理 if (html.indexOf('oMath') === -1 && html.indexOf('oMathPara') === -1) { return; } // 有公式，阻止默认粘贴，走自己的逻辑 e.preventDefault(); e.stopPropagation(); handleWordPaste(editor, html); }, true);这里有两个细节要注意。第一个是window.currentEditor怎么来的，在编辑器初始化完成后赋值：
var editor = UE.getEditor('editorId'); window.currentEditor = editor;第二个是粘贴事件触发时，ueditor内部可能已经在监听同一个事件，我们使用捕获阶段（第三个参数传true）可以保证先于ueditor处理，及时调用stopPropagation拦截掉后续冒泡阶段的事件。
3.2 从剪贴板HTML中提取OMML节点
拿到带公式的HTML字符串后，下一步是把里面的<m:oMath>节点提取出来。注意，一个Word文档里可能有多个公式，所以提取结果是一个数组。
实现代码如下：
function extractOMMLFromHtml(html) { var results = []; var parser = new DOMParser(); var doc = parser.parseFromString(html, 'text/html'); // 从Word粘贴的HTML里，OMML节点可能是 m:oMath 或 m:oMathPara // 注意标签名里的冒号在querySelectorAll里需要转义 var mathNodes = doc.querySelectorAll('m\\:oMath, m\\:oMathPara'); for (var i = 0; i < mathNodes.length; i++) { var serializer = new XMLSerializer(); results.push(serializer.serializeToString(mathNodes[i])); } return results; }这里有一个实际踩过的坑：querySelectorAll的转义符问题。如果你直接写querySelectorAll('m:oMath')，浏览器会把冒号当作CSS伪类分隔符，要么报错要么匹配不到。必须用双反斜杠m\\:oMath，或者用getElementsByTagNameNS('http://schemas.openxmlformats.org/officeDocument/2006/math', 'oMath')这种带命名空间的方式，但后者在HTML解析环境下命名空间不一定保留，实测不如querySelectorAll稳定。
提取出来的OMML是一串XML，比如第一节里那个<m:oMath>示例。把这个字符串原样发给后端转换接口。
3.3 把OMML传给后端做转换（Java接口示例）
后端我用Java实现了一个最简接口，接收OMML字符串，返回MathML字符串。用Spring MVC就是一句话的事：
@RestController @RequestMapping("/formula") public class FormulaConvertController { @PostMapping("/convert") public Result convert(@RequestBody ConvertRequest request) { try { String omml = request.getOmml(); if (omml == null || omml.trim().isEmpty()) { return Result.error("OMML内容为空"); } String mathml = ommlConverter.convert(omml); return Result.success(mathml); } catch (Exception e) { // 不打印公式原文，避免敏感信息进日志 log.error("OMML转换失败", e); return Result.error("公式转换失败"); } } }注意日志这一点很关键，军工项目安全审查会看这个。日志里只输出异常堆栈，不拼接OMML原文，防止公式里的敏感内容出现在日志文件里被审计系统扫出来。
3.4 插入渲染结果并处理ueditor白名单冲突
后端返回MathML后，前端用MathJax把MathML渲染成可视化的HTML，再插到编辑器里。这里有个取舍：是把MathML标签直接插入，还是把渲染后的HTML插入？
我的经验是插入渲染后的HTML。因为ueditor的内容过滤规则对MathML里的<math>、<mi>、<mo>这些标签一窍不通，要么过滤掉，要么留着但显示成一堆标签源码。直接把MathJax渲染后的HTML插入，ueditor把它当作普通富文本内容，完全不会动它，省去配置白名单的麻烦。
实现如下：
async function handleWordPaste(editor, html) { var ommlList = extractOMMLFromHtml(html); // 提取公式后，把公式的位置替换成占位符，处理剩下的普通文本 var textContent = html.replace(/<m:oMath[^>]*>[\s\S]*?<\/m:oMath>/g, '【公式占位】'); // 这里可以继续对textContent做ueditor样式清理，此处省略 var insertHtml = textContent; var needInsertHolders = []; for (var i = 0; i < ommlList.length; i++) { var omml = ommlList[i]; var mathml = await sendToBackend(omml); // POST /formula/convert var formulaHtml = await renderMathMLToHTML(mathml); // 用渲染结果替换第一个占位符 insertHtml = insertHtml.replace('【公式占位】', formulaHtml); } // 最后插回编辑器 insertHtml = cleanUpWordSpacing(insertHtml); editor.execCommand('insertHtml', insertHtml); }MathJax渲染部分：
function renderMathMLToHTML(mathml) { var holder = document.createElement('div'); holder.innerHTML = mathml; return MathJax.typesetPromise([holder]).then(function () { return holder.innerHTML; }); }3.5 兜底策略：识别不到公式时的降级处理
有一种情况你必须考虑：用户用的是旧版Word 2003的公式编辑器，复制到剪贴板时根本不含OMML，只有OLE对象。这种情况下OMML节点提取不到，转换链路走不下去，内容会丢。
我们的兜底方案是：检测到剪贴板HTML里有<o:OLEObject>或者<v:shape>这种VML节点时，给用户弹一个提示框，建议使用Word 2010以上的版本编辑公式，或者导出文档为docx后再复制。虽然不够优雅，但至少不会“无声无息”丢内容。
还有一种更简单的场景，有些用户直接把公式截图保存为图片再粘贴，这种情况ueditor默认就能处理，因为图片粘贴本身是正常流程。
4. 后端转换实现：OMML到MathML的关键细节
4.1 找到OMML2MML.XSL并配置
后端转换的核心依赖是一个XSLT文件：OMML2MML.XSL。这个文件微软随Office一起分发，如果你电脑上装了Office，通常在以下路径能找到：
C:\Program Files\Microsoft Office\root\Office16\OMML2MML.XSL不同Office版本路径里Office16可能不一样，Office 2013是Office15，Office 2010是Office14。找到后把这个文件复制到项目的静态资源目录或WEB-INF/classes下面，不依赖外网、不需要许可，内网项目直接用。
如果项目组里没人有Windows环境，也可以去开源仓库找这份XSLT的镜像，内容是一样的。但要留意一下文件的编码，有些镜像版本是UTF-8，有些是UTF-16，Java加载时可能因编码问题报错。
4.2 Java代码实现和性能优化
后端转换的Java实现，标准JDK自带XSLT引擎就够用，不需要额外引三方包。
import javax.xml.transform.*; import javax.xml.transform.stream.StreamResult; import javax.xml.transform.stream.StreamSource; import java.io.StringReader; import java.io.StringWriter; public class OmmlConverter { private volatile Templates templates; public String convert(String omml) throws TransformerException { Transformer transformer = getTemplates().newTransformer(); StringWriter writer = new StringWriter(); Source source = new StreamSource(new StringReader(omml)); transformer.transform(source, new StreamResult(writer)); return writer.toString(); } private Templates getTemplates() throws TransformerConfigurationException { if (templates == null) { synchronized (this) { if (templates == null) { // xsl文件的路径，部署时放到classes目录下 InputStream xslStream = getClass().getClassLoader() .getResourceAsStream("xsl/OMML2MML.XSL"); templates = TransformerFactory.newInstance() .newTemplates(new StreamSource(xslStream)); } } } return templates; } }性能上有一个必须注意的点：Templates对象要复用，不要每次转换都new一个TransformerFactory和Templates。XSLT模板的加载和解析开销很大，在高频并发场景下每次重新加载会导致CPU飙高和Full GC。我一开始没有复用Templates，压测两百个并发就把老年代堆挤爆了，后来改成懒加载单例才稳定。
另外，XSLT转换默认会带出大量命名空间声明，导致转换结果里一串xmlns:m="..."这种噪声。这个不影响MathJax渲染，但会撑大库里的内容体积。如果在意，可以在转换后做一次命名空间清理，或者接受这种冗余，反正量不大。
4.3 转换结果的校验与异常处理
OMML转换失败的情况比想象中多，主要出现在公式嵌套复杂、包含特殊符号（比如带圈数字、箭头）时，XSLT本身可能跑不过去。转换接口必须做好异常兜底。
我的做法是转换后检查MathML的特征标签，比如<math是否存在。如果转换结果是空串或者没有math节点，直接返回错误信息。前端的降级逻辑是：某个公式转换失败时，至少保留一个占位符和错误提示，不能把整个粘贴内容扔了。实践中，几百个Word文档转换下来，失败率在百分之几的量级，大部分失败是因为XSLT无法识别OMML中的扩展数学符号，这种场景下可以提示用户将公式转为图片格式后粘贴，属于可接受的降级。
5. 军工环境部署适配：离线、杀软、国产浏览器的应对
5.1 MathJax离线资源与字体瘦身
MathJax默认从CDN加载，内网环境必须把资源全量下载后放本地。完整MathJax包大概几十MB，其中绝大多数是字体文件。对于军工内网这种网络环境，部署一个几十MB的静态资源包不是什么大问题，但如果你用的是老掉牙的服务器，或者客户要求资源包尽量小而精，可以做个瘦身。
做法是在MathJax配置里指定只使用SVG输出，不让它加载字体文件。MathJax 3支持SVG渲染引擎，渲染出来的公式是矢量图形，不依赖字体，体积骤减，而且打印效果更好。配置如下：
window.MathJax = { loader: {load: ['input/mml', 'output/svg']}, svg: {fontCache: 'local'} };用SVG输出还有一个额外的好处：公式变成图形后，ueditor的内容过滤完全不会干扰它。缺点是公式再次编辑会很麻烦，因为存进库里的内容已经从MathML变成SVG标签了。如果客户明确要求公式可以二次编辑，那还是要用HTML-CSS输出加字体文件，这两种方案看需求选。
5.2 老浏览器与国产化浏览器的兼容处理
军工内网浏览器环境乱，我分两种情况说。
一种是Chromium内核的国产浏览器，比如360安全浏览器、奇安信、红莲花，这类浏览器对ES6、MathJax 3支持都还好，问题不大，按标准方案部署即可。另一种是IE11甚至IE9的老环境，MathJax 3直接不兼容，只能用MathJax 2.7.9。
MathJax 2.7.9对MML渲染同样支持，只是API不一样，渲染方法从MathJax.Hub.Queue(["Typeset", MathJax.Hub, container])改成这个。如果你要兼容IE，需要把整个技术路线里依赖ES6 Promise的代码改掉。我的建议是：开发前先跟客户确认浏览器基线，如果超过20%的终端还在用IE11，就直接用MathJax 2.7.9，省得后面返工。
还有一点，军工项目经常装了安全管理软件，粘贴板权限会被锁。从Word复制公式后，如果粘贴事件拿不到clipboardData或者getData返回空串，多半是被安全管控策略拦了。这种情况没有太好的绕过办法，只能协调终端安全策略放行编辑器的剪贴板访问，把这个作为部署前置条件之一。
5.3 涉密数据安全要求
整个公式转换链路中，安全要求最集中的几个点：
第一，转换接口必须在服务器内网部署，不挂载到公网出入口。第二，接口调用要加权限校验，不能变成谁都能调用的公开接口，否则会变成内网数据泄漏通道。第三，日志不能打公式原文，异常堆栈可以打但不能拼正文。第四，MathML和SVG内容入库前要做HTML实体转义，防止XSS注入。第五，如果系统对接了审计系统，转换行为本身也要写审计日志，包括时间、用户、文档ID。
我们做第一个军工项目时，安全评审会专门有人追问“公式转换的数据链路走外部网络吗”，这个问题要在方案里写得明明白白，否则评审批不过，后面全白干。
6. 实战排坑：我踩过的坑和排查心得
6.1 现场问题速查表
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
| 公式变成上下标小字符 | OMML节点未提取，只保留了Unicode文本 | 确认粘贴事件捕获是否生效，检查qSA转义写法 |
| 公式变成灰色方框 | OLE对象被过滤 | 兜底弹窗，建议升级Word版本或使用图片模式 |
| 粘贴后内容完全丢失 | 拦截逻辑误判了所有粘贴事件 | 检查isInEditor判断逻辑，确保无公式时放行 |
| 公式插入后空白 | MathJax异步渲染未完成就插入 | 用MathJax.typesetPromise包裹后再insertHtml |
| 表单提交后公式消失 | 后端XSS过滤误杀了MathML/SVG标签 | 调整服务端过滤规则，对公式容器放行 |
| IE下DOMParser不可用 | 老浏览器兼容问题 | 换用MathJax 2.7.9 + 降级提取方案 |
| 转换接口偶发超时 | XSLT模板每次重新加载 | 使用Templates单例复用 |
| 公式和文字垂直不对齐 | 公式容器行高和基线问题 | 给公式容器设置vertical-align: middle |
6.2 几个容易被忽略的细节
第一个是Word粘贴时中文乱码的叠加问题。公式处理链路只处理OMML节点，但文档正文的中文如果经过编码转换变成乱码，公式再正常也没用。这个问题一般出现在后端接收OMML字符串时字符集设置不对。统一用UTF-8接收，前端在发送时明确Content-Type是application/json;charset=UTF-8，基本能根治。
第二个是MathJax渲染完成的时机。MathJax渲染是异步的，如果你在renderMathMLToHTML返回前就把内容insertHtml，编辑器里会看到一堆MathML标签源码。需要用Promise或者async/await确保渲染完成后再插入。我见过很多开发者栽在这上面。
第三个是占位符替换的顺序问题。如果文档中有多个公式，我前面用【公式占位】做标记再replace，replace默认只替换第一个匹配，所以循环里要按顺序一一对应。如果公式内部包含占位符文本，就会错位，稳妥做法是先把公式从HTML中抠出来存数组，处理完后再按索引拼回去，不要用字符串replace。
第四个是“公式与文字不对齐”的处理。公式容器插入后，经常出现公式比旁边文字高出半个头或低半个头的情况。给公式容器加vertical-align: middle和line-height: 1通常能改善。各种公式尺寸不同，还需要微调MathJax的ex-height参数，这个参数控制公式与行内文字的垂直对齐基准。
第五个是“粘贴时卡顿”的排查。如果一次粘贴了几十个公式，MathJax逐个渲染会导致页面短暂卡死。解决办法是批量收集所有MathJax容器，一次性typeset，或者做个异步队列，每次渲染5个，分片处理。
6.3 后续扩展的想象空间
这套链路稳定后，公式问题其实只解决了“输入”端。顺着这个思路，后面还能扩展出两个很有用的功能——一个是把库里的MathML/SVG导出为Word文档时，反向把公式还原成OMML，Word打开就是可编辑的公式；另一个是基于MathML做公式全文检索，用户搜“勾股定理”能精确搜到这个公式。这两个方向我们在后续项目中验证过可行性，工程量主要在格式转换上，有兴趣的可以去试。
我在实际项目里体会最深的一点是：公式乱码这类问题，表面看是技术bug，本质上是对数据格式理解不透彻。搞清楚Word复制到剪贴板时带了什么、ueditor丢掉了什么、MathJax能渲染什么，整条链路打通并不难。关键在于不要被“乱码”两个字带偏，急着去清洗字符、转码，那是治标不治本。把精力花在结构化数据的提取和转换上，才是真正能交差的办法。