场景导入：别让老旧系统的 XML 成为你自动化的“拦路虎”
兄弟们，咱们搞自动化的，最头疼的是什么？不是新系统 API 不够开放，而是那些动辄十几年前的老古董系统。这些系统往往还在用 XML 格式传输数据，而我们现在用的 n8n、Python 脚本、Web API，全是 JSON 的天下。
每次对接这种老旧系统，就像在两个语言不通的人中间当翻译。如果手动写代码去解析 XML，太慢了；如果让业务人员手动复制粘贴，太容易出错了。笔者在 N8N大学 接触过大量案例，发现这简直是企业数字化转型的“血泪重灾区”。
其实，n8n 早就替你想到了这一点。今天，笔者就手把手教你用 n8n 的 XML 节点，把老旧系统吐出来的 XML 数据，毫发无损地转换成标准 JSON，让老系统也能拥抱自动化。
核心实操：三步搞定 XML 到 JSON 的转换
别怕，这个过程比你想象的要简单。我们不需要写一行复杂的正则表达式，只需要像搭积木一样连接几个节点。
第一步：获取原始 XML 数据
首先，你需要拿到那个老旧系统的数据。通常，这通过 HTTP Request 节点来完成。
假设老系统提供了一个返回 XML 的 API 接口。在 n8n 中创建一个 HTTP Request 节点，配置好 URL 和认证信息。关键在于，你不需要手动处理返回的数据格式，先让它原样吐出来就好。
笔者提示： 如果老系统只支持 SOAP 协议（一种特殊的 XML Web Service），你可能需要先通过 HTTP Request 获取到完整的 SOAP 响应包，这通常是一个巨大的 XML 字符串，包含 Header 和 Body。
第二步：清洗数据（如果需要）
很多时候，老系统返回的 XML 并不“纯粹”。比如，它可能包含 SOAP 的信封（Envelope），或者返回的不是一个列表而是一个字符串。
这时候，我们需要用 Set 节点或者 Function 节点做一个简单的预处理。我们的目标是：把那个长长的 XML 字符串提取出来，单独放在一个字段里，方便下一步转换。
比如，通过 item.json.xmlResponse 这样的路径，把 HTTP Request 返回的 body 捞出来。如果你懂一点点 JavaScript，用 Function 节点写一行代码 return [{json: {rawXml: $input.item.json.body}}] 是最稳妥的。
第三步：使用 XML 节点进行转换（重头戏）
这是最关键的一步。在工作流中加入一个 XML 节点（在 n8n 的节点搜索栏输入 "XML" 即可找到）。
配置这个节点非常直观：
- 模式 (Mode)： 选择 Convert to JSON（转换为 JSON）。
- 数据来源 (Data)： 告诉节点去哪找 XML 数据。通常选择上一步 Set 节点设置的字段，比如
item.json.rawXml。 - 选项 (Options)： 这里有个坑点，后面细说。
点击执行，你会发现输出的 JSON 已经变得非常结构化了。原本嵌套的 XML 标签，现在变成了 JSON 的对象层级。老旧系统的数据，瞬间就被 n8n “驯服”了。
避坑指南：这两个细节决定了成败
在 N8N大学 的实战课程中，很多学员都在这里翻过车。看似简单的转换，其实暗藏玄机。
1. 命名空间（Namespace）地狱
很多老旧系统，尤其是 SAP、用友、金蝶这类 ERP 系统，在 XML 中使用了大量的命名空间，比如 <soap:Envelope xmlns:soap="...">。
如果你直接转换，n8n 默认可能会忽略这些前缀，或者在 JSON 的 key 里带上冒号，导致后续节点无法识别字段名。
解决方案： 在 XML 节点的“选项”中，勾选 Ignore Namespace（忽略命名空间）。除非你的 XML 结构非常复杂且依赖命名空间区分不同标签，否则勾选它能省去 90% 的麻烦。
2. 数组的单一元素陷阱
这是所有数据格式转换的经典问题。假设 XML 里有个列表：
<Users>
<User>Alice</User>
</Users>转换成 JSON 后，Users 可能变成了 { "User": "Alice" }（对象），而不是 { "User": ["Alice"] }（数组）。
当老系统后续突然多塞了一条数据进去，比如 <User>Bob</User>，你的 JSON 结构突然变成了数组，下游处理逻辑直接报错。
解决方案： 在 n8n 的 Set 节点或者 Function 节点里，对转换后的数据做一次“兜底”处理，强制把特定字段转为数组。或者，使用 n8n 社区里大神们分享的“通用数据清洗”Workflow。
进阶技巧：不仅仅是转换，还要利用
把 XML 转成 JSON 只是第一步，我们的目标是让数据流动起来。
比如，你可以接着把转换好的 JSON 数据，通过 Spreadsheet File 节点生成 Excel 报表发给老板；或者通过 HTTP Request 节点，把清洗后的数据 POST 到你的新系统数据库里。
笔者见过最硬核的一个案例，是把一个只支持 XML 导入的老旧 OA 系统，通过 n8n 接入了钉钉的审批流。流程就是：钉钉发起审批 -> n8n 接收 -> 转换 JSON -> 再封装成 XML -> 调用 OA 接口写入数据。这中间，XML 节点 就是那个最重要的桥梁。
FAQ 问答
Q1: 如果 XML 数据量非常大（几百 MB），n8n 能处理吗？
A: 这是一个性能问题。n8n 默认在内存中处理数据，超大文件可能会导致内存溢出。对于这种场景，建议先用其他脚本（如 Python）做一次流式处理，或者在 n8n 中分批次请求数据。如果必须用 n8n，请升级服务器配置，并注意调整 n8n 的内存限制参数。
Q2: XML 节点支持把 JSON 转回 XML 吗？
A: 当然支持！这是双向的。在 XML 节点中选择 Convert to XML 模式即可。这在你需要把数据写回老旧系统时非常有用。
Q3: 老系统返回的 XML 格式很乱，没有标准 Schema 怎么办？
A: 这种情况很常见。n8n 的 XML 节点是基于自动推断的，它会尽力去解析。如果解析失败，你可能需要先用 Function 节点写正则表达式简单清洗一下字符串，或者找开发人员要一份大概的结构说明，手动定义一下转换逻辑。
总结与资源
老旧系统并不可怕，可怕的是我们没有趁手的武器。n8n 的 XML 节点就是那把帮你打通新旧数据壁垒的瑞士军刀。记住，不要试图去改变老系统的脾气，而是学会如何优雅地“翻译”它。
如果你在实操中遇到了具体的报错，欢迎前往 N8N大学 (n8ndx.com) 社区发帖，笔者和众多老司机都会在那里帮你解答。
