Parse XML活动无法直接解析multipart/form-data上传的XML文件，需先用Parse MIME拆出part并提取content，再通过Mapper或Java Code转为String/InputStream；注意编码匹配、命名空间处理及大文件的SAX解析与超时限制。
Parse XML活动不支持直接解析multipart/form-data中的XML文件
上传XML文件时，如果前端用 form 表单以 multipart/form-data 方式提交，Parse XML 活动无法直接读取 —— 它只认纯XML字符串或流（InputStream），而BW默认把整个multipart请求封装成 multipart 类型的输入变量，里面是带边界（boundary）的原始字节流。
常见错误现象：Parse XML 报错 Invalid XML content 或直接抛 NullPointerException，因为传进去的是乱码般的multipart body，不是XML。
- 必须先用
Parse MIME活动拆出具体part（比如名为xmlFile的附件） - 再从该part中提取
content字段（类型为InputStream或byte[]） - 若内容是UTF-8但含BOM，需手动跳过前3字节，否则解析失败
Parse MIME之后怎么把内容喂给Parse XML
Parse MIME 输出结构里，每个part是一个 part 元素，其中 content 是二进制数据。但 Parse XML 的 Input 端口只接受 String、InputStream 或 Document 类型 —— 不能直接连 part/content（它是 byte[]）。
实操建议：
- 用
Mapper将part/content转成String：调用new String(byte[], "UTF-8")，注意捕获UnsupportedEncodingException（虽然UTF-8总存在，BW旧版本仍可能抛） - 或者更稳妥：用
Java Code活动构造ByteArrayInputStream，再传给Parse XML的InputStream输入端口 - 避免在
Mapper里用toString()直接转byte[]—— 那只是内存地址，不是XML文本
Parse XML活动对编码和命名空间的敏感点
BW 6.x 默认用JAXP解析，底层是Xerces。一旦XML声明里写了 <?xml version="1.0" encoding="GBK"?>，但实际内容是UTF-8，Parse XML 就会解错字节，导致中文变问号或解析中断。
关键控制项：
-
Parse XML活动属性里的Encoding字段留空（让解析器自动探测），或显式设为UTF-8—— 但仅当确定所有输入都是UTF-8时才设死 - 若XML含命名空间（如
xmlns="http://example.com/ns"），Parse XML会正常加载，但后续用XPath提取时必须带命名空间前缀，否则查不到节点 - 不要依赖
Parse XML的Validate against Schema勾选框做校验——它只校验结构，不报字段级业务规则错误
大XML文件上传时的内存与超时风险
Parse XML 默认走DOM解析，整棵树加载进内存。上传10MB XML文件可能直接触发JVM OutOfMemoryError，尤其在BW容器内存限制较严时（如Docker部署限制512MB）。
缓解方式：
- 改用
SAX Parse XML活动（BW 6.5+ 支持），它流式处理，内存占用恒定，但只能做事件驱动解析，不能随机访问节点 - 在HTTP接收端配置超时：在
HTTP Receiver活动里调高Receive Timeout（默认30秒），否则大文件上传中途就断连 - 生产环境务必限制上传大小：在反向代理（如Nginx）层加
client_max_body_size 20M，比在BW里做校验更早拦截
java
// 示例：Java Code活动构造InputStream供Parse XML使用
import java.io.*;
byte[] raw = (byte[]) getPipelineVariable("multipartPart/content");
InputStream is = new ByteArrayInputStream(raw);
setPipelineVariable("xmlStream", is);
真正卡住人的地方，往往不是XML语法错，而是multipart没拆干净、编码没对齐、或者大文件时DOM撑爆堆内存——这些环节没有报明确错误码，只默默失败。 
