Mbox アーカイブビューア
mbox ファイルはメッセージを並べただけのもので、それぞれの前に "From " で始まり差出人と asctime 形式の日付を持つ行が 1 本あるだけです。長さフィールドも終端記号もないので、メッセージの終わりを示すのは、どんな本文にも書けてしまう 1 行だけです。mbox を読む難しさは MIME ではなくここにあります。書き出す側はその行をエスケープすべきですが、やり方が揃っていません。mboxo はちょうど "From " で始まる行だけ、mboxrd は ">*From " もエスケープして ">From " が "From " に戻るようにし、mboxcl と mboxcl2 はエスケープせず Content-Length ヘッダーで本文の長さを書きます。このビューアは目の前のファイルがどれに従っているかを判定します。すべてのメッセージの Content-Length が次の区切り行にぴったり合うか、mboxrd の書き出し側しか作らない ">>From " 行があるか。そのうえでその方式で分割し、別の方式に従うリーダーなら境界を何か所ちがう位置に引いたかを示します。この最後の数字が肝心です。アーカイブが静かにメールを失うのはまさにこの経路だからです。ヘッダーが 1 つも読めないメッセージは誰かの本文から漏れ出した "From " 行であり、その瞬間アーカイブはメッセージを 1 通増やし、本物のメッセージは後半を失っています。メッセージごとに、ファイル内のバイトオフセットと長さ、From_ 行の差出人と日付をそのまま、そして実際に見たいヘッダー（From、To、Cc、Subject、Date、Message-ID、In-Reply-To、References、Content-Type）を RFC 2047 エンコードワードまでデコードして表示します。マルチバイト 1 文字が隣り合う 2 つのエンコードワードにまたがって切られた場合も扱います。多くのビューアが文字化けするのはここです。MIME ツリーはパートごとに型、転送エンコーディング、RFC 2231 の連続パラメーターも含むファイル名、デコード後のサイズを並べ、添付の数を数えます。コレクション全体では、メッセージ数、合計サイズ、日付範囲、主な差出人、In-Reply-To と References から導いたスレッド構造、マージ事故の典型症状である重複 Message-ID、そして Message-ID をまったく持たないメッセージを報告します。メールクライアントではありません。HTML パートは描画せずソースとして表示し、添付の取り出しや DKIM 検証、S/MIME の復号も行いません。1 通を深く読むなら EML ビューア、この道具はその 1 通を包むアーカイブのためのものです。
使い方
- .mbox ファイルを枠にドロップします。アップロードはなくこのタブ内で読むので、数ギガバイトの Takeout 書き出しでも端末の性能次第で扱えます。
- まず方式の行を読みます。本文をエスケープする方式（mboxo/mboxrd）か Content-Length で長さを書く方式（mboxcl）か、そしてその判断根拠が書かれています。
- 所見を確認します。ヘッダーがまったく読めないメッセージはエスケープ漏れで 2 つに割れた本物のメッセージであり、別方式なら引かれた境界の数はアーカイブの危うさを示します。
- 表のオフセットと長さを見ます。投入したファイル内のバイト位置なので、dd やバイナリエディタで該当部分を切り出して独立に確かめられます。
- 行番号を押すとメッセージが 1 通開きます。From_ 行、デコード済みヘッダー、パートごとのエンコーディング・ファイル名・デコード後サイズを含む MIME ツリーが見えます。
よくある質問
- 受け取った覚えのないメッセージが増えているのはなぜですか。
- 誰かの本文に "From " で始まる行があり、ファイルを書いたプログラムがそれをエスケープしなかったからです。リーダーには本物の区切りと区別する手段がありません。どちらも行頭が "From " の 1 行にすぎないからです。結果として 1 通が 2 つに割れ、後半はヘッダーが 1 つもない「メッセージ」になり、前半は後ろを失います。この道具はまさにその状態を印します。ヘッダーブロックが空のメッセージが本物であることはほぼありません。直せるのは書き出す側だけで、mboxrd のエスケープや Content-Length は防ぎますが、素の mboxo はたいてい防ぎません。
- mboxo、mboxrd、mboxcl、mboxcl2 は実際に何が違うのですか。
- メッセージの終わりをどう守るかだけが違います。mboxo はちょうど "From " で始まる本文行の前に ">" を付けますが、エスケープなのか元から引用された行なのか区別できず不可逆です。mboxrd は ">*From " に一致するすべての行に ">" を付けるので、">From " は "From " 由来、">>From " は ">From " 由来だと確定でき、元に戻せます。mboxcl は本文をそのままにして本文のバイト数を Content-Length に書き、mboxcl2 は同じ方式で元のエンコーディングのまま保存しどこにもエスケープを入れません。分割そのものは mboxo と mboxrd で同一で、リーダーが何を戻すかだけが違います。だからこの道具は Content-Length のファイルでのみ境界が変わると報告します。
- メッセージの長さが 1 バイト短いことがあるのはなぜですか。
- 2 つのメッセージの間の空行はどちらにも属しません。これを前のメッセージに含めると、すべての本文の末尾に余計な改行が 1 つ増えるため、古典的な実装はその行を落とします。ただし空行が LF 1 バイトのときだけです。CRLF で書かれたファイルの空行は 2 バイトで、この規則は認識しないため前のメッセージに付いたまま残ります。この道具は黙って改善せずその挙動を再現するので、同じファイルについて参照実装が報告するオフセットと長さと一致します。
- 件名が生のファイルと違って見えるのはなぜですか。
- ヘッダーには ASCII しか入らないため、それ以外は =?UTF-8?B?SGVsbG8=?= や =?ISO-8859-1?Q?Caf=E9?= のような RFC 2047 エンコードワードに包まれます。このビューアはそれをデコードし、文字集合が同じ隣接エンコードワードはバイトを先に連結してからデコードします。この 2 段目が思う以上に重要です。エンコーダーはマルチバイト 1 文字を 2 つのワードに割ることがあり、ワードごとにデコードするとその文字が置換文字に化けるからです。未知の文字集合名（打ち間違いや私的な x- 名）も致命的ではありません。UTF-8 としてデコードするので ASCII 部分は正確で、本当に読めない箇所だけが印されます。
- HTML パートを描画せずソースで見せるのはなぜですか。
- アーカイブは信頼できない入力だからです。HTML 本文をこのページ内で描画すると、そのマークアップとスタイルが周囲のページに作用し、参照される遠隔の画像・背景・フォントは差出人が選んだ場所から取得されます。トラッキングピクセルがアドレスの生存を確認する経路であり、ウェブメールのアーカイブに保存された XSS ペイロードがブラウザーに届く経路でもあります。ソース表示で失うのは体裁だけで、本文もリンクも構造もそこにあり、パートのデコード後サイズを見れば見栄えのよい側に中身があったかも分かります。
- 重複 Message-ID や Message-ID のないメッセージはどれくらい心配すべきですか。
- Message-ID は世界で一意であるべきで、そのメッセージを最初に扱ったシステムが一度だけ付けます。同じ ID が 1 つのファイルに 2 回あるなら、たいてい同じメッセージの複製がバックアップと実運用フォルダから、あるいは両方に入っていた 2 つのフォルダから混ざったものです。ID による重複排除はおおむね安全ですが、先にバイト長を見てください。メーリングリストを通った複製は末尾が違います。Message-ID がない場合は性質が別です。下書きや一部の自動送信、スクリプトが組み立てたメッセージにはもともと ID がありません。スレッド化も重複排除もできないので、その数は ID で動くあらゆる道具にとってアーカイブのどれだけが見えないかを表します。
関連ツール
EML ファイルビューア
`.eml` ファイルをドロップしてパースされたメッセージを読む — キーヘッダー、プレーンテキストと HTML ボディパート、添付ファイルのリスト — すべてブラウザ内で。
Java .properties パーサー
java.util.Properties.load とまったく同じ手順で .properties を解析し、区切り文字・エスケープ・継続行の落とし穴を行単位で示します。
vCard (.vcf) ファイルパーサー/インスペクター
vCard 2.1・3.0・4.0 の .vcf エクスポートをドロップまたは貼り付け、すべての連絡先をカード形式で表示 ─ 名前・電話・メール・住所・所属・URL・誕生日・メモ・埋め込み写真・X- カスタムフィールドをすべてブラウザ内でローカル解析。
ZIP 内容ビューア
ZIP をドロップすると展開せずに中身を一覧・サイズ・プレビュー・個別ダウンロード可能。
ELF バイナリ検査ツール
Linux の実行ファイル・.so・.o をブラウザーで開きます。アーキテクチャ、必要な共有ライブラリ、ビルド ID、PIE・NX・RELRO の有無まで。
HAR ファイルインスペクター (HTTP Archive ビューア)
Chrome / Firefox / Safari DevTools からエクスポートした .har ファイルをドロップすれば、すべてのリクエスト — メソッド、ステータス、サイズ、時間、コンテンツタイプ — を即座に表示。統計、最遅・最大テーブル、フィルター・ソート可能なエントリ。すべてブラウザ内処理。