企业官网建设流程全解析

1. 政务公众号里的公式，为什么一搬到网站就变成乱码？

做政务新媒体或者网站维护的朋友，大概率都撞上过同一个坑：领导在微信公众号里发了一篇带数学公式的通知，或者下属单位提交的材料里全是带根号、分数、求和符号的内容，排版倒是挺好看，结果你复制到政务网站后台，一粘贴，公式全部散架——有的是大段类似\frac{}{}的原始代码，有的是风格跑偏、还带着微信底部灰色横线的文本，更常见的是公式直接“消失”，只剩下一串莫名其妙的字符。

我前一阵帮某个区级政务平台处理一批教育类政策解读稿件，就遇到了典型的公式导入问题。那边编辑从微信公众号后台复制文章，里面的公式原本是用公式编辑器生成的图片，复制时微信会自动带上图片的 base64 编码，但粘贴到我们基于 HTML 的 CMS 后台后，图片显示不出来，公式就变成一个破图标。另一批稿件比较特殊，公式是用第三方编辑器以 LaTeX 语法嵌入的，从微信公众号复制到 Word，再粘贴到平台，LaTeX 语法全都被转义了，发布出来就是满屏的$x^2$。

这个问题不是个例。政务平台的特点是“内容要准、格式要稳、发布要快”，而微信公众号作为一个封闭生态，它的编辑器、复制行为、公式存储方式都跟普通网页完全不同。你不能指望编辑们人人都懂代码，也无法要求每个科室都去装付费公式插件。最现实的做法是：建立一条从“公众号文章复制”到“政务平台发布”的公式导入流水线，从源头把公式转成统一、可发布的格式。下面我把这套方法拆开讲，每一步都是我实际踩过坑之后才理顺的。

2. 先搞清楚微信公众号里的公式到底是什么格式，再谈导入

2.1 三种最常见的公式存储形态

要解决公式导入，第一件事不是找工具，而是扒开公众号文章的 HTML 看一下公式的真面目。我处理过的案例里，公式在公众号里基本有三种形态：

• 图片公式：公式以图片形式嵌入正文。微信编辑器排版时，图片会被转成 base64 字符串存放在 HTML 中，或者上传到微信的 CDN 上。政务场景里，很多老编辑喜欢用“公式截图+图文排版”的方式，这类公式本质上就是图片，无法检索、无法缩放，发布到网站后也特别容易丢。
• 富文本公式：公式用 Unicode 字符拼出来，比如“x²”“√3”“∑”，这些看着是公式，但到了不同系统的字体渲染下，符号经常丢失或变形。政务平台的后台如果字体库不支持某些数学符号，发布后就是方框。
• LaTeX/MathML 公式：一些编辑会用第三方工具（如 MathType、语雀、Latex 编辑器）生成公式，复制到公众号时可能转换为 MathML 或 OMML（Office Math Markup Language），也可以保留 LaTeX 源码。这类公式复制到普通文本域时最乱，经常变成大段的语法代码。

我遇到最头疼的是 OMML。有次编辑在 Word 里用 MathType 敲了一个方程组，然后直接复制到微信公众号编辑器，微信把它转成了 HTML，再从公众号后台复制出来，粘贴到我们平台的编辑器里，得到的是一整段带m:oMath标签的 XML。普通 CMS 根本不认这种格式，前端渲染直接出错。

2.2 微信复制行为的“坑”在哪

很多人以为从微信公众号复制文章，复制到的是干净文本，这是个误解。微信公众号后台的编辑器基于富文本，复制时会把样式、内联 CSS、图片 base64、嵌套标签全部一起复制。你去浏览器“检查元素”就能看到，微信复制的片段里，字体大小全都是font-size: 15px，行高是letter-spacing: 0.544px，这些都是微信在排版时强加的内联样式。而公式部分，如果是图片，可能还会附带><m:oMathPara> <m:oMath> <m:r> <m:t>样本量 = (Z² × p × (1-p)) / d²</m:t> </m:r> </m:oMath> </m:oMathPara>

