MIME添付ファイル名チェッカー

生の.eml（RFC 822/MIME）を貼り付けるか読み込み、Windows、macOS、Linuxで受信者が保存するとき、添付ファイル名が保存できない、黙って変更される、メールクライアント間で異なる箇所を確認します。

解析する内容を貼り付けてください

ブラウザー内でローカルに処理します。ファイルがアップロードされることはありません。

使い方ツール

生の.emlを貼り付けるか.emlファイルを読み込みます。ファイルはブラウザー内で処理しアップロードしません。
「添付ファイル名を確認」を選びます。
指摘された各名前と影響するOS/クライアントを確認します。
文字置換、予約デバイス名への接尾辞追加、末尾ドット/空白削除、RFC 2231エンコードなど、安全な書き換えを利用します。ヘッダー不一致や二重拡張子のヒューリスティックは推測で直しません。

前提条件

8つの問題を認識します：Windows予約文字、予約デバイス名、末尾ドット/空白、RFC 2231拡張形式の通常名フォールバック欠如、一般的な255バイト上限超過、Content-Disposition/Content-Type間の名前不一致、二重拡張子偽装パターン、RFC 2231/2047未エンコード非ASCIIバイト。
同じマイクロサイトの限定.eml/MIMEパーサーを再利用し、各MIMEパートで宣言された名前を探します。MIME解析を再実装しません。
Content-DispositionのfilenameとContent-Typeのnameが一致する場合、通常クライアントが保存に使うContent-Disposition側を採用します。不一致ならどちらかを黙って優先せず両方表示します。
添付なし（Content-Disposition: attachmentもfilename/nameパラメーターもない）のメッセージは、このツールが指摘する問題は0件です。

出典と参考データ

方法論

生テキストをMIMEパートツリーへ解析し、各パートのContent-Disposition/Content-Typeからfilename/nameを調べます。宣言名をWindows/macOS/Linuxの文書化されたファイルシステム規則とRFC 2183/2231/6266要件で確認します。予約文字置換、予約デバイス名への接尾辞、末尾ドット/空白削除、ASCIIへ復号できるRFC 2231名への通常フォールバック追加、非ASCII名のRFC 2231エンコードのみ提案します。ヘッダー不一致と二重拡張子パターンは意図した名前やヒューリスティックでの改名を決めず説明のみです。

計算例

コロンと疑問符を含むPDF添付名

入力項目: Content-Disposition: attachment; filename="Q3 report: draft?.pdf"

結果: Windows（NTFS/exFAT）は< > : " / \ | ? *を含む名前を保存できませんが、Linux/macOSでは有効です。エラーとして指摘し、各予約文字を`_`へ置換します。

正確にcon.txtという.txt添付

入力項目: Content-Disposition: attachment; filename="con.txt"

結果: Windowsは拡張子にかかわらずCON、PRN、AUX、NUL、COM1-COM9、LPT1-LPT9を予約します。エラーとして指摘し予約名へアンダースコアを追加する`con_.txt`を提案します。

文書らしい拡張子に隠れた実行形式

入力項目: Content-Disposition: attachment; filename="invoice.pdf.exe"

結果: 安全そうな拡張子の直後に実行形式の拡張子が続くのは、マルウェア偽装で知られるパターンです。確実な判定ではなくヒューリスティック警告として指摘し、自動改名しません。

実用的なアドバイス

管理する添付名にはWindows予約文字（< > : " / \ | ? *）と予約デバイス名（CON、PRN、AUX、NUL、COM1-COM9、LPT1-LPT9）を使わないでください。送信側クライアントに関係なくWindows保存で失敗します。
非ASCII文字が必要ならRFC 2231拡張形式（`filename*=UTF-8''percent-encoded`）と、旧式/簡易クライアント用のASCII `filename=`フォールバックを併記します。
添付の安全性をContent-Type宣言だけで判断しないでください。安全そうな拡張子の後に実行形式拡張子があるのは文書化された偽装手法です。
添付名は255 UTF-8バイトを大きく下回る長さにしてください。メールゲートウェイや旧システムはそれより前に切り詰めることがあります。

よくある間違い

送信クライアントで正しく表示されればどこでも保存できると思うこと。予約文字・デバイス名の問題は受信側OSがファイル作成するときに発生し、送信者には見えません。
`filename*=`と`filename=`を同じものとみなすこと。RFC 2231非対応クライアントでは通常名フォールバックがないと名前が空または文字化けになる場合があります。

よくある質問

予約文字はエラーでヘッダー不一致は警告なのはなぜ？

予約文字やデバイス名はWindows保存で確実に失敗します。Content-Disposition/Content-Type不一致は曖昧で、実クライアントにより選択が異なり得ます。リスクですが失敗が保証されるわけではありません。

二重拡張子チェックで指摘された名前を改名しないのはなぜ？

`summary.pdf.bak`のような正当なファイルもあるヒューリスティックで誤検知があり得ます。推測で実際の添付名を変えるのは受信者が判断します。

添付内容を復号・表示しますか？

いいえ。各添付のfilenameを宣言するContent-DispositionとContent-Typeのみ確認し、添付本文を復号・表示しません。

メール添付名が文字化け、または保存時に変わるのはなぜ？

特にRFC 2231エンコード名、通常名フォールバック欠如、未エンコード非ASCII名、Content-DispositionとContent-Typeの矛盾をメールクライアントが異なって扱う場合があります。このツールは宣言された名前の移植性問題を調べますが、添付内容を検査せず、各クライアントの保存名をすべて予測しません。

最終確認日： 2026-09-26

添付名の宣言のみを確認し、本文は調べません。同マイクロサイトの限定.eml/MIMEパーサーを再利用するため、通常のmultipart入れ子を超える特殊構造は解析しません。長さは一般的な255バイト上限をUTF-8バイト数で近似します。一部OS・ゲートウェイはもっと短く切り詰めますが、システム別の別警告は行いません。

このツール上記の前提条件に基づく参考値を提示します。

テーマとツールの設定、保存済みリストと最近使用したリストは、このブラウザー内にのみ保存されます。