企业官网建设流程全解析

用 LibreOffice 这些年，最常被问到的一个问题其实是这么一句：“为什么我在 Calc 里打开宏管理器，我的宏下面既有 Standard 又有 WikiEditor，两个到底有什么区别？”表面上看这只是个宏库命名的问题，但往深了挖，它牵出来的是整个 ODF 格式的组织逻辑。这篇内容我就以 ODF 格式为主线，从文件结构一路讲到宏库存放，最后再回到 Standard 和 WikiEditor 的身份判断上，顺便把用 ODF + 宏时容易踩的坑也一起说清楚。适合三类人看：刚接触 LibreOffice、想弄明白 ODF 和 docx 到底差在哪的新人；已经在用 Calc 写 Basic 宏、却始终没搞懂宏管理器列表含义的进阶用户；以及打算把公司文档全面转向 ODF 格式、需要评估成本和风险的办公负责人。

1. ODF 不是一种文件，是一个“包”：第一次拆包的正确姿势

1.1 把 .odt 后缀改成 .zip 会看到什么

很多教程都会告诉你“ODF 文件本质上是 ZIP 压缩包”，但真正动手拆过包的人并不多。拿一个 .odt 文本文档举例，复制一份，把后缀改成 .zip，双击解压，你会看到这样的目录：

content.xml styles.xml meta.xml settings.xml META-INF/manifest.xml mimetype Thumbnails/thumbnail.png

这个结构的背后道理很简单：ODF 不是把文字、图表、样式揉成一个二进制大块，而是把所有内容拆成职责明确的 XML 文件，再用 ZIP 把它们装订成册。mimetype 文件放在最外层且不压缩，是为了让对方程序不用解压整个 ZIP 就能识别文件类型，这是 ODF 规范里专门定义的。

1.2 每一个 XML 文件各管哪摊事

理解 ODF 最轻松的入口，是先记清楚这几个 XML 的分工：

重点看 content.xml 和 styles.xml 的拆分逻辑：内容管“是什么”，样式管“长什么样”。这么设计最大的好处是，当你要把内容从一套排版体系挪到另一套排版体系时，剥离样式的时间会大大缩短。我帮朋友从某个老旧的文字系统迁移资料时，就是写了个脚本只提取 content.xml 里的文本，几十个文档几分钟就处理完了。

1.3 ZIP 容器带来的三个隐藏能力

除了“拆得开”，ZIP 容器还顺带给了 ODF 三个实用的能力。

第一是压缩率。ODF 默认对 XML 做压缩，所以一个内容非常多的 .ods 电子表格，文件体积往往比同样内容的 .xlsx 还要小一点。第二是加密边界清晰。加密时既可以整包加密，也可以只加密 content.xml 这类核心文件，manifest.xml 里会写着每个文件的加密算法和密钥信息。第三是局部替换非常方便。改样式不满意，直接解压替换 styles.xml 再压回去就行，不用重新生成整个文档。

1.4 和 docx 的“同构不同命”

用过 Office 的人可能觉得看着眼熟——docx 也是 ZIP 包加 XML，原理上确实是一回事。但差别在标准归属上：docx 的细节由微软维护，ODF 则由 OASIS 标准组织维护，LibreOffice 只是它的实现者之一，而不是它的主人。这意味着就算哪天 LibreOffice 项目不在了，ODF 仍然是一个公开的标准文档，任何软件都可以继续实现它。对需要长期保存资料的机构来说，这种“标准不跟软件共存亡”的属性，比压缩格式本身更值钱。

2. ODF 的硬实力：为什么它值得被当成默认格式

2.1 “样式与内容分离”怎么帮版本对比解决大问题

团队协作时最烦的是两个人同时改一个文档，最后合并出一堆格式错乱。ODF 因为 content.xml 和 styles.xml 分家，版本管理工具在做 diff 时，能更干净地区分“这次改了哪段文字”和“这次动了哪个格式”。用 Git 管理 .odt 文件时，哪怕不会装 ODF 插件，也能在 XML 层面看出大概改动范围。这一点在 docx 上也能做，但因为 ODF 的 XML 命名空间更规范、标签更紧凑，做程序化处理的成本稍低一些。

2.2 从 ODF 1.1 到 1.3：版本演进里藏着兼容性秘密

