RFC 2047: MIME パート 3 — 非 ASCII テキスト用メッセージヘッダ拡張

Standards Track MIME — Multipurpose Internet Mail Extensions Published March 2026

ELI5: メールのSubjectやFromなどのヘッダーはプレーンASCII（英字と基本的な句読点）に限定されています。RFC 2047は、Subjectラインをアルファベットでなく日本語で書く、送信者名をアラビア語で書く、またはフランス語の名前をアクセント記号付きで書くことを可能にする工夫です。非ASCII文字をメールサーバーがどれでも転送できるASCIIセーフなラッパーにエンコードし、メールクライアントが表示用にそれをデコードします。

これが存在する理由

RFC 2045とRFC 2046はメッセージ本文でASCII以外のコンテンツを転送する問題をContent-Transfer-Encodingで解決しました。しかしメールヘッダー（Subject、From表示名、To表示名など）はRFC 5322によって管理され、7ビットUS-ASCIIに制限されています。

これは明らかな問題を生じます。数十億のメールユーザーがASCII以外の文字を必要とする言語で書きます。RFC 2047なしでは、以下を含むメールを送信できません。

中国語、日本語、韓国語、アラビア語、ヘブライ語、またはタイ語のSubjectライン
アクセント付き文字を含む送信者表示名（René、Müller、Björk）
ASCII範囲外の文字を含むヘッダーフィールド

RFC 2047はASCIーのみのヘッダー内にASCII以外のテキストを埋め込むコンパクトな方法であるencoded-word構文を定義します。これはMIME対応のメールクライアントで読み取り可能です。

動作原理

Encoded-Word形式

Encoded-wordは以下の構造を持ちます。

=?charset?encoding?encoded-text?=

3つのコンポーネントは以下の通りです。

コンポーネント	目的	値
`charset`	元のテキストの文字セット	`UTF-8`、`ISO-8859-1`、`ISO-2022-JP`など
`encoding`	テキストをASCIIにエンコードする方法	`B`（base64）または`Q`（quoted-printableバリアント）
`encoded-text`	エンコードされた表現	ASCII文字のみ

Bエンコーディング（Base64）

標準base64エンコーディングを使用します。CJKスクリプトなどASCII以外が大部分のテキストに最適です。

; Subject: 日本語の「Meeting confirmation」
Subject: =?UTF-8?B?5Lya6K2w44Gu56K66KqN?=

; From表示名（中国語）
From: =?UTF-8?B?5byg5LiJ?= <zhang@example.com>

Qエンコーディング（Quoted-Printableバリアント）

ヘッダー用に最適化された修正quoted-printableエンコーディング。本文QP同様、ASCII以外のバイトは=XX16進数ペアになります。主な違い：スペースはアンダースコア（_）としてエンコードされます。

; Subject: アクセント付きeを含む「Café menu」
Subject: =?UTF-8?Q?Caf=C3=A9_menu?=

; From表示名：「René Dupont」
From: =?UTF-8?Q?Ren=C3=A9_Dupont?= <rene@example.com>

; Subject: 「Gruße aus Berlin」（ドイツ語の挨拶）
Subject: =?UTF-8?Q?Gru=C3=9Fe_aus_Berlin?=

QエンコーディングはほとんどのテキストがASCIIでわずかなASCII以外の文字のみの場合に人間が読める形式です。Bエンコーディングはほとんどの文字がASCII以外の場合により圧縮されています。

Encoded-Wordが使用可能な位置

Encoded-wordはヘッダー内の特定の位置で使用可能です。

Subject、Comments、Keywords：テキストが期待される任意の場所（atomまたはquoted-stringの置換として）。
From、To、Cc、Bcc、Reply-To、Sender：表示名部分のみで、メールアドレス自体には使用できません。
Content-Description：MIMEパーツの説明に使用可能です。

Encoded-wordはquoted-string内、メールアドレスのlocal-partまたはドメイン内、Content-Typeなどの構造化ヘッダーのパラメータ値内では使用できません（その場合はRFC 2231を使用します）。

主要な技術的詳細

長さの制限

各encoded-wordは75文字を超えてはいけません。エンコードされたテキストが長い場合、折り畳み空白（CRLF+スペースまたはタブ）で区切られた複数のencoded-wordに分割する必要があります。

; 2つのencoded-wordに分割された長いSubject
Subject: =?UTF-8?B?5LuK5pel44Gu5Lya6K2w44Gr44Gk44GE44Gm?=
 =?UTF-8?B?44GU5qGI5YaF44GE44Gf44GX44G+44GZ?=

隣接する2つのencoded-wordが線形空白のみで区切られている場合、それらの間の空白はデコード時に無視されます。これにより、長いテキストを複数のencoded-wordにシームレスに分割できます。

文字セットの選択

新しいメッセージには常にUTF-8を使用してください。他の文字セットはレガシー上の理由で存在します。

