将传统 WordPerfect 文件转换为现代格式：实用指南

WordPerfect 曾是企业、法律事务所和学术机构的主流文字处理平台。虽然该程序仍在使用，但大多数组织已迁移至 Microsoft Word、Google Docs 或开源套件。然而，现实是无数旧的 .wpd 文件仍存放在共享盘、归档盒或备份磁带上，常包含合同、案件文件或研究论文，这些文档在法律或历史上仍具重要性。要在不丢失排版、嵌入对象或元数据的前提下转换这些文档并非易事。本指南将从评估源文件集合到验证最终输出，完整展示工作流程，重点在于保持忠实度并确保长期可访问性。

1. 理解 WordPerfect 转换的挑战

WordPerfect 实现了一种专有的二进制布局，与 DOCX 使用的 Office Open XML 结构或 PDF 规范大相径庭。最常见的障碍包括：

• 字体替换 – WordPerfect 嵌入的是字体度量而非字体文件本身。当转换主机缺少原始字体时，转换引擎可能使用默认字体替代，从而改变换行和分页。
• 复杂布局特性 – 页眉/页脚区域、多栏段落、脚注和条件文本规则若被普通转换器误读，会导致内容错位。
• 嵌入对象 – OLE 对象（如 Excel 图表、Visio 图形）以二进制块形式存储。部分转换工具无法提取或渲染这些对象，导致信息丢失。
• 宏和脚本 – WordPerfect 的宏语言（WPM）在原生环境之外几乎没有支持。转换依赖宏生成内容的文档需要另行策略。
• 元数据缺口 – 旧版 WordPerfect 将作者、创建日期和修订历史存储在专有字段中。若工具未将其映射到标准 Dublin Core 或 Office Open XML 属性，转换时这些信息可能会被丢弃。

提前识别这些陷阱可防止后期迁移管线中出现昂贵的返工。

2. 为转换准备源文件

严格的准备阶段可以降低风险，并使后续转换步骤可复现。

2.1 清点与分类

创建一张电子表格，列出每个 .wpd 文件、其大小、最后修改日期以及已知的使用场景（如法律合同、营销手册）。按优先级为文件打标签，有助于资源分配：高风险的法律文件值得手动复核，而大量的时事通讯可批量处理。

2.2 字体整合

收集文档中使用的原始字体文件。如字体为专有，请考虑许可可替代的、在视觉度量上相匹配的字体。将这些字体安装在转换工作站上；大多数转换器会优先使用首个匹配的字体。

2.3 转换前备份

切勿直接在原始档案上操作。将整个集合复制到专用的转换磁盘。这为意外损坏提供安全网。

2.4 清除冗余文件

删除重复或废弃的 .wpd 文件。对清单运行重复文件查找工具可将工作量削减 10‑20 %，并降低存储成本。

3. 选择目标格式

最佳输出格式取决于后续使用场景。

• DOCX – 当文档仍将在 Office 或 Google Workspace 中编辑时最合适。DOCX 保留大多数结构元素（样式、表格、批注），并支持修订记录。
• PDF/A‑2 – 适用于归档。PDF/A 通过嵌入字体消除对外部字体的依赖，并禁止活动内容，保证只读呈现。
• ODT – 对于偏好 LibreOffice 等开源生态的组织有用。
• HTML5 – 当内容将发布在网站或内联网时，转换为干净的语义化 HTML 可保留标题层级并便于样式化。

在很多项目中会采用 双输出 方法：一个 DOCX 用于日后编辑，另一个 PDF/A 用于合规和长期存储。

4. 选取转换引擎

转换工具大致分为三类：

对于大型、隐私敏感的档案，混合方案往往效果最佳：对最复杂的文件使用本地安装的 WordPerfect 实例（或授权试用版），其余大多数文档则交给云服务如 convertise.app 处理。Convertise 在可能的情况下在浏览器中完成全部处理，确保源文件永不离开用户机器——这对机密法律合同尤为关键。

5. 详细转换工作流

下面是一套可重复执行、可脚本化的逐步流程。

5.1 自动化预检查脚本（PowerShell 示例）

# 扫描文件夹中的 .wpd 文件并生成 CSV 报告
Get-ChildItem -Path "E:\LegacyWPD" -Recurse -Filter *.wpd |
Select-Object FullName, Length, LastWriteTime |
Export-Csv -Path "E:\ConversionReport\wpd_inventory.csv" -NoTypeInformation

生成的 CSV 用作批处理引擎的输入，可将大于一定大小（>5 MB）的文件标记为手动复核。

5.2 使用 Convertise CLI 进行批量转换（假设性）

# 假设 convertise 提供名为 cs-cli 的命令行包装器
cs-cli batch \
  --input "E:/LegacyWPD/**/*.wpd" \
  --output-format docx \
  --output-dir "E:/Converted/DOCX" \
  --log "E:/ConversionReport/batch_log.txt"

CLI 会保留原始时间戳并为每个输出文件写入 SHA‑256 校验和。这些哈希将在后续验证中使用。

5.3 PDF/A 生成（使用 LibreOffice 无头模式）

