Outlook MSG 转纯文本：读得了、索引得了、搜得了
有人转发给你一个叫 RE_ Invoice query.msg 的文件。双击之后，系统提议用文本编辑器
打开，结果是一整屏二进制乱码，中间零星飘着几个认得出的词。你没装 Outlook。你只想知道这封
邮件说了什么。
这就是在线把 Outlook MSG 转成文本最简短的理由：它是不装 Outlook 打开 .msg 文件并真正读到内容的最快途径。更长远的理由是，扁平文本是每个搜索索引、每个 embedding 模型、每个分类器都想要的格式——所以如果你面对的不是一封邮件而是一整个邮箱导出， 起点就在这里。免费、免注册、单文件 50 MB，我们这边什么都不存。
这文件为什么打不开
.msg 是 Outlook 自家的单邮件格式，它不是文本。它是一个复合二进制文件——一个内部
带目录树的容器，主题、正文、每个收件人、每个附件各自待在以 MAPI 属性标识符命名的独立流里。
正因为这种结构，文本编辑器给你看的才是噪音：你看到的是一个小型文件系统的原始字节，不是一封
邮件。
开放的对应格式是 RFC 5322 定义的 .eml，那才是真正的纯文本——邮件头、空行、MIME
正文——随便哪个编辑器都能给你看。Thunderbird、Apple Mail 和多数网页邮箱的导出给你的就是它。
Outlook 给你的是 .msg：有人把邮件从收件箱拖到桌面，或者在"文件 > 另存为"里
选了"Outlook 邮件格式"，得到的就是这个。文件本身没有任何问题。你只是缺那一个把它当原生格式
的程序，而转换恰好能完全绕开这一点。
扁平文本到底强在哪儿
这不是"去掉格式的 Markdown"。文本是一大类具体工作的正确输出，而且在其中大多数场景里， 结构化标记是负担而不是损失：
- 搜索索引。Elasticsearch、SQLite FTS、Postgres 的
tsvector—— 每一个都要往列里塞裸文本。喂它们 Markdown 就等于多加一道清洗，还得让词干化器去发愁怎么 处理散落的竖线和星号。 - 关键词排查与电子取证。把一个文件夹的往来邮件转出来，然后
grep某个供应商名字、某个合同约定术语，或者一句本不该出现的话。离线、即时， 任何有 shell 的人都能复核。 - embedding。切块、向量化、按相似度召回。格式字符不携带任何含义，却照样 占着向量的位置——纯属稀释。干净的散文块召回得更准。
- 分类与情感分析。按主题给客服邮件分流、给客户回信打不满度评分、给一个
季度的往来邮件贴主题标签。词袋和 TF-IDF 会一板一眼地把
###当 token，除非你 剥掉它——所以干脆别制造它。 - 大批量下的 token 经济账。处理一封邮件，标记的代价不值一提。处理四千封， 每个多余字符都要乘以四千。文本就是下限。
当你是在读一条线程而不是批量处理——重建谁在什么时候同意了什么—— MSG 转 Markdown 那种带标签的邮件头和清晰可见的引用层级，值得多花那几个字符。本页顶部的格式切换按钮在两者 之间切换，并保留你已经选好的文件。
过一遍邮箱导出
没有人为了搜索语料只转一个 .msg。这活儿的常见形态是几百封邮件从 Outlook 拖进
一个文件夹，这时批量就很关键：把它们打包成一个归档，跑
ZIP 转文本，里面所有
支持的文件一次上传全部转完，而不是几百次。
邮件往往涉及个人隐私或商业敏感信息，上传工作邮件之前，先确认你所在组织对往来函件的处理 规定。文件转换完即返还，不做保留。
另一件要提前规划的事是重复，它是邮件语料里最大的膨胀来源。回复是累积的：第十二封邮件里 引用着第一到第十一封。转一整条线程，开头那封会在你的输出里出现十几次。再叠上签名块—— 姓名、职务、电话、办公地址——每封都重复一遍，还有很多公司自动钉在每封外发回复末尾的法律 免责声明，样板文字完全可能压过正文。
对搜索和 embedding 来说，这种重复是实打实的毒药：同一段话被索引十几次，把召回分数全带偏。 两个值得做的修复：想要完整历史时，每条线程只留最新一封；再写一条正则，把从第一个"From:" 引用头或免责声明开头行起的内容全部剪掉。输出下方的 token 计数器会告诉你省了多少。
输出里会看到的痕迹
- HTML 正文压得很扁。大多数商务邮件是 HTML 格式。粗体、项目符号、项目周报 里五颜六色的状态表——全都变成不带样式的散文。通常没事。但如果一封邮件的意思全在表格里， 数值能活下来，它们所属的列活不下来。
- 引用标记不统一。Outlook 在引文上方写一个"From/Sent/To/Subject"块。Gmail
写"On [date], [name] wrote:"。老客户端用
>前缀。一条穿过好几家组织的 线程会同时包含这三种惯例——要写正则把邮件拆开的话，这一点很要命。 - 时间戳是发送时区，不是你的时区。把一批转换结果按时间排序之前，先核对 时区偏移，再相信跨地区的先后顺序。
- 附件不会被提取。
.msg里装着它们，但转换给你的是邮件内容。 把附件单独存出来，需要里面的东西就走 PDF 转文本或 Word 转文本。 - 粘贴的截图过不来。正文里的图片不会被读取，所以一封全部内容就是一张报错 弹窗截图的邮件，转出来几乎是空的。把图片存出来，走 图片转文字，那边 确实能识别图片里的文字。
它解决的活儿
- 读一封别人发来的邮件。最朴素的场景，也最常见。你要的是文字，你没有能打开 这种格式的邮件客户端，十秒钟搞定。
- 搭建可搜索的归档。几年的项目往来邮件变成一个文件夹的文本文件，
grep、ripgrep或桌面搜索索引都够得着——不用挂载 PST，不用碰 邮件客户端。 - 审阅与披露工作。对一批邮件扫约定术语、产出命中清单，再交给审阅人一份 不用给全组买 Outlook 授权就能读的东西。
- 基于往来邮件做 RAG。把客户的邮件历史做成向量，客服助手就知道之前答应过 什么，而不是打四个月前同事的脸。
- 批量分类。对一个季度的进件邮件跑情感或主题模型，找出投诉升级扎堆的 地方。
- 给助手喂背景。要模型在起草回复之前知道双方谈定了什么，把线程转成文本 是最便宜的办法。
常见问题
不装 Outlook 怎么打开 .msg 文件？
传到这里。MSG 容器会被解析，邮件以可读的纯文本返回——发件人、收件人、主题、日期和正文——不需要 Outlook，不需要插件，不需要安装任何东西。免费、免注册、单文件 50 MB，我们这边什么都不存。
为什么 .msg 在文本编辑器里是一堆二进制乱码？
因为它是复合二进制文件，不是文本文件。Outlook 把一封邮件存成一个内部带目录树的容器，主题、正文、每个收件人和每个附件各自待在以 MAPI 属性标识符命名的独立流里。按文本打开，你看到的是容器的原始字节，中间零星飘着几个认得出的词。
它会提取附件吗？
不会——输出的是邮件本身：邮件头和正文。附件留在文件里。附带文档的内容也需要的话，先把它从邮件里存出来，去对应格式的页面转换；或者把几封邮件打包成 ZIP，用 ZIP 转文本。
能一次转整个邮箱导出吗？
一次上传不行——这里接的是单个 .msg。一个文件夹的话，把文件夹打成 zip 转归档，一趟走完里面的每封邮件。做取证、重建线程或给邮箱导出建搜索索引，通常走的就是这条路。
邮件内容保密吗？
文件处理完即丢弃——不存储、不记日志、不建索引，也不关联任何账号。话虽如此，如果邮件真的高度敏感，更稳妥的选择是本地文件夹转换器，它直接在浏览器里读文件，没有上传这一步。
工具箱的其余部分
MSG 是 File2Txt 支持的 格式之一，懒得挑页面就把任何文件都丢给它。值得认识的近邻：存下来的网页和邮件简报标记有 HTML 转文本，总爱附在 你正在转的那些邮件里的导出文件有 CSV 转文本。在线页面 方面，Web2Txt 把网址直接 抓成文本；代码这边有 GitHub 仓库转文本转换器，可以把 一条邮件线程和它争论的那份实现配成一对。 为 LLM 准备文档的指南 把通用的道理讲了一遍。
Repo2Txt 由 v12hero 开发和维护，那是一位独立开发者，专做隐私优先的原生应用和 Web 应用。