从 .doc 到 .docx：老格式文档批量迁移的完整方案

.doc 是 Word 97 到 Word 2003 使用的二进制文档格式，.docx 是 Office 2007 起沿用的 ZIP 加 XML 格式。把 .doc 转成 .docx，就是把一批文档从前者搬到后者，而文件数量上千时不可能靠手工"另存为"。

这篇先讲清两种格式在存储结构上的差别，再给出四条能完全在本地跑的批量转换路径（Word VBA 宏、PowerShell、开源工具 DocTo、LibreOffice 命令行）和一条 Linux 退路，最后把宏丢失、字体替换这些"转换后走样"的成因与抽样验证的做法说透。

信息核验时点：2026-10-28（LibreOffice 当前稳定版 26.8.1，发布于 2026-10-08；开源工具 DocTo 最新 v1.16，发布于 2025-11-30；微软 MS-DOC 规范现行版本 12.5，发布于 2026-02-17）

.doc 和 .docx 到底差在哪？

.doc 是 Microsoft Word 从 Word 97 开始使用的二进制文件格式（Binary File Format），将文本、图片、样式、宏等信息打包在一个连续的字节流中（MS-DOC 规范）。这种格式沿用了二十多年，直到 Office 2007 引入全新的 .docx 格式。

.docx 的全称是 Office Open XML（开放 XML 格式），2006 年 12 月被 ECMA 国际组织批准为 ECMA-376 标准（ECMA 官方页面，现行的是 2021 年 12 月发布的第 5 版），2008 年成为 ISO/IEC 29500 国际标准。从文件结构上看，.docx 本质上是一个 ZIP 压缩包，里面存放着多个 XML 文件和资源文件（Microsoft 官方说明）。把 .docx 文件的后缀改为 .zip 用压缩软件打开，就能看到 [Content_Types].xml、word/document.xml（正文）、word/styles.xml（样式）、word/settings.xml、word/fontTable.xml 和 docProps/ 下的属性文件；文档里的图片则单独放在 word/media/ 文件夹中。同样是这份只有文字和一张表格的文档，.doc 的开头四个字节是 D0 CF 11 E0——这是 OLE 复合文档的签名，说明它是一个"文件里的文件系统"；.docx 的开头是 50 4B 03 04，也就是 ZIP 包的前奏。

下表对比了两种格式的核心差异：

同一份文档存为 .docx 后体积明显缩小，原因有两层：一是 .doc 走的 OLE 复合文档按固定扇区分配空间，正文写多写少都要占整块；二是 ZIP 对 XML 这种重复标签极多的文本压缩率很高。Microsoft Office 2010 的技术文档给出的说法是"文档会自动压缩，最多比原先缩小 75%"，并补了一句"具体取决于图像数量"（Microsoft Learn 页面)）。

这个比例我在手边的机器上量过。这台 Windows 10 只装了 WPS，没有 Microsoft Word，下面这组数字用的是 WPS 提供的兼容 Word 的 Word.Application COM 接口——不是 Word 本体的输出，严格说属于"兼容实现的实测"。同一份内容（若干段中文正文，夹少量英文单词和数字，末尾一张 12 行 5 列的表格，不含图片）分别另存两种格式：

文字越多，.docx 省得越狠——因为 .doc 那两个数字都正好是 512 的整数倍，增长的是"占位"而不只是内容。但别把这个比例套到含大量图片的文档上：.doc 和 .docx 里的图片都是原始字节，ZIP 压不动已经压缩过的 JPEG，微软那句话特意点了"取决于图像数量"。所以"转换后能省多少空间"对图文混排的档案库往往只有一两成，对以文字为主的公文库才有接近七成。

为什么现在还要把 .doc 转成 .docx？

现代版本的 Word（Word 2007 及之后）仍然可以打开 .doc 文件，但会进入"兼容模式"——窗口标题栏会跟着显示"兼容模式"四个字，意思是编辑器暂时按旧格式的能力上限来伺候这份文档。微软在不同版本之间的兼容性更改一页里列了兼容模式下用不了的功能，包括 Web 视频、Office 加载项、重复的内容控件、自定义脚注栏、折叠式页眉以及已完成的批注；构建基块在存回旧格式时会被拆成普通的自动图文集条目，引文和书目则会变成死的纯文本。

