MIMEデコーダーとは何か、そしてこれらのヘッダーはすべて何を意味するのか？

あなたが受け取るすべてのメールは、その内側では、MIME（Multipurpose Internet Mail Extensions）と、より古い RFC 5322 メッセージ形式によって定められた厳密な構造に従うプレーンテキストの文書です。「生ソース」や保存された .eml ファイルを開くと、その構造が見えてきます。ヘッダーのブロック、空行、そして本文です。このデコーダーは、貼り付けられたメッセージをこれらの要素に分解します — ヘッダー、MIME ツリー、各パートの転送エンコーディングと charset、デコードされた text/HTML、そして各添付ファイル — すべてお使いのブラウザ内で行います。サーバーには何もアップロードされず、解析はあなた自身のコンピューター上で実行されます。

1. メッセージ全体の形

メッセージは、最初の空行で区切られた 2 つのセクションからなります。

Header-Name: header value Another-Header: another value (a folded continuation line) <blank line> The body starts here…

ヘッダーはメッセージについて記述します。誰が、いつ送ったか、件名、そして — MIME にとって決定的に重要なのが — 本文がどのようにエンコードされ、構造化されているかです。
空行はヘッダーと本文の境界です。最初の空行がヘッダーブロックを終わらせます。
本文はその後のすべてです。現代のメッセージでは、本文は通常プレーンテキストではなく、複数のパートを持つ MIME 構造です。

2. ヘッダーの書かれ方

生ソースを読むときに人がつまずくルールが 2 つあります。

折りたたみ（folding）。長いヘッダーは複数行に分割できます。各継続行はスペースまたはタブで始まります。読み取るときには、これらの行は 1 つの値に再び結合されます（「展開」）。
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」アドレス）。受信サーバーによって追加され、しばしば `From` と異なります。
`Sender`	メッセージを実際に投函したエージェントが作成者でない場合のそれ（メーリングリスト、「代理送信」）。
`Message-ID`	このメッセージのグローバルに一意な識別子。`<a1b2c3@example.com>` のような形式です。スレッド化と重複排除に使われます。

スレッド化、日付、件名

ヘッダー	意味
`Subject`	件名の行。非 ASCII 文字を含む場合は、しばしば encoded-word になります。
`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`	インラインパート（例：画像）の識別子。HTML 本文が `cid:` でそれを参照できるようにします。

よくある multipart タイプ

multipart/alternative — 同じメッセージの 2 つの形式：フォールバックの text/plain と text/html バージョン。クライアントは表示できる最もリッチなものを表示します。
multipart/mixed — 本文と添付ファイルをまとめたもの。
multipart/related — HTML パートと、それが Content-ID で参照するインライン画像を合わせたもの。

これらは入れ子になります。実際のメッセージはしばしば、multipart/alternative（テキスト + HTML）を PDF 添付ファイルの隣に含む multipart/mixed です。デコーダーはこれを番号付きのツリー（1、1.1、1.2…）として表示します。

5. Content-Transfer-Encoding の値

値	意味
`7bit`	プレーン ASCII で、何も変更されません。エンコーディングが指定されないときのデフォルトです。
`8bit`	127 を超える生のバイトが直接使われます（8-bit-clean な経路が必要）。
`binary`	任意のバイトで、行長の制限がありません — 通常のメールではまれです。
`quoted-printable`	ほぼ読めるテキストで、非 ASCII バイトは `=XX`（16 進数）になります（行末の `=` はソフト改行）。ほとんど英語でわずかにアクセント記号があるテキストに適しています。
`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 なので、本文は「コンテンツ + 添付ファイル」です。その最初の子は、同じメモのプレーンテキスト版と HTML 版を保持する multipart/alternative です。2 番目の子は notes.txt の添付ファイルです。Subject は encoded-word で、「Meeting notes – café」にデコードされます。

7. プライバシー

すべてはあなたのデバイス上にとどまります。このツールは、お使いのブラウザ内の JavaScript でメッセージを解析します — 生のメールが当サイトや他の誰かに送られることは決してなく、何も保存されません。プライベートな、あるいは機微なメッセージも安全に調べることができます。

メッセージがどのサーバーから来たかがわかったら、さらに掘り下げられます。ドメインの MX検索を調べたり、サーバーがどう応答するかを telnetによるSMTPチェックガイドで読んだり、アドレスが配信可能かどうかをメールチェッカーで確認したりできます。