Gmail の takeout 機能で自分の email を mbox 形式でダウンロードできる。適宜検索して昔のメールを見れる状況にはしておきたいし、定期的に takeout した場合に、統合した mbox を作ったりできるようにしておきたいが、どういう環境を整えればいいか…の過程メモ。ちゃんとまとまったら（工事中）外すけど、meliのインストールと意味なかったあたりの情報はさっさと共有しておこうと思って。
普通には Thunderbird を使えばいいと思うけれど、Thunderbird への移行 | Thunderbird ヘルプ のところに、
Windows Mail (.eml ファイル) から Thunderbird へのインポートは、サードパーティ製のアドオンである ImportExport Tools を使用し、メッセージ形式を変換してインポートします。ImportExportTools アドオン をダウンロードし、Thunderbird にインストールしてください。
として貼られている、ImportExport Tools は Thunderbird の最新版（本記事執筆時点で Version 102.1.2）には対応しておらず（ Version 60.* まで！）ImportExportTools NG というアドオンで対応している。でも少し前はこちらも最新版に全然追いついていなかった、みたいな状況がある。ImportExport をメインの機能に位置づけていない時点で、アーカイブツールとしては使い物にならない。
アーカイブという言葉を出すならば BitCurator が最適なんだろう。名前の通り Bit レベルのデジタル保存から NLP を用いた分析まで用意されているツールだ。しかし、今の目的の下ではオンラインに公開することを想定していないし、そんなに分析したいわけでもないし、手軽さの面で今回の目的には適していない。
mbox が扱えるメールツールがあればいいので、linux 上のメールツールならけっこうできるんじゃないかと思い、meliを試そうとしたが、結論、Windows WSL の Ubuntu では、うまく動かなかった。meli を実行しても何も表示されない。以下寄り道的なメモ：
meli は Rust で作られていて、rust のパッケージ管理？cargo というのを Ubuntu に apt でインストールして…とやっていっても、一部のライブラリについて Rust のバージョンが低すぎるというエラーでインストールできなかった。そこで apt の方で Rust を remove し、Install Rust - Rust Programming Language に従って rustup を使えるようにした。この過程でも、勧められている curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh could not download file from … と言われて、うまくいかなかったので、Rustupをインストールするときに発生したエラーの回避方法 | ひがし研究所 を参考にインストーラを直接探してダウンロードしてきて、chmod +x rustup-init sudo ./rustup-init するという方法でようやく成功した。そうすると、rust も最新版が使えるようになって問題解決、cargo install meli … と思いきや、meli の方はまだまだエラーに悩まされる。failed to run custom build command for openssl-sys v0.9.75 とか言われる件については、rust で failed to run custom build command for `openssl-sys` が出るときにすること - Qiita を参考に、export OPENSSL_LIB_DIR=/usr/lib/x86_64-linux-gnu/ export OPENSSL_INCLUDE_DIR=/usr/include/openssl/ が必要だった、error: linking with cc failed: exit code: 1 /usr/bin/ld: cannot find -lsqlite3 って言われる件については、sudo apt-get install libsqlite3-dev が必要だった。そこまでやって、やっとインストールして、何も動かない。インストールが失敗しているのかもしれないし、何もわからない。初の Rust 製品体験は散々だった。
そして、eneam/mboxviewer: A small but powerfull app for viewing MBOX files というのにたどり着いたが、日本語のメールで使われる ISO-2022-JP がうまく扱えておらず、issue 上げたらめっちゃ活発に対応してくれていて、現在進行形で対応中。ISO-2022-JPのISO/IEC 2022適合性 とか読んでても思うけれど、マジで日本のガラパゴスな仕様で、こんなのがまだ使われているの、メール関連の色んなツールにとってすごく負担だ。一説にはガラケーがまだ生きてるから生きてる、みたいな説明もあるけれど、文字コードのレベルでは本当に UTF-8 に統一されてほしいわ。あとで、年ごとの文字コード利用統計とかとってみるし、分析とか含めて個人メールデータでできることや、その本格的なアーカイブとの比較と要件、「「個人メールアーカイブと公的なメールアーカイブとの関係」と「個人史と全体史との関係」との関係」、某個人追悼の際に考えたこと、をまとめて研究会論文くらいにはするかもだけど、アーカイブとして文字コードを気にする&強い真正性を気にするのは技術史観点か公的な権力性がある場合であって、個人メールアーカイブはとりあえず、文字コード UTF-8 に統一した mbox や eml ってのが扱いやすそうだよなー。Eml形式 - Wikipedia の中身全無視全消去でリダイレクトされちゃった（ノートのところに米国議会図書館のデジタル保存に関するページを張って、その方向での加筆の必要性をコメントしつつ統合提案して２年も放置してたわたしゃが悪いんですが）のも対応しなきゃだし、やりたいことが多すぎる。
