Webhook 收到数据，n8n 却报错“读不懂”？
作为在 N8N大学 深耕多年的老编辑，笔者见过太多初学者在处理 Webhook 数据时碰壁。最常见的场景是：你兴冲冲地配置好一个第三方应用的 Webhook 回调，满怀期待地在 n8n 里点击“测试”，结果节点直接报红，或者数据传到下一步时完全乱套。
原因通常只有一个——**数据格式不标准**。第三方应用传来的 JSON 结构可能嵌套过深，或者干脆是 XML、CSV 甚至纯文本。面对这些“非标准格式”，直接使用默认的 Webhook 节点往往力不从心。今天，我们就来聊聊如何优雅地处理这些棘手的数据，让你的自动化流程坚如磐石。
第一步：理解 Webhook 节点的“脾气”
在深入技巧之前，我们必须先摸清 n8n Webhook 节点的习性。默认情况下，Webhook 节点会将接收到的整个请求体（Body）作为一个 JSON 对象传递给下一个节点。
但如果你的请求是 application/xml 或者 text/plain，n8n 默认可能无法正确解析，导致数据丢失或格式错误。这就是为什么我们需要手动介入，进行数据转换。
关键参数：Binary Data
在 Webhook 节点的设置中，有一个容易被忽视的选项：Binary Data。如果你接收到的是文件（如图片、PDF），必须勾选此项。但如果是文本数据（JSON、XML），通常不需要勾选，除非你想以二进制流的方式处理。
第二步：处理非标准 JSON 结构（嵌套与扁平化）
很多时候，数据虽然是 JSON 格式，但结构过于复杂。比如，一个电商订单数据可能嵌套了多层用户信息和商品列表。直接处理这种数据会让后续的逻辑节点变得非常臃肿。
这时，我们通常使用 Set 节点或 Function 节点来“重塑”数据。
使用 Set 节点提取关键字段
如果你只需要提取顶层的几个字段，Set 节点是最简单的选择。
- 在 Webhook 节点后添加一个 Set 节点。
- 在 Keep Only Set 选项中勾选，这意味着只保留你手动设置的字段。
- 在 Values to Send 中，映射你需要的字段。例如，将
$.body.user.id映射为userId。
这样做能有效减少数据体积，让后续流程更清晰。
第三步：搞定 XML 与 CSV 等“异类”格式
这是最让新手头疼的部分。当 Webhook 发来的不是 JSON，而是 XML 或 CSV 时，n8n 的 Webhook 节点本身是“听不懂”的。我们需要一个翻译官——Function 节点。
场景一：XML 数据的转换
假设 Webhook 传来了 XML 字符串。我们需要在 Webhook 节点后接入一个 Function 节点，编写简单的 JavaScript 代码进行转换。
首先，你需要安装一个轻量级的 XML 解析库（如 fast-xml-parser）。在 n8n 的 Function 节点中，你可以使用 require 引入库（如果环境支持），或者直接使用原生 JS 处理简单的 XML。
对于复杂的 XML，推荐使用如下逻辑：
**N8N大学 实战技巧**：如果不想折腾代码，可以先用一个 HTTP Request 节点将数据发往一个免费的在线 JSON 转换 API（如 xml2json 服务），处理完后再传回 n8n。虽然多了一步，但稳定性极高。
场景二：CSV 字符串转 JSON 数组
CSV 数据通常以逗号分隔的字符串形式存在。我们需要将其解析为 n8n 能处理的 JSON 数组。
在 Function 节点中，你可以编写如下逻辑：
const csvString = items[0].binary.data; // 假设数据在 binary 中
const lines = csvString.split('n');
const headers = lines[0].split(',');
const result = [];
for (let i = 1; i {
obj[header.trim()] = currentLine[index].trim();
});
result.push(obj);
}
}
return result;这段代码能将 CSV 字符串转换为标准的 JSON 对象数组，完美兼容 n8n 的后续节点。
第四步：利用 HTTP Request 节点作为“前置转换器”
这是一个进阶技巧，但在处理极端非标准格式时非常有效。如果你的 Webhook 来源允许你配置回调地址，你可以直接将 Webhook 指向 n8n 的 Webhook 节点，但也可以耍个花招。
你可以利用 n8n 的 HTTP Request 节点的“Webhook”模式（或者配合另一个 Webhook 节点），在数据进入核心逻辑前，先经过一个专门的转换流程。
具体做法是：
- 建立一个专门的 Workflow A，接收原始 Webhook。
- 在 Workflow A 中使用 Function 节点清洗数据。
- 清洗后，使用 HTTP Request 节点 POST 到 Workflow B 的 Webhook URL。
虽然增加了网络跳转，但这种架构解耦了数据清洗和业务逻辑，非常利于维护。
避坑指南：那些年我们踩过的坑
在处理非标准格式时，有两个坑笔者必须提醒大家：
1. 字符编码问题 (Encoding Issues)
有些 Webhook 发送的是 GBK 编码的 CSV 或 XML，而 n8n 默认通常按 UTF-8 处理。这会导致中文乱码，进而导致解析失败。
解决方案：在 Function 节点中，使用 iconv-lite 等库进行编码转换。或者在 Webhook 接收端（如果使用自定义节点）强制指定编码。
2. 大数据量超时
如果 Webhook 传来的数据量极大（例如几 MB 的 JSON），直接在 Webhook 节点后的 Function 节点处理可能会导致超时。
解决方案：尽量不要在 n8n 内部处理大数据转换。如果必须处理，确保你的 n8n 实例有足够的内存，并考虑使用流式处理（Stream）而非一次性加载。
FAQ 常见问题解答
Q1: Webhook 节点返回 "404 Not Found" 怎么办？
这通常不是数据格式问题，而是 URL 拼写错误。n8n 的 Webhook URL 通常是 your-n8n-domain.com/webhook/your-webhook-path。请检查是否漏掉了 /webhook 或者路径拼写错误。
Q2: 如何在不写代码的情况下处理 XML？
如果不想写代码，可以利用 n8n 的 Spreadsheet File 节点。虽然它主要用于 Excel，但某些版本支持读取 CSV。对于 XML，目前最稳妥的无代码方案是寻找支持 XML 转 JSON 的第三方 API 配合 HTTP Request 节点使用。
Q3: 数据传到下一个节点变空了，为什么？
检查 Webhook 节点的设置。如果你在 Webhook 节点中勾选了 Binary Data，那么 JSON 数据可能会被放入 binary 属性中，而不是 json 属性中。确保根据数据类型正确配置。
总结与资源
处理 n8n Webhook 的非标准格式，核心思路是“先翻译，后处理”。不要试图让 n8n 的原生节点去理解它不支持的格式，而是利用 Function 节点或外部工具将其转换为标准的 JSON 数组。
掌握了这一招，你就能打通绝大多数第三方系统的数据壁垒。如果你在实践中遇到更棘手的格式，欢迎来到 N8N大学 (n8ndx.com) 交流，我们一起拆解。
