xml 作为 rpc 请求体本质是序列化问题，取决于框架是否支持其作为有效载荷；grpc 默认不支持 xml，强行使用会报错如 typeerror 或 unmarshal error。
XML 作为 RPC 请求体时，本质是序列化问题，不是传输协议问题
RPC 本身不规定数据格式，XML 能不能传，取决于你用的 RPC 框架是否支持把它当有效载荷（payload）序列化/反序列化。强行把 XML 字符串塞进不支持它的 RPC 接口（比如 gRPC 默认用 Protobuf），会直接报错或静默失败。
常见错误现象：TypeError: expected bytes, got str（gRPC）、Unmarshal error: invalid character '（JSON-RPC 误传 XML）、服务端收不到完整 XML 或解析成空对象。
- 确认框架是否原生支持 XML：如 Java 的
JAX-WS、.NET 的WCF（SOAP）、Python 的xmlrpc.client是明确设计来处理 XML 的；而gRPC、JSON-RPC默认不支持，需额外封装 - 如果必须用非 XML 原生框架传 XML，就把整个
XML当作字符串字段塞进请求结构体里，服务端再手动解析——但这时已不是“XML RPC”，只是“带 XML 字符串的 RPC” - 注意编码：确保
XML字符串用 UTF-8 编码，且声明一致（如<?xml version="1.0" encoding="UTF-8"?>），否则服务端解析可能乱码或中断
Python xmlrpc.client 调用远程 XML-RPC 接口的典型写法
xmlrpc.client 是 Python 标准库中唯一开箱即用、专为 XML-RPC 设计的客户端，它自动处理 XML 序列化、HTTP 封装和响应解析，不用手拼 XML 字符串。
使用场景：调用老系统、WordPress XML-RPC API、某些 IoT 设备管理接口。
常见错误现象：ProtocolError: <protocolerror for example.com method not allowed></protocolerror>（URL 错或服务器禁用了 XML-RPC）、Fault 异常（服务端逻辑报错，不是网络问题）。
本文档主要讲述的是Android如何使用WebService接口；WebService是一种基于SOAP协议的远程调用标准。通过WebService可以将不同操作系统平台，不同语言、不同技术整合到一起。在OPhone SDK中并没有提供调用WebService的库，因此，需要使用第三方类库（KSOAP2）来调用WebService。在本文将介绍在OPhone中调用WebService的具体细节，并在最后给出一个完整的例子来演示如何使用KSOAP2来调用WebService。感兴趣的朋友可以过来看看
- URL 必须指向真实的 XML-RPC 端点，通常是
/xmlrpc.php、/RPC2或类似路径，不是普通 REST 接口地址 - 方法名是字符串，参数按顺序传入，类型由
xmlrpc.client自动映射（int→<i4></i4>，str→<string></string>），不支持嵌套过深的自定义对象 - 若服务端返回的是原始 XML（非标准 Fault 或响应结构），
xmlrpc.client会抛出ResponseError，需捕获并检查args[0]获取原始响应体
import xmlrpc.client
client = xmlrpc.client.ServerProxy("https://example.com/xmlrpc.php")
try:
result = client.wp.getPosts({'post_type': 'post'}, 10)
except xmlrpc.client.Fault as e:
print(f"Server fault: {e.faultCode} - {e.faultString}")
except xmlrpc.client.ProtocolError as e:
print(f"HTTP error: {e.errcode} {e.errmsg}")Java JAX-WS 客户端调用 SOAP/XML-RPC 接口的关键配置点
Java 用 JAX-WS 调用基于 XML 的 Web Service（SOAP）很常见，但默认生成的客户端对命名空间、头信息、编码很敏感，稍有不匹配就解析失败。
性能影响：每次调用都会触发 XML 解析和 JAXB 绑定，比 JSON 或二进制协议慢 2–5 倍；兼容性上，JDK 11+ 已移除 javax.xml.ws 模块，需显式添加 jaxws-api 和实现（如 metro）。
- 务必校验 WSDL 地址是否可访问，且内容未被 Nginx/Apache 重写过滤（常见于
404或返回 HTML 登录页） - 生成客户端代码后，检查
@WebServiceClient注解里的wsdlLocation是否正确；若 WSDL 动态变化，建议设为空并在运行时传入 URL - 需要加 SOAP Header（如认证 token）时，不能直接改 XML 字符串，得用
BindingProvider+Handler实现，否则 header 会被忽略 - 遇到
javax.xml.bind.UnmarshalException: unexpected element，大概率是命名空间（xmlns）不匹配，检查 WSDL 中的targetNamespace和生成类的@XmlSchema是否一致
绕过框架手组 XML 发起 HTTP POST 的边界情况
当所有 RPC 框架都不适用（比如目标服务只认特定格式的 XML POST，且不遵循任何标准），就得自己构造 HTTP 请求。这不是推荐做法，但真实运维中常遇到。
容易踩的坑集中在 Content-Type 和字符边界：服务端严格校验 Content-Type: text/xml 或 application/soap+xml，少一个分号或字符集声明（; charset=utf-8）就会拒收；XML 中的特殊字符（&、、<code>"）没转义会导致解析中断。
- 用
requests.post()时，显式设置headers={"Content-Type": "text/xml; charset=utf-8"}，不要依赖默认值 - XML 字符串必须是
str类型（Python 3），requests会自动 encode；若传bytes，需同时删掉 charset 声明，否则双重编码 - 调试时先用
curl -X POST -H "Content-Type: text/xml" --data-binary @request.xml https://api.example.com验证服务端是否接受，再移植到代码 - 响应不是标准 XML？别用
xml.etree.ElementTree.fromstring()直接解析，先用response.text打印原始内容，确认有没有 HTML 错误页混在里面
实际项目里最麻烦的往往不是怎么发，而是对方服务文档缺失、WSDL 地址失效、或者 XML 命名空间套了三层还大小写混用——这些细节不会报“XML 格式错误”，只会让你卡在 None 返回值或空数组上半天。
