二进制流操作:在 Code 节点中读取、转换 Base64 图片与文件流 (Binary Data)

2026-01-26 15 0

别让“二进制数据”把你拦在门外

兄弟们,我是 N8N大学 的主编。老实说,很多刚接触 n8n 的朋友,一看到“二进制流(Binary Data)”这几个字,头都大了。明明是想处理个图片、转个 PDF,结果在 Code 节点里折腾半天,数据传不过去,格式乱七八糟,最后只能骂骂咧咧地放弃。

这事儿真没那么玄乎。在 n8n 的世界里,二进制流其实就是“文件”的另一种叫法。今天,笔者就带你硬核拆解,如何在 Code 节点里驯服这些“野马”,搞定 Base64 转换与文件流读取。

二进制流(Binary Data)到底是个啥?

咱们不说教科书定义。在 n8n 里,你把它想象成一个“黑盒子”就行了。HTTP 请求下载了一张图片,它不会直接把图片像素塞给你,而是把这个文件打包成一个二进制对象,扔给下一个节点。

Code 节点默认处理的是 JSON 文本数据。你想在 JS 代码里操作图片?那就得学会怎么“拆盒”和“装盒”。

场景一:把图片转成 Base64 (Binary → Base64)

这是最常见的需求,比如你要把图片存进数据库,或者发给某些只认 Base64 的 API。

1. 准备工作

确保你的工作流中,上游节点已经把文件以二进制流的形式传过来了。比如用 HTTP Request 节点下载图片时,记得在 Response Format 里选 File(或者叫 Binary),否则你拿到的只是乱码。

2. Code 节点实战

拖入一个 Code 节点,选择 JavaScript。核心代码如下:

// 假设输入数据是二进制流,键名为 binaryData
const binaryData = $input.first().binary;

if (!binaryData) {
  throw new Error('没接收到二进制数据,上游是不是搞错了?');
}

// 这里的 data 就是 Base64 字符串了
const data = binaryData.data;

// 输出结果,把 Base64 放入 JSON 字段中
return {
  json: {
    base64String: data,
    filename: binaryData.fileName || 'image.png'
  }
};

笔者提示: 上面的代码里,binaryData.data 就是 n8n 自动帮你转好的 Base64 字符串。如果你需要手动拼接成 data:image/png;base64,... 这种格式,记得自己加前缀。

场景二:读取并处理文件流 (Base64 → Binary)

反过来,如果你手里有一串 Base64 字符串(比如从数据库里读出来的),想把它还原成文件发给用户,该怎么操作?

在新版 n8n 的 Code 节点(NodeJS 环境)中,我们可以使用 Buffer 对象来转换。

// 假设输入 JSON 里有个字段叫 base64_str
const base64Str = $json.base64_str;

if (!base64Str) return { json: {} };

// 1. 去除 Base64 头部(如果有的话)
const cleanBase64 = base64Str.split(',')[1] || base64Str;

// 2. 转换成 Buffer (二进制缓冲区)
const buffer = Buffer.from(cleanBase64, 'base64');

// 3. 放入 binary 对象中,供下游节点使用
return {
  json: { success: true },
  binary: {
    data: {
      data: buffer.toString('base64'), // 保持数据完整性
      mimeType: 'image/png',           // 必须指定 MIME 类型
      fileName: 'output.png'           // 建议指定文件名
    }
  }
};

执行完这段代码,下游节点(比如 Send EmailWrite Binary File)就能直接识别出这是一个文件了。

避坑指南:三个致命细节

在 N8N大学 的无数次实战中,关于二进制流的坑,笔者总结了这三点:

  1. 不要在 JSON 里塞大文件: 有些老版本教程会让你把 Base64 存在 JSON 字段里传。如果文件超过 1MB,这会导致 n8n 内存暴涨甚至崩溃。请务必使用 binary 属性传递文件。
  2. MIME 类型搞混: 转换回二进制时,如果不填 mimeType,下游节点可能无法识别文件类型,导致下载下来的文件打不开。不知道填什么?去搜一下“文件后缀 MIME 对照表”。
  3. Code 节点的版本差异: 如果你用的是老版 n8n 的 Function 节点,写法是 return [{ json: {...}, binary: {...} }] 。新版 Code 节点返回对象即可,注意版本兼容性。

FAQ:你可能还想问

Q: 为什么我的 Code 节点输出的二进制数据,下一个节点读不到?
A: 检查一下你的返回格式。确保是直接返回给 binary 属性的,而不是把 Base64 字符串塞在 json 里。另外,确认下一个节点的输入设置是否正确。

Q: Base64 字符串太长了,有没有性能更好的办法?
A: 有的。如果在同一个工作流内流转,尽量保持 Binary 格式,不要频繁转 Base64。只有在必须存文本库或发 JSON API 时才转换。

Q: Code 节点能处理多大的文件?
A: 这取决于你给 n8n 分配的内存。一般建议不要在 Code 节点里处理几百 MB 以上的文件,容易 OOM(内存溢出)。如果是大文件处理,建议使用流式处理或外部存储。

总结与资源

二进制流操作是 n8n 自动化进阶的必经之路。掌握了 Buffer 和 n8n 的 binary 数据结构,你就打通了处理文件、图片、音频的“任督二脉”。

如果你在实操中遇到报错,或者有更复杂的文件处理需求,欢迎来 N8N大学 (n8ndx.com) 找我。记住,别被报错吓退,那是 n8n 在教你更懂数据。

相关文章

安全加固:限制 n8n Code 节点访问文件系统与内网 IP (Sandbox 配置)
超越 SQLite:为什么生产环境必须连接 PostgreSQL 以及如何配置?
元数据获取:使用 $workflow.id 和 $execution.id 生成带追踪参数的回调链接
高并发架构:配置 Redis + n8n Worker 模式实现分布式任务处理
解决 OOM 崩溃:优化 n8n 大数据量处理时的内存占用 (Memory Leak) 技巧
多入口触发:如何让一个工作流同时支持 GET/POST 甚至多个不同路径的 Webhook?

发布评论