企业官网建设流程全解析

最近帮我一个学弟改毕业论文，他往里贴公式的方式把我惊到了——拿手机拍书上的公式，再用识别软件扫成图片，插进Word里。结果公式稍微改个下标就得重新截图，排版也忽大忽小，导师看了直摇头。我说你写论文怎么不用LaTeX？他说用了，但LaTeX写的公式往Word里复制，过去就是乱码，根本没法用。

这个问题其实困住了很多人：一边是Markdown/LaTeX这套高效、纯文本、版本管理友好的写作流程，一边是学校、公司最终交付必须用的Word/WPS。公式恰恰是中间的硬骨头。好在这两年GitHub上冒出一批开源项目，专门解决“把Markdown里的公式、LaTeX代码一键转成Word/WPS原生公式”这件事。我花了一个周末把它们的原理、实现、坑全摸了一遍，自己也搭了一条可以直接用的流水线。这篇就把这些内容完整写出来，给被公式粘贴折磨的程序员、学生、还有出试卷的老师一个能落地的答案。

1. 为什么“把LaTeX公式直接粘贴到Word”总是一地鸡毛

1.1 粘贴后你看到的三种事故现场

先回忆一下直接复制粘贴会发生什么。我用Typora写Markdown，里面有一行$\frac{a}{b}$，选中复制，切到Word里一粘贴，三种情况我都见过：

第一种，变成了纯文本，斜杠、花括号、反斜杠全都原样躺在那里，仿佛在嘲笑你。

第二种，变成了一张图片。有些编辑器复制时会自动渲染公式再以图片形式塞进剪贴板，Word收下来倒是能看，但不能编辑、缩放变形、打印还不清晰，本质上和截图没区别。

第三种，也是最好笑的，粘贴到Word里自动变成了“线性公式”，比如一个分数显示成了a/b这种歪歪扭扭的样子，分式结构全丢了。

这三种事故的根源都一样：Word/WPS根本不认识LaTeX语法，它们只认自己的公式语言。你直接喂一句“外语”，人家当然只能按最原始的方式处理。

1.2 Word/WPS的公式母语叫OMML

Office里从Word 2007开始引入了一套公式标记语言，英文全称是Office Math Markup Language，简称OMML。你在Word里按Alt+=进入公式编辑状态，敲进去的任何东西，包括分式、根号、矩阵、希腊字母，最终存进docx文件里的描述格式都是OMML。

WPS这边稍微特殊一点，早期版本有自己的公式域实现，但新版本对docx的OMML兼容性已经相当不错，只要你在WPS里打开一个带OMML公式的Word文档，双击公式是可以正常进入公式编辑器修改的。

理解这件事是“完美粘贴”的关键：所谓完美，就是让你的LaTeX公式最终以OMML的形式进入Word/WPS，而不是以文本、图片、或者MathML等“外来格式”存在。

1.3 那MathML去哪了

你可能会在技术讨论里看到MathML这个词。MathML是W3C制定的数学标记语言标准，网页上的公式渲染、维基百科、MathJax，底层都在用MathML描述数学结构。它和LaTeX、OMML是三种不同的“语言”：LaTeX是给人写的人类友好语法，MathML是给浏览器和工具看的通用XML格式，OMML是Office系的私有格式。

所以这里就出现了一条天然的转换链：LaTeX → MathML → OMML。第一跳把人类友好语法翻译成通用标记，第二跳把通用标记翻译成Office母语。开源项目大多都是在这条链上做文章，后面我会拆开讲。

注意：如果你在网上搜“Word识别MathML”，会发现Word确实支持直接把纯MathML粘贴进公式编辑器。但实操里这个行为非常不稳定，跟Word版本、剪贴板携带的额外格式都有关系。真正可靠的做法是先转成OMML再插入，或者利用HTML剪贴板的特殊机制让Word自己完成转换。

2. 公式“完美粘贴”背后的那条转换链，到底是怎么转的

2.1 第一跳：LaTeX怎么变成MathML

LaTeX和MathML虽然是两种完全不同的表达，但数学结构是等价的：分式还是分式，根号还是根号，上下标还是上下标。开源社区里有一个非常经典的Python库叫latex2mathml，它的工作就是解析LaTeX语法树，然后按对应的数学语义生成MathML标签。

举个例子。你写\frac{a}{b}，它解析出来的就是一个<mfrac>标签，里面嵌套两个<mi>标签分别代表a和b。你写\sum_{i=1}^{n}，它生成的就是带<msubsup>下上标的<mo>∑</mo>。

