Word 转 Markdown：一次真实的映射，而不是有根据的猜测
随便找个 .docx，改名成 .zip 再打开。里面是一棵目录树：
word/document.xml 装正文，word/styles.xml 定义样式，
word/media/ 存所有内嵌图片，旁边还躺着 footnotes.xml 和
comments.xml。.docx 不是一张页面的照片，而是装在 zip 容器里的一份结构化 XML 文档。
这对转换质量的影响是决定性的。把 PDF 转成 Markdown，靠的是从字号和坐标里推断结构；把 Word
转成 Markdown，读的是文件里已经声明好的结构。一个标着 w:pStyle="Heading2" 的段落
会变成 ##，因为文件明明白白说了它是二级标题。这就是为什么 docx 转 Markdown
转换器的输出，通常比同一份文档先导出成 PDF 再转要干净。传个文件上去看看——免费、免注册、上限 50 MB、
不存任何东西。
样式 vs 手动调格式：决定你输出质量的那一件事
在 Word 里把一行字弄得像标题有两种办法，它们并不等价。
套用样式——在功能区点"标题 1"——会往 XML 里写入一个语义标签。转换器读到这个标签，
就输出 #。手动调格式——选中那行字、调到 16 磅、点加粗——写进去的只有视觉
属性。文件里任何地方都没有"这是标题"的记录，在 Word 看来它就是个碰巧又大又粗的普通段落。它会被转成
一行加粗的正文，你的文档到了 Markdown 里就是一堵没有任何章节的平墙。
如果你的输出看起来"结构空空"，原因几乎必是这个，而解法在源文档里。打开样式窗格，给各节标题套上真正的 标题样式，保存，重新转换。五分钟的活儿，结果脱胎换骨——而且 Word 文档本身也变好了：导航窗格和自动 生成的目录都开始能用了。
修订、批注和脚注
真实世界的 Word 文档大多经过好几个人的手，痕迹全留在文件里。每一层的下场如下：
- 修订记录以包裹受影响文字的
w:ins和w:del片段形式存在 XML 里。转换会把文档解析到"已接受"状态：插入保留，删除丢弃。如果法务团队的修订史对你有意义， 那段历史就没了——改成分别转换修改前后两版，再对两份输出做 diff。 - 批注存在压缩包的独立部分里，锚定到正文的某段范围。它们不是正文，所以不会出现在 转换结果中。页边闲话是噪音时这很省心；但如果你要总结的恰恰是审阅意见，这就是问题。
- 脚注和尾注也各占一块。它们一般会以文本形式出现，但脱离了精确的锚点——Markdown 基础规范里没有原生脚注语法。引注重要的话，检查一下输出的尾部。
- 页眉、页脚和页码直接丢弃。Markdown 没有"页"，页面装饰在 AI 场景里反正也是噪音。
- 域——自动编号、交叉引用、生成的目录——转成它们最后一次渲染出来的值，而不是 活的引用。
稳妥的习惯是：审阅 → 接受所有修订，另存一个副本，再转换。这样你清楚地知道自己在处理哪份文本。
表格、图片，以及 Markdown 撑不住的地方
Word 的表格是货真价实的网格——行和单元格都在 XML 里声明，而不是几列碰巧在视觉上对齐的文字。所以它们 能干净地映射为 Markdown 竖线表格——只要文档里有任何表格内容，这就是选 Markdown 而不选纯文本的最强 单项理由。
例外是合并单元格。Markdown 表格没有 rowspan 和 colspan，一个横跨三列的表头只能被硬压扁，复杂的嵌套 表格出来的是近似而不是精确。简单网格转换得完美无缺；发票那种带合并横幅行的版式，信它之前先扫一眼。
内嵌图片是更硬的限制。像素在 word/media/ 里，但文本转换产出的是文本——一个图片引用，
不是图片本身，更不是图片里的文字。如果文档的关键示意图是一张表格截图，那部分内容对转换来说是隐形的。
把图片单独导出，走一遍图片转 Markdown；
更好的做法是转换前把它重建成一张真正的 Word 表格。
.doc 和 .docx 根本不是同一种格式
它们只共享三个字母，别的几乎什么都不共享。.docx 随 Office 2007 而来，是 Open XML——
上面说的那个装 XML 的 zip 包，规范公开、解析直截了当。老的 .doc 是二进制复合文件：
一个由数据流组成的微型文件系统，被逆向工程了几十年，内部结构还随写它的 Word 版本而变。
实际结论：.docx 转换可靠，.doc 转换只能尽力而为。老文件转出来不对劲的话，用 Word 或 LibreOffice 打开，另存为 .docx，再转那份。三十秒的成本，消灭一整类问题。 RTF 文件同理——它更老， 携带的语义结构更少。
Markdown 还是纯文本？看你接下来要干什么
文档的形态携带信息时，选 Markdown。带嵌套编号条款的需求规格、有明确章节层级的制度 文件、塞满报价表的方案书、含代码示例的技术文档——在这些场景里，结构就是信息。你问模型"第 3 节的 交付物有哪些"，第 3 节得作为一个单元存在才行。
只要文字、别的都不要时，选 Word 转文本—— 喂分类器、做向量化、建搜索索引，或者逐行 diff 两个版本。在那些管线里，Markdown 语法是死重。
本页顶部的切换按钮能在两种格式之间来回切，并把你已选的文件一起带过去，两种都转出来对比不用上传两次。 输出下方的 token 计数器会在你把结果贴到任何地方之前，先告诉你它在模型上下文窗口里要花多少钱。
常见问题
怎么把 DOCX 转成 Markdown？
把文件传到上方，把 Markdown 复制走，或下载为 .md。支持 .docx 和更老的 .doc，单文件 50 MB，免费且无需账号。标题样式映射为 # 层级，加粗和斜体保留为 ** 和 *，列表保持嵌套。
我的标题真的能转过去吗？
前提是它们本来就是真标题。作者用"标题 1""标题 2"样式写的文档，会转成干净的 # 和 ## 大纲。而靠手动加大加粗做出来的文档，文件里根本没存任何标题信息——在 Word 里看着一模一样，转出来却是普通段落，因为那里没有任何东西可读。
拿它把 Word 文档迁进文档站点够用吗？
能帮你走完大半程。正文、标题、列表和简单表格转出来干净到可以直接提交。之后需要人工过一遍的是：内嵌图片、复杂的合并单元格表格、公式，以及一切靠约定俗成而非结构来传达含义的自定义样式。
公式和内嵌图片怎么办？
公式不会以 LaTeX 或 MathML 的形式保留，图片也不会被抽取到素材文件夹——输出的是文本和结构。数学内容就是正文的文档，这些块要有重写的心理准备。在转第一百个文件之前知道这一点，总好过在第九十个文件上才发现。
Word 转 Markdown 还是 Word 转文本？
文档有一份值得保留的大纲，或者它的去处能渲染 Markdown——仓库、wiki、LLM 提示词——就选 Markdown。目的地解析的是词而不是格式，就选纯文本，大多数搜索索引和向量化管线都属于这一类。
工具箱里的其他家伙
Word 只是这里支持的十三种格式之一。File2Txt 一次上传什么都收，也可以直接跳到 PDF 转 Markdown、 PowerPoint 转 Markdown处理演示文稿，或者 Excel 转 Markdown处理电子表格。 手上是一个混装各种文档的文件夹？打成 zip 交给 ZIP 转 Markdown，里面的东西 一趟全转。
代码和网页这边有 GitHub 转文本工具、 GitLab 对应版本、 本地目录转换器，还有把网页抓成 Markdown 的 Web2Txt。想深入了解这一切为什么值得做， 看这篇为 LLM 准备文档的指南。
Repo2Txt 由 v12hero 开发和维护，那是一位独立开发者，专做隐私优先的原生应用和 Web 应用。