EML/MIMEインポート診断
生の.eml（RFC 822/MIME）ソースを貼り付けるかファイルを読み込み、Outlook、Gmailインポート、Apple Mail、Thunderbird、一般的なIMAPツール間で異なって動作・失敗する構造を確認します。
ブラウザー内でローカルに処理します。ファイルがアップロードされることはありません。
使い方 ツール
- 生の.emlソースを貼り付けるか.emlファイルを読み込みます。内容はブラウザー外へ送信されません。
- 「インポート互換性を確認」を選びます。
- 各指摘について移植性を損なう理由と影響するメールクライアント/インポーターを確認します。
- 利用可能な安全な書き換えを使います。CRLF改行の正規化とRFC 2047ヘッダーエンコードは機械的に安全です。他の問題は安全な修正を推測できないため説明のみです。
前提条件
- 8つの具体的な問題を認識します：multipart境界の欠落/不正、MIME構造があるメッセージのMIME-Version欠落、Content-Transfer-Encodingと本文の不一致、未エンコード非ASCIIヘッダー、RFC 5322の998オクテット上限超過行、LFのみの改行、重要ヘッダーの重複、本文と衝突する弱い境界文字列。
- このツール用に作られた行認識型RFC 822/MIMEパーサーです。ヘッダー折り返しとmultipart境界構造をこの検査に必要な範囲で認識しますが、完全なメール解析ライブラリではありません。
- 重複検査する重要ヘッダーはContent-Type、From、To、Subject、MIME-Version、Content-Transfer-Encoding、Message-ID、Dateです。
出典と参考データ
方法論
生テキストをRFC 822折り返しを展開したヘッダーとMIMEパートツリーに解析します。各パートのContent-Typeにあるboundaryで区切りを探し、RFC 5322/2045–2049/2047要件およびクライアント/インポーターの寛容さの差を確認します。損失のない決定的変換であるCRLF改行の正規化とRFC 2047による非ASCIIヘッダー値エンコードのみ提案します。境界欠落、転送エンコード不一致、長すぎる行、弱い境界は説明し、推測で修正しません。
計算例
boundaryパラメーターのないmultipart Content-Type
入力項目: Content-Type: multipart/mixed (boundary=...なし)
結果: 厳格なMIMEパーサーは各パートの境界を見つけるパラメーターが必要です。構造解析を妨げるエラーとして指摘し、正しい値を推測できないため修正しません。
ファイル全体がLFのみの改行
入力項目: ヘッダーと本文が「\r\n」でなく「\n」で分離
結果: RFC 5322はCRLFを要求します。現代のクライアントの多くは正規化しますが、厳格パーサーはLFのみを誤解析・拒否する場合があります。情報として指摘しCRLFへ安全に正規化します。
未エンコード非ASCII文字を含むSubject
入力項目: Subject: Café meetup notes
結果: 従来のRFC 822/5322メッセージではヘッダーに7-bit ASCIIを使用します。RFC 6532では、受信経路がSMTPUTF8に対応している場合にUTF-8ヘッダーを直接使用できます。旧式システムとの幅広い互換性にはRFC 2047 encoded-wordが適しています。互換性の警告として示し、決定的で可逆なRFC 2047への書き換えを提案します。
実用的なアドバイス
- multipart Content-Typeにboundaryを設定し、本文の各パートが`--boundary`を使い、`--boundary--`で閉じることを確認します。不一致は表示だけでなく解析を壊します。
- MIME機能を使うメッセージには`MIME-Version: 1.0`を含めます。一部クライアントは推測しますが明記すれば曖昧さを減らせます。
- 実際の本文と衝突しにくい長く予測困難なboundary文字列を使います。
- 旧式のASCII限定メールシステムとの幅広い互換性のため、ヘッダー内の非ASCIIテキストにはRFC 2047を使用してください。受信経路がRFC 6532とSMTPUTF8に対応している場合は、ヘッダーでUTF-8を直接使用できます。
よくある間違い
- 現代クライアントで開けたLFのみの.emlはどこでも動くと思うこと。一部の厳格/旧式パーサーはCRLFを要求し、誤解析・拒否します。
- Content-Transfer-Encodingを飾りと考えること。base64宣言なのに本文が有効なbase64でなければ、厳格クライアントで復号に失敗し、寛容なものでも読めないデータになる場合があります。
よくある質問
boundary欠落はエラーでMIME-Version欠落は警告なのはなぜ？
boundaryがないと厳格パーサーはパートの位置を特定できず処理に失敗します。MIME-Version欠落はRFC 2045違反ですが、寛容なクライアントは他ヘッダーからMIMEを推測できることがあり、実影響が限定的な場合があります。
非ASCIIヘッダーは書き換えるのに境界欠落を直さないのはなぜ？
RFC 2047による値エンコードは既存データの可逆で決定的な変換です。boundary値を作る、重複ヘッダーのどちらを残すか決めるには意図を知る必要があり、推測できません。
添付ファイルを復号・表示しますか？
いいえ。境界、エンコーディング宣言、行長などのヘッダーと構造マーカーを調べます。不正base64の最初の不正文字など、特定問題を説明するための短い抜粋を除き、添付本文を復号・表示しません。
このEMLがOutlookで開かない・インポートできないのはなぜ？
multipart境界欠落/不正や転送エンコード不一致など、このツールが検査する特定の構造問題を確認します。Outlook自体をテストせず、すべてのインポート問題を診断しません。検査を通っても対象外の理由で失敗することがあります。
最終確認日： 2026-09-25
限定目的のRFC 822/MIMEパーサーであり完全なメール解析ライブラリではありません。UTF-8以外の文字コード境界、S/MIME署名、カレンダー/iCalパート、深く入れ子のmultipart/relatedなどは解析しません。行長はUTF-8バイト数で近似し、実際のメッセージの大半では正確です。
このツール 上記の前提条件に基づく参考値を提示します。
テーマとツールの設定、保存済みリストと最近使用したリストは、このブラウザー内にのみ保存されます。