SOAP with Attachments（SWA）是通过MIME multipart/related封装实现SOAP消息与二进制附件并列传输的标准机制，避免Base64编码导致的体积膨胀和解析开销；其第一部分为SOAP信封，其余为带Content-ID的原始二进制附件，SOAP体内用cid引用；相比MTOM和DIME，SWA兼容性强但WSDL描述弱、缺乏附件元数据定义，且现代框架更倾向MTOM。
SOAP with Attachments（SWA）是一种在SOAP消息中携带二进制附件的标准机制，它不改变SOAP本身，而是借助MIME多部分（multipart/related）封装，把SOAP信封和附件作为独立部分并列传输，避免将二进制数据Base64编码嵌入XML正文。
SWA的核心设计逻辑
SOAP本质是纯文本协议（基于XML），无法直接承载图片、PDF、音频等二进制内容。传统做法是用Base64编码把文件转成ASCII字符串塞进，但这会带来约33%的数据体积膨胀，且解析开销大、内存占用高。SWA绕开了这个瓶颈：它把整个HTTP请求/响应构造成一个MIME多部分消息，其中：
- 第一部分是标准的SOAP信封（Content-Type:
text/xml或application/soap+xml） - 其余部分为原始二进制附件（如
image/jpeg、application/pdf），各自拥有独立的Content-ID（如 - SOAP体内的元素可通过
href="cid:abc123@example.org"引用对应附件，实现“逻辑关联”而非“物理内嵌”
SWA与MTOM、DIME的关键区别
三者都解决SOAP传二进制的问题，但机制和适用性不同：
- SWA：基于已有MIME规范，无需新协议，兼容性强；但WSDL描述附件能力弱，对Document/literal绑定支持不佳，且未定义附件元数据（如文件名、类型）如何在SOAP层表达
- MTOM（Message Transmission Optimization Mechanism）：W3C标准，明确结合XOP（XML-binary Optimized Packaging），能自动识别XML中Base64-encoded节点并外置为附件，语义更清晰，现代Web服务框架（如Axis2、.NET WCF）默认优先支持
- DIME：微软早期提出的轻量二进制封装格式，已基本淘汰，仅遗留于旧Office客户端互操作场景
实际开发中的典型用法
以Java Axis2为例，客户端上传一个JPG文件的SWA请求流程如下：
- 构造SOAP Body时，只放轻量字段（如文件名），附件ID用
urn:uuid:xxx占位 - 调用API（如
OperationClient.addAttachment()）添加原始字节流，并指定Content-ID - 框架自动组装MIME边界（boundary）、设置
Content-Type: multipart/related及相应头字段 - 服务端通过
MessageContext.getAttachmentMap().getDataHandler("cid:xxx")获取附件流，直接写入磁盘或解码处理
注意事项与局限性
SWA虽简单直接，但落地时需注意：
