德国政府统一采用 ODF：数字主权落到每一份办公文档

德国正式将政府办公文档的标准格式统一为 ODF（OpenDocument Format），并把微软 OOXML 格式，如 .docx、.xlsx 和 .pptx，排除在官方标准之外。这不是简单地更换文件扩展名，而是把长期保存、跨软件交换和供应商选择权落实到政府日常产生的文档中。

格式标准决定了谁掌握文档

办公文档看似只是文件，背后却包含版式、公式、批注、修订记录、嵌入对象和宏等复杂结构。一个组织如果把核心资料长期绑定在特定厂商的默认格式上，迁移成本会随着文件数量和使用年限不断增长。

ODF 对应的常见扩展名包括：

德国此次调整的重点，是让开放格式成为政府办公文档的规范交付物。它与德国近年来推动数字主权的方向一致：从数据中心、云平台延伸到应用软件和办公套件，公共机构需要保留替换供应商和独立处理数据的能力。

需要注意的是，“OOXML 不再是官方标准”不等于外部发送来的 Office 文件会立刻无法打开。真正需要改变的是模板、采购合同、归档规则、系统导出接口和跨部门交付流程。

迁移难点不在安装软件，而在兼容性边界

安装支持 ODF 的办公套件并不困难，批量迁移时更棘手的是文档行为是否保持一致。复杂表格可能发生分页变化，演示文稿的字体和动画可能偏移，电子表格中的高级函数、外部数据连接和 VBA 宏也可能无法原样运行。

因此，迁移不能只统计“成功转换了多少文件”，还应按风险分类：

• 普通通知、会议纪要和无复杂样式的表格，可以优先转换。
• 法律文本、固定版式材料和长期档案，应同时生成 PDF/A 等归档版本，并保留原文件。
• 含宏、插件、外部链接或复杂公式的文件，需要人工验收或重构流程。
• 业务系统生成的文档，应从源头改造导出格式，而不是长期依赖事后批量转换。

字体也是容易遗漏的依赖。同一个 ODF 文件在两台机器上显示不同，问题可能不在格式，而在系统没有安装相同字体。政府或大型组织应把字体包、模板和办公软件版本纳入统一配置。

可以这样实践：批量转换并自动检查

下面示例假设使用 Debian 或 Ubuntu，并已准备一个 incoming 目录。运行前应备份源文件；该脚本适合试点和普通文档，不应直接用于覆盖正式档案。

sudo apt-get update
sudo apt-get install -y libreoffice

mkdir -p converted

find incoming -type f \( -iname '*.docx' -o -iname '*.xlsx' -o -iname '*.pptx' \) -print0 |
while IFS= read -r -d '' file; do
  case "${file##*.}" in
    docx|DOCX) format=odt ;;
    xlsx|XLSX) format=ods ;;
    pptx|PPTX) format=odp ;;
    *) continue ;;
  esac

  libreoffice --headless \
    --convert-to "$format" \
    --outdir converted \
    "$file"
done

转换完成后，可以用标准库编写一个轻量检查器。ODF 文件本质上是包含多个 XML 文件的 ZIP 包；下面的脚本检查扩展名、压缩包结构和声明的 MIME 类型。

将其保存为 check_odf.py，然后执行 python3 check_odf.py converted：

from pathlib import Path
from zipfile import BadZipFile, ZipFile
import sys

EXPECTED = {
    ".odt": "application/vnd.oasis.opendocument.text",
    ".ods": "application/vnd.oasis.opendocument.spreadsheet",
    ".odp": "application/vnd.oasis.opendocument.presentation",
}

root = Path(sys.argv[1] if len(sys.argv) > 1 else "converted")
failed = False

for path in sorted(root.rglob("*")):
    expected = EXPECTED.get(path.suffix.lower())
    if not expected:
        continue

    try:
        with ZipFile(path) as archive:
            names = set(archive.namelist())
            mime = archive.read("mimetype").decode("ascii").strip()
            valid = "content.xml" in names and mime == expected
    except (BadZipFile, KeyError, UnicodeDecodeError):
        valid = False

    print(f"{'OK' if valid else 'FAIL'}  {path}")
    failed |= not valid

raise SystemExit(1 if failed else 0)

这类检查只能证明文件结构基本正确，不能判断排版、公式和宏是否等价。更稳妥的流水线还应生成 PDF 预览，对关键模板做视觉比较，并抽样打开转换后的文件。

推行时应检查什么

ODF 政策要真正发挥作用，不能停在“默认保存格式”设置上。落地时至少应明确以下事项：

• 新建文档、邮件附件、系统导出和归档分别接受哪些格式。
• 哪些复杂文档必须人工验收，哪些可以自动转换。
• 是否存在依赖 VBA、专有插件、特殊字体或外部数据源的流程。
• 采购条款是否要求软件完整读写 ODF，而不只是能够打开文件。
• 是否保留原始文件、转换日志、失败清单和可追溯的版本信息。

德国的选择表明，数字主权不仅由云平台和数据中心决定，也存在于每天流转的文字、表格和演示文稿中。开放标准降低了长期锁定风险，但转换成本不会自动消失。先盘点文档类型和专有依赖，再从低风险流程开始试点，通常比一次性全量转换更可靠。