使用Axios动态生成XML请求时返回二进制数据问题排查

• 校验XML格式合法性
  手动拼接的换行、缩进可能引入多余空白字符，导致SOAP服务端解析出错。把生成的genXML完整打印出来，和仅保留首尾节点的正常XML对比，检查是否存在节点闭合错误、多余空白（比如换行后未对齐的空格）等问题——SOAP对XML语法的容错性极低，这类细节很可能触发服务端返回非预期的二进制错误响应。

• 显式配置Axios的请求头与响应解析规则
  其他请求库可能自动适配了SOAP请求的头部和响应解析逻辑，Axios需要手动指定：

  1. 请求时设置Content-Type为application/soap+xml; charset=utf-8或text/xml; charset=utf-8，确保服务端正确识别请求格式；
  2. 强制指定responseType: 'text'，避免Axios将服务端返回的内容默认解析为二进制（比如ArrayBuffer）。示例配置：

     axios.post(targetUrl, genXML, {
       headers: {
         'Content-Type': 'application/soap+xml; charset=utf-8'
       },
       responseType: 'text'
     })
     

• 简化XML拼接逻辑，移除多余空白
  当前循环里的手动缩进、换行完全没必要，反而可能引发问题。直接拼接节点即可，SOAP服务端会忽略节点间的合法空白：

  const genXML = idArray.map(item => item.XMLCode).join('');
  

  如果需要本地调试时的可读性，再用XML格式化工具处理，请求时务必使用无冗余空白的版本。

• 检查服务端的响应压缩处理
  当XML内容较长时，服务端可能启用了gzip压缩，Axios默认不会自动解压，导致返回二进制数据。可以通过抓包工具查看响应头的Content-Encoding字段，如果是gzip，需要添加解压逻辑：

  import zlib from 'zlib';
  
  axios.interceptors.response.use(async response => {
    if (response.headers['content-encoding'] === 'gzip') {
      const decompressed = await new Promise((resolve, reject) => {
        zlib.gunzip(response.data, (err, data) => err ? reject(err) : resolve(data));
      });
      response.data = decompressed.toString();
    }
    return response;
  });
  

• 对比HTTP报文差异
  用Chrome DevTools或抓包工具，分别捕获完整XML请求、仅首尾节点请求的HTTP报文，对比：

  • 请求体的内容是否一致（重点看空白字符、节点顺序）；
  • 请求头的Content-Length是否正确——手动拼接换行可能导致长度计算错误，服务端接收不完整请求后返回二进制错误响应。

内容的提问来源于stack exchange，提问作者sylargaf