ひさびさに
おおお、処理が軽くなってる……
最終記事書いた頃はアホの子ですかってぐらい動作が遅くて、そのくせ頻繁にログインが必要で、そのまま放置してました。忍者ツールズのメルマガで久々にアメブロの文字を見たんで……ちょっと復活。
プログラミング的には大分後退しています。再インストールの際に全部消してしまった。サルベージするのかったるいんで、全部一から組み直すことに。そのほうが面倒くさくないかって? だから何にもしてません(笑)
とりあえず、ファイルのショートカットからコンテナフォルダを開いたりとかデスクトップ時計とかは復活したのねん。見た目が同じでも仕様が全然違っているあたりがアマチュアプログラミングの醍醐味。て言うか、仕様、無い。更々無い。 サッパリ無い。あはあは。
メーラー作りましょ(5)
utf-8 なヘッダが届いた……デコードできなかったすー。
まぁそんなに甘くはないか。再度あれこれ調べた結果、uft-8 エンコードだとヘッダに使えないコードがあるので base64 でエンコードして使うらしい。
つかー、utf-"8"なんだから、7bitで送信できない罠(笑)
ISO-2022-JP なんかでも同様に 7bit にしてやらんといけない訳ですが、これは訳も解らずデコードする際にライブラリがやってくれていただけの事。
=?UTF-8?B? などと指定されている中の B というのが base64 を指しているのは前に読んでいたのですが、理解できていませんですた。あはあは。
とりあえず base64 でデコードした後で Utf8ToAnsiString してみまふ。
今回のお師匠さま。
http://homepage1.nifty.com/glass/tom_neko/web/web_03.html
まぁそんなに甘くはないか。再度あれこれ調べた結果、uft-8 エンコードだとヘッダに使えないコードがあるので base64 でエンコードして使うらしい。
つかー、utf-"8"なんだから、7bitで送信できない罠(笑)
ISO-2022-JP なんかでも同様に 7bit にしてやらんといけない訳ですが、これは訳も解らずデコードする際にライブラリがやってくれていただけの事。
=?UTF-8?B? などと指定されている中の B というのが base64 を指しているのは前に読んでいたのですが、理解できていませんですた。あはあは。
とりあえず base64 でデコードした後で Utf8ToAnsiString してみまふ。
今回のお師匠さま。
http://homepage1.nifty.com/glass/tom_neko/web/web_03.html
メーラー作りましょ(4)
マルチパートはヘッダの Content-Type が multipart で始まるので用意に判定できます。その時 boundary 属性が付くので、本文をこの文字列で分割してやるだけです。この文字列はメーラごとに違うので毎回取得するべし。
詳しい事は添付ファイルを自分宛てに送って、IdPOP3.RetrieveRaw で TStrings に取り込んで全文を見てみれば一目瞭然であります。
本文中の各パート毎に更に細かいヘッダがつきますが、最初の空行までがヘッダである事は同じ(センチネルというのだそうだ)。
なので、個々のメッセージ保持クラスは更にリスト管理クラスを持ち、パート毎にメッセージ保持クラスを持させて管理します。
TNgymMessageList = class;
TNgymMessage = class( TPersistent );
FOwner : TNgymMessageList;
FPartList : TNgymMessageList;
end;
TNgymMessageList = class( TObjectList );
property Items[Index:Variant] : TNgymMessage; default;
end;
大体の雰囲気わかりますかね。これだけど孫、曾孫とナンボでも保持しますが現実にそういう状況はありませんし。パートの分割は必要になってからリストを生成するのでメモリの無駄はありません。
リストへのアクセスは、インデックスと文字列で受け付けています。文字列は各パートの Content-Type ヘッダの name 属性 を検索して返します。バリアントはこういう風に使うもんだ!と自画自賛(笑)
でもプロトタイプはIndexなので、ソース見て直感的に使えたりはしませんね……何かいい命名規則ないもんでしょか。
リクエストがあれば、実装したクラスのソースコードを公開しても良いです。まぁ、要らんと思うがね。
詳しい事は添付ファイルを自分宛てに送って、IdPOP3.RetrieveRaw で TStrings に取り込んで全文を見てみれば一目瞭然であります。
本文中の各パート毎に更に細かいヘッダがつきますが、最初の空行までがヘッダである事は同じ(センチネルというのだそうだ)。
なので、個々のメッセージ保持クラスは更にリスト管理クラスを持ち、パート毎にメッセージ保持クラスを持させて管理します。
TNgymMessageList = class;
TNgymMessage = class( TPersistent );
FOwner : TNgymMessageList;
FPartList : TNgymMessageList;
end;
TNgymMessageList = class( TObjectList );
property Items[Index:Variant] : TNgymMessage; default;
end;
大体の雰囲気わかりますかね。これだけど孫、曾孫とナンボでも保持しますが現実にそういう状況はありませんし。パートの分割は必要になってからリストを生成するのでメモリの無駄はありません。
リストへのアクセスは、インデックスと文字列で受け付けています。文字列は各パートの Content-Type ヘッダの name 属性 を検索して返します。バリアントはこういう風に使うもんだ!と自画自賛(笑)
でもプロトタイプはIndexなので、ソース見て直感的に使えたりはしませんね……何かいい命名規則ないもんでしょか。
リクエストがあれば、実装したクラスのソースコードを公開しても良いです。まぁ、要らんと思うがね。
メール機能 in 伺か(2)
予定していたラインまでの要素を実装したので、とりあえずネットワーク更新だけアップデートしました。
マルチパート状態で SSTP というブロックがあり BASE64 でエンコードされていれば、中身を SakuraScript として実行します。
これは拡張子のない "SSTP" というファイルを添付しているという状況なのですが、実際に添付されての事かどうか調べていません。というのも正しくは content-type の name 属性ではなく Content-Disposition の各属性を見るべきだからです。
まぁ、これはその内のこととして。
他、[MESSAGE HIINA/*.*] で始まる subject をもったメールは、内部で取り込んで削除します。バージョン 0.0 は保存せずに捨てるだけですが。
1.0 はイベントかスクリプトとして実行する用に考えていますが……未定。
GP01 ver0.5.38 を正式リリースする時までに、メーラとしての見栄えを少し整えようかと。
あとまぁトークの追加とかしてますんで、ひいなを使ってる人はアップデートしてみてもいいかも。
マルチパート状態で SSTP というブロックがあり BASE64 でエンコードされていれば、中身を SakuraScript として実行します。
これは拡張子のない "SSTP" というファイルを添付しているという状況なのですが、実際に添付されての事かどうか調べていません。というのも正しくは content-type の name 属性ではなく Content-Disposition の各属性を見るべきだからです。
まぁ、これはその内のこととして。
他、[MESSAGE HIINA/*.*] で始まる subject をもったメールは、内部で取り込んで削除します。バージョン 0.0 は保存せずに捨てるだけですが。
1.0 はイベントかスクリプトとして実行する用に考えていますが……未定。
GP01 ver0.5.38 を正式リリースする時までに、メーラとしての見栄えを少し整えようかと。
あとまぁトークの追加とかしてますんで、ひいなを使ってる人はアップデートしてみてもいいかも。