メールスレッド復元

なぜスレッドを組み立て直す必要があるのか

メールボックスはメッセージが平らに積まれただけのものです。会話の構造は 2 つのヘッダーに宿っています。返信先を指す In-Reply-To と、ルートまでの連鎖全体を運ぶ References です。メールソフトは会話を表示するたび、この 2 つから木を組み立て直しています。メッセージがファイルへ書き出された時点で、その作業はもう一度やり直す必要がありますが、書き出しを開けるツールの多くはそれをまったく行いません。

アルゴリズム

1997 年に Netscape Mail のために書かれた Jamie Zawinski のスレッド構築アルゴリズムを使います。今なお正解です。Message-ID ごとにコンテナーを 1 つ用意し、各メッセージを自身の References が示す連鎖の下にぶら下げ、空のコンテナーを刈り込み、そのうえで初めて——任意で——件名を照合する補助処理を走らせます。

件名による補助照合と、それが選択である理由

携帯電話から、あるいはヘッダーを書き換えるウェブメールから返信すると、References を削ってしまうクライアントがあります。そうした返信は結び付ける手がかりを持たずに届き、件名の照合だけが唯一の回収手段です。しかし同時に、ありふれた件名を共有するだけの無関係な 2 通をまとめてしまうこともあります——別々の「Re: 打ち合わせ」12 スレッドが 1 つになる、というような形で。

そのためこれは既定でオンのスイッチにしてあり、いくつのルートを吸収したかを結果の隣に表示します。その数が大きくスレッドがおかしく見えるなら、オフにして見比べてください。補助照合が併合するのは返信に見えるルートだけです。どちらも返信でない同一件名の 2 通は切り離したままにします。それは 1 つの会話であるより、2 つの別々の告知であることのほうがはるかに多いからです。

欠けているメッセージも表示します

スレッド内のすべての返信が、渡されたファイルに含まれていないメッセージを指している場合、アルゴリズムはメッセージのないコンテナーを生成します。これは本物の結果なので、Message-ID を添えた木の欠落として描き、隠しません。隠せばその返信群が黙って上の階層へ付け替えられ、実際より浅いスレッドに見えてしまいます。

対応形式

EML、Outlook の MSG、MBOX アーカイブを任意に混ぜられます。形式はファイル名ではなくバイト列から判定します。MBOX はヘッダーだけで一覧化するため、大きなメーリングリストのアーカイブでも 1 秒を大きく下回って処理できます。メッセージ全体を解析するのは、それを開いたときだけです。

プライバシー

すべてブラウザー内で動作します。ファイルはアップロードされず、ネットワークリクエストも一切発生しません。