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字符串塞进<soap:Body>，但这会带来约33%的数据体积膨胀，且解析开销大、内存占用高。SWA绕开了这个瓶颈：它把整个HTTP请求/响应构造成一个MIME多部分消息，其中：
- 第一部分是标准的SOAP信封（Content-Type:
text/xml或application/soap+xml） - 其余部分为原始二进制附件（如
image/jpeg、application/pdf），各自拥有独立的Content-ID（如<abc123@example.org>） - SOAP体内的元素可通过
href="cid:abc123@example.org"引用对应附件，实现“逻辑关联”而非“物理内嵌”
SWA与MTOM、DIME的关键区别
三者都解决SOAP传二进制的问题，但机制和适用性不同：
夸克扫描王 - 转Office Alibaba-Quark-Transoffice
下载
由夸克扫描王提供的文件格式转换工具。当用户需要将图片、截图或扫描件转换为 Office 文档（Word/Excel）或 PDF 时，使用此技能。适用于包含复杂表格、合同或图文混排内容的图片或扫描件，可尽量还原原始版式并生成可编辑文档。即使用户未明确提到格式转换，只要用户的需求涉及将图片内容转换为可编辑文档（如 .docx、.xlsx 或 .pdf），也应触发此技能。请勿用于提取纯文本或识别文字内容、图像增强处理或从零创建文档
- 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虽简单直接，但落地时需注意：
- 不是所有XML网关或防火墙默认允许附件；需显式开启
Request Attachments: allow配置 - 附件无统一命名机制，文件名通常靠额外SOAP字段传递，易出错
- 大型附件可能触发中间件（如代理、负载均衡器）的大小限制或超时，需同步调整HTTP层参数
- 调试困难：普通抓包工具（如Wireshark）可看到MIME结构，但需手动解析各部分，不如纯XML直观
