API вернул файл строкой Base64, а следующий узел ждёт binary. В n8n для этого есть операция Move Base64 String to File. Превратим учебную строку в настоящий TXT, прочитаем его обратно и сравним байты. На выходе будет файл, который можно скачать или передать следующему узлу.
Результат инструкции
Получим base64-demo.txt размером 19 байт с текстом «Привет, n8n!» и переводом строки в конце. Файл будет в binary.document, рядом — JSON с text и verified: true. Все действия выполняются локально; настоящие API, ключи и рабочие документы не используются. Sample Response имитирует ответ сервиса, а не вызывает его.
Base64 — способ представить байты текстовыми символами, не шифрование и не защита данных. Декодирование также не превращает произвольный файл в безопасный. Для проверки возьмём только небольшой TXT в UTF-8, без BOM и NUL. PDF, изображения и аудио требуют другого контракта проверок.
Что понадобится
- Локальный n8n и новый учебный workflow. Проверено на n8n 2.42.4, Convert to File 1.1, Extract from File 1.1 и Code 2.
- JSON-схема ниже. Платные аккаунты, токены и установленный редактор документов для преобразования не нужны.
- Текстовый редактор для ручной проверки скачанного TXT, если захотите сравнить результат вне n8n.
Установка n8n локально через Docker
Шаг 1. Импортируйте учебную схему
Скачать n8n-base64-to-file.json
Создайте новый workflow и выберите Import from File. Импортируйте JSON, сохраните схему под именем «Учебный Base64 в файл». В ней семь узлов:
Manual Trigger → Sample Response → Check Base64 → Make File → Check File → Read Text → Verify FileMake File — Convert to File, Read Text — Extract from File. Остальные рабочие узлы — Code. Схема неактивна и запускается вручную. Не вставляйте её в действующий workflow до проверки учебного результата.
Шаг 2. Проверьте имитацию ответа API
В Sample Response выберите Run Once for All Items, JavaScript. Код уже заполнен:
return [{ json: {
file_name: 'base64-demo.txt',
mime_type: 'text/plain',
file_base64: '0J/RgNC40LLQtdGCLCBuOG4hCg==',
} }];file_base64 содержит только стандартную Base64, без префикса data:, пробелов и переносов строк. В данном примере строка заканчивается на ==. Это часть её корректной записи, не мусор, который нужно удалить. У Base64 длиной, соответствующей целому числу трёхбайтовых блоков, завершающих знаков = может не быть.
| Что пришло | Как выглядит | Для этой схемы |
|---|---|---|
| Чистая стандартная Base64 | 0J/RgNC40LLQtdGCLCBuOG4hCg== | Подходит |
| Data URL | data:text/plain;base64,… | Префикс не принимается |
| Base64url | Алфавит с - и _ | Нужен отдельный разбор по контракту |
| Готовый binary | Файл уже в binary.document | Повторное декодирование не нужно |
В реальном ответе API поле может называться data или content. Сначала посмотрите фактический JSON, затем явно сопоставьте поля. Не подставляйте весь объект ответа или строку с именем файла вместо содержимого.
Шаг 3. Проверьте Base64 до преобразования
В Check Base64 оставьте Run Once for All Items и JavaScript:
const items = $input.all();
if (items.length !== 1) throw new Error('Expected one response');
const row = items[0].json;
if (Object.keys(row).sort().join('|') !== 'file_base64|file_name|mime_type' ||
row.file_name !== 'base64-demo.txt' || row.mime_type !== 'text/plain') {
throw new Error('Unexpected fields, filename or MIME');
}
const value = row.file_base64;
if (typeof value !== 'string' || value.length === 0 || value.length > 5464 ||
!/^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$/.test(value)) {
throw new Error('Expected standard padded Base64 without spaces or prefix');
}
const bytes = Buffer.from(value, 'base64');
if (bytes.length < 1 || bytes.length > 4096 || bytes.toString('base64') !== value) {
throw new Error('Invalid size or noncanonical Base64');
}
const text = bytes.toString('utf8');
if (!Buffer.from(text, 'utf8').equals(bytes) || !text.trim() ||
text.charCodeAt(0) === 0xFEFF || text.includes('\u0000')) {
throw new Error('Expected nonempty UTF-8 text without BOM or NUL');
}
return [{ json: {
file_name: row.file_name, mime_type: row.mime_type, file_base64: value,
} }];Код ждёт ровно один item и три известных поля. Имя и MIME фиксированы, чтобы из учебного примера не получился произвольный загрузчик. Проверяются алфавит, длина, расположение padding и повторное кодирование декодированных байтов. Последнее ловит записи, которые декодер принимает, но которые не являются канонической Base64.
После декодирования допустимы от 1 до 4096 байт непустого UTF-8 текста без BOM и NUL. Проверка размера применяется к полученным байтам, а не только к длине строки. Это ограничение учебной схемы, не входной лимит Webhook и не защита сервера от любых больших ответов API.
Не удаляйте пробелы и префиксы наугад, чтобы пройти проверку. Для Data URL сначала нужен явный разбор заголовка и разрешённых MIME, для Base64url — согласованное преобразование алфавита и padding. Здесь эти входные форматы намеренно отклоняются.
Шаг 4. Настройте Convert to File
Откройте Make File. Выберите Operation: Move Base64 String to File. Затем проверьте:
| Поле Make File | Значение | Что означает |
|---|---|---|
| Base64 Input Field | file_base64 | Имя JSON-поля, не сама строка |
| Put Output File in Field | document | Выходной binary-файл |
| File Name | base64-demo.txt | Имя создаваемого TXT |
| MIME Type | text/plain | Тип учебного содержимого |
В Base64 Input Field вводите file_base64, без {{ }}, $json и .data. Для этой настройки нужно имя поля. В импортированном узле Add Byte Order Mark выключен. В проверенной версии операция Base64 восстанавливает байты напрямую, а не перекодирует текст в выбранную кодировку.
В Convert to File 1.1 отдельный переключатель Data Is Base64 для этого сценария не требуется: выбранная операция уже означает декодирование Base64. Не ищите настройки из старого узла Move Binary Data и не используйте Convert to Text File: тот создал бы файл из букв Base64, а не восстановил исходные байты.
После Make File JSON может быть пустым. Это нормально: готовый файл находится в Binary, поле document. Исходные метаданные проверка ниже берёт из Check Base64.
Шаг 5. Сравните байты файла с входом
В Check File используйте Run Once for All Items, JavaScript:
const items = $input.all();
if (items.length !== 1 || Object.keys(items[0].binary ?? {}).join('|') !== 'document') {
throw new Error('Expected one file in binary.document');
}
const item = items[0];
const source = $('Check Base64').first().json;
const file = item.binary.document;
if (file.fileName !== source.file_name || file.mimeType !== source.mime_type) {
throw new Error('Filename or MIME changed');
}
const bytes = await this.helpers.getBinaryDataBuffer(0, 'document');
if (bytes.toString('base64') !== source.file_base64) {
throw new Error('File bytes differ from the Base64 input');
}
return [{ json: { bytes: bytes.length }, binary: { document: file } }];Код проверяет имя, MIME и binary.document. Затем получает реальные байты через getBinaryDataBuffer и кодирует их обратно в Base64 для точного сравнения. Это позволяет заметить потерю или изменение содержимого после Make File.
Не обращайтесь к binary.document.data как к гарантированной строке Base64. При хранении файлов на диске n8n может использовать служебную ссылку. Проверенная схема работает с binary в режиме filesystem и читает файл через helper. Рядом с binary остаётся только число bytes.
Шаг 6. Прочитайте восстановленный TXT
В Read Text задайте Operation: Extract From Text File, Input Binary Field: document, Destination Output Field: text. В Options выберите File Encoding: utf8, Strip BOM: включено, Keep Source: Both.
Both сохранит и JSON с bytes, и binary.document. Если оставить только JSON, последний узел не увидит файл для скачивания. Если оставить только Binary, потеряется число bytes. Для нашей схемы нужны оба.
На выходе появится text с кириллицей и конечным переводом строки. Нельзя читать так любой PDF или PNG: UTF-8 проверяется потому, что мы заранее договорились о TXT. MIME и расширение сами по себе не преобразуют формат содержимого.
Шаг 7. Проверьте итоговый результат
В Verify File оставьте Run Once for All Items, JavaScript:
const item = $input.first();
const source = $('Check Base64').first().json;
const expected = Buffer.from(source.file_base64, 'base64').toString('utf8');
if (typeof item.json.text !== 'string' || item.json.text !== expected ||
item.json.bytes !== Buffer.byteLength(expected, 'utf8') || !item.binary?.document) {
throw new Error('Read text, metadata or binary differs');
}
return [{
json: {
file_name: source.file_name, bytes: item.json.bytes,
text: item.json.text, verified: true, action: false,
},
binary: { document: item.binary.document },
}];Код сравнивает извлечённый текст с декодированным входом, размер и наличие binary. verified: true означает, что наша цепочка сохранила переданные байты и правильно прочитала их как UTF-8. Это не проверка смысла документа, авторства или безопасности вложения.
Важный пример: если отправитель дважды закодировал текст, после одного декодирования в TXT окажутся буквы первой Base64-строки. По байтам всё может совпасть, verified будет true. Поэтому всегда сравнивайте содержимое с ожидаемым результатом задачи, а не только с техническим статусом.
Шаг 8. Запустите схему целиком
Сохраните workflow и выполните Execute workflow от Manual Trigger. Не запускайте один Verify File без предыдущих узлов: ему нужен Check Base64 из текущего выполнения. Все семь узлов должны завершиться успешно.
Откройте JSON последнего узла. Для неизменённого примера ожидается:
{
"file_name": "base64-demo.txt",
"bytes": 19,
"text": "Привет, n8n!\n",
"verified": true,
"action": false
}Здесь 19 — размер в байтах, не количество видимых символов. В JSON перевод строки показывается как экранированная запись. В самом файле после восклицательного знака будет перевод строки. action: false означает отсутствие отправки наружу; создание файла уже произошло.
Шаг 9. Скачайте TXT и сравните содержимое
В выходе Verify File перейдите в Binary, найдите document и используйте Download. В текстовом редакторе должен быть «Привет, n8n!» с переводом строки в конце. Если вместо него видите 0J/RgNC40LLQtdGCLCBuOG4hCg==, вы записали Base64 как текст или получили двойное кодирование.
Ниже доступен образец, с которым редакция сравнила реальные байты результата. Публичное имя содержит префикс n8n, внутри workflow создаётся base64-demo.txt. Образец не заменяет запуск своей схемы.
Скачать учебный результат n8n-base64-demo.txt
Дальше файл можно использовать в узле отправки вложений, но не подставляйте реальный адрес получателя до проверки. Скачивание из редактора n8n вручную в редакционном тесте не выполнялось; проверялись наличие binary, его байты и доступность образца на сайте.
Передать готовый binary через HTTP Request
Шаг 10. Проверьте отказ на некорректном входе
В Sample Response временно замените первый символ Base64 на ! и запустите весь workflow. Check Base64 должен остановиться с Expected standard padded Base64 without spaces or prefix. Make File не должен создать новый файл в этом выполнении.
Верните исходную строку и повторите запуск: снова должны получиться 19 байт и ожидаемый текст. Не включайте Continue On Fail, Always Output Data и обработку ошибки как успех. On Error оставьте Stop Workflow.
Если Sample Response вернул ноль items, последующие узлы в нашем тесте не запустились. Отсутствие ошибки workflow не доказывает, что файл создан. Пустая строка Base64 и отсутствие items — разные случаи; оба не дают учебного файла.
Если результат отличается
| Симптом | Причина | Что проверить |
|---|---|---|
| Ошибка Check Base64 | Префикс, пробел, Base64url или повреждение | Контракт ответа и исходную строку |
| Нет binary.document | Другое имя выходного поля | Put Output File in Field: document |
| В TXT буквы Base64 | Другая операция или двойное кодирование | Move Base64 String to File и источник |
| Кириллица повреждена | Байты не UTF-8 или другое чтение | Формат TXT и File Encoding: utf8 |
| Ошибка Verify File | Потерян binary, bytes или поле text | Read Text и Keep Source: Both |
Что менять для реального API
Подключайте HTTP Request только после проверки документации сервиса: где лежит файл, какой вариант Base64 используется, какой формат и размер ожидаются. Имя файла из ответа не используйте без проверки как путь на сервере. Для других типов файлов замените текстовые проверки на соответствующие формату, а не просто снимайте ограничения.
Не вставляйте API-ключи в Code или публичный JSON workflow. Ответы, Base64 и восстановленные файлы могут сохраняться в истории n8n. Base64 не скрывает персональные данные. Настройте доступ и сроки хранения до обработки настоящих документов.
Что проверено редакцией
17 октября 2026 года публичная схема проверена на n8n 2.42.4 в отдельном Docker-экземпляре с binary на диске. Все 39 проверок прошли: исходный TXT, Unicode, CRLF, одно-, двух- и трёхбайтовый текст и граница 4096 байт; двойное кодирование как отдельная диагностика; пустой или нестроковый вход, пропущенное и лишнее поле, неверное имя или MIME, Data URL, пробел, перенос строки, неверный символ, Base64url, отсутствующий или лишний padding, неканоническая запись, превышение размера, неверный UTF-8, BOM, NUL и пустой по смыслу текст; неверные настройки источника, binary-поля, имени, MIME и чтения, потеря binary или метаданных и изменение прочитанного текста. Проверены ноль items и точные байты публичного TXT-образца. Диагностика Add BOM подтвердила, что в этой операции он не меняет декодированные байты. Двойное кодирование сохраняется как передано, без проверки замысла отправителя. Контейнер остановлен, существующие workflows не менялись. Реальные API, Cloud, клики редактора, ручное скачивание из n8n, PDF, изображения и большие файлы не тестировались. Обложка — редакционная AI-иллюстрация с отдельным коротким примером Zm9v → foo.
Частые вопросы
Base64 защищает содержимое файла?
Нет. Это обратимое представление байтов, не шифрование. Base64 с документами требует такого же контроля доступа и хранения, как сами документы.
Что вводить в Base64 Input Field?
Имя JSON-поля file_base64. Не саму длинную строку, не весь JSON и не binary.document.data.
Почему схема не принимает data:text/plain;base64,…?
Это Data URL с заголовком, а пример ждёт чистую стандартную Base64. Для Data URL нужен отдельный проверяемый разбор формата.
Можно восстановить PNG или PDF тем же узлом?
Сам узел умеет превращать Base64 в байты файла, но проверки этой инструкции рассчитаны только на UTF-8 TXT. Для PNG и PDF нужен другой контракт и соответствующая проверка содержимого.
Почему verified: true, а в файле осталась Base64?
Возможно двойное кодирование. Проверка подтверждает сохранение байтов переданного входа, но не угадывает намерение отправителя. Для нашего примера ожидается именно «Привет, n8n!».