LibreOffice 的默认保存版本是 ODF 1.2 扩展版（带一些 LibreOffice 自己的扩展），而 ODF 1.3 在 2020 年成为标准。这里有个很容易被忽略的知识点：ODF 1.2 引入了 OpenFormula，也就是电子表格公式的统一规范。以前 Calc 里的公式函数在不同实现之间可能有差异，OpenFormula 之后，公式的行为被白纸黑字定义下来，这才让“这个 .ods 拿到另一个软件里算出的结果一致”成为可能。

日常使用中，我建议普通用户保持默认的“ODF 1.2 扩展版”不要动。只有当你需要和其他严格遵循国际标准的系统做长期交换时，才在“工具 → 选项 → 加载/保存 → 常规”里把默认格式改成“ODF 1.3”或“ODF 1.2（严格）”。注意，切到严格模式后，某些 LibreOffice 独有的特性（比如某些控件属性）可能会被警告或丢弃，改之前先备份。

2.3 一个实际案例：跨软件迁移那天的情况

去年我帮一个朋友把二十多个老文档从旧系统迁出来，里面既有表格又有图文混排，工具链是 LibreOffice 加上一点 Python 脚本。流程很简单：先用 LibreOffice headless 批量转出 ODF，然后用脚本读取 content.xml 做文本清洗。最让我意外的是，有个软件无法识别的特殊字符在 docx 里已经乱码，但在 .fodt（ODF 的扁平 XML 格式）里完好无损。因为 .fodt 就是未压缩的 ODF 全部内容，可以直接用文本编辑器打开，跑soffice --convert-to fodt转换后，处理难度一下子降低了很多。这个技巧也推荐给所有需要做文档内容治理的人。

2.4 和 Office 交换文件时的三条实用守则

ODF 再好，你身边总有人只用 Microsoft Office。跨软件交换时记住三条：

• 需要对方“编辑”而不是“只读预览”，最好另存为 docx/xlsx，LibreOffice 对这些格式的兼容性已经相当成熟。
• 如果发给对方只是为了确认内容，直接导出 PDF 最省事，避免样式差异引发的无谓沟通。
• 如果强制要求保留 ODF，确认对方 Office 版本在 2016 以上，老版本打开 ODF 的体验普遍较差。

这几条不是妥协，是工程思维：工具选择服务于信息传递的效率，而不是服务于“我很在意格式”的执念。

3. 宏到底藏在 ODF 的哪个角落：从“我的宏”到文档内嵌库

3.1 打开宏管理器前，先搞懂三个存储位置

LibreOffice 里的宏并不全都存在文档内部，它一共有三处安身之所：

第一处是“我的宏”，存储在用户配置目录下，任何文档都能调用，相当于你的个人工具箱。第二处是“文档宏”，紧跟一个具体文档走，打开这个文档时才能用。第三处是“LibreOffice 宏”，是程序自带的宏，通常用来做系统级功能，不太建议普通用户修改。

打开“工具 → 宏 → 宏管理器”，左侧树形结构里常见的“我的宏 → Standard → Module1”，指的就是第一处。这也是大家产生困惑的起点：Standard 到底是什么？为什么它一上来就存在？

3.2 用一条命令查看文档里的宏代码

现在来看第二处“文档宏”。一个宏如果保存在文档内部，它在 ODF 包里的路径通常是这样的：

Basic/Standard/Module1.xml

我在 Linux 终端里拆开一个含宏的 .ods 文件：

mkdir odf_extract unzip -o 我的表格.ods -d odf_extract find odf_extract -name "*.xml" | grep -i Basic

输出结果可以看到类似odf_extract/Basic/Standard/Module1.xml的路径。打开这个 Module1.xml，里面的<sub:module ...>节点存的就是 Basic 源代码。看懂这一点对你做宏备份特别有价值：很多人只在界面上复制代码，很容易漏掉模块属性或引用库；而直接备份 Basic 目录，整个宏库连同模块结构一起带走了。

3.3 宏嵌入文档带来的安全门槛

宏跟文档一起走很便捷，但也意味着攻击者可以把恶意宏塞进 ODF 文档发给目标。LibreOffice 对此设置了一道默认策略：宏安全级别设为“高”时，只有已签名且受信任的宏才会运行；设为“中”则每次打开带宏文档都弹确认框。我个人的建议是保持在“高”或“中”，不要因为嫌麻烦改成“低”。