libreoffice --headless --convert-to pdf:writer_pdf_Export --outdir "E:/Converted/PDF" "E:/Converted/DOCX/*.docx"
# 使用 Ghostscript 强制 PDF/A‑2 合规
for f in E:/Converted/PDF/*.pdf; do
  gs -dPDFA -dBATCH -dNOPAUSE -sProcessColorModel=DeviceRGB \
     -sDEVICE=pdfwrite -sOutputFile="${f%.pdf}_pdfa.pdf" "$f"
done

两阶段方法确保生成的 PDF 符合归档标准。

5.4 验证与质量保证

1. 校验和比较 – 通过确认预转换哈希与伴随元数据文件的后转换哈希一致，验证源文件在转换过程中未被修改。
2. 目视抽样检查 – 随机抽取 5 % 的转换文档。在 Word/LibreOffice 中打开，对比页数、页眉/页脚一致性及表格对齐情况。
3. 元数据审计 – 使用 exiftool 或 pdfinfo 提取属性，确保作者、创建日期和关键字被保留。如有字段缺失，可通过脚本从原始 CSV 中注入。

6. 处理嵌入对象与宏

6.1 提取 OLE 对象

WordPerfect 将 OLE 对象存储为二进制流。Ole2Extract 等工具可在转换前将其抽出。抽取后，可手动或通过宏重新嵌入目标文档。

6.2 处理 WordPerfect 宏

由于 WPM 宏不可移植，最安全的做法是先在 WordPerfect 环境中运行宏，将生成的内容导出为静态文档（如 PDF），再对该静态输出进行转换。如果宏仅生成文本，可考虑使用 Python 脚本（如 python‑wpd 库）自行处理原始 .wpd 文件并复现逻辑。

7. 保留与映射元数据

在转换后仍能保留的标准元数据字段包括：

• 标题 → dc:title（PDF）或 coreProperties.title（DOCX）
• 作者 → dc:creator / coreProperties.author
• 主题/关键字 → dc:description / coreProperties.subject
• 创建/修改日期 → dcterms:created / dcterms:modified

若转换工具丢弃这些字段，可在后处理阶段重新注入。例如使用 python‑docx 为 DOCX 填充元数据：

from docx import Document
import csv, datetime
from pathlib import Path

metadata = {row['filename']: row for row in csv.DictReader(open('wpd_inventory.csv'))}
for file in Path('E:/Converted/DOCX').glob('*.docx'):
    doc = Document(str(file))
    meta = metadata.get(file.name, {})
    doc.core_properties.title = meta.get('title', '')
    doc.core_properties.author = meta.get('author', '')
    created = meta.get('created')
    if created:
        doc.core_properties.created = datetime.datetime.fromisoformat(created)
    doc.save(str(file))

8. 大规模批量自动化

当档案包含数万文件时，可采用 RabbitMQ 或 AWS SQS 等队列系统来异步调度转换工作者。每个工作者从队列中取出包含文件路径的消息，执行转换管道，将结果写入输出存储桶，并发布成功/失败事件。此设计提供：

• 可伸缩性 – 队列积压时可随时新增工作者。
• 容错性 – 失败的任务可自动重试。
• 审计追踪 – 每条消息携带唯一标识符，日志集中保存，满足合规报告需求。

9. 隐私与合规考量

尽管许多旧 WordPerfect 文件仅供内部使用，但仍可能包含个人身份信息（PII）或受保护的健康信息（PHI）。在将任何文件发送至云服务前，请确保：

1. 数据驻留 – 服务在与贵组织相同司法辖区内处理文件。
2. 端到端加密 – 文件在传输期间使用 TLS 加密，如可能在处理期间也进行静态加密。
3. 无持久存储 – 确认供应商在转换完成后不会保留副本。以 Convertise.app 为例，文件在转换结束后会立即被删除。

若文件不满足上述条件，则应坚持本地转换。

10. 转换后资产的归档存储

转换成功后，请按照记录保留策略进行存储。推荐的目录层级如下：

ArchiveRoot/
├── Original_WPD/        # 只读、不可变的备份
├── DOCX_Editable/       # 用于未来编辑
├── PDF_A_Archive/       # 长期只读
└── Metadata/            # CSV 报告、校验和、审计日志

对 PDF/A 层使用 WORM（一次写入、多次读取）存储，以防止意外修改。对重复数据进行去重，以节省空间，同时保留校验和完整性。

11. 常见陷阱与解决方案

12. 为转换后语料库做好未来保障

一旦文档以开放、规范良好的格式（DOCX、PDF/A、ODT）存放，未来过时的风险将大幅降低。为进一步巩固：

• 依据标准进行校验 – 使用 PDF/A 验证工具（例如 veraPDF）和 DOCX 模式验证器。
• 定期刷新存储介质 – 每 5‑7 年迁移至新存储技术。
• 保留转换配方 – 存档完整的命令行参数、工具版本以及使用的字体包。该配方可在下游系统更新渲染引擎时重新生成相同结果。

---

将传统 WordPerfect 转换视作一次严谨的数据迁移项目——包括清点、受控工具、自动化验证与稳健归档——组织即可在不牺牲布局完整性或合规性的前提下，释放数十年的宝贵内容。无论选择全本地方案，还是借助如 convertise.app 这类注重隐私的云工具，本文所述原则均能确保过程透明、可重复、易审计。