そもそも添付ファイル名の規約って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のねじれ」と付き合い続けるしかなさそうです。

今日こそ終止符！iPhoneの標準メーラーで添付ファイル名が文字化けする原因とその対応

OutlookからiPhoneにメールを送ると、添付ファイル名が =?UTF-8?Q?...?= と化ける問題。長年「相性の問題」で片付けられてきたこの怪奇現象に、休日の半日を潰してトドメを刺してきました。

1. 境界線の発見：「5Nの法則」

実験の結果、ファイル名に日本語（非ASCII）が混じっている場合、ある一定の条件でエンコード方式が切り替わることが分かりました。それが以下の「5Nの法則」です。

5Nの法則：
非ASCII文字を N 個含むとき、ASCII文字（英数字）が 5N 個に達した瞬間にiPhoneで文字化けが発生する。

非ASCII数 (N)	Base64限界 (ASCII)	文字化け発動 (ASCII)
1文字 (あ)	4文字	5文字以上
2文字 (あい)	9文字	10文字以上
3文字 (あいう)	14文字	15文字以上

この法則はUTF-8だけでなく、欧州圏の iso-8859-1 (Latin-1) でも全く同様に発動しました。

2. なぜ「5」なのか？数学的背景

Outlookはメールヘッダーを1バイトでも節約しようと、以下の2つのエンコードを動的に使い分けています。

• MIME-B (Base64): 全体を1.33倍にする。
• MIME-Q (Quoted-Printable): 英数字はそのまま、非ASCIIを =XX 形式にする。

Latin-1の1バイト文字 Á を例にとると、Qエンコードでは =C1 (3バイト) に膨らみます。計算すると、英数字が5文字を超えたあたりで、全体をBase64で包むよりも、英数字をそのまま送れるQエンコードの方がヘッダーサイズが短くなるのです。Outlookの「ケチな最適化」がこの「5」という数字を生んでいます。

3. 犯人は誰だ？PHPによる「パケット偽装」実験

「Outlookが生成するQエンコードが悪いのか、それともiPhoneが悪いのか」を特定するため、以下の検証スクリプトを作成しました。意図的に添付ファイル名をQエンコードで送りつける「嫌がらせ」コードです。

// --- 検証用添付ファイルパート抜粋 ---
switch ($attachment_type) {
    case "B": // RFC 2047 Base64
        $filename_encoded = mb_encode_mimeheader($filename, "UTF-8", "B");
        $head = "Content-Type: application/octet-stream; name=\"{$filename_encoded}\"\r\n";
        $head .= "Content-Disposition: attachment; filename=\"{$filename_encoded}\"\r\n";
        break;
    case "Q": // RFC 2047 Quoted-Printable
        $filename_encoded = mb_encode_mimeheader($filename, "UTF-8", "Q");
        $head = "Content-Type: application/octet-stream; name=\"{$filename_encoded}\"\r\n";
        $head .= "Content-Disposition: attachment; filename=\"{$filename_encoded}\"\r\n";
        break;
    default: // RFC 2231 (モダンな形式)
        $head = "Content-Type: application/octet-stream;\r\n";
        $head .= "Content-Disposition: attachment; filename*=UTF-8''" . rawurlencode($filename) . "\r\n";
}

検証結果

• To/FromヘッダーのQエンコード： iPhoneでも正常表示。
• 添付ファイル名のQエンコード： iPhoneで文字化け確定。

驚くべきことに、iPhoneはQエンコードそのものが解釈できないわけではありません。「ヘッダー（宛先など）なら読めるが、添付ファイル名の場所にあるQエンコードだけは無視する」という、極めて偏った実装をしていたのです。

4. 結論：我々が取るべき自衛策

Outlook先輩が「1バイトでも削って効率化しよう（Qを使おう）」とした善意が、iPhoneの「そこはBase64かRFC2231しか読まないよ」という偏食によって仇となる。これがこの問題の正体です。

現状、現場のエンジニアができる唯一の対策は、「英数字が5の倍数に達する前に、全角文字を1文字追加して、OutlookにBase64を強制させる」という、泥臭いファイル名ハックのみです。

もし、あなたの周りでファイル名が化けて困っている人がいたら、そっと「全角文字をもう一文字増やしてみて」と伝えてあげてください。

そして、欧州のお友達には、逆に「非ASCII文字を添付ファイル名に使わないで！」と教えてあげてください。

Outlookは添付ファイル名をMIME-BエンコードするときとMIME-Qエンコードするときがある ～ OutlookでUTF-8を使ったら、iPhoneの標準メーラーで添付ファイル名が文字化けした話 ～

Outlook で Unicode (UTF-8) を使うときのお話として聞いてね。

あ、良かったらこちらもどうぞ

【Outlookで自動改行させないための設定　～もういい加減 UTF-8 / base64 でよくね？～】

https://chibitcpu.blogspot.com/2025/12/outlook.html

RFCも絡めてまとめてみたので、サクッと対応したい人はこちら

【今日こそ終止符！iPhoneの標準メーラーで添付ファイル名が文字化けする原因とその対策】

https://chibitcpu.blogspot.com/2026/03/outlook-iphone-filename-encoding-5n.html

さて・・・

 iPhoneの標準メーラーで添付ファイル名が文字化けした。（正確には「復号してくれなかった」）

=?utf-8?Q?....

今までと同じ方法でファイルを添付して送っていたのに、なぜか表示されない。

そこで、表示できるときとできないときの違いを知りたくて、メールのソースを表示してみた。

すると

■ 表示できる方

filename="=?utf-8?B?..."

■ 表示できない方