这里面有个很实际的场景：你用“文档宏”写好一个自动化流程，换电脑打开时却被拦住了。解决方案不是关掉安全级别，而是去“工具 → 选项 → 安全 → 宏安全性 → 受信任的文件位置”里把你的文档目录加进去。这样既不影响安全性，又能免确认运行你自己的宏。

3.4 “Standard” 在文档内嵌库里的特殊意义

文档内嵌宏的默认库名也叫 Standard。也就是说，你在“宏管理器”里看到的 Standard 可能有两个不同身份：一个存在于“我的宏”下面，另一个藏在某个打开的文档内部。区分它们最简单的方法就是看它挂在哪个父节点下：挂在“我的宏”下，是全局库；挂在文档路径下，是文档独有库。当然这个库名最迷惑人的地方也在这里——LibreOffice 把“默认库”和“默认模块”都叫 Standard，容易让人以为它们是同一个东西。

4. Standard 和 WikiEditor 到底有什么区别：宏管理器里的身份辨析

4.1 Standard：系统自带的基础库，不是“神秘文件”

在“我的宏”下面，Standard 是安装 LibreOffice 时自动创建的默认 Basic 库。它里面默认有一个 Module1，你直接往里写代码就能运行。可以把它理解为软件给你的默认工作区，任何文档都能调用它里的宏。

Standard 有几个特性值得知道：第一，它是全局的，存在用户配置目录里，路径一般在 Linux 的~/.config/libreoffice/4/user/basic/Standard/，Windows 则在%APPDATA%\LibreOffice\4\user\basic\Standard\。第二，它不需要额外创建，所以初学者第一眼看到的总是它。第三，为了方便管理，很多人会新建库或模块，但 Standard 本身删不掉，它是用户配置的“基础设施”。

4.2 WikiEditor：看看它是哪来的“编外成员”

再来看 WikiEditor。先说结论：在标准且干净的 LibreOffice 安装里，宏管理器不会无故出现 WikiEditor。如果你在“我的宏”下面看到它，九成是因为安装或曾经安装过 WikiEditor 扩展（LibreOffice 生态中一个用于编辑 MediaWiki 系网站内容的工具）。这类扩展为了提供功能，会在用户配置目录里创建自己的 Basic 库，宏管理器会把它们和 Standard 并排列出来。

还有一种可能同样常见：你的配置是从旧版本或其他人那里继承过来的。老版本里安装的扩展虽然已经停用，但只要它创建的库目录还留在user/basic/下，宏管理器照样会识别并显示出来。WikiEditor 就是典型的“历史遗留型”条目。

4.3 自查：三步判断一个宏库的真实身份

看到陌生的库名，不要急着删除，按三步走就能查清楚：

第一步，打开“工具 → 扩展管理器”，看看列表里有没有 WikiEditor 相关的扩展。有，那 WikiEditor 就是它的库；没有，进入下一步。第二步，打开文件管理器，找到用户配置目录下的basic文件夹，查看 WikiEditor 目录的创建时间，这能帮你判断它是不是老版本迁移带来的。第三步，在宏管理器中选中 WikiEditor，看它下面有哪些模块。如果里面有明显与维基编辑相关的功能代码，那就确定无疑了。

但如果不影响使用，留着也不碍事。宏库不是病毒，它只是占了一个树形节点，不运行没有任何风险。我见过有人为了“清理干净”把配置目录整个删了，结果丢了一堆自己写的宏——这个操作的成本实在太高了。

4.4 一张表理清两者关系

4.5 “另一个 Standard”的经典误区

和 WikiEditor 纠缠在一起的问题里，还有一种情况：用户明明打开了宏管理器，却看到两个 Standard。一个在“我的宏”下，另一个在某个文档节点下。这其实是前文说的“全局库”和“文档内嵌库”同名导致的。你要运行的宏若只在其中一个库里存在，另一个库里的同名 Module 里却是空的，运行宏时就会提示“找不到宏”或弹出空白选项。