而前台页面完全没渲染出任何公式，只看到一行扎眼的蓝字 XML 标签。这就是典型的 OMML 格式在普通 HTML 环境下“裸奔”的结果。

4.2 处理过程

我的处理过程分了四段：

第一段：把 OMML 结构化内容从微信复制片段中抽取出来。我用一个简单的 Python 脚本读取 HTML 文件，用正则和 BeautifulSoup 提取所有<m:oMathPara>节点，并按顺序拼接成新的 HTML 文件。这一步最大的价值是把公式集中到一起处理，避免反复翻页面。

第二段：用 Pandoc 把 OMML 转成 LaTeX。这里我用了 Pandoc 最省事的办法：把包含 OMML 的 HTML 文件直接喂给 Pandoc，再用--mathjax参数输出为新的 HTML。Pandoc 会自动识别 OMML 并转成 LaTeX 公式，同时把正文保留成干净的 HTML 结构。命令大概是：

pandoc input.html --mathjax -o output.html

实测效果不错，原来的“样本量 = (Z² × p × (1-p)) / d²”会转成样本量 = \frac{Z^{2} \times p \times (1-p)}{d^{2}}，公式结构保住了。

第三段：把 LaTeX 装进 CMS 的正文栏。先在政务平台后台打开“源码模式”，把转换后的 HTML 粘贴进去。因为我们的 CMS 用的编辑器是 UEditor，它在源码模式下不会自动过滤 LaTeX，只要前端模板引入了 MathJax，公式就能正常渲染。我更推荐在前端加载 KaTeX，因为它速度快且轻量，对政务网站访问高峰比较友好，前提是公式复杂度不高。KaTeX 对 LaTeX 的兼容性已经能覆盖政务场景里九成以上的公式。

第四段：校验和发布。我在测试栏目里发了一版预览，检查公式图片、公式渲染、移动端显示。有一个细节：OMML 里的公式经常含有多余的空白控制符，Pandoc 转换时大概率会保留，好在 KaTeX 遇到多余空格不会报错，只是显示略宽，不影响阅读。确认没问题后，把测试内容删掉，正式发布。

4.3 处理结果

最终发布页面里，公式全部正常显示为排版良好的数学符号，和公众号原文观感一致。编辑侧操作流程固化下来后，整个导入耗时从原来的半天缩短到十几分钟，主要时间花在第二段的 Pandoc 转换和第四段的校验上。

5. 没有 Pandoc 怎么办？纯前端/纯手工也能搞定公式导入

不是所有政务网站管理员都有条件在后台跑 Pandoc，也没法要求信息技术科的人随时配合安装工具。我自己也遇到过连 Python 环境都没有的临时环境，那套保底方案你也可以收藏。

5.1 用 MathJax 直接渲染 MathML 原样标签

如果你复制出来的公式是 MathML 而不是 OMML，那就简单多了。MathJax 天然支持 MathML 输入，你只要保证 CMS 前端模板里加载了开启了 MathML 扩展的 MathJax 库，然后把<math>标签原样放进正文源码中即可。

实际操作里，政务后台的编辑器经常会干一件事：在保存时自动加上contenteditable或>import re bad_chars = re.findall(r'[\ue000-\uf8ff]', html_text) print(bad_chars)

如果有，直接在脚本里替换掉或删除。政务内容不需要这些标记字符，删掉不影响信息完整性。

6.4 政务平台过滤规则会吃掉 MathML 和 LaTeX

很多政务 CMS 的富文本编辑器都有 XSS 过滤机制，比如 UEditor 自带的xssFilter、或者第三方编辑器里的白名单过滤。默认配置下，<math>、<semantics>、<annotation>这些标签是会被直接剔除的。即使你前端引入了 MathJax，后台保存时公式标签已经被删除，前端拿什么渲染？

解决方案有两种：