filename="=?utf-8?Q?..."

できる方は 「B」エンコーディング (Base64)、できない方は 「Q」エンコーディング (Quoted-Printable っぽいやつ) だった。

おいおい、なんで違うんだよって思って、Copilotに聞いてみた。

Q. Outlook2019を使っています。ファイル名に日本語を含む添付ファイルを送るとき、ファイル名が「B」エンコーディングされるときと、「Q」エンコーディングされるときがあります。「B」エンコーディングで固定したいのですが、どうすればいいですか？

A. 結論から言うと、Outlook 2019 では添付ファイル名の符号化方式をユーザー側で固定する設定は存在しません。これは仕様であり、Outlook が内部ロジックに基づいて自動的に選択しているためです。ただし、どのような条件で 「B」/「Q」が選ばれるのかは不明です。ただ 、「B」エンコーディング に“寄せる”ために現実的にできる対策があります。

まじかよ。仕様かよ。

Base64に「寄せるため」には、日本語を多めにしろだって。

【2026.3.3 】

Outlookのエンコード仕様を確認したくて、ファイル名を変えながら添付して送って調べてみた。

漢字1文字(3バイト)：半角5文字(5バイト)以上の比率だと「Q」エンコーディング 、未満だと「B」エンコーディングだった。

Quoted-Printableより、Base64の方が短い（エンコード後のバイト数が少ない）んだけど…なんでだろ

エンコードマニアックス

【2026.3.4　その1】

おもしろそう。あとで読もうっと。

MIMEの基礎

【2026.3.4　その2】

おぉ、そういうことか。日本人にしてみたら謎の（Base64の方がバイト数が少ないのに、なんでバイト数が増えるQuoted-Printableを使うの？）変換ルールは、ヨーロッパ系文字にあわせた仕様だったのね。

MIME - quoted-printable

添付ファイル名について調べてみた限り、Outlook の 「送信メッセージで優先使用するエンコード方法」による違いはこうだった。

・日本語 (JIS)　⇒　「B」エンコーディング

・日本語 (JIS 1 バイト カタカナ可)　⇒　「B」エンコーディング

・日本語 (シフト JIS)　⇒　「B」エンコーディング

・Unicode (UTF-8)　⇒　変換ルール

日本語は「B」エンコーディング (Base64) の方が効率いいけど、多言語も扱うUnicode(UTF-8)は変換ルールが採用されるようだ。

【2026.3.4　その3】

BとQの境界線を調べたよ。Copilotの回答にあった「内部ロジック」の正体はこれだった。

■ Outlookの添付ファイル名変換ルール

B ＜ 5N ≦ Q　※ Nは非ASCII文字数。

ちなみに UTF-8 だけかと思ったけど、Latin-1 もこのルールだったよ。結局、こういうことだった。

～ Geminiの回答 ～

『「UTF-8（マルチバイト）」でも「Latin-1（シングルバイト）」でも共通して 5N だったのは、結局のところ 「8ビット目のフラグが立っている文字（= 非ASCII文字）を、いかに効率よく7ビットの網（メールサーバー）に通すか」 という、1970〜80年代から続くメールの基本設計に由来していたわけです。』

文字エンコード方法とOSのロケールの両方を見て、BとQのどっちが効率いいか判断してもらえると、『さすがMS先輩、Apple小僧とは違うね』と称賛されると思う。

【2026.3.6】

iPhone標準メーラーは、添付ファイル名が RFC2047 の「B」エンコーディングには対応してるけど、「Q」エンコーディングには未対応。新しいほうのRFC2231は対応してた。

//  添付ファイルに関する処理 抜粋
$filename = "あ.xlsx";

//  RFC2047 B は OK
$filename_encoded = mb_encode_mimeheader($filename, "UTF-8", "B");
$body  = "Content-Type: application/octet-stream; name=\"{$filename_encoded}\"\r\n";
$body .= "Content-Disposition: attachment; filename=\"{$filename_encoded}\"\r\n";
$body .= "Content-Transfer-Encoding: base64\r\n";

//  RFC2047 Q は NG
$filename_encoded = mb_encode_mimeheader($filename, "UTF-8", "Q");
$body  = "Content-Type: application/octet-stream; name=\"{$filename_encoded}\"\r\n";
$body .= "Content-Disposition: attachment; filename=\"{$filename_encoded}\"\r\n";
$body .= "Content-Transfer-Encoding: base64\r\n";

//  RFC2231 は OK
$filename_encoded = rawurlencode($filename);
$body  = "Content-Type: application/octet-stream;\r\n";
$body .= "Content-Disposition: attachment; filename*=UTF-8''{$filename_encoded}\r\n";
$body .= "Content-Transfer-Encoding: base64\r\n";

Toとccの使い分け

 入社３年目の女性社員がメールを書いていた。

Toに10人ぐらい入っていた。

メール本文の宛名は2名。

「このメールは、Toに宛名の2名、あとはccに入れて送るのが基本」

って教えたけど

「え、Outlookでアドレスグループ作って宛名に入れると、全部展開されてこうなるんですけど～」

「いやいや、そういうことじゃなくて」

って言ったけど、別にいいでしょ？的な雰囲気を醸し出して送信ボタンをポチっていた。

Toに入っているけど本来ccの人たちが、誰も彼女に指摘していない。

まぁ、確かに、大事なのはメール本文だし、受け取った側も本文読めばわかるし、もう、Toとccの使い分けなんて、どうでもいいのだろうか。

その昔、Windows 95 が出てメールが一般的になったてから研修で教えてもらったが、今は、もうそんなことどうでもいいんだろうか。

老害の部類に入った気がした。