这个过程没有太多魔法，核心就是一个语法解析器加一个语义映射表。真正麻烦的是处理LaTeX宏包带来的“私货”，比如\bm、\mathbb、\mathcal这些字体命令，需要在转换时逐条建立映射规则。这也是为什么有些开源项目能转常见公式、遇到花里胡哨的宏就不认识的原因。

2.2 第二跳：MathML怎么变成OMML

LaTeX转成MathML之后，剩下的事情反而简单了，因为微软自己给过官方答案。Word/Office产品里内置了一份XSLT样式表，能直接把MathML映射成OMML。这份东西的名字就叫MML2OMML.XSL，在很多Office安装目录里都能找到，微软的文档里也公开过它的原理：通过XSLT模板匹配MathML的每个标签，然后输出对应的OMML结构。

比如MathML里的<mfrac>对应OMML里的<m:f>，MathML里的<msqrt>对应OMML里的<m:rad>。本质上就是一张又长又细的对照表。

开源项目里，有的直接调微软这份XSLT，用的是Windows系统的已有能力；有的自己用Python重写了一套等价转换逻辑，比如mathml2omml这个库，把XSLT的相对应关系用Python实现了，好处是跨平台，Linux和macOS上也能跑。这就是为什么你在GitHub上看到那些公式粘贴工具能“一次成功”，它们背后基本都这么干。

2.3 浏览器里藏着一个隐藏通道

还有一条捷径值得单独说：很多开源工具根本不自己生成OMML，而是走了浏览器剪贴板这条“官方通道”。

具体来说，你可以把MathML包在一个完整的HTML片段里，然后以HTML格式写入系统剪贴板。当Word/WPS接收到这段HTML时，如果里面存在带有正确命名空间的<math>标签，Word会自己尝试把它转换为OMML公式对象。实测下来，这个行为在Word 2016以后的版本里非常稳定，WPS则要看版本，新版多数情况也能认。

这条路径的好处是代码量极小。你甚至不用装一堆Python库，只要写一个简单的HTML文件，把MathML塞进去，用浏览器打开，全选复制，到Word里粘贴就完成了。

2.4 为什么转完之后的公式还能“双击编辑”

这一节最后说一个很多人关心的问题：转换完成的公式，到底是不是和直接用Word公式编辑器敲出来的一样？

答案是基本一样。因为OMML格式没有“转译损”，从MathML转成OMML是标签级别的映射，得到了就是原生公式对象。你粘贴进去之后，单击选中，右键会有“数学选项”，双击可以直接进入公式编辑器修改。它的字体默认会跟随Word的Cambria Math，当然你也能改。

唯一和“原生”有细微差别的地方：如果你的LaTeX里带了某些特殊宏包效果，比如特定样式的花括号、某种不常见的矩阵分隔线，转换后的公式在样式层可能和LaTeX渲染结果不完全一样，但结构上是100%等价的。

3. 开源项目最常见的四种落地形态，以及它们背后的同一个内核

3.1 形态一：剪贴板增强小脚本

这是最简单也最灵活的实现方式。项目通常只提供一个Python脚本，你复制一行LaTeX公式，运行脚本，剪贴板里就变成了Word可识别的公式内容，直接回Word里Ctrl+V完成粘贴。

我见过有的实现是把MathML转成OMML后用自定义剪贴板格式写入；也有的是生成HTML剪贴板片段。它们的共同特点是：轻量、透明、没有界面，适合那种“我就想偶尔转几条公式，不想装全家桶”的人。

3.2 形态二：浏览器插件或书签小工具

这类项目面向的场景是：你在知乎、维基百科、arXiv上看文章，网页里公式是MathML/LaTeX渲染的，想直接摘进Word。插件一般会在右键菜单里加一个“复制为Word公式”，点击后自动抓取附近的公式源码，再走一遍转换链塞进剪贴板。

书签小工具更野一点，本质上是一段JavaScript代码，你把网页上的公式选中，点书签，脚本把LaTeX抓下来、转换、复制，全程不离开浏览器。

3.3 形态三：VSCode/编辑器扩展

程序员群体里最受欢迎的是这个。你日常写Markdown用VSCode，装一个公式粘贴扩展之后，选中某个公式片段，右键就能“复制为Word格式公式”。扩展内部直接把latex2mathml和mathml2omml的逻辑内置了，不需要你额外装Python环境。

这类扩展的好处是与你已有的Markdown编辑流程完全融合，不需要来回切窗口。我自己现在的主力工作流就是这个，后面实操部分我详细说。

