Що таке MIME-декодер і що означають усі ці заголовки?

Кожен лист, який ви отримуєте, насправді є текстовим документом зі суворою структурою, визначеною стандартом MIME (Multipurpose Internet Mail Extensions) і старішим форматом повідомлення RFC 5322. Коли ви відкриваєте «джерело» листа або збережений файл .eml, ця структура стає видимою: блок заголовків, порожній рядок, а далі тіло. Цей декодер розкладає будь-який вставлений лист на ці частини — заголовки, MIME-дерево, кодування передачі й charset кожної частини, декодований текст/HTML і кожне вкладення — повністю у вашому браузері. Нічого не надсилається на сервер; розбір виконується на вашому комп’ютері.

1. Загальна форма листа

Лист складається з двох секцій, розділених першим порожнім рядком:

Header-Name: значення заголовка Another-Header: інше значення (згорнутий рядок-продовження) <порожній рядок> Тут починається тіло…

Заголовки описують лист: хто надіслав, коли, тему і — що важливо для MIME — як закодовано й структуровано тіло.
Порожній рядок — це межа між заголовками й тілом. Найперший порожній рядок завершує блок заголовків.
Тіло — це все, що після нього. У сучасному листі тіло зазвичай не простий текст, а MIME-структура з кількох частин.

2. Як записуються заголовки

Дві речі спантеличують при читанні джерела:

Згортання (folding). Довгий заголовок можна розбити на кілька рядків; кожен рядок-продовження починається з пробілу або табуляції. При читанні ці рядки склеюються назад в одне значення («розгортання»).
Encoded-words (RFC 2047). Заголовки офіційно дозволяють лише ASCII, тож неанглійський текст і емодзі обгортаються як =?charset?B?…?= (Base64) або =?charset?Q?…?= (варіант quoted-printable). Наприклад, =?UTF-8?Q?caf=C3=A9?= декодується у café. Декодер вище показує читабельне значення; «сире» значення — це те, що реально йде по мережі.

3. Пояснення полів заголовків

Це змінні, які ви побачите вгорі майже будь-якого листа. Не всі присутні завжди.

Адресація та ідентичність

Заголовок	Що означає
`From`	Автор, показаний читачеві — ім’я та адреса, напр. `Anna <anna@example.com>`. Саме це відображає ваш поштовий клієнт; це не доказ того, хто справді надіслав лист (див. SPF/DKIM нижче).
`To`, `Cc`	Основні отримувачі та копія. Суто інформаційні заголовки — реальну доставку визначає SMTP-конверт, а не вони.
`Bcc`	Прихована копія. Зазвичай видаляється перед доставкою, тож у отриманій пошті ви її рідко бачите.
`Reply-To`	Куди мають іти відповіді, якщо це відрізняється від `From` (напр. відправник «no-reply», що спрямовує відповіді у підтримку).
`Return-Path`	Адреса-конверт (адреса «MAIL FROM»), куди надсилаються звіти про недоставку (bounce). Додається сервером-отримувачем і часто відрізняється від `From`.
`Sender`	Фактичний агент, що подав лист, коли це не автор (розсилки, «від імені»).
`Message-ID`	Глобально унікальний ідентифікатор цього листа, як-от `<a1b2c3@example.com>`. Використовується для гілок і усунення дублікатів.

Гілки, дати й тема

Заголовок	Що означає
`Subject`	Тема листа. Часто encoded-word, коли містить не-ASCII символи.
`Date`	Коли автор надіслав лист, зі зсувом часового поясу, напр. `Wed, 9 Jul 2026 10:15:00 +0000`.
`In-Reply-To`	`Message-ID`, на який відповідає цей лист — дозволяє клієнтам будувати гілки розмови.
`References`	Ланцюг попередніх `Message-ID` у гілці.

Маршрутизація та автентифікація

Заголовок	Що означає
`Received`	Рядок-слід, який додає кожен поштовий сервер на шляху листа, найновіший — зверху. Читаючи їх знизу вгору, бачите шлях доставки й позначки часу.
`DKIM-Signature`	Криптографічний підпис, що дозволяє отримувачу підтвердити: лист справді надіслано доменом і не змінено в дорозі.
`Authentication-Results`	Вердикт сервера-отримувача щодо перевірок SPF, DKIM і DMARC (`pass`/`fail`). Швидкий спосіб оцінити, чи можна довіряти полю «From».
`Received-SPF`	Чи вповноважений IP-відправника надсилати пошту для домену-конверта.
`List-Unsubscribe`	Для масової пошти/розсилок: адреса чи URL для відписки в один клік.