判断方法很简单：分别点开两个 Standard 看各自 Module1 里是否有代码。文档内嵌库平时隐藏较深，只有在文档打开状态下才会出现在宏管理器中。别被同名的假象骗了。

5. ODF 与宏的日常维护：备份、签名、迁移的实操细节

5.1 最省心的宏备份方案：直接备份 basic 目录

有人习惯把写好的宏代码复制到文本文件里保存，这当然可以，但很费劲，还容易漏掉库里的引用关系。我推荐直接备份整个用户配置目录下的basic文件夹。不管你的宏是写在 Standard 里还是 WikiEditor 里，也不管你建了多少个自定义库，一个文件夹全带走。恢复的时候把它放回同样路径即可。

在 Linux/macOS 下一条命令就能打出备份包：

tar czf liboffice_macro_backup.tar.gz ~/.config/libreoffice/4/user/basic

Windows 下同理，把%APPDATA%\LibreOffice\4\user\basic直接压缩即可。需要说明的是，宏库备份和文档备份是两码事：宏库备份管的是“我的宏”，文档内嵌宏要另行保存源文档本身。

5.2 宏签名与受信任文件位置

LibreOffice 支持对 Basic 宏库签名，签了名的宏在被其它人打开时更容易通过安全检查。但个人使用场景里，最常遇到的其实是自签宏信任问题：你在自己电脑上签了名，换到另一台电脑上因为证书不同，签名就不被信任。与其折腾签名，不如把常用文档目录加入“受信任的文件位置”，这样更直接。

对团队而言，建议把公共宏库做成扩展（.oxt 格式）分发，而不是让人一一拷贝 basic 目录。用扩展管理器安装后，宏会统一出现在“我的宏”或扩展库节点下，更新时只需要分发新版本 .oxt，用户点一下安装即可，覆盖逻辑由系统处理，比手工覆盖文件稳妥得多。

5.3 用 ODF 的扁平格式做程序化处理：.fodt 和 .fods

处理大量 ODF 文档时，解压再分析 XML 有点绕路。LibreOffice 支持扁平 ODF 格式：文本文档是 .fodt，电子表格是 .fods。它是单个 XML 文件，没有 ZIP 包裹，写脚本处理更顺手。比如你想批量替换某个文档里的所有图片描述文字，可以直接对 .fodt 做文本替换，再用 LibreOffice 转为普通 .odt。

有个小坑提前提醒：.fodt 文件体积比 .odt 大很多，因为未压缩且包含完整标签。处理完记得删掉中间文件，别让它们混进正式的文档目录。我见过有人把 .fodt 当成常规文档格式一直用，结果文件库容量疯长，最后排查半天才发现是这个原因。

5.4 迁移到 ODF 时的批量转换命令

如果你所在团队决定把旧文档统一转为 ODF 格式存储，手动一个一个另存为太低效。LibreOffice 的命令行转换是更靠谱的路子：

soffice --headless --convert-to ods --outdir /output/path /input/dir/*.xlsx

这个命令会把指定目录下所有 xlsx 批量转成 ods。大规模转换前先抽样检查三种典型文件：一个纯文本报告、一个含复杂图表的表格、一个带宏的文档。带宏的文件转换后特别要在宏管理器中确认宏是否完整，因为跨格式转换时宏代码可能被剥离或产生兼容警告。

我在实际转换中还发现一个规律：同一批文件里，xlsx 转 ods 的成功率通常高于 docx 转 odt。因为电子表格的数据结构相对单一，而文字排版中字体、分页、文本框等元素在不同格式间的映射更容易出现差异。所以如果你要在文字文档上做大规模迁移，切换后最好人工抽查页面分页和样式表现，不要只看内容文字有没有少。

最后交代一句

关于 Standard 和 WikiEditor 的那个问题，我再浓缩成一句话：Standard 是系统默认库，人人都有；WikiEditor 是扩展带来的库，不是标配。你在宏管理器里看到它时，去“扩展管理器”里看一眼就知道了，不用删也不用慌。ODF 这个格式的很多设计都是这样——初看是目录和 XML，用久了才发现，它真正解决的是“这套文件到底归谁所有、如何长期保管”的问题。希望这篇能把 ODF 的里子翻给你看清楚，下次再遇到宏库或格式迁移的疑问，拆一个文件比搜十篇教程都管用。