至于格式名称，别凭印象写：Microsoft 支持的保存文档的文件格式页把 .doc 标注为"Word 97-2004 文档 (.doc)"，说明文字是"与 Word 98 至 Word 2004 for Mac 和 Word 97 至 Word 2003 for Windows 兼容的文档格式"——名字里带上 2004，是因为 Mac 版比 Windows 版多走了两代。.docx 在那一页里的名称是"Word 文档 (.docx)"，这才是各版本 Word 现在的默认格式。

除了功能受限，.doc 的安全性也不如 .docx。旧格式将宏代码与文档内容混合存储，攻击者可以把恶意宏嵌入看似普通的文档中。.docx 体系对此做了分离：普通的 .docx 文件不含宏，只有 .docm（启用宏的文档）才能携带 VBA 代码。这种设计让用户在收到 .docx 文件时可以更放心地打开。

.docx 的跨平台兼容性也更好。LibreOffice、WPS Office、Google Docs 等第三方办公套件对 .docx 的解析准确度普遍高于对 .doc 的处理——原因不难理解：.docx 是公开标准，谁都能照着规范实现读写器；.doc 是微软私有的二进制格式，第三方只能靠逆向和兼容层去猜。本站那篇《为什么你的文件传给别人就乱了：WPS 与 Office 排版兼容性的真相》把字体缺失和版面漂移的成因讲得更细，跨软件送文件前值得一读。LibreOffice 的介绍稿则给出了它在信创和 Linux 环境下的安装路径。把文件转成 .docx，相当于给文档换了一个更通用的"通行证"。

批量转换有哪些靠谱的方法？

如果只有十几个文件，用办公软件手动"另存为"即可。但当文件数量达到几百甚至上千，就需要自动化方案。下面五条路径分两类：走本机办公软件 COM 接口的有三条（VBA 宏、DocTo、PowerShell），产出等于在本机手工另存一次；走 LibreOffice 引擎的有两条（命令行直转、unoconv/unoserver），好处是不需要 Office 许可证，Linux 服务器也能跑。

方法一：用 VBA 宏在 Word 内批量转换

VBA（Visual Basic for Applications）是 Word 内置的编程语言。打开 Word，按 Alt + F11 进入 VBA 编辑器，点击"插入"菜单下的"模块"，粘贴以下代码，修改文件夹路径后按 F5 运行即可：

Sub BatchConvertDocToDocx()
    Dim strFolder As String
    Dim strFile As String
    Dim objDoc As Document

    ' 修改为你的 .doc 文件所在文件夹路径
    strFolder = "D:\OldDocs\"
    strFile = Dir(strFolder & "*.doc", vbNormal)

    Application.ScreenUpdating = False

    While strFile <> ""
        ' 跳过已经是 .docx 的文件，避免二次打开
        If Right(strFile, 5) <> ".docx" Then
            Set objDoc = Documents.Open(FileName:=strFolder & strFile, _
                AddToRecentFiles:=False, ReadOnly:=True, Visible:=False)
            ' wdFormatXMLDocument = 12，即 .docx
            objDoc.SaveAs FileName:=strFolder & Replace(strFile, ".doc", ".docx"), _
                FileFormat:=wdFormatXMLDocument
            objDoc.Close
        End If
        strFile = Dir()
    Wend

    Application.ScreenUpdating = True
    MsgBox "转换完成！"
End Sub

上面这段用的是常量名，而不是网上这类脚本里更常见的 FileFormat:=16。这不是洁癖：16 对应的常量不是 wdFormatXMLDocument，而是 wdFormatDocumentDefault——微软的 WdSaveFormat 枚举对它的解释是"Word 的默认文档格式，对 Word 而言就是 DOCX"，而 wdFormatXMLDocument 是 12。在 Word 里两者产出同一种文件，区别在语义：16 说的是"按默认格式存"，12 说的是"存成 OOXML 文档"，脚本要锁定后者才不会被"默认"这个前提带走。另外 0 是 wdFormatDocument（存回 .doc），13 是 wdFormatXMLDocumentMacroEnabled（.docm），17 是 PDF。

