Вкладення електронної пошти в n8n: практика збереження та звіряння файлів
Практикуйте обробку поштових вкладень у власному n8n через IMAP: окремі записи файлів, стійкі до колізій шляхи та ручне звіряння.
Перевірено за наведеними джерелами .
Ваша вправа з поштовими вкладеннями в n8n
Створіть робочий процес, який отримує тестові повідомлення, зберігає поштові вкладення n8n у дозволену папку й фіксує, які вкладення ще потребують уваги. Це редакційна вправа: запропонований робочий процес не запускали й не перевіряли. Її межі — тимчасова поштова скринька та ручне відновлення тестових даних.
Використовуйте Email Trigger (IMAP) з обліковими даними IMAP і форматом вихідних даних Resolved, який, за документацією, містить двійкові вкладення. Змінювана реалізація n8n у гілці master описує це для версій вузла 2, 2.1 і 2.2. Документація без дати та змінювані гілки реалізації можуть відрізнятися від установленого у вас випуску.
На нашу думку, обробку вкладень варто практикувати як завдання зі звіряння записів, адже отримане повідомлення та завершене збереження відповідають на різні запитання.
Sources: n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.emailimap.md at main · n8n-io/n8n-docs · GitHub, n8n/packages/nodes-base/nodes/EmailReadImap/v2/EmailReadImapV2.node.ts at master · n8n-io/n8n · GitHub
Підготуйте скриньку, папку та записи
Підготуйте n8n на власному сервері, тимчасову скриньку IMAP, робочі облікові дані та абсолютний шлях призначення з правом запису. Для n8n на власному сервері, починаючи з версії 2.0, задокументоване обмеження доступу до файлів за замовчуванням дозволяє ~/.n8n-files. Шляхи Docker стосуються файлової системи контейнера; налаштуйте монтування тому для каталогу хоста й перевірте конфігурацію дозволених каталогів у встановленій версії.
Перш ніж створювати робочий процес, створіть Data Tables із запропонованими нижче стовпцями. Журнал вкладень використовує задокументовані операції upsert, отримання та оновлення; назви цих стовпців — редакційна пропозиція.
| Таблиця | Стовпці | Призначення |
|---|---|---|
| receipts | test_case_id, received, attachment_count | Зберігати видимість кожного тестового повідомлення |
| attachments | attachment_key, test_case_id, ordinal, original_name | Ідентифікувати кожне вкладення |
| attachments | intended_path, status, error, attempt_count | Відстежувати збереження та звіряння |
Sources: Read/Write Files from Disk | Nodes | n8n Docs, skills/skills/n8n-data-tables-official/references/OPERATIONS.md at main · n8n-io/skills · GitHub
Розгорніть повідомлення в окремі елементи вкладень
Для вправи із завантаження поштових вкладень у n8n надішліть штучно створені повідомлення з явно заданими унікальними ідентифікаторами тестових випадків. Використайте запропоновані набори тестових даних і запишіть очікувані назви вкладень, перш ніж щось запускати.
| Випадок | Вкладення |
|---|---|
| EMPTY | Немає |
| SINGLE | Один штучно створений файл |
| MULTI | Кілька штучно створених файлів |
| REPEAT | Два файли з назвою report.txt |
Перевірте фактичні двійкові властивості у вихідних даних Resolved. Відповідь у n8n Community за 2025 рік про Gmail показує, як не повертати елементи вкладень за відсутності двійкових даних і як перетворювати двійкові властивості на окремі елементи. Адаптація цього підходу до IMAP — редакційна пропозиція: приберіть фільтр розширень, збережіть метадані повідомлення й розмістіть у кожному вихідному елементі одне вкладення в однаково названому двійковому полі, наприклад attachment.
Створіть запис про отримання перед розгортанням, щоб порожня гілка не приховала випадок без вкладень. Для листів n8n із кількома вкладеннями призначте кожному тестовому вкладенню записаний порядковий номер і зберігайте це призначення під час підготовки наступної спроби. Після збереження набору REPEAT вручну надішліть його незмінений вміст повторно з початковим ідентифікатором тестового випадку та порядковими номерами вкладень, щоб відпрацювати перевірку наявного запису.
Sources: n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.emailimap.md at main · n8n-io/n8n-docs · GitHub, Getting only the correct attachment - Questions - n8n Community
Виберіть стабільні ключі та зафіксуйте заплановані збереження
Використайте цю запропоновану послідовність для іменування та збереження поштових вкладень у n8n. Вузол Crypto підтримує хешування SHA256; Read/Write Files from Disk потребує шляху призначення та вхідного двійкового поля. Змінювана реалізація запису на диск у гілці master n8n використовує прапорці усічення файлу, коли Append вимкнено, тому повторне використання шляхів призначення створює ризик перезапису файлів.
- Сформуйте ключ вкладення з призначеного ідентифікатора тестового випадку та записаного порядкового номера.
- Знайдіть цей ключ перед зміною його стану в журналі. Кожен наявний запис спрямовуйте на звіряння, перш ніж дозволяти наступний запис файлу.
- Для нового ключа обчисліть хеш SHA256; використайте хеш і контрольоване розширення в межах дозволеної папки.
- Для нового запису виконайте upsert ключа, метаданих, запланованого шляху, статусу pending і значення attempt_count, рівного нулю. Під час відновлення зберігайте наявні шляхи та лічильники, окрім виправлення навмисно некоректного шляху призначення.
- Вимкніть автоматичні повторні спроби для вузла запису на диск у цій вправі. Безпосередньо перед кожним явним викликом запису вкладення збережіть статус pending і один раз збільште attempt_count цього запису; зупиніться, якщо оновлення не вдалося. Отримання, пошук, порівняння та пропущені записи файлів не збільшують лічильник.
- Запишіть двійкове поле вкладення за збереженим шляхом призначення з вимкненим Append.
- Після успіху оновіть відповідний запис до saved; спрямуйте окремий вихід помилок на запис статусу needs-another-attempt і подробиць помилки.
Наприклад, ключ REPEAT:1 перетворюється на базове ім’я SHA256 із контрольованим розширенням .txt у дозволеній папці. REPEAT:2 утворює окремо обчислений шлях призначення, хоча початкова назва файлу та сама. Збережіть вибраний шлях і повторно використовуйте його під час відновлення. Це іменування, стійке до колізій, а не дедуплікація, що виключає колізії чи безпечно працює за одночасного виконання.
На нашу думку, у цій вправі початкові назви файлів слід зберігати в метаданих; якщо дозволити їм визначати шляхи у файловій системі, це відволікатиме від логіки відновлення, яку ще належить з’ясувати.
Sources: n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.readwritefile.md at main · n8n-io/n8n-docs · GitHub, n8n/packages/nodes-base/nodes/Files/ReadWriteFile/actions/write.operation.ts at master · n8n-io/n8n · GitHub, n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.crypto.md at main · n8n-io/n8n-docs · GitHub, skills/skills/n8n-data-tables-official/references/OPERATIONS.md at main · n8n-io/skills · GitHub, skills/skills/n8n-error-handling-official/SKILL.md at main · n8n-io/skills · GitHub
Звірте незавершені записи перед наступною спробою
Отримайте записи зі статусами pending і needs-another-attempt. У цій редакційній процедурі звіряння перевіряйте кожен очікуваний файл перед повторним записом: файл може існувати, навіть якщо оновлення статусу не вдалося. Порівняйте його байти зі збереженим штучним вкладенням. Якщо вони збігаються, позначте запис як saved без перезапису файлу чи збільшення attempt_count. Якщо файлу немає, вручну відновіть вкладення та повторіть спробу через послідовність запису з перевірками. Збережіть файл, вміст якого не збігається, зафіксуйте розбіжність і залиште вкладення позначеним як таке, що потребує уваги для розслідування.
Під час повторної обробки застосовуйте цю перевірку також до наявних записів saved, перш ніж виконувати будь-який upsert зі статусом pending або запис файлу. Пов’язуйте помилки з ключем вкладення, не припускаючи, що вихід помилок зберігає всі початкові поля. Для складених фільтрів журналу явно задавайте AND; довідка попереджає, що в деяких версіях за замовчуванням використовується OR, а оновлення без відповідних записів нічого не змінює.
Лист позначається прочитаним, коли n8n його отримує, тому статус непрочитаного не може підтвердити завершення збереження файлу. У змінюваній реалізації IMAP у гілці master n8n версії вузла 2.1 і новіші пропонують Fetch Only New Emails на основі останнього запуску; залишення повідомлення непрочитаним не забезпечує повторної обробки. Відновіть двійкові дані зі збереженого тестового листа або вручну надішліть тестовий набір повторно з його початковим ключем тестового випадку.
Ця схема не забезпечує ні доставки рівно один раз, ні атомарної координації між файлами й оновленнями журналу. Ця вправа не надає автоматичної повторної обробки зі стійким збереженням даних або гарантії збереження повідомлень.
Sources: n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.readwritefile.md at main · n8n-io/n8n-docs · GitHub, skills/skills/n8n-data-tables-official/references/OPERATIONS.md at main · n8n-io/skills · GitHub, skills/skills/n8n-error-handling-official/SKILL.md at main · n8n-io/skills · GitHub, n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.emailimap.md at main · n8n-io/n8n-docs · GitHub, n8n/packages/nodes-base/nodes/EmailReadImap/v2/EmailReadImapV2.node.ts at master · n8n-io/n8n · GitHub
Перевірте завершення та поясніть, яка прогалина залишається
Використовуйте цей редакційний контрольний список як критерії завершення вправи з поштовими вкладеннями в n8n, а не як перевірену систему оцінювання.
Якщо якась перевірка не пройдена, перевірте облікові дані та вибір скриньки, фактичні назви двійкових полів, дозволені каталоги, монтування Docker і відповідність фільтрів журналу. Для осмислення поясніть, як ви відрізнили б відсутній файл від завершеного запису файлу, після якого не вдалося оновити журнал, і які докази виправдали б зміну його статусу.
Sources: n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.emailimap.md at main · n8n-io/n8n-docs · GitHub, n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.readwritefile.md at main · n8n-io/n8n-docs · GitHub, Read/Write Files from Disk | Nodes | n8n Docs, skills/skills/n8n-data-tables-official/references/OPERATIONS.md at main · n8n-io/skills · GitHub, skills/skills/n8n-error-handling-official/SKILL.md at main · n8n-io/skills · GitHub
