thunderbird-2.0.0.9-source.tar.bz2
を展開して内容を見ています。
質問
１．このすべてがサンダーバードの構築に使われるのですか？
２．サンダーバードが添付ファイルのついている日本語メールを受け取るときには、
　　base64デコードをして、その後は、
　　みんなまとめてmailboxに書き込み、
　　表示するときに、添付ファイルの部分を取り出しているのでしょうか？
３．メールボックスに書き込むときには、BTree構造を使うのでしょうか？
このあたりの疑問は
どのソースファイルを見れば解決するのでしょうか？
よろしくご指導ください。

私は見たことないですが、makeの方法がどこかに書いてあるはずなので、makeをやってみてexeが生成されたら全てと言うことになるのではないでしょうか。unresolvedなんとかというエラーが出れば揃っていないのかと。

受信時にはやっていないと思います。最初にフォルダを開くか、開いた状態の時に一覧と添付ファイルアイコンの解決のために処理するのかと思っています。ユーザアクションに対する反応の時間からの想像ですが。
インデックスには添付ファイルの有無のフラグしか無かったような気がします。一覧表示のためや添付ファイルをダブルクリックで開くか操作するときにヘッダの情報に従ってデコードするだけだと思います。

BTreeを使っているんでしょうか。使っているとしたらインデックスファイルだけだと思います。メールボックスはただの連続したテキストです。

関数マップに関するドキュメントが無いのなら、全てのソースから関数リファレンスを生成して場所を予想して探すんだと思います。


個人的な興味で聞いてみますが、「展開して内容を見ています」と書いてあるだけで目的が書かれていません。なにか目的があるのでしょうか？
＃ 表題も「ソースコード」だけですし

ただ、どんなことをやっているのか勉強してみたいということなら、まず全てのソースを調べてツールを使わずに自分で関数リファレンスを作ってみてはどうでしょうか。
その上で質問等が有れば（すべて英語になりますが）本家の開発関連のサイトで質問すれば教えてもらえるのではないでしょうか。

私はソースには興味がないので参加しないと思いますが、このトピックの内容によってはフォーラムの異動になるかもしれません。