代码会遍历指定文件夹中的所有 .doc 文件，逐一打开并另存为 .docx，最后弹出完成提示，整个过程在 Word 后台运行，不需要手动干预。

需要注意的是，这种方法要求电脑上装了提供 VBA 环境的办公软件。Microsoft Word 原生支持；WPS 走的是另一套 JS 宏体系，VBA 只在部分企业版/兼容组件里可用，具体见《WPS 宏怎么用？JS 宏与 VBA 宏的区别及 JSAPI 上手路径》。如果文件中包含 .doc 独有的旧式宏，转换后宏代码会随格式切换被丢弃——因为 .docx 格式本身不支持存储宏。

方法二：用 LibreOffice 命令行批量转换

LibreOffice 是一款开源免费的办公套件，支持 Windows、macOS 和 Linux 三大平台。它的命令行模式（headless 模式）可以在不打开图形界面的情况下完成文档格式转换。

单文件转换命令：

soffice --headless --convert-to docx report.doc

批量转换脚本（Windows 批处理）：

@echo off
setlocal
set INPUT_DIR=D:\OldDocs
set OUTPUT_DIR=D:\NewDocs
if not exist "%OUTPUT_DIR%" mkdir "%OUTPUT_DIR%"
for %%f in ("%INPUT_DIR%\*.doc") do (
    soffice --headless --convert-to docx --outdir "%OUTPUT_DIR%" "%%f"
)
echo 转换完成

在 Linux 或 macOS 上，用 shell 循环实现同样的效果：

mkdir -p ./output
for f in *.doc; do
    soffice --headless --convert-to docx --outdir ./output "$f"
done

LibreOffice 的 --headless 参数按官方启动参数页的说法是"Starts in 'headless mode' which allows using the application without user interface"——无界面运行；--convert-to 的完整形式是 --convert-to OutputFileExtension[:OutputFilterName[:OutputFilterParams]]，写 docx 就够了，如果想点名过滤器，它的名字叫 MS Word 2007 XML；--outdir 省略时结果落在当前工作目录。这种方案不依赖 Microsoft Office 许可证，适合服务器端或 Linux 环境下的自动化场景。

批量转换时有两个坑值得提前避开。其一是并发：LibreOffice 默认所有实例共用同一个用户配置目录，脚本里前后脚起多个 soffice 进程时，后起的会去抢同一份配置，转换就会时灵时不灵。官方启动参数页给的对策是用 bootstrap 变量各开一份配置——-env:UserInstallation=file:///c:/lo-batch-profile（原文举的例子正是"To set a non-default user profile path"）。其二是首次启动：真正会拖慢无人值守脚本的是用户配置的首次初始化，对策同样是把 UserInstallation 指到一个专用目录，而不是加 --nofirststartwizard——那个参数在官方页里的说明是"Does nothing, accepted only for backward compatibility"，写了也不起作用，属于文档残留。想跳过启动画面用的是 --nologo。

不过 LibreOffice 对 Word 复杂排版的还原度与 Word 本身存在差异，涉及精密表格或特殊字体的文档需要在转换后抽样检查。当前 LibreOffice 稳定版为 26.8.1（2026 年 10 月 8 日发布），可从官方下载页面获取。

方法三：用开源工具 DocTo 进行批量转换

DocTo 是开发者 Anthony Tubridy 维护的开源命令行工具，托管在 GitHub（项目地址），专门用于将 .doc、.xls、.ppt 等旧格式文件批量转换为其他支持的格式。项目 README 的原话是它"Can be used to convert older word documents to latest format"，支持单文件转换和整个文件夹批量处理，最新版本 v1.16，发布于 2025 年 11 月 30 日。

典型用法：

docto -f "D:\OldDocs" -o "D:\NewDocs" -t wdFormatXMLDocument -fx "*.doc"

