SOAP传XML附件须用MIME multipart/related封装，设base64编码与Content-ID，SOAP体中用xop:Include引用；服务端需启用MTOM并手动提取AttachmentDataSource，避免Base64直塞Body引发膨胀、乱码及解析失败。
SOAP请求怎么传XML文件当附件
SOAP本身不直接支持“文件上传”概念，text/xml 或 application/soap+xml 请求体里硬塞一个大XML字符串，既不安全也不符合规范。真要传XML文件（比如配置文件、报文模板），得用 MIME multipart/related 封装 —— 这才是WS-I Basic Profile推荐的附件方式，也叫DIME或MTOM的前身。
- 客户端必须把原始XML文件作为独立part，设
Content-Transfer-Encoding: base64，并用Content-ID标记（如 - SOAP信封里的
Body不能直接写XML内容，而要用xop:Include引用该ID： - HTTP头必须设为
Content-Type: multipart/related; type="application/xop+xml"; start="，否则服务端解析器会当普通XML丢弃附件part"; boundary="boundary123" - 别用
application/soap+xml直传——多数老服务端（如Java Axis2、.NET 3.5 WCF）根本不识别，直接返回415 Unsupported Media Type
Web Service端怎么解析SOAP附件（以Java Axis2为例）
Axis2默认不启用MTOM，即使客户端发了multipart，它也只取第一个part（SOAP信封），其余全丢。必须显式开启enableMTOM，且服务端代码要从MessageContext里手动提取AttachmentDataSource。
- 在
services.xml中配：true - Java方法签名不能只写
String，得接收OMElement或org.apache.axiom.om.OMElement，再调getMessageContext().getAttachmentMap().get("cid:config.xml@service.example") - 拿到
javax.activation.DataSource后，用getInputStream()读原始字节，别用toString()转String——XML文件若含中文或特殊字符，base64解码后直接toString会乱码 - 如果用Spring-WS，它默认不支持MTOM，得换用
WebServiceTemplate+HttpComponentsMessageSender并手动构造MultipartEntityBuilder
为什么不用Base64字符串直接塞进SOAP Body
有人图省事把整个XML文件base64.encode()后放进某个
- XML实体体积膨胀约33%，10MB XML变成13MB+，SOAP信封嵌套多层标签后更臃肿，容易触发
org.apache.axis2.AxisFault: Message size exceeded - 服务端反序列化时需额外
Base64.getDecoder().decode()，若没做长度校验，可能被构造超长字符串打爆JVM堆内存 -
... 、&等字符若未转义（如zuojiankuohaophpcn），会导致SOAP解析失败，报Unexpected character " - 无法流式处理：必须等整个base64字符串加载进内存才开始解码，而multipart可边收边存磁盘
.NET WCF服务接收SOAP附件的坑
WCF虽原生支持MTOM，但默认绑定是basicHttpBinding，它关着MTOM。必须显式设messageEncoding="Mtom"，且服务契约操作不能声明string参数。
- 服务端接口得用
Stream或byte[]接收附件，例如：public string ProcessConfig(Stream configXml)
- 客户端调用前必须用
new MtomMessageEncoderFactory()替换默认编码器，否则Content-Type还是text/xml - WCF对
Content-ID格式敏感：必须严格匹配cid:xxx或xxx都解析失败，日志只报Cannot find attachment with ID - 调试时用Fiddler抓包，重点看HTTP响应头是否含
Content-Type: multipart/related; type="application/xop+xml"，没有就说明服务端根本没走MTOM路径
真正难的不是发或收，而是两端对Content-ID的拼写、boundary的生成规则、base64换行符（\r\n还是\n）、空格是否忽略这些细节达成一致。一个字符不对，附件就静默丢失。
