MIME多段邮件文件是按RFC 2046定义的结构化数据，含多个Content-Type、boundary分隔符及Base64/quoted-printable编码载荷；直接用fstream逐行读取会丢header、错判boundary、解码失败，尤其在嵌套multipart场景下极易误切分或漏子部分。
什么是MIME多段邮件文件，为什么不能直接用fstream读取
它不是纯文本文件，而是按 RFC 2046 定义的结构化数据：含多个 Content-Type、boundary 分隔符、Base64 或 quoted-printable 编码载荷。直接用 fstream 逐行读取会丢 header、错判 boundary、解码失败——尤其遇到嵌套 multipart（如 multipart/mixed 套 multipart/alternative）时，手写解析极易漏掉子部分或误切分。
用 libmime 还是自己写 parser？实际选型建议
没有标准 C++ 库支持 MIME 解析；libmime（如 mimetic）已多年未维护，C++17 后编译报错多；Boost.Mail 从未进入 Boost 官方发布版；最可行路径是轻量级第三方 + 手动补关键逻辑：
- 推荐
rfc2047+rfc2045兼容的libmailutils（Linux/macOS 可 apt-get / brew install），它提供mu_message_create_from_file()和mu_body_get_part()，能递归展开 multipart - Windows 下优先用
POCO Net的Poco::Net::MessageHeader+ 手动 split boundary（需自行处理 Base64 解码） - 若项目不允许引入外部依赖，必须手写：核心是提取
Content-Type: multipart/.*; boundary="(.*)"，再用该 boundary 正则匹配--{boundary}和--{boundary}--，注意边界前后可能有空格或 CRLF
boundary 解析中最容易踩的三个坑
boundary 不是固定字符串，RFC 允许带空格、引号、特殊字符，且实际邮件中常出现不规范写法：
-
boundary="----=_NextPart_12345"中的=_NextPart_是合法 base64-like 标识，但有些邮件会漏掉开头的--，需兼容{boundary}和--{boundary}两种前缀 - 最后一段 boundary 后可能紧跟
--（即--{boundary}--），也可能只有单个--，甚至无终止符（靠 EOF 判断），必须检查末尾是否为--再决定是否截断 - boundary 在 header 中是 ASCII，但在 body 中可能出现 CRLF 混合（尤其是 Windows 发送的邮件），用
\r\n--{boundary}匹配比单纯--{boundary}更可靠
如何安全提取 Base64 编码的附件内容
不能直接对整段 body 调用 std::base64_decode()——因为中间可能混入空白、注释行或换行符（RFC 2045 允许每 76 字符插入 CRLF）。正确做法：
立即学习“C++免费学习笔记（深入）”；
- 先用正则提取
Content-Transfer-Encoding: base64对应的 body 片段（从下一个 header 前一行开始，到下一个 boundary 前一行结束） - 逐行 trim 掉
\r\n和空格，拼接成连续字符串（忽略空行） - 调用
openssl/base64或boost::beast::http::base64_decode()解码；若用自实现 base64，务必处理末尾=补位和非法字符跳过 - 特别注意：某些邮件把
Content-Disposition: attachment; filename="中文.pdf"的 filename 用=?UTF-8?B?...?=编码，需先调用rfc2047_decode()解码文件名
复杂点不在解析结构，而在容忍现实邮件的各种不合规写法——比如 missing boundary、mixed line endings、header field 大小写混乱、multipart/related 中 cid 引用缺失。别指望一次跑通所有样本，得留日志打桩看每一段的 raw header 和 boundary match 结果。