3.4 形态四：CLI批处理工具

最后一种是面向“整篇文档处理”的。你有一篇几十页的Markdown或者LaTeX源码，想一次性转成docx，同时保证里面的每条公式都变成Word原生公式。这种情况下，大部分开源项目会直接建议你用Pandoc，因为Pandoc从很早的版本起就把“Markdown/LaTeX公式在docx输出里转成OMML”作为内置行为。

pandoc input.md -o output.docx

就这么一条命令，你的标题层级、列表、表格、代码块、加粗斜体、公式全部处理妥当。公式在docx里是OMML原生对象，不是图片。

3.5 花里胡哨的外壳，同一个内核

不管项目界面做成什么样，点开源码你看到的核心依赖基本跑不掉下面这张表：

理解了这张表，你在挑项目的时候就不会被花哨的README迷惑了。看到一个新仓库，先看它的依赖列表，只要出现上面这几个名字，那它的核心能力基本不会差；反过来，如果它自己写了私有的转换逻辑，又没有充分测试，那建议先谨慎试用。

4. 手把手实操：搭一条你自己的“一键公式粘贴”流水线

4.1 准备工作

我推荐的方式是在本地装一个Python环境，然后自己写一个十几行的转换脚本，再配合一个剪贴板写入。这样做的好处是彻底跨平台，不依赖某个特定编辑器，也没有项目停维护的风险。

需要安装的依赖只有三样：

pip install latex2mathml mathml2omml pyperclip

三个库做的事情前面已经说过：第一个是LaTeX解析器，第二个是MathML转OMML的Python实现，第三个是跨平台剪贴板操作。如果你的系统是Windows，也可以不装mathml2omml，而是去Office安装目录里找MML2OMML.XSL，用lxml来执行XSLT转换。我建议直接用Python实现，省得路径问题烦心。

4.2 一个够用的最小脚本

我自己日常用的是下面这个版本，英文名就叫latex2word_math.py，放在一个固定目录里，然后把它做成一个快捷命令，随时可以调用：

#!/usr/bin/env python3 import sys import pyperclip import latex2mathml.converter from mathml2omml import mathml_to_omml def latex_to_word(latex_str): # 第一步：LaTeX -> MathML mathml = latex2mathml.converter.convert(latex_str) # 第二步：MathML -> OMML omml = mathml_to_omml(mathml) # 第三步：把OMML作为文件格式写入剪贴板（也可用HTML通道） # 这里使用OMML的HTML包装方式，Word/WPS粘贴时能识别为公式 html_snippet = ( '<html xmlns:o="urn:schemas-microsoft-com:office:office" ' 'xmlns:m="http://schemas.openxmlformats.org/officeDocument/2006/math">' '<body>' '<!--[if !mso]><object style="display:none"></object><![endif]-->' f'<m:oMathPara><m:oMath>{omml}</m:oMath></m:oMathPara>' '</body></html>' ) pyperclip.copy(html_snippet) print("已复制，去Word/WPS里 Ctrl+V 吧") if __name__ == "__main__": latex_input = sys.argv[1] if len(sys.argv) > 1 else r"\frac{a}{b}" latex_to_word(latex_input)

如果不想用HTML包装，也有一种更“硬核”的写法：把omml字符串写成Word支持的application/x-omml-data剪贴板格式。但实测下来，对多数人来说HTML通道最省心，Word和WPS都能认。

4.3 行内公式与独立公式的粘贴手法

公式分两种场景，粘贴的时候手法有细微差别。

行内公式，也就是嵌在句子中间的小公式，比如“设x大于0，则x的平方大于等于0”。你转换完直接粘贴到文本段落里就行，Word会自动把它当成一个行内公式对象，和文字在同一行。但注意，我的脚本里用的是oMathPara标签，这表示“独立公式段落”。如果想粘贴为行内公式，把包装改成：

<m:oMath>...</m:oMath>

去掉了外层的oMathPara，Word粘贴时就会识别为行内公式对象，不会强制换行。

独立公式，就是单独占一行、带编号的那种大公式，直接用oMathPara包装就好。粘贴后如果发现公式前面多了个换行段，再手动调整一下段落格式就行。

4.4 从“单条公式”升级到“整篇Markdown”

单条转换解决的是零散需求。如果你的Markdown文档里有一二十条公式，一条条复制转换显然太蠢。这时候我的建议是直接放弃脚本，改用Pandoc整篇转换。

pandoc 论文.md -o 论文.docx

