そもそも添付ファイル名の規約ってRFCでどうなってるの？

Outlookから送ったメールの添付ファイル名が、iPhoneで「=?utf-8?Q?...?=」と無残に文字化けしてしまう現象。その元凶を紐解くと、1990年代から続く「RFC規格のねじれ」と、Microsoftによる「独自の割り切り」という深い闇に突き当たります。

前回の検証記事（Outlookのエンコード選択 / iPhoneでの5nの法則）を補完する形で、そもそもRFC（インターネット標準）では添付ファイル名がどう定義されているのかを解説します。

1. 添付ファイル名を定義する「RFC 2183」

メールにファイルを添付する際、ヘッダーには Content-Disposition というフィールドが使われます。これを定義しているのがRFC 2183です。

Content-Disposition: attachment; filename="example.txt"

ここで重要なのは、このRFC 2183が制定された1997年当時、filenameパラメータには「7bitのASCII文字（英数字）」しか想定されていなかったという点です。日本語などのマルチバイト文字をどう扱うかは、この規格内には書かれていません。

2. 日本語対応の救世主「RFC 2231」

そこで、ファイル名に日本語を使ったり、長すぎる名前を分割したりするために作られたのがRFC 2231です。これが現在、世界標準の「正しい作法」です。

• 特徴： filename*=utf-8''%... という形式を使い、文字コードを明示する。
• 利点： ヘッダーの文法を壊さずに、安全に非ASCII文字を伝送できる。

3. なぜ問題が起きるのか？ ― Outlookの「不採用」

ここが最大のポイントですが、デスクトップ版のOutlook（2019等を含む）は、この「正しい作法（RFC 2231）」を頑なに採用していません。

代わりにOutlookが何をしているかというと、本来はメールの件名（Subject）などに使うための規格であるRFC 2047（Encoded-Word）を、添付ファイル名のパラメータの中に無理やり流用しているのです。

【Outlookの非標準な挙動】
Content-Disposition: attachment; filename="=?utf-8?B?...?=" (Base64形式)
Content-Disposition: attachment; filename="=?utf-8?Q?...?=" (Quoted-Printable形式)

※RFC 2047の仕様書には「このエンコードをパラメータ（quoted-string）内で使ってはいけない」と明記されているため、これは明確なRFC違反です。

4. iPhone（iOS Mail）の孤独な抵抗

受信側のiPhoneは、本来この「違反」を無視しても構わない立場です。しかし、あまりにOutlookユーザーが多いため、iPhone側で「救済措置」を入れています。

• Base64（?B?）の場合： Appleが「まあ、Outlookの仕業だな」と判断してデコードしてくれるため、正しく表示される。
• Quoted-Printable（?Q?）の場合： Appleのパーサーがこれをエンコードと見なさず、ただの文字列として扱う。結果、iPhoneの画面にはデコード前の無残な生コードが表示される。

まとめ：ユーザーが踏む地雷の正体

検証記事で明らかになった「5n文字」などの特定の条件下でOutlookがQエンコードを選んでしまう挙動は、まさにこの「標準を無視する送信側（Outlook）」と「中途半端に救済を拒む受信側（iPhone）」のデッドロックによって引き起こされています。

根本解決は「OutlookがRFC 2231に対応すること」なのですが、四半世紀放置されている現状を鑑みると、私たちはこの「RFCのねじれ」と付き合い続けるしかなさそうです。