-f 指定输入文件夹，-o 指定输出文件夹，-t 指定目标格式。按 README 的帮助文本，-t 既可以传整数也可以传 wdSaveFormat 常量名，参数标记本身不区分大小写，所以 -T 12 和 -t wdFormatXMLDocument 是等价的——沿用上一节的结论，写常量名比记数字稳。

这里有个官方文档里明写着的坑：DocTo 的输入文件匹配默认值是 -fx "*.doc*"，README 特别提示这一条"will find .docx also"。也就是说迁移跑到一半时中断、再重跑一遍，它会把你上一轮刚生成的 .docx 也当作输入重新打开一遍。加上 -fx "*.doc" 把范围收紧，或者把输入输出分成两个目录，就不会出现套娃转换。

DocTo 底层调用的是本机安装的办公软件 COM 接口，README 里要求"Must have Microsoft Word, Excel or Powerpoint installed on host machine"。因此它的格式保真度与本机软件的"另存为"一致，同时又能享受命令行自动化带来的便利。

方法四：用 PowerShell 脚本实现自动化

Windows 环境下，PowerShell 可以通过 COM 自动化接口调用办公软件完成转换，不需要打开 VBA 编辑器：

$ErrorActionPreference = "Stop"
$inDir  = "D:\OldDocs"
$outDir = "D:\NewDocs"
if (-not (Test-Path $outDir)) { New-Item -ItemType Directory -Path $outDir | Out-Null }

$app = New-Object -ComObject Word.Application
$app.Visible = $false
$app.DisplayAlerts = 0

try {
    # 用 Extension 精确筛，避免把 .docx 也捞进来
    Get-ChildItem -Path $inDir | Where-Object { $_.Extension -eq ".doc" } | ForEach-Object {
        $out = Join-Path $outDir ($_.BaseName + ".docx")
        $doc = $app.Documents.Open($_.FullName, $false, $true)   # 不进最近列表、只读
        try {
            $doc.SaveAs($out, 12)     # 12 = wdFormatXMLDocument
            Write-Host "已转换: $($_.Name)"
        } catch {
            "$($_.Exception.Message)" | Out-File -Append -Encoding utf8 (Join-Path $outDir "失败.log")
            Write-Warning "失败: $($_.Name)"
        } finally {
            $doc.Close($false)
        }
    }
} finally {
    $app.Quit()
    [void][System.Runtime.InteropServices.Marshal]::ReleaseComObject($app)
}

脚本里有两个来自实际验证的细节：

其一是筛选条件。稳妥做法是拿扩展名做精确比对（$_.Extension -eq ".doc"），而不是靠 *.doc 这种前缀通配。我特意在一个同时放了 sample50.doc 和 sample50.docx 的目录里试了三种写法——Get-ChildItem -Path "*.doc"、-Filter "*.doc"、-like "*.doc"——这台 Windows 10 上三者都只返回 .doc，没有把 .docx 捞进来；网上常警告的"短文件名（8.3）匹配会让 *.doc 命中 .docx"在这块 NTFS 卷上没有复现。但同一个文件夹里跑第二轮时，上一轮产出的 .docx 就在你的输入目录里躺着，用扩展名精确比对能一刀切断这类误伤，代价只是多一行 Where-Object。

其二是 SaveAs 的参数写法。网上大量 PowerShell 转换脚本写成 $doc.SaveAs([ref]$path, [ref]16)，[ref] 是从 C# 互操作时代抄下来的习惯。我在这台机器上把三种写法各跑了一遍：SaveAs($out, 12)、SaveAs2($out, 12)、SaveAs([ref]$out, [ref]16) 都正常落盘，同一份探测文档的产出分别是 10,030、10,043、10,021 字节，最大相差 22 字节。也就是说 [ref] 不算错，只是多余——PowerShell 对 IDispatch 参数的自动处理已经不需要它了，直接传值更好读。SaveAs2 也在，两种名字在这台机器上都可用。

这种方式的优势是可以方便地嵌入更大的 PowerShell 运维脚本中，与文件管理、日志记录等操作串联起来。顺带一提，COM 自动化在不同办公软件上的行为差异，《Office 与 WPS 编程方式横向对比》有专门的一节讲 VBA、JS 宏与 COM 的选型。

