叶减肥去年做信创项目时，客户在需求文档里只写了一行：从Word复制的公式，粘贴到我们基于XHEDITOR搭建的在线编辑页面里，显示要正常，最好还能二次编辑。一行需求，我从方案设计到上线前后改了四版，踩的坑比想的还多。
先说症状。Word里插一个公式复制，切到XHEDITOR按Ctrl+V。运气好，出来的是一张截图，模糊且不能改；运气不好，粘贴框里直接空白；要是对方用MathType，还会粘进去一个白框或者一堆乱掉的标签。更麻烦的是，信创电脑上操作系统、浏览器、办公软件的搭配非常杂，同一个方案在开发机上好好的，到客户环境就翻车。
这篇文章主要面向做在线文档、富文本编辑器、题库系统、协同办公平台的开发同学。如果你正在被“Word公式粘贴进HTML编辑器”这个问题折磨，下面这一整条链路——从剪贴板格式、OMML、MathML、MathJax，到信创浏览器差异、服务端导出Word——应该能帮你少走很多弯路。
1. 先看问题：公式粘贴进XHEDITOR时的三个真实痛点
1.1 公式变成了图片，而且往往是不完整的图片
用Word 2019做一份包含数学公式的试卷，复制到XHEDITOR，默认情况下编辑器会从剪贴板读到一份位图，把它当成普通图片插入。初看好像没啥问题，但用户真正用起来会发现：公式在Word里是矢量的，放大多少倍都清晰，一旦变成位图，在100%缩放下可能还好，页面放大到150%或者打印预览，公式边缘的锯齿会非常明显；如果页面背景不是纯白色，公式周围自带的白底会显得很突兀。
更极端的情况是，用户在WPS或某些Linux办公环境里复制公式，剪贴板里给到的是WMF或EMF格式图片。Chromium内核的浏览器根本没有办法直接渲染这两种格式，粘贴完后只能看到一个空白占位框，连图都没有。我曾经在客户现场遇到过，用户以为是系统坏了，实际上就是粘贴结果的格式兼容性问题。
图片方案的另一个致命伤是不可编辑。对在线题库、试卷系统这类场景，老师经常只想把题目拿走改几个数字，结果公式变成图片后只能整图删除重做。这种工单反馈多了，需求方就会提“公式必须能编辑”，你之前的图片方案就白做了。
1.2 MathType公式“粘进来之后只剩一个空壳”
MathType的历史比Office自带的公式编辑器更久，很多老课件、老试卷里都是MathType公式对象。这类对象在Word里双击可以进入MathType编辑器重新编辑，但复制到剪贴板后，在浏览器看来它不是“一段公式”，而是一个OLE对象。
XHEDITOR拿到这类数据时，处理动作一般是：尝试插入对象，失败；退回到图片，再失败；最后只留下一个空白占位或一串无意义的对象标签。用户看到的现象就是“公式丢了”。如果页面上还能看到白框，里面写着类似“Microsoft Equation 3.0”的字样，那基本可以判定是MathType老格式。开发同学如果在现场遇到一次，后续再碰到也能秒判。
1.3 公式没丢，但对齐、字号、字体全乱
还有一种情况，公式确实显示出来了，但细节完全不对。Word里公式和正文是沿着基线对齐的，公式部分比正文略高略低都正常，但在HTML编辑器里，公式如果没有被MathJax这类工具渲染，而是靠浏览器原生能力或者普通内联元素展示，基线就会偏，显示出来就是公式比正文高出一大截或沉下去。
再有就是字体缺失。Windows上Word默认用Cambria Math渲染公式符号，信创机器上很多没有这个字体，于是字母部分正常，但根号、积分号、求和号、上下标符号变成一个个方框。用户看到后第一反应是“乱码了”，其实这是字体栈问题，不是编码问题。
1.4 先判断业务场景，再决定投入
这几个痛点摆在一起，很容易让人一开始就憋大招，想做一套“万能公式还原方案”。我的建议相反：先分清场景，再决定投入。
| 业务场景 | 对公式的要求 | 推荐方案 | 开发成本 |
|---|---|---|---|
| 内容预览/只读展示 | 能看清就行 | 图片兜底 | 低 |
| 在线题库录入 | 要改数字、改符号 | MathML可编辑方案 | 高 |
| 文档协同平台 | 展示与导出并重 | MathML + 服务端导出转换 | 最高 |
| 混合场景 | 大多数人不编辑，少数人要编辑 | 渐进式：默认图片，可手动升级为可编辑公式 | 中高 |
如果客户只是要一个“能看”的效果，图片方案一天就能上线，没必要为公式语义折腾。但如果确认要支持公式编辑，那就必须走MathML这条路，越早越好。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 剪贴板里的公式：一次复制背后的四种数据
2.1 剪贴板不是“文本箱”，而是多格式容器
在Word里按下Ctrl+C，系统并不是只往剪贴板写了一段文字，而是写入了一组格式。以一次最简单的公式复制为例，剪贴板里可能同时存在这些内容：
- CF_TEXT：纯文本。Word会把公式转成线性文本，例如E = mc^2，信息严重丢失。
- CF_HTML：Word以MsoHTMLClipboard格式输出，公式字段以特定标记嵌在HTML里，这是兼容性工作的主战场。
- image/png、image/bmp：公式渲染后的位图。
- EMF/WMF：老版本Office或MathType常见的矢量图片格式，浏览器大部分场景无法渲染。
- application/x-oleobject：MathType/OLE公式专用，浏览器读不到内部内容。
- 私有格式：Word Document Object、Object Descriptor等，普通网页完全无感。
浏览器通过clipboardData只能读到一部分格式。OLE这类私有格式在现代浏览器里基本拿不到，能拿到的无非是纯文本、HTML、图片。所以公式能不能保留语义，关键就藏在text/html里。
2.2 三种常见公式来源在剪贴板里的“真实身份”
不同公式来源，剪贴板里的表现差异很大。我工作中常用的判断表是这样：
| 公式来源 | text/html中的公式标记 | 剪贴板图片格式 | 可处理程度 |
|---|---|---|---|
| Word 2016+自带公式 | <m:oMath>或<m:oMathPara> |
PNG/EMF | 高，可做OMML转MathML |
| MathType公式 | OLEObject或v:shape占位 | PNG/WMF | 低，多数情况只能取图 |
| WPS公式 | 无公式标记，通常整段图片 | PNG | 中低，兜底图片 |
| 网页MathJax/KaTeX公式 | <math>或<annotation> |
无 | 高，可直接使用 |
这里有个很容易忽略的细节：新版Word复制公式时，剪贴板里的MathML并不总是存在，但OMML几乎必有。所以兼容方案不能只等MathML，必须能处理OMML。
2.3 为什么直接读HTML和直接读图片都不可行
有人会问：直接读剪贴板里的text/html，把整个Word片段塞进XHEDITOR不就行了？不行。Word生成的HTML带一堆非标准命名空间标签，比如<m:oMath>，浏览器不认识它，XHEDITOR的过滤规则也会把它当成非法标签直接吃掉。最终用户看到的是空内容。
也有人想：那就直接读图片，至少能显示。但前面说过，图片不可编辑、放大模糊、带白底；而且如果剪贴板里只有WMF/EMF，浏览器连显示都做不到。图片只能作为兜底，不能作为主方案。
所以核心工作就是：从text/html里精准抽取OMML或MathML，再转换成HTML编辑器能理解并渲染的结构。
3. 核心处理链路：让OMML在HTML编辑器里活过来
3.1 为什么中间格式必须是MathML
我对比过把公式转成LaTeX、图片、MathML三种中间格式的路线。LaTeX虽然通用性强，但Word的OMML转LaTeX并没有无损的现成工具，容易丢冗余符号，而且XHEDITOR里渲染LaTeX还得额外引KaTeX或MathJax的tex组件；图片的问题前面已经说透了；MathML是W3C标准，MathJax原生支持，而且微软官方给出了OMML和MathML互转的XSLT，这条链路最顺。
在实际项目中，MathML不仅能保留公式结构，还能带语义，方便后续做检索、复制、导出。所以我把系统的公式内部存储格式定为MathML，图片只作为渲染兜底缓存。
3.2 第一步：拦截粘贴事件，防止默认行为
在XHEDITOR初始化完成后，要给编辑器内容区绑定paste事件，先检查剪贴板里有没有可处理的公式数据，如果有就阻止默认粘贴行为，走我们的自定义流程。
javascript复制var editor = $('#editor').xheditor({ /* 你的初始化配置 */ });
var content = editor.$content || editor.$editor;
content.addEventListener('paste', async function (evt) {
var clipboard = evt.clipboardData || window.clipboardData;
if (!clipboard) return;
var html = clipboard.getData('text/html');
if (!html) return;
if (html.indexOf('oMath') === -1 && html.indexOf('<math') === -1) {
return; // 没有公式数据，走默认粘贴
}
evt.preventDefault();
try {
var mathHtml = await extractMathFromClipboard(html);
insertMathToEditor(editor, mathHtml);
} catch (e) {
console.error('[formula-paste] 处理失败', e);
// 失败后可以让用户手动粘贴图片
}
});
这里有一个细节：evt.preventDefault()必须在读取clipboardData之后、在事件处理函数同步阶段调用，否则某些浏览器会不允许后续异步操作。我一开始把读取剪贴板放在await之后，结果在Firefox下拿到的一直是空字符串。
3.3 第二步：从Word HTML中抽取OMML片段
text/html虽然是HTML，但里面嵌的OMML是XML结构的标签。先用DOMParser解析，再通过选择器把公式节点抠出来。
javascript复制function extractOMath(html) {
var doc = new DOMParser().parseFromString(html, 'text/html');
// 注意选择器里冒号要转义
var omath = doc.querySelector('m\\:oMath, m\\:oMathPara');
if (!omath) {
// 有些版本不带m前缀，做一次兜底
var all = doc.getElementsByTagName('*');
for (var i = 0; i < all.length; i++) {
var tag = all[i].tagName || '';
if (tag.toLowerCase().indexOf('omath') === 0) {
omath = all[i];
break;
}
}
}
return omath ? omath.outerHTML : '';
}
注意几个容易翻车的地方。第一，querySelector('m\\:oMath')这种写法只在XML DOM或标准HTML DOM里有效，如果某个浏览器把标签名小写化，选择器会失效，所以要有getElementsByTagName兜底。第二，如果Word文档里公式不止一个，querySelector只能取到第一个，需要改成querySelectorAll后逐个处理，并且要明确是插入到一个段落还是每个公式独立一行。第三，OMML的命名空间前缀可能是m:，但极少数情况下Office会输出不带前缀的<oMath>，所以遍历兜底很有必要。
3.4 第三步：OMML转MathML的两种方式
拿到OMML字符串后，可以转成MathML。最推荐的方式是直接用微软官方XSLT：OMML2MML.XSL。这个文件在Office安装目录里通常能找到，网上也很容易下载到。
前端转换可以用XSLTProcessor：
javascript复制async function ommlToMathML(omml) {
var xslResponse = await fetch('/xslt/OMML2MML.XSL');
var xslText = await x