4. MIME-змінні — як побудовано тіло

Кілька цих заголовків керують усією структурою тіла. Це змінні, які найбільше цікавлять цей декодер.

Змінна	Що робить
`MIME-Version: 1.0`	Оголошує, що лист використовує MIME. Практично завжди `1.0`.
`Content-Type`	Найважливіша змінна: тип медіа частини (`text/plain`, `text/html`, `image/png`, `application/pdf`, `multipart/*`…). Несе параметри після крапки з комою.
`charset`	Параметр текстового `Content-Type`: кодування символів тексту, напр. `charset="UTF-8"`. Потрібне, щоб перетворити байти назад на правильні літери.
`boundary`	Параметр типу `multipart`: унікальний рядок-маркер. Кожна частина починається з `--boundary`, а остання завершується `--boundary--`.
`Content-Transfer-Encoding`	Як байти частини «упаковано», щоб вони пройшли як 7-бітний текст по мережі (див. таблицю нижче).
`Content-Disposition`	`inline` (показати в листі) або `attachment` (запропонувати як файл). Зазвичай несе параметр `filename`.
`name` / `filename`	Запропонована назва файлу вкладення — у `Content-Type` і `Content-Disposition` відповідно.
`Content-ID`	Ідентифікатор inline-частини (напр. зображення), щоб HTML-тіло могло послатися на неї через `cid:`.

Поширені типи multipart

multipart/alternative — той самий лист у двох формах: запасний text/plain і версія text/html. Клієнт показує найбагатшу, яку може.
multipart/mixed — тіло плюс вкладення, зібрані разом.
multipart/related — HTML-частина разом із inline-зображеннями, на які вона посилається через Content-ID.

Вони вкладаються одне в одне: реальний лист часто — це multipart/mixed, що містить multipart/alternative (текст + HTML) поряд із PDF-вкладенням. Декодер показує це як пронумероване дерево (1, 1.1, 1.2…).

5. Значення Content-Transfer-Encoding

Значення	Що означає
`7bit`	Простий ASCII, нічого не змінено. Значення за замовчуванням, коли кодування не вказано.
`8bit`	Байти понад 127 використовуються напряму (потрібен 8-bit-clean канал).
`binary`	Довільні байти без обмежень довжини рядка — рідкість у звичайній пошті.
`quoted-printable`	Здебільшого читабельний текст, де не-ASCII байти стають `=XX` у hex (а `=` у кінці рядка — м’який перенос). Добре для тексту, що переважно англійський з кількома акцентами.
`base64`	Будь-які байти перекодовані у безпечний 64-символьний алфавіт, ~на 33% більше. Використовується для зображень, PDF та інших бінарних вкладень.

Декодер обертає назад те кодування, що було використане, а потім застосовує charset частини — щоб текст повернувся читабельним, а вкладення — як їхні оригінальні байти (які можна завантажити).

6. Робочий приклад

Натисніть «Завантажити приклад» вище, щоб завантажити невеликий лист і побачити його декодованим. Його скелет має такий вигляд:

Subject: =?UTF-8?Q?Meeting_notes_=E2=80=93_caf=C3=A9?= ← encoded-word MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="OUTER" --OUTER Content-Type: multipart/alternative; boundary="INNER" --INNER Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ← текстова частина ... --INNER Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 ← HTML-альтернатива ... --INNER-- --OUTER Content-Type: text/plain; name="notes.txt" Content-Disposition: attachment; filename="notes.txt" Content-Transfer-Encoding: base64 ← вкладення ... --OUTER--

Як це читати: зовнішній тип — multipart/mixed, тож тіло — це «вміст + вкладення». Його перша дитина — multipart/alternative з простим текстом і HTML-версією тієї самої нотатки; друга дитина — вкладення notes.txt. Subject — це encoded-word, що декодується у «Meeting notes – café».

7. Приватність

Усе лишається на вашому пристрої. Цей інструмент розбирає лист за допомогою JavaScript у вашому браузері — сирий лист ніколи не надсилається ні нам, ні комусь іще, і нічого не зберігається. Ви можете безпечно переглядати приватні чи чутливі листи.

Коли ви знаєте, з якого сервера прийшов лист, можна копнути глибше: перегляньте MX Lookup домену, прочитайте, як відповідає сервер, у довіднику SMTP-перевірка через telnet, або перевірте, чи адреса приймає пошту, через Перевірка Email.