MNBVC-Wiki

1. 任务
   • 转换大量的DOC和WPF文件为DOCX文件，具体为959457份DOC和10029份WPF文件。
2. 目标
   • 实现一种既节约人工成本又高效高质量的自动化转换流程。

1. 环境要求
   • 一台装有Office 2019或以上的windows机器
2. 技术限制
   • Word自带一个大锁，无法在单个windows上用多进程或者多用户会话的方式实现并行转换
3. 解决方案
   • 使用hyper-v功能在本地机器上安装多个带有Office的windows虚拟机，进行虚拟机级别的并行文档转换，以充分利用CPU的多核计算性能

1. 将爬下来的带文件号的DOC文件以文件形式进行任务拆分
   • 任务分发服务器代码
2. 每个客户端（工作节点）主要用save_as_docx函数调用Word来解决实际的转换任务
   • 客户端脚本

开一个管程，给一个合理的超时时间（笔者用20秒），时间结束转换函数还未执行完则认为异常，用kill_word杀掉WINWORD.EXE进程后再尝试后续转换。

顶层级弹窗出现得非常频繁，close_top_window函数用于将这些弹窗点掉，避免程序在人没盯着屏幕的时候摸鱼。

我们已经尽可能把转换交给自动脚本处理，然而，还有部分比较罕见的异常导致部分文件无法另存为，这些剩下的文件我们尽力通过人工的方式去另存为DOCX文件。由于剩下的文件仍有1826个之多，为了节约人力我们使用gui层面的自动化来辅助转换这些文件。

辅助人工另存为的脚本

人工导出后的文件统计结果如下：

1. 成功：1809个
2. 文件损坏：15个
3. 因加密无法打开：2个

在最终对齐前，我们使用了校验脚本来验证输出的DOCX文件是否存在问题。具体而言，我们使用了以下两套规则：

1. 某个给定语种的文件是否存在比较高含量的其它语言字符
2. 某个给定语种的文件自身的字符含量是否够高

具体的过滤规则与阈值在脚本中给出。

过滤脚本

筛选出来的文件统计结果如下：

1. 文件DOCX转出和源DOC不匹配，已手工重新另存为：515个
2. 因tex错误无法转换：7个
3. 空文件：34个
4. 文件损坏：26个
5. 单文件存在多语种版本：138个
6. 已加密而无法转换：1个
7. 爬下来的文件语种和预期不符：86个
8. 意外保存了HTTP 404内容的文件：114个
9. 乱码文件：2个
10. PDF格式的文件：76个

我们使用WPF宏来进行批量的WPF到DOCX转换。

LibreOffice宏

由于WPF数据量不大，单机单线程只需要数个小时即可转换完毕，细节不多，所以这里不详述。

除上述提到的异常文件之外，其余文件均已成功转换为DOCX。被丢弃的文件或者爬虫提供的数据源中缺失的文件在最终数据集上以空字符串形式提供。

1. 所用算力
   • 笔者找到3台物理机合计开了13个客户端节点
   • 自动脚本转换总耗时大约一周，人工事后补救的文件耗时未计入