方法五：Linux 环境下的替代方案

如果 Linux 服务器上已经装了 LibreOffice，只是嫌一条条敲命令麻烦，可以用 unoconv 或 unoserver 把它包成常驻服务。unoconv 通过 UNO 接口与 LibreOffice 通信，但根据 Linux Command Library 的记录，它已被标记为"deprecated"（已弃用）。作者给的继任者是 unoserver，按它在 PyPI 上的自述，那是"a rewrite, and hopefully a replacement to unoconv"，用法是先跑 unoserver 起一个监听进程，再用它带的转换命令连上去发任务——服务常驻，不用每份文档都冷启一次 LibreOffice。

如果服务器上连 LibreOffice 都不想装，那就只能退而求其次：antiword 的官方描述是"converts the documents from Word 2, 6, 7, 97, 2000, 2002, and 2003 to text, Postscript"，轻量、依赖少，但它不输出 .docx，版式信息也不会带过去。真需要保留排版的批量迁移，这条路走不通，还是得装 LibreOffice。

五种方案对比

下表从运行环境、是否依赖办公软件、格式保真度三个维度对比：

总体规律：凡是底层调用本机办公软件 COM 接口的方案（VBA、DocTo、PowerShell），产出就等于你在本机手工"另存为"一次，保真度取决于装的是哪套软件；走 LibreOffice 引擎的方案跨平台更强、不需要 Office 许可证，但在复杂排版上可能有细微差异。unoconv 那一行之所以还带着 unoserver，是因为前者已被标记弃用，新脚本别再起它。

转换后格式走样怎么办？

格式转换不是简单的"换后缀"，而是把一种数据模型映射到另一种数据模型。.doc 的二进制结构和 .docx 的 XML 结构在表达文档元素时存在差异，某些情况下会出现以下问题：

• 字体替换：如果 .doc 文件使用了系统中未安装的字体，转换后可能被替换为默认字体，导致行距和分页发生变化。这也是为什么"迁移完的文档看起来页数变了"多半不是转换器算错，而是字体度量不同。
• 嵌入对象丢失：.doc 中嵌入的 OLE 对象（如旧版公式编辑器、第三方插件生成的图表）在 .docx 中可能无法正常显示。这类对象的宿主程序往往比文档格式本身更早停服，属于"两边都打不开"而不是"转换搞坏了"。
• VBA 宏丢弃：标准转换流程会把 .doc 中的宏代码丢弃。如果文件包含重要的自动化逻辑，直接把目标格式改成 wdFormatXMLDocumentMacroEnabled（13），一次存成 .docm，不必分两步走。
• 页眉页脚偏移：使用自定义页眉页脚样式的文档，在转换后可能出现位置微调。

根据 Microsoft 的说明，.docx 文件不能包含 VBA 宏和 XLM 宏，只有文件扩展名以"m"结尾的文件（如 .docm、.xlsm）才能包含宏（Open XML 格式和文件扩展名）。所以如果旧文档中有需要保留的宏，应该把目标格式改为 .docm 而不是 .docx。

大规模迁移有什么策略建议？

先抽样，后批量。 不要一次性把上千个文件全部转换。先挑选 20 到 30 份有代表性的文档（涵盖简单文本、复杂表格、含图片、含目录等不同类型），转换后逐份检查格式保真度。确认没有问题后，再分批处理其余文件。如果这批文件里有党政机关公文，格式本身要遵守 GB/T 9704 的字体与行距规定，抽样检查时把版记和页码这两处的位置单独看一眼，细节可参考《党政机关公文格式规范详解》。

保留原始文件。 转换完成后，原始 .doc 文件不要立即删除。建议保留一段时间作为备份，确认所有 .docx 文件都可以正常打开和编辑后再做清理。上面的 VBA 和 PowerShell 脚本都可以根据需要修改，把输出文件放到单独的文件夹中，不覆盖原文件。

考虑双格式归档。 对于需要长期保存的重要文档，建议同时保留 .docx 和 PDF 两个版本。PDF 可以"冻结"文档的版面效果，适合作为归档副本。Word 本身就支持"另存为 PDF"，DocTo 和 LibreOffice 也支持直接输出 PDF。