珍しい質問が目に入ったので少しだけ何となく。(^^;

1. ビルドに不要なファイルも一部ありますが少数です。
   具体的に読み込まれるファイルが知りたければ、ビルドですから当然 Makefile 見ましょう。xul や js 等は jar manifest ファイル (*.mn) にリストされたものが含まれます。
   その他ビルドに関しては:
   http://developer.mozilla.org/ja/docs/Bu ... umentation
   ソースのオンライン検索などについては:
   http://mxr.mozilla.org/mozilla1.8/
2. 現状の Thunderbird ではメールデータを mdb 形式で保存していますから、コードで確認はしていませんが常識的に考えて、base64 その他のエンコードはいじらずそのまま保存し、表示時などにデコードでしょう。
3. 「メールボックスに書き込むとき」というのが、何をどこから書き込むときについて聞きたいのかはっきり分かりません。
   ソースファイル群を常識的に眺める限り mdb ファイルについては
   http://mxr.mozilla.org/mozilla1.8/source/db/mdb/
   msf ファイル(インデックスファイル)については
   http://mxr.mozilla.org/mozilla1.8/source/db/mork/
   http://mxr.mozilla.org/mozilla1.8/source/db/morkreader/
   あたりが入出力のコードだろうと思います。
   サーバやローカルのファイルから読み込んだデータをメモリ上でどのように取り扱ってるかは知りません。これらを使って何処に読み込んでいるか、あるいは POP や IMAP で得たデータを何処に渡しているか探してみれば良いのではないでしょうか。

何を目的としているのか分かりかねますが、もし Thunderbird 自体に関心があるのではなく単に Thunderbird でのメールデータの保存と管理方法から何かを学ぼうというのであれば、あまり楽しいことにはならないかもしれません。
メールインデックスの msf ファイルが mork という独自の極悪フォーマットファイルであったりして、あまり美しいことはしてなさそうですから。(^^;
http://firefoxhacks.at.webry.info/200705/article_2.html
# 将来的には Thunderbird でも SQLite とか使うようになるんじゃないでしょうか…

# 相互開発サポート系の話題かも？

アドバイスをいただきありがとうございます。
VC++でメーラーを作っています。
送信の最後ではbase64エンコードを行っています。
受信したものは、デコードしてさらに、シフトJISにしてから
添付ファイルなどは別々にして保存しています。
これだと、接続時間が長くなるので、
改良したいと思ったのです。

なるほどなるほど。送受信の接続時間が長くならない(送受信に伴う処理が重くならない)ような処理方法とデータ形式を知りたいという話だったのですね。

私は専業プログラマじゃないですが、何かの参考になればということで好き勝手に書きます。
# 変なこと言ってたら誰かつっこんで。(^^;

mbox 形式や maildir形式(とその類似形式)はヘッダを含めてすべて既存のデータファイルに追記あるいは新ファイルとして保存するだけなので、高速受信(高速保存)には適しているかと思います。
取り敢えず受信時にデコードする必要はないと思います。表示や検索の高速化その他の要求によりデコードした状態で保存しておきたいというのであれば、受信時は(未処理フラグを立てて)そのまま保存して、その後アイドルタイムか初回表示時に(未処理フラグの立っているものだけ)デコードなどすれば良いのではないでしょうか？

メールに適したデータファイル形式については mbox も maildir も極端でメール数が増えてくると問題になりがちなので Becky などのように適当なサイズで分割してお茶を濁すか、データベースなどに入れるのが現実的なのだろうと思います。

フォルダ単位での整理という時代遅れとなろうとしている制約から逃れることを念頭に置けば、適当な軽量 RDB を使うのが現実的なのではないかと、個人的には想像しています。
# 専用のデータ管理形式を開発して管理できたらそれに越したことはないけど、どのような形式が最適かというのは難しい…

BTree というのはフォルダ分けだしツリー系のインデックスをということなのかと想像しましたが、個人的にはフォルダ非依存の次世代メーラに夢を見たいので Hash とかでの上手い実装に期待。(^^;

いろいろなヒントをいただき、
少しわかりました。

base64--ShiftJIS
の変換ではなく
UTF-8---Unicode
の変換が使われているようですね。

受信時には、
ユニコードに戻してから
データの最後に
貼り付けていると考えてよいのでしょうか？

あー、うー。質問の意図をつかみかねます。
ユニコードに戻してからデータの最後に貼り付けるって、何をですか？
添付ファイル？日本語(その他 8bit 系文字の)メール本文？
# 必ず長文書けとはいいませんが、質問時には目的語や 5W1H にあたることはできる限り誤解の余地がないよう具体的に。

繰り返しますが、Thunderbird はデータを受信したメールは base64 や uoted-printable でエンコードされていても、8bit のまま送信されていても関係なく、受信したデータそのままで保存しています。
実際に Thunderbird を使ってメールボックスのデータ開いてみましたか？メールデータファイル見れば何もデコードや変換してないのはすぐ分かると思いますが？
# 推定です。コードは読んでません。もし違ったらごめんなさい。

また、それ以前に base64--ShiftJIS と UTF-8--Unicode という二つの関係(変換)を同列に並べることと、UTF-8 を Unicode に変換するという意味が分かりません。
UTF-8 は Unicode の一種であり、Unicode に変換するものではないし、UTF-8 -> UTF-16 変換のことであれば 7 ビット化のデコードと文字符号化方式の変更とぜ別次元の話です。
もしかしたら受信データのデコードと、文字列データ読み込み時の内部表現への変換を混同してたりしませんか？

念のため:
base64, quoted-printable などは 8bit データを 7bit ASCII テキストで表現するための(7bit 化)符号化方式です。
Shift_JIS, EUC-JP などは文字集合およびその文字符号化方式です。
Unicode などは文字集合です。
UTF-8, UTF-7, UTF-16 などは Unicode という文字集合の文字符号化方式です。

いずれにしても受信したデータを保存するために base64 デコードや UTF-16 への変換はされていないハズです。受信時にそれらの変換を行っていたとしても、それは保存のためではないハズです。
一緒にコードを読む時間は取れませんので、本当に何をしているかはご覧のソースにご相談ください。m(_ _)m

ご指摘ありがとうございました。

mailnews/compose/src
のなかに、nsMsgAppleDecode.cppを見つけました。
　この中で、
ファイルとして保存したものを解析し
base64デコード
をしている部分が見つかりました。

コードの件は

　UTF-8では1文字を1～6バイトの可変長の数値(バイト列)に変換するようになっているが、現在定義されているUnicode文字をUTF-8で表現した場合、最長で4バイトのバイト列に変換される。
　UTF-8では、Unicodeの最初の128文字(UCS-2でいうU+0000からU+007F)を変換した結果がASCIIとまったく同じになるため、従来の処理システムとの親和性が高いという特長がある。一方、日本語などの文字は元々2バイトだったものが3バイトや4バイトで表現されてしまうため、UTF-16と比べてデータサイズが大きくなってしまうという欠点がある。

と書いてあったのをネットで見つけて、
　日本語の文字は
送信するときにコード化されているので
元に戻さないと表示できないと考えました。

さらに、私は
シフトジスを使っていますので、
送信のときは、base64変換して送信していました。
受信の途中で、メール本文をシフトジスまで
逆変換してからファイルを作成していました。

そんな理由で、
ファイルを作成する前にユニコードまで戻している
と考えてしまいました。

ありがとうございました。

ShiftJIS を使っているという言葉にちょっと引っかかったので一応。

まさか ShiftJIS と base64 しか対応していないメールソフトを開発されているってことはないですよね？
base64 は ShiftJIS 専用ではないし、ShiftJIS は base64 変換を使うという決まりはありません。文字符号化方式と 7bit 化符号化方式の組み合わせは任意です。メールソフトはどのような組み合わせでも対応する必要があります。

日本人が使うメールソフトなら最低限 ISO-2022-JP/ISO-8859-1/Shift-JIS/EUC-JP/UTF-8 と base64/quoted-printable 7bit符号化の任意の組み合わせに対応が必要でしょう。

一般用途での ShiftJIS の具体的な欠点をあげるとすれば、英語以外の欧米言語に使えません(アクセント記号付きアルファベットが含まれていない)。
ShiftJIS なんかさっさと過去の遺物になるべきです。(^^;

なお、base64 エンコーディングなどは RFC 違反や文字境界を無視したコードを吐くライブラリとか結構ある(例えば PHP)のでメールソフト側は柔軟な対応が必要です。デコードで文字化けさせてそのまま保存すると復元不能なので、そういう意味でも受信データはデコードしないで保存された方が安全なことがあります。
# まぁそこは送信側が悪いと割り切っても良いでしょうが

文字エンコーディング周りの話はややこしいですが、文字データを扱うプログラムの作成時には必ず必要なことですので、この際よく調べて身につけておくことをオススメします。

ではでは。

詳しい説明 お疲れ様です。
他の人の勉強にもなっていると思います。観閲数も伸びていくと思います。
予想通り、私は参加しない宣言して正解でした。陰で応援します。
＃ でも、みんなに読んでもらう読み物として面白いと思います

tunosazaeさん、
ソースコードやデータ構造も大切ですが、実用に供するものを作るためにはRFCも大切です。
それと、dynamisさんが書いている内容を理解する知識と想像力も。
がんばってください。

RFCですが、
１．メーラー作成に必要なもの。
２．ネットワークの基礎知識。
の観点から、番号を教えていただければ、
読んでみます。
よろしくお願いします。

それから、ご意見を参考に
メーラーの文字コードは
ユニコードに変えます。
　

ごめんなさい。どれを読めば良いのかわからないという時点でちょっと... って感じです。
私からは「全てに目を通して自分で取捨選択して下さい」としか言えません。それに、実装者は「読んでみます」ではなくて読むことは必須です。

http://www.rfcsearch.org/rfcview/rfc-index.html

日本語化されたものは少ないですし、検索すればたくさん出てきますがMUAやMTAの実装者のために翻訳されたものはほとんど見かけません。
http://rfc-jp.nic.ad.jp/

また、当然ながらネットワークの基礎知識に関するRFCなんて無いと思います。低レベルに関するRFCも通信に関する知識を持った人へのヘッダを規定するものなので。

dynamisさんしか参加してないですが、誰もユニコードで保存しろと言う意見はしてないと思います。
「受信したデータそのまま」が正解なんじゃないでしょうか。ヘタにコード変換してしまうと後で破綻します。
＃ 表示するために一旦unicodeに変換するというのなら理解できるけど

Thunderbird 3 では、mork とか RDF とかを捨てるような話が出ていますね。どこまで捨てるのかはわかりませんが…
Mac の Mail が SQLite を採用しているところを見ると、その方向性は専門家から見てもきっと間違いではないのでしょう。
まず、何はなくとも
2822 Internet Message Format.
は絶対に必須。
また、MIME を扱うには
2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of
Internet Message Bodies.
2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media
Types.
2047 MIME (Multipurpose Internet Mail Extensions) Part Three: Message
Header Extensions for Non-ASCII Text.
2049 Multipurpose Internet Mail Extensions (MIME) Part Five:
Conformance Criteria and Examples.
2231 MIME Parameter Value and Encoded Word Extensions: Character Sets,
Languages, and Continuations.
あたりが必要でしょう。
また、日本語メールでは ISO-2022-JP でエンコードするのがデファクトスタンダードとなっていますので、これについては
1468 Japanese Character Encoding for Internet Messages.
です。
# あくまで必要なものを挙げただけで、十分というわけではありません。
RFC は、基礎知識を得るためのものじゃないです。
意図を読み取りかねます。
メーラ内部で使用する話ですか？送信するメールのエンコードですか？ファイルに保存する話ですか？

番号を教えていただきありがとうございます。

意味不明だった部分を補足します。

１．メールを作成のエディターで
内部的に使う文字コードを
ユニコードにします。

２．受け取ったデータは
そのまま保存します。
表示するときに変換して表示します。

３．RFCについては、
番号だけを見ると３０００個くらいありそうなのですが、
小さな番号を持っているものを以前見たのですが
もう古くなったと大きな番号を持つものに書いてあったので
どれを読めばよいのかというところで困りました。
楕円曲線暗号の勉強もあり、全部読む時間は取れません。

４．目標は、送受信は出来る。にしぼって作ってみます。

番号だけ見るとすでに 5000 を超えてますね。
1rfc_index.txt を見れば Obsolete される側にもそう書いてありますので、まずはこちらで確認すると良いでしょう。
そうすると、あとは pop と smtp とそれらの認証がわかれば送受信はできそうですね。