把DeepSeek、豆包等AI工具输出的公式整理进Word时,经常会碰到一种情况:网页上显示的是分式,粘贴后却只剩下 \frac{a}{b}。另一些转换结果外观正常,点击后选中的却是一张图片。
判断导出是否成功,需要分别检查三件事:公式源码是否被正确识别,文档中是否保存了公式对象,以及目标编辑器中的显示和编辑是否正常。
1. Word支持LaTeX,为什么粘贴仍可能失败?
“Word不支持LaTeX”不是准确的解释。微软文档说明,Word公式编辑器支持LaTeX线性输入,并能转换为专业显示格式;具体支持范围取决于版本和语法。[1]
但是,在普通段落中粘贴一段带反斜杠的文本,不等同于进入公式编辑器并调用转换。复制网页时,还可能得到HTML、纯文本或图片,不同复制入口和粘贴方式会影响结果。
LaTeX源码是输入表达,OMML是Office文档中的公式存储格式。[2] 输入路径没有触发解析,或者转换器不支持某个表达式,都可能让源码保留为普通文字。
因此,排查时应先确认拿到的是源码、图片还是已渲染的富文本,再检查后续转换步骤。
2. 用一个分式理解OMML
从下面这个LaTeX表达式开始:
\frac{
a}{
b}
它包含分式、分子和分母三个结构。对应的简化OMML片段如下:
<m:oMath xmlns:m="http://schemas.openxmlformats.org/officeDocument/2006/math">
<m:f>
<m:num><m:r><m:t>a</m:t></m:r></m:num>
<m:den><m:r><m:t>b</m:t></m:r></m:den>
</m:f>
</m:oMath>
m:oMath表示公式对象,m:f表示分式,m:num和m:den分别承载分子与分母,文字位于数学运行元素中的m:t。[3]
这段XML只展示公式结构,不是完整DOCX文件。将它存成.docx并不能得到有效Word文档,还需要文档包和Word正文等结构。
对于嵌套分式,分子或分母可以继续包含其他数学结构。转换器需要保留这些层次,仅仅替换\frac字符串无法处理任意嵌套表达式。
例如:
\frac{
1}{
1+\frac{
1}{
x}}
如果分母被压平成普通文本,即使生成文件成功,也不能说明公式结构正确。
3. 用Pandoc建立一个最小转换样例
为了让示例独立于具体商业产品,可以使用Pandoc作为参考转换工具。其官方手册说明,DOCX输出使用OMML表示数学公式。[4]
创建UTF-8编码的sample.md:
# 公式转换样例
行内公式:$x^2$。
独立分式:
$$
\frac{a}{b}
$$
嵌套分式:
$$
\frac{1}{1+\frac{1}{x}}
$$
安装Pandoc后,在样例目录运行:
pandoc --version
pandoc sample.md -f markdown+tex_math_dollars -t docx -o sample.docx
这里显式开启tex_math_dollars,让读者能看出本例使用美元符号识别数学区域。代码块里的LaTeX是展示用代码,不应当被当成数学公式转换。
这个DOCX转换路径不需要为了上述简单公式安装完整TeX Live。使用LaTeX引擎生成PDF是另一条处理路径,其依赖不能直接套到DOCX导出上。[4]
本文提供的是依据官方文档编写的复现步骤。当前写作环境未安装Pandoc,因此不将这些命令的预期结果称为本机转换实测结果。
4. 怎样检查DOCX里是否真的有公式?
DOCX是ZIP格式的文档包,普通正文通常位于word/document.xml。可以读取其中的OMML元素,作为结构检查的第一步。
下面的Python脚本只使用标准库:
import sys
import zipfile
import xml.etree.ElementTree as ET
NS = {
"m": "http://schemas.openxmlformats.org/officeDocument/2006/math"}
with zipfile.ZipFile(sys.argv[1]) as archive:
root = ET.fromstring(archive.read("word/document.xml"))
for tag in ("oMath", "f", "sSup"):
print(f"{tag}: {len(root.findall('.//m:' + tag, NS))}")
保存为inspect_math.py后运行:
python inspect_math.py sample.docx
对于上面的三个数学区域,如果按所示结构成功转换,预期为三个oMath、三个分式节点和一个上标节点。其中嵌套分式本身包含两个分式节点,所以不能把分式数量当作公式数量。
脚本按命名空间URI定位元素,不依赖XML恰好使用m作为前缀。这里只检查普通正文,没有遍历页眉、页脚等其他文档部件。
找到OMML说明文档包含Office数学结构,但不能单凭数量证明内容完全正确。还应检查分子、分母、上下标的归属;在Word中打开文件,修改分母并保存,再重新打开确认。WPS需要单独验证,并记录版本。
5. 将故障定位到具体步骤
| 现象 | 优先检查 | 后续处理 |
|---|---|---|
| 文档中出现原始反斜杠和命令 | 数学区域是否被识别 | 检查定界符和输入格式配置 |
| 公式变成图片 | 是否采用了图片回退策略 | 确认是否需要可编辑结构输出 |
| 有OMML,但分式结构错误 | 解析结果与数学节点层次 | 用最小表达式定位不支持的结构 |
| Word正常,另一编辑器异常 | 编辑器版本、字体与兼容性 | 分开记录各环境的结果 |
| 简单公式正常,特定命令失败 | 解析器支持范围 | 保留失败源码,建立回归样例 |
避免遇到无法解析的内容时,直接删除未知命令再输出。这样可能使文件看起来正常,却改变了公式含义。更可控的做法是保留原始输入,记录失败位置,并明确说明是否回退成文本或图片。
6. 如何建立自己的验证样例
在最小样例通过后,再逐项加入根式、矩阵、带括号的嵌套结构和含中文说明的公式。每个样例记录输入、转换器版本、生成日志、结构检查及编辑器操作结果。
对于鲸鱼AI助手这类AI内容导出工具,同样可以采用这套验证方法:先用可控样例检查公式结构,再验证编辑和保存,最后扩大到完整对话。仅用网页预览截图无法证明导出的公式仍可编辑。
如果某一项暂未验证,就记录为未验证。这样后续排查才能分清是输入语法、转换实现还是编辑器兼容性造成的差异。