SOAP with Attachments（SwA）是通过MIME multipart/related封装SOAP信封与base64编码附件的机制，不修改SOAP协议；因体积膨胀和解析开销大，已被更高效的MTOM替代，现主要用于遗留系统集成。
SOAP with Attachments（SwA）是一种让 SOAP 消息携带二进制附件（比如图片、PDF、XML 文件等）的机制，它本身不修改 SOAP 协议，而是借助 MIME 多部分（multipart/related）封装，把 SOAP 信封和附件“打包”成一个 HTTP 请求体发送。
SwA 的核心思路：用 MIME 把 SOAP 和附件捆在一起
标准 SOAP 消息是纯 XML 文本，没法直接放图片或大文件。SwA 不去改 SOAP 规范，而是借用了电子邮件常用的 MIME 标准：
- 整个请求是一个
multipart/related类型的 MIME 包 - 第一部分是标准的 SOAP Envelope（Content-Type: text/xml）
- 后续部分是附件（如 image/jpeg、application/pdf），每个有独立 Content-ID
- SOAP 正文中通过
xop:Include或引用cid:（如<report.pdf></report.pdf>）指向对应附件
SwA 和 MTOM 的关系：后者是前者的升级替代方案
SwA 早期被广泛使用（尤其在 .NET Framework 1.x/2.0 和一些老 Java WebService 框架中），但它有个明显缺陷：
- 附件必须做 base64 编码嵌入 MIME，导致体积膨胀约 33%，效率低
- 解析时需先解码再处理，增加 CPU 开销
因此 W3C 推出了 MTOM（Message Transmission Optimization Mechanism）——它同样用 multipart/related 封装，但允许附件以原始二进制形式传输（不 base64），只对 XML 部分编码，更高效。现在新系统基本都用 MTOM，SwA 主要出现在遗留系统集成场景。
实际开发中你可能遇到 SwA 的几种情况
- 调用老版本 WebService（如 Axis 1.x、.NET ASMX）时收到带附件的响应，HTTP 响应头含
Content-Type: multipart/related - 抓包看到多个 MIME boundary 分隔块，其中一块是 XML，其余是二进制流
- 客户端解析失败，报错类似 “Unexpected start of multipart body” 或 “Cannot resolve cid:xxx”——常因未正确解析 MIME 结构或忽略 Content-ID 引用
基本上就这些。SwA 现在不算主流，但理解它有助于调试老系统、读懂协议交互细节，也帮你明白为什么后来有了 MTOM。