文字セット	使用例	推奨
`UTF-8`	すべてのUnicode文字をカバー	常にこれを使用する
`ISO-8859-1`	西ヨーロッパレガシー	新しいメッセージでは使用しないでください
`ISO-2022-JP`	日本語レガシーエンコーディング	一部の日本のメールクライアントからまだ見られます
`GB2312`	簡体字中国語レガシー	新しいメッセージでは使用しないでください

ヘッダー折り畳みとの相互作用

RFC 5322はヘッダーラインを998文字に制限し、78以下に保つことを推奨しています。Encoded-wordは折り畳みと相互作用します。空白境界でencoded-word間で改行できますが、encoded-word内で改行してはいけません。=?...?=ラッパー全体は1行に収まる必要があります。

デコードルール

メールクライアントがencoded-wordに遭遇するとき、以下を行います。

=?charset?encoding?text?=ラッパーから文字セット、エンコーディングタイプ、エンコードされたテキストを抽出します。
base64（B）またはquoted-printable（Q）を使用してテキストをデコードします。
結果のバイトを宣言された文字セットに従って解釈します。
デコードされたUnicodeテキストをユーザーに表示します。

クライアントが文字セットを認識しない場合、文字化けしたテキストを表示するのではなく、encoded-wordをそのまま表示する必要があります。

例

エンコードされたヘッダーを含む完全なメッセージ

MIME-Version: 1.0
From: =?UTF-8?Q?Ren=C3=A9_Dupont?= <rene@example.fr>
To: =?UTF-8?B?5bGx55Sw5aSq6YOO?= <yamada@example.jp>
Subject: =?UTF-8?Q?Re:_R=C3=A9union_du_15_mars?=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Bonjour Taro,

Confirmons la r=C3=A9union pour le 15 mars.

注意：ヘッダーはRFC 2047 encoded-word（=?...?=）を使用しますが、本文は通常のquoted-printableエンコーディング（ラッパーなしの=XX）を使用します。これらはメッセージの異なる部分用の異なるメカニズムです。

エンコーディング比較

同じテキスト「München」を両方でエンコードします。

; Qエンコーディング：読める形式で、ほぼASCIIテキストに最適
=?UTF-8?Q?M=C3=BCnchen?=

; Bエンコーディング：コンパクトだが不透明
=?UTF-8?B?TcO8bmNoZW4=?=

一般的な誤り

メールアドレス自体をエンコードする。表示名のみをエンコードできます。=?UTF-8?Q?user?=@example.comは無効であり、拒否または誤解釈されます。国際化されたメールアドレスの場合はRFC 6531/6532を参照してください。
Encoded-wordと通常のテキスト間のスペースを失う。Encoded-wordは隣接するテキストから空白で区切る必要があります。Hello=?UTF-8?Q?World?=は形式が間違っています。Hello =?UTF-8?Q?World?=である必要があります。
Encoded-wordを行にまたがって改行する。全体の=?...?=トークンは1行に収まる必要があります。折り畳み必要な場合は、単語の境界で複数のencoded-wordに分割してください。
Content-Typeパラメータでrfc 2047を使用する。Encoded-wordはfilename=やname=などの構造化ヘッダーパラメータでは有効ではありません。filename*=UTF-8''R%C3%A9sum%C3%A9.pdfのようにRFC 2231パラメータエンコーディングを使用してください。
75文字の制限を超える。各encoded-wordは75文字以下である必要があります。長いテキストは複数のencoded-wordに分割する必要があります。サイズ超過のencoded-wordはメールサーバーで無音で切り詰められる可能性があります。
二重エンコーディング。既にエンコードされたテキストをエンコードすると、=?UTF-8?Q?=3D=3FUTF-8=3FQ=3F...?=のようなガベージが生成されます。エンコーディングパイプラインが正確に1回実行されることを確認してください。

配信可能性への影響

不正確なエンコーディングはスパムフィルターをトリガーします。Subjectラインの形式が間違ったencoded-wordは赤信号です。スパムフィルターはスパムツールから数十年の不正なエンコーディングを見てきました。クリーンで標準に準拠したエンコーディングは正当な送信ソフトウェアを表します。
表示名エンコーディングは信頼に影響します。From表示名にASCII以外の文字が含まれていても適切にエンコードされていない場合、受信者は読める名前の代わりに生の=?UTF-8?Q?...?=テキストを見ます。これは疑わしく見え、開封率を傷つけます。
Subject行のレンダリングはエンゲージメントに重要です。エンコーディングの誤りまたは文字セット間違いによる文字化けしたSubjectラインは、受信者がそれを読むことができないことを意味します。メールは無視されるかスパムとして報告されます。
常にUTF-8を使用してください。ISO-8859-1などのレガシー文字セットはすべての文字を表現できません。システムが異なるヘッダー全体で文字セットを混在させる場合、クライアントはいくつかは正しく表示し、他は文字化けで表示する可能性があります。すべてでUTF-8に標準化してください。
クライアント全体でテストしてください。Outlook、Gmail、Apple Mail、Thunderbirdはすべて、特に長いencoded-wordや単一ヘッダー内のエンコーディング/非エンコーディング混在などのエッジケースについて、RFC 2047デコーディング動作が少しずつ異なります。