• 找技术同事在过滤白名单里加上 MathML 相关标签，重新发布编辑器配置。
• 绕开富文本编辑器，在 CMS 模型里单独增加一个“公式源码”字段，前端通过模板输出。

我最终采用的是第二种。因为政务平台的编辑器经常升级，改白名单的维护成本高，不如直接在数据模型层面单独存公式源码，干净又稳定。

7. 从一次导入到长期可用：政务平台公式能力的规划建议

如果你不只是处理一次导入，而是需要长期把公众号内容同步到政务网站，那最好做一点长远规划，避免每次都靠人工手工转。

7.1 建立标准化的公式书写规范

先跟公众号的内容生产端约定好：普通通知类文章，不写复杂公式，最多用 Unicode 字符；涉及数据指标和政策计算的内容，统一用 LaTeX 语法写在第三方程编辑器里；需要严格排版的内容，直接用图片公式，但图片必须走本地上传。这个规范能直接减少八成以上的导入问题。我们单位公众号上的公式绝大多数是平均数、百分比、标准差，这些用 Unicode 和简单 LaTeX 就能覆盖，根本不需要 Word 公式编辑器介入。

7.2 在 CMS 前端统一集成公式渲染引擎

政务平台的前端模板里，一次性引入 KaTeX 的 CSS 和 JS。然后在模板的正文输出区域，加入一个轻量级脚本，自动识别页面中的$...$和$$...$$公式块并渲染。这样编辑发布时不需要手动处理公式，前端会自动展示成规范公式。这个思路对网站性能影响极小，KaTeX 的压缩后 JS 不到 300KB，按需加载即可。

7.3 预留公式源码字段，方便二次编辑

与其把公式混在正文 HTML 里，不如在 CMS 数据表中专门加一个formula_source字段。编辑从公众号复制的内容，经过转换后，把公式源码单独存到这个字段。后续如果要修改数据、重新排版、导出 PDF，都能直接读取源文件，不需要再从文章正文里反向解析。尤其是政务场景里经常需要把同一份内容同时发布到网站、微信公众号、政务 APP，统一留一个公式源字段能省不少功夫。

7.4 定期抽查发布内容的公式兼容性

政务网站不像技术博客，没有专门的自动化测试。我的习惯是每个月抽两篇带公式的文章，用不同浏览器（Chrome、国产浏览器、手机自带浏览器）检查公式显示效果。不要假设发布一次就永远有效——CMS 升级、模板改动、CDN 策略调整，都可能让原本正常的公式一夜之间变成乱码或方框。保持抽查，至少能早发现问题。

8. 我个人在实际操作中总结出的一套最低成本方案

每次给其他单位做交流时，总有人问“你们这么处理公式，是不是要专门招一个懂技术的人？”其实不需要。我梳理一下实际落地时的最小配置：一个会复制粘贴的编辑，加一个能帮忙上线一次 MathJax/KaTeX 的技术同事，再加上一套固定流程，就能解决九成以上微信公众号公式导入的问题。我见过太多政务平台采购了昂贵的文档中台、富文本组件，最后公式导入还是靠截图的例子。工具不是关键，流程才是。

更进一步说，公式只是公众号同步到政务平台时众多兼容性问题中的一个典型代表。表格样式、图片防盗链、段落间距、字体单位，这些问题背后都是同一个逻辑：微信公众号的内容是“私有格式”，政务平台是“标准格式”，中间必须有翻译层。公式导入恰好是最需要技术含量的一块，也是阅读体验影响最大的一块。搞定了公式，其他内容的迁移基本就顺畅了。

最后分享一个我常用的保底小技巧：遇到怎么都处理不好的公式，别纠结，直接截图放到正文里。政务网站的内容，至少九成读者只是想知道结论，公式的准确性和可复制性反而不是刚需。截图虽然不能检索、不能缩放，但至少不会在发布时翻车。等有时间了再用正规方案替换，比卡在导入环节耽误发布要强得多。这句话听起来有点不思进取，但在政务新媒体这种“发布时效压倒一切”的环境里，实用永远比完美更重要。