注意Pandoc转换docx时，默认行为就是公式转OMML，不需要额外参数。唯一需要你提前设置的是，Markdown里公式必须用标准的$...$行内写法或$$...$$块级写法，Pandoc才能识别。

转换完成后打开docx检查一遍，公式基本都是可编辑的OMML。如果你看到某条公式变成了图片，大概率是那条公式里用了Pandoc解析不了的特殊宏，这时候再单独用我的最小脚本手动转那一条，补贴进去。

我这里有个更细的分工策略：草稿阶段用VSCode写Markdown，公式全部用LaTeX语法；最终交稿前用Pandoc一次性转docx；转完检查出个别奇怪的公式再用单条脚本修补。整套流程跑下来，半小时能处理完一份几十页的文档。

4.5 给WPS用户单独提个醒

上面所有方案都默认你在用Word。用WPS的同学要特别注意：WPS对OMML公式的支持是目前能跑通大部分转换的，但老版本（比如2019年之前的版本）偶尔会把OMML公式退化成图片或者域代码。出现这个情况时，先检查你的WPS版本，再确认粘贴时选的是“保留源格式”而不是“无格式文本”。

还有一个规避办法：用Pandoc转出来的docx先不急着用WPS开，先用Word开一遍保存一次，再拿到WPS里编辑。这个“洗格式”的操作可以解决不少兼容性问题。虽然听起来有点玄学，但我在帮别人处理时验证过多次，确实有效。

5. 桌面端踩坑实录：这些坑我在帮人转公式时一个不落全踩过

5.1 花括号、反斜杠被“吃掉了”

我最开始用自己写的Python脚本时，最常翻车的就是转义问题。Python字符串里\frac里的反斜杠如果不写成\\frac，反斜杠本身会被吃掉，转换出来的MathML直接缺了关键标签。更隐蔽的是公式里有\left\{这种带花括号的结构，正则替换时一不小心就把结构拆坏了。

这个坑的解决方案很朴素：所有进入转换函数的LaTeX字符串一律用原始字符串，也就是前面加r前缀：

latex_str = r"\int_0^1 \frac{x^2}{\sqrt{1-x^2}} \, dx"

如果你的LaTeX公式是从文件里读出来的，那读取时也别做任何字符串替代处理，保持原文。我见过有人为了处理换行符，先把LaTeX里的\n换成空格，结果把公式语义都改坏了。

5.2 Word/WPS宏安全设置导致粘贴卡死

用剪贴板粘贴HTML公式时，Word有时会弹一个“是否更新此文档中的域”的提示，或者直接卡住几秒。这通常是因为Word正在尝试解析剪贴板里那堆OMML格式，而你的文档恰好在“受保护的视图”模式下打开。

解决办法是先把文档从受保护视图里切出来，或者在Word选项里把“受保护视图”对本地文件的启用选项关掉。另外，如果你用VBA宏做批量粘贴，宏安全级别必须调到“启用所有宏”，这个坑在给学校机房电脑装工具时尤其常见，装完工具发现宏被禁用了，脚本等于白费。

5.3 不是所有LaTeX都能走这条转换链

这是最重要的一条经验。latex2mathml能处理的是标准LaTeX数学环境里的常用命令，但三种东西它几乎必翻车：

第一种是自定义宏。你导入了某个模板类文件，里面用\newcommand自定义了一堆简写命令，比如\R代表实数集。转换器不认识\R，直接报错或输出空内容。

第二种是特殊环境。比如aligned、cases、array这些多行环境，有的转换器支持得好，有的支持得差。实测下来aligned大部分能转，但array里如果加了竖线分隔列，粘贴到Word里经常对不齐。

第三种是中文和文本混排。你写\text{如果} x>0，转换器对\text里的中文处理不稳定，粘贴过去中文可能消失。

碰到这三种情况，我的建议是：要么手动改写成纯标准LaTeX命令再转换，要么干脆这条公式直接用Word公式编辑器手敲，不要死磕自动转换。

5.4 多行公式粘贴后变成了单行堆叠

aligned环境转换后，粘贴进Word有时会出现多个公式挤在一个oMath里，变成用&对齐但显示却是一行叠一行的视觉错乱。这个问题在Word里可以通过公式工具里的“对齐”选项手动改，但根治的办法是：在转换前把多行公式拆成两条独立公式，分别转换粘贴。

比如：

\begin{aligned} a &= b + c \\ d &= e + f \end{aligned}

我会拆成两个独立的$$ a = b + c $$和$$ d = e + f $$，分别转换。虽然改动一下原始写法，但粘贴效果最保险。如果你实在需要那种带大括号的联立方程效果，Word里手动加一个左大括号比自动转换靠谱得多。

5.5 “双击进不去公式编辑器”问题

有时你粘贴完公式显示正常，但双击它却进不了公式编辑状态，右键菜单里也没有“数学选项”。这种情况一般说明：你粘贴进去的其实不是OMML公式对象，而是MathML文本被Word“按原样显示”了。看起来像公式，底层可能只是个特殊字符序列。

判断方法很简单：单击公式，看Word顶部菜单栏是否出现“公式工具/设计”选项卡；或者看公式外框是否是那种深灰色带角标的“公式框”。如果不是，说明没转换到位，回头检查剪贴板内容是不是被文本编辑器“洗”过一遍——很多人复制了我生成的HTML片段，但先粘贴到了记事本里“检查一下”，结果剪贴板内容已经被剥成纯文本，再复制就全废了。改剪贴板内容要用专门的剪贴板工具，别用记事本过一道手。

5.6 从图片公式到可编辑公式的歪路与正路

顺带提一下“公式图片转Word”这个很常见的需求。如果你手头只有公式图片，想变成可编辑公式，有人会先截图识别成LaTeX，再走转换链。开源生态里有pix2tex这类基于深度学习的LaTeX OCR模型，效果尚可，但复杂公式识别率确实一般。

正确而且靠谱的路径是：能用源文件找源文件，你从LaTeX源码或Markdown里复制原文，永远比OCR识别再转换损失小。只有在实在没有源文件的情况下，才考虑OCR，而且OCR完的LaTeX要人工逐条核对，识别错的概率一点都不低。

6. 反向操作与边界：Word公式转LaTeX，以及什么时候别用开源工具

6.1 Word公式复制到Markdown时，为什么经常变成图片

这个问题和前面的转换链正好相反。Word里你选中一个公式，复制，切到Markdown编辑器里粘贴，得到的要么是一张PNG图片，要么是一段巨大的OMML代码，几乎不可能还原成LaTeX源码。

原因是Word复制公式时，放进剪贴板的格式有好几种，Markdown编辑器只会挑自己认识的格式，通常优先挑图片。老牌的Markdown编辑器对OMML、MathML格式都没有原生解析能力，只能显示成图片。

那有没有自动反向转换的工具？有，但质量好的不多。有的开源项目会解析docx里的OMML，先转回MathML，再通过mathml2latex这类库反向输出LaTeX。结构简单的公式能还原个八九不离十，复杂的带多行对齐、特殊字体的公式就经常差强人意。当前印象里mathml2latex能把\frac、\sum、上下标这些基础结构还原好，遇到\begin{pmatrix}这类环境则时好时坏。

6.2 什么时候还是老实用付费/商业方案

开源转换链能处理“标准的、结构清晰的LaTeX”，但如果你要的是：从一张模糊的书籍扫描图里识别并还原为可编辑公式、从旧版MathType公式全量转换、处理大量带自定义宏包的论文模板，这时候开源工具就有点力不从心了。

商业方案比如Mathpix，它的OCR识别能力确实强，尤其对复杂公式和带文本混排的截图，识别准确率远超开源模型；MathType自带格式转换工具在旧版docx/Word文档批量处理上也比开源脚本省心。我不是说商业工具有多神，但明确了人力和时间成本之后，在大量复杂公式场景里，付费工具的性价比就体现出来了。

6.3 我现在的公式流转工作流

写了这么多，最后直接晒一下我目前跑的这套东西，供参考：

• 写草稿：Markdown + LaTeX公式，用VSCode/Typewriter。
• 给别人协作：直接用Pandoc把Markdown转docx，公式自动OMML。
• 临时粘贴少量公式：用我的Python脚本，复制一条转一条。
• 收到只有图片的公式：能找源码就找源码，不能就手动敲，OCR只作为辅助参考。
• 反方向要LaTeX：优先找原始Markdown/LaTeX文件，实在没有再考虑OMML转MathML再转LaTeX，但转完要逐条核对。

这套组合拳下来，我已经很少被“公式格式不兼容”这种事卡住了。你要是也想摆脱“截图贴公式”的魔咒，可以照着上文内容先搭个最小脚本试试，先从最常用的分式、根号、上下标开始转，用顺了再逐步增加复杂度。公式转换这件事，本质上就是学会在三种语言之间搭桥，桥搭好之后，Word和Markdown之间就不再是隔阂了。