记录转换日志。 无论用哪种方案，都应该记录转换过程中的错误信息。VBA 脚本可以加入错误处理代码，把转换失败的文件名写入日志文件；PowerShell 脚本中的 Write-Host 语句可以改为 Out-File 输出到日志。这样在几千个文件的批量操作中，就能快速定位哪些文件需要人工处理。

常见问题

.doc 文件里的宏在转换后会怎样？

标准的 .doc 转 .docx 流程会丢弃文件中的 VBA 宏代码，因为 .docx 格式本身不支持存储宏。如果需要保留宏，应该把目标格式改为 .docm（启用宏的文档）。Microsoft 的格式说明文档明确指出，默认的 .docx 格式不包含宏，只有以"m"结尾的扩展名才能携带 VBA 代码。

批量迁移前想先摸出哪些文件带宏，最省事的土办法是打开 Alt+F11 看工程窗口：每份 Word 文档都自带一个 ThisDocument，它不算自定义代码；除它之外还有"模块""类模块""用户窗体"，才说明这份文件真的带了宏。查出名单后单独走一遍输出 .docm 的流程（VBA 里把 FileFormat 改成 13，PowerShell 里改成 SaveAs($out, 13)，DocTo 里写 -t wdFormatXMLDocumentMacroEnabled）。

LibreOffice 转换的效果和 Word 一样吗？

LibreOffice 对大多数常规文档（纯文本、简单表格、常见图片嵌入）的转换效果与 Word 接近。但在处理复杂排版时——比如多层嵌套表格、特殊字体、SmartArt 图形、旧版公式编辑器对象——可能出现细微的格式偏差。如果你的文档包含大量复杂排版元素，建议优先走本机办公软件的 COM 接口（VBA、DocTo 或 PowerShell），因为那等于让 Word 自己另存一次；LibreOffice 引擎则要多经过一层它自己的格式解析。对于排版简单的文档，LibreOffice 完全够用，而且跨平台能力更强。

在线转换工具能用吗？

CloudConvert、ASPOSE 等在线服务可以完成 .doc 到 .docx 的转换，适合临时处理少量文件。但对于包含商业机密、个人信息或内部数据的文档，把文件上传到第三方服务器存在安全风险。企业环境下的批量迁移建议使用本地方案——Word VBA、LibreOffice 命令行或 DocTo 都在本地运行，文件不需要离开你的电脑。

转换后文件打不开或显示乱码怎么办？

首先检查原始 .doc 文件本身是否完好——有些年代久远的文件可能已经存在损坏。其次，确认转换工具的输出格式设置正确（.docx 而非 .doc）：用 VBA 或 PowerShell 时，核对 FileFormat 传的是 12（wdFormatXMLDocument）或 16（wdFormatDocumentDefault），而 0 会原样存回 .doc；用 DocTo 时看 -t 后面那个常量名有没有拼错，-fx 是否被通配带进了别的文件。如果用 LibreOffice 却什么都没生成，先排除两个常见原因：同一台机器上已有 soffice 进程占着用户配置目录（加 -env:UserInstallation=file:///… 各开一份，官方参数页给的正是这个例子），以及带空格的路径没加引号。别指望 --nofirststartwizard——官方启动参数页明写它"Does nothing, accepted only for backward compatibility"。仍然无法解决的话，换一种转换方案交叉验证，排除工具本身的问题。

下一步行动：根据你手头的文件数量和电脑环境选择一种方案，先用 20 份有代表性的文件做小批量测试，确认格式保真度后再全面铺开。如果你的环境中既有 Word 又有大量文件，VBA 宏或 DocTo 是最省心的选择；如果是 Linux 服务器或不想购买 Office 许可证，LibreOffice 命令行是最稳妥的免费方案。

本文外部事实核验于 2026-10，以 Microsoft 官方文档、LibreOffice 官方启动参数页与 DocTo 项目页面为准；文中那组体积数字来自本机 WPS 兼容 COM 接口的实测，已在正文标明出处。