Kafka Connect本身不识别XML结构，需依赖kafka-connect-xml-converter等专用转换器实现解析与Schema映射；若环境受限，可绕过Connect直接用KafkaProducer发送XML字符串以规避解析风险。
XML消息在Kafka Connect中不能直接传输
Kafka Connect本身只处理字节数组（byte[]），不识别XML结构。如果你把原始XML字符串塞进Kafka主题，下游消费者得自己解析；但若想让连接器（比如IBM MQ源/汇）真正“理解”XML并做字段映射、嵌套转换或Schema校验，必须靠专用转换器——不是Kafka自带的StringConverter或JsonConverter。
用kafka-connect-xml-converter实现XML解析与序列化
IBM官方维护的kafka-connect-xml-converter是目前最成熟的选择，它支持将XML转为Struct（兼容Kafka Connect Schema），也支持反向生成格式良好的XML。关键点在于：它必须和IBM MQ连接器**一起部署在同一Connect worker进程里**，且需显式配置在连接器定义中：
-
key.converter=org.apache.kafka.connect.storage.StringConverter（通常保持字符串键） value.converter=com.ibm.eventstreams.connect.xml.XmlConverter-
value.converter.schema.registry.url=http://schema-registry:8081（可选，用于注册XML对应的Schema） value.converter.xml.encoding=UTF-8-
value.converter.xml.flatten=false（设为false保留嵌套结构，设为true则展平为点号路径，如order.customer.name）
注意：该转换器从IBM MQ 9.4.2起随连接器发布，9.4.3+才正式纳入Kafka Connect插件体系。别直接从Maven拉旧版jar，容易和connect-api版本冲突。
常见失败场景：XML非法、命名空间、编码不一致
实际跑起来常卡在这三类错误：
- XML含BOM头或
零宽空格 → 消费端报org.xml.sax.SAXParseException: Content is not allowed in prolog→ 用iconv -f UTF-8 -t UTF-8//IGNORE预清洗 - 带
xmlns命名空间的XML → 默认转换器会丢弃namespace属性，导致字段匹配失败 → 需设置value.converter.xml.namespace.aware=true（仅9.4.3+支持） - MQ传入的XML是GBK编码，但配置写
UTF-8→ 报Invalid byte 2 of 3-byte UTF-8 sequence→ 查清源系统真实编码，改value.converter.xml.encoding
不升级IBM MQ？试试绕过Connect，手写Producer
如果环境受限（比如MQ是老版本，无法部署新插件），最稳的方案其实是跳过Kafka Connect，直接在业务层用KafkaProducer发XML字符串：
Properties props = new Properties();
props.put("bootstrap.servers", "kafka:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer"); // 就用String，别碰XML转换器
KafkaProducer producer = new KafkaProducer<>(props);
producer.send(new ProducerRecord<>("xml-topic", "msg-id", "123 99.9
这样虽失去Schema推导和字段级过滤能力，但规避了所有XML解析时序问题，也避免Connect worker因XML异常而挂掉整个任务——对中小规模XML集成，这反而是更可控的路径。
真正麻烦的从来不是“能不能转XML”，而是谁负责校验格式、谁承担解析失败的重试逻辑、以及下游是否真需要结构化字段。这些决策比选哪个转换器更重要。
