MSG 转 Markdown：让 Outlook 线程在模型眼里变得清晰
一条关于合同续签的四十封邮件线程，装着整个决策过程——谁提了什么方案、谁提出异议、条款究竟 在什么时候变的。它同时也几乎没法读，因为每封回复都拖着此前全部内容的副本，还裹在三家邮件 客户端各执一词的引用标记里。把这坨东西贴进聊天窗口，你得到的是一面灰色文字墙，同一段话出现 十一遍。
把 MSG 转成 Markdown，就是给这团乱麻一个形状。邮件头变成顶部一个带标签的块，
发件人、收件人、抄送、主题和发送日期成为明明白白的事实，而不是要模型从上下文里猜的东西。
正文保住段落和列表。引用的回复保持可见的嵌套，不会摊平混进周围的散文。结果是一份"谁在什么
时候说了什么"有答案的文档。把 .msg 文件拖进上方的转换器——免费、免注册、上限
50 MB。
.msg 文件到底是什么
多数人是偶然遇上 .msg 的。有人把邮件从 Outlook 拖到桌面再发给你，或者在
"文件 > 另存为"里选了"Outlook 邮件格式"。不管哪种，你手上都是一个装着一封邮件的
单一文件。
它的内里不是文本。.msg 是复合二进制文件——和微软老式 .doc、
.xls 用的同一种 OLE 结构化存储容器，一个文件里装着带目录和流的微型文件系统。
邮件的每个部分住在各自以 MAPI 属性标签命名的流里：主题一个流，正文一个流，每个收件人各占
一个编号存储，每个附件又是一个。用文本编辑器打开，得到的是一屏二进制噪音，中间漂着几个
认得出的词。
开放的对应物是 .eml——就是一封 RFC 5322 邮件：邮件头、一个空行、MIME 正文——
真的能在记事本里读。Thunderbird、Apple Mail 和多数网页邮箱导出的是 .eml。
Outlook 产出的是 .msg。这个差别正是那么多人去搜"不装 Outlook 怎么打开
.msg 文件"的原因：文件没坏，你只是没有那个把它当原生格式的应用。转换是通往"读到它"
的最短路径，顺带还得到一份能搜索、能粘贴的东西。
转换会呈现出什么
过来的有三层，动手写提示词之前，值得分清哪层是哪层。
- 邮件头。发件人、收件人、抄送、主题和发送日期，渲染成一个带标签的块，
而不是埋在散文里。这是 Markdown 明显优于扁平文本的部分——模型读到
**From:** Priya Raman，就知道这是元数据，不是谁写的一句话。 - 正文。邮件本身。发件人用 HTML 写的话——多数商务邮件如此——标题、粗体、 项目符号和超链接都映射到对应的 Markdown。用纯文本写的话，你拿到的就是敲出来的那些段落， 更干净，也更扁平。
- 引用链。"On Tuesday, X wrote:"那行以下的一切。它会保留，缩进并与正文 分开，因为在一场谈判里，链条常常比最上面那封更重要。
文件转换完即返还，不做存储。邮件常涉及个人隐私或商业敏感信息，上传工作邮件之前，按你所在 组织对往来函件的规定办。
回复链的重复问题
这是人人都会栽的那个坑，与其盲目绕开，不如把它弄明白。
邮件回复是累积的。一条线程的第十二封邮件里装着第一到第十一封。所以你从同一场对话里导出几封 邮件全部转换时，转的不是十二封邮件——算上每封拖着的祖先，大约是七十八份邮件副本。长线程的 第一封邮件能在你的输出里出现十几遍。
再加上签名块。每封邮件都重复发件人的姓名、职务、电话和办公地址。再加上企业法律免责声明—— 那段"本邮件及其附件均属保密"——许多组织自动附在每封外发邮件上，回复也不例外。长线程里， 这些样板文字真能压过实际内容。
两条实用对策。第一，只想要线程的完整历史时，转最新那一封就够了——它已经包含一切。转整个 文件夹买来的多半是重复。第二，粘贴到任何地方之前先看输出下方的 token 计数器。屏幕上看着 几页纸的线程，把重复算进去可能贵得吓人，事先看到数字总比从截断报错里发现强。
结构在哪儿真正见效
只要你在乎"谁说的"和"什么顺序"——对邮件而言这几乎是常态——Markdown 就是对的选择：
- 重建决策轨迹。"60 天付款期限是什么时候定的？谁批的？"面对带日期头的 结构化线程，模型答得出来。面对压平的散文，它要么含糊其辞，要么更糟——信心十足地把话 安到错的人头上。
- 总结一场谈判。立场是随时间移动的。清晰的引用层级让模型看出第九封邮件的 第三段是对第四封的引用，不是一句新表态。
- 提取行动项。项目符号以项目符号存活，第六封邮件里某人敲的"下一步"清单 出来还是清单，不是一句连成一气的长话。
- 交接文档。转出线程，把 Markdown 放在项目笔记旁边，半年后接手的人拿到的 是来龙去脉，而不只是结论。
- 为审阅准备函件。法务、人力和合规审阅人要一眼看到发件人、收件人列表和 时间戳。带标签的邮件头块正好给他们这个，还不用打开邮件客户端。
这些都不沾边的话——你在为搜索索引几千封邮件，或者在做 embedding——标记就是不需要的开销， MSG 转纯文本是更好的 选择。本页顶部的格式切换按钮在两者之间切换并带着你已选的文件，对比只花一次点击，不用重新 上传。
附件，以及一次搞定整条线程
.msg 内部可以携带附件——复合文件格式的用途之一就是这个。转换器给出的是邮件
内容：邮件头、正文、引用链。附带的合同 PDF 或预算表不会被单独提取，需要它们的内容就把附件
从邮件里存出来单独转。这是两分钟的事：文档用
PDF 转 Markdown，
DOCX 用 Word 转 Markdown，
电子表格用 Excel 转 Markdown——
在那儿表格结构是真能活下来的。
行内图片是相关的坑。粘进邮件正文的截图是图片，这里没有 OCR，所以一封全部意义都在一张报错 截图里的邮件，转出来几乎什么都没有。没有东西坏掉——本来就没有文字可提取。
超过一两封的话，打包处理。选中那些 .msg 文件，压缩成一个归档，走
ZIP 转 Markdown——
里面所有支持的文件一次上传全部转换。把整个 Outlook 文件夹拖到磁盘上、想把往来函件变成一份
可读文档的时候，这是理所当然的一步。
常见问题
怎么把 Outlook 的 .msg 文件转成 Markdown？
把邮件传到上方，它就以 Markdown 返回——邮件头是带标签的块，正文在下方，能映射的格式全部保留。免费，单文件 50 MB，不需要账号，读这个文件也不需要装 Outlook。
邮件为什么选 Markdown 而不是纯文本？
因为邮件是有部件的，Markdown 能把部件分开。发件人、收件人、主题和日期待在正文上方一个界限分明的块里，不会撞进第一段。引用的回复链仍然认得出是引用。要把邮件贴进工单或文档，这种分隔就是全部价值——否则纯文本更省事。
引用的回复链还保持可读吗？
通常可以。长线程会转成嵌套的引用块层级，你能看出哪封回复套在哪封里。局限在于：回复链的格式取决于当初写它的客户端，而这没有标准——一条在 Outlook、Gmail 和手机客户端之间转了三圈的线程，转出来的东西结构上诚实，视觉上凌乱。
HTML 格式的邮件比纯文本邮件转得更好吗？
它可用的材料更多。HTML 正文带着真正的标记——标题、列表、链接、表格——能直接映射进 Markdown。纯文本邮件只有换行和约定俗成，输出和原样相差无几。最糟的是塞满布局表格的营销邮件，转出来的东西不值一读。
能用它把邮件归档进仓库或 wiki 吗？
这是个合理的用法——Markdown 耐久、可 diff、可 grep，不用任何邮件客户端就能读，一个装满 .msg 的文件夹可说不出这些话。转换邮件、提交输出，十年后这条线程照样搜得到。附件需要另外保存。
工具箱的其余部分
MSG 是 File2Txt 支持的 格式之一，懒得挑页面的话，一次上传任何支持的文件都行。网页内容方面， Web2Txt 把网址抓成 Markdown——线程里反复引用一份放在线上的规格文档时很好用。代码这边可以转 GitHub 仓库为文本或 本机的文件夹，再把邮件线程和 实现一起递给模型。 为 LLM 准备文档的指南 讲的是这一切背后的通用道理。
Repo2Txt 由 v12hero 开发和维护，那是一位独立开发者，专做隐私优先的原生应用和 Web 应用。