ZIP 转 Markdown：一次上传，整个归档全转完
文档一份一份地转，二十份以内还行。到了二十份，就是二十次上传、二十次等待、二十次复制粘贴， 转到第十四个你已经记不清哪些转过了。本页存在的意义就是消灭这个问题。
把文件夹打成 zip。上传这一个归档。里面每份支持的文档在一趟里全部转换，以 Markdown 返回， 每个文件自身的结构完好，彼此之间界限分明。这是一个伪装成文件上传的批处理作业——而且和全家桶 其他工具一样免费。免注册、上限 50 MB，事后什么都不留。
你的归档究竟经历了什么
归档被解包，内部的文件树从头到尾遍历一遍，每个扩展名受支持的文件走一遍它在自己专属页面上 会走的同一套转换。ZIP 里的 PDF 和直接上传的 PDF 待遇完全一样。电子表格变成表格。演示文稿 变成逐页的小节。最后所有结果缝合成一份 Markdown 文档。
有两个细节比人们预想的更重要。第一，归档内的文件夹结构会作为上下文保留——
你分得清 2024/q3/board-pack.pdf 和 archive/old/board-pack.pdf 不是
一个来路，当文件名跨目录重复时这一点极其要紧，而文件名总是会重复的。第二，归档是
按原样解包的，不是拍平成一堆。当初有人整理这些文件时搭起的层级本身就是信息，扔掉它
只会让输出更难推理。
混合格式的归档是常态，不是麻烦事。一个装着四份 PDF、两份 Word 文档、一张电子表格和一份 PowerPoint 的 ZIP 一次转完，每个文件都由适合它自己格式的逻辑处理。
什么会转换，什么会跳过
凡是转换器能单独接的，放进归档也能转——PDF、DOCX、PPTX、XLSX 和 XLS、HTML、CSV、JSON、 XML、EPUB、RTF、MSG 和图片。想知道某种类型的确切表现，各自的页面里讲得更细： PDF 转 Markdown、 Word 转 Markdown、 PowerPoint 转 Markdown和 Excel 转 Markdown 正好覆盖工作归档里最常见的四样东西。
被略过的是一切没有文字可给的东西。视频、音频、字体、编译好的二进制、安装包，以及支持列表 之外的私有格式，都不会有贡献，因此原地不动。图片是值得单独点名的情况，也是最容易让人栽 跟头的。单独上传时，图片文件会被正经读取——截图或翻拍页面里的文字以文字返回。放在归档里 就不会。批量流程只记下这个文件在场，然后继续，所以一包截图能"转换成功"，到手的却是文件名 而不是屏幕上的字。字才是重点的话，把图片抽出来，直接走 图片转 Markdown。
嵌套归档——ZIP 里还有 ZIP——是另一个要检查的点。要是你的导出到手就是"归档套归档"，上传前 自己解开一层、把内容重新打包。两分钟的收拾，换来好得多的输出。
批量作业为什么该选 Markdown
单份文档时，Markdown 还是纯文本是个见仁见智的判断。二十份文档挤在一份输出里时，胜负毫无 悬念。
原因是边界。几个文件被拼接成一整块文本后，对你和对语言模型最难的事都是分清一份文档到哪儿 结束、下一份从哪儿开始。Markdown 标题白送你这个——每个文件自报家门，它下面的一切显然归它 所有。问模型"这几份合同里哪份的通知期最短"，它能逐份作答，而不是把三份协议的条款搅在一起， 给出一个信心十足的错误答案。
文件各自的结构也活了下来。电子表格的表格还是表格。演示文稿的每页还是独立小节。报告的条款 编号原封不动。这就是批量把文档转成 Markdown 而不是转成裸文本的全部理由： 结构让多文档上下文变得可导航，而不只是变得庞大。
例外是批量分析——embedding、搜索索引、跨语料的关键词工作，一切你只想要一堆扁平散文、语法 字符纯属噪音的场景。那是 ZIP 转文本的地盘，本页 顶部的切换按钮会带着你已选好的归档切过去。
大家实际在传什么归档
- 邮件附件包。有人把"评审要用的全部材料"打包成九个附件的 ZIP 发来。全部 转掉，读摘要，再决定哪两份才值得正经打开。
- 数据导出。Google Takeout、Slack 工作区导出、Notion 工作区转储和客服 系统导出，到手全是塞满嵌套文件夹的归档。这一步把一棵原本要点一个小时的目录树变成一遍 就能读完的东西。
- 课程资料包。一个单元的课件、讲义和阅读清单一次下载。转完之后，让模型 根据真实材料——而不是它对这门课的泛泛认识——编一份学习指南。
- 客户交接与尽调材料包。数据室导出、供应商文档包、项目交接文件夹——一步 变成可搜索的文本，文件夹路径还标明每份材料的出处。
- 标书与申报材料。带附录的多文档答复，你需要检查不同人写的文件之间是否 前后一致。
- 个人旧档。连自己都记不清里面有什么的老备份文件夹。先转，再挖。
50 MB 这条线，以及怎么活在线下
上限针对你上传的归档，不针对里面的单个文件。这通常很宽裕，因为 ZIP 对文字类格式压缩得很好—— 一文件夹的 Word 文档和电子表格能缩小得非常可观，文件很多的归档也往往轻松装下。
真正撑爆上限的是媒体。视频、音频和高分辨率图片几乎压不动，会吃光全部额度却对输出毫无贡献。 归档超线了就把它们剔出去重新打包——你不会损失任何用得上的东西。真正庞大的文档集就按文件夹 拆成两三个归档，依次转换。
另一个要盯的预算是输出下方的 token 计数器。五十份文档转起来没问题，却照样塞不进小模型的 上下文窗口。贴之前知道数字总比从报错里得知强，它还告诉你该整批发出去，还是分块来。
如果你的 ZIP 其实是个代码项目
值得把话说明白，因为这事没完没了地发生。要是你打包的是一个仓库或源码文件夹，这就是用错
工具了。改用本地目录转换器——
它直接从你的机器读文件夹，展示一棵带复选框的文件树，让你精确挑选哪些文件进输出。也就是说，
你可以在 node_modules、构建产物和锁文件吃光整个上下文窗口之前把它们扔掉——
闭着眼的归档转换可帮不了你这个。
项目已经托管在哪儿了？打包这步都省了—— GitHub 仓库转文本转换器直接从网址 拉取整棵树。
常见问题
怎么把 ZIP 归档转成 Markdown？
传到上方，里面每个支持的文件都会转成 Markdown 并拼接起来，归档的文件夹路径保留为标题。免费，单个归档 50 MB，不用账号。结果是一份 .md 文档，哪一节来自哪个文件依然看得清清楚楚。
文件路径会变成标题吗？
会，这正是归档该选 Markdown 而不是扁平文本的理由。每个文件的内容待在一个以其 ZIP 内路径命名的标题之下，输出因此保持可导航，被问到某份具体文档的模型能定位到它，而不是靠上下文瞎猜。
嵌套归档能处理吗？
ZIP 里的 ZIP 会被当作又一个支持的文件依次解包。对把每月归档装进年度归档的导出很有用。嵌套太深还是要避免——输出会拉得很长，而标题级别到第六级就见底了，再往下结构就无从表达。
文件按什么顺序出来？
目录遍历顺序，也就是文件按文件夹分组，而不是按相关性。对布局有讲究的归档来说这正合适。对两百个自动命名文件的平铺转储来说，顺序就是任意的，你会想去搜索输出，而不是从头读到尾。
里面的文件数量有限制吗？
实际的约束是 50 MB 的归档上限，不是文件个数，但要盯着输出下方的 token 计数器。几百份文档能把多数模型的上下文窗口超出好几倍，所以只转你需要的那部分，往往好过产出一份哪儿都贴不进去的语料。
工具箱的其余部分
不想挑页面的话， File2Txt 在一个地方处理 全部十三种支持的格式。而 为 LLM 准备文件的指南 把"先转换、再提问"的大道理讲了个透。
Repo2Txt 由 v12hero 开发和维护，那是一位独立开发者，专做隐私优先的原生应用和 Web 应用。