mailpeeper-tlsのUTF-8対応とかしてみる２ [プログラミング]
前回からだいぶ時間が経って、もう少し早めに書きたかったんだけど、やっとうまく動きだしたので、コミットしたついでに、やった事をダラダラと書く。
とあるメールチェッカーのUTF-8のみの対応が、お手軽にできそうなので、Shift_JISとかも欲張って実装しちゃおうという野望。というか野暮用。
既に実装しているところがあって、それはBASE64でエンコードしてあるISO-2022-JPなんだけど、既にきちんと動いているから、参考にしたいと思う。
http://homepage1.nifty.com/glass/tom_neko/web/web_03.html#Base64
ここ↑だと、
＞ 元のデータの6bitを0～63の数字としてA～Za～z0～9+/の64文字で置き換えます。
＞ 元のデータが8bitと6bitの最小公倍数である24bitで割り切れない場合、
＞ 6bitに足りないbitには0を代入して変換し、変換後の文字列の最後には
＞ 「=」を１つないし２つ付け足して割り切れるbit数にします。
＞ 変換前よりデータサイズが一律33%大きくなります。
そうそう、少しでかくなるんだよね、メールに添付したファイルって。そんでファイルの日付とかファイルシステムに依存する部分は全部消えちゃうんだよね。そういう属性残すために、テキストをZIPで圧縮して、Base64でASCIIコードにエンコーディングして、って何か間違っている気はしてたけど。ASCIIテキストで送らなきゃダメって以前には言っていたから仕方なかったんだね。
ソースを読む。シフトとか普段はあんまり使わないからすぐにしっくりこない。
Base64の処理とメールヘッダの構造がそのままソースにした感じで、動いているから間違いではないのだけど、なんつーか今回必要となるメインとなるところの全部が、ダラダラ書かれていて、関数分割としてはうまくない感じ。人の事全然言えないけど、他のBase64のサンプルコードを読んで、始めて全体像が掴めたので、こういうコーディングはちょっと困る。同じ文字列を長いこと引っ張り回すのは私の趣味ではない。
元ネタのソースを読んでいくと、やっとメールのヘッダのフォーマットが見えてきた。普通ならRFCなどからメールヘッダのお作法を一通り読んでから、コーディングって形なんだろうけど、動いてるところをデバッガで追い回した方が、実際にやっている事が何なのかははっきりする。実際のメールのヘッダを見てみて、コードと照らし合わせると、実際の意味が読み取れてくるのだ。GUIな時代に産まれたので、GDBとかコマンドラインで使えないっすよ。まぁこのくらいの認識でもソフトは作れるってことです。
つーか、strstr_toupperedとか、ググっても世界中に一つもないと思ったら、自前で作った関数でした。こういう紛らわしい関数名をマクロとかで軽く隠蔽されても困るんだよな。やっぱり人の作ったソースって色々気になるから、できれば触りたくないんだよね。インデントとか動作には全く関係ないんだけど、キモイ見た目だと全部直すか、新しくスクラッチしたくなるもの。
とはいえ、動いているものを再検証しながら、また同じ物を書くのは色々無駄が多いので、ラッパー関数使って隠蔽するってのが普通のやり方かな。前にリファクタリングが流行った気がするけど、相当な事がなければやらない方が良い。変数名がカウンタでもないのに、一文字だけなどで情報がなさすぎで散々使われているとかはまだ分かるけど、色々へたくそなソースの大幅な改変ってのはやりたくない。
今回は比較的読みやすい部類だけど、英語以外の他の言語のコメントだったらまず触らないかも。なんか文字列探すのと、Base64のデコードと、ISO-2022-JPの操作がごっちゃになっていて、読むのが面倒臭くなってきた。ISO-2022-JP以外のデコード操作は、別途やる事にした。元ソースになるべく干渉しないようにしないと痛い目を見るし、更に読みにくくしてどうする、な状態になりそうだし。
とりあえず、ISO-2202-JPの機能をなるべく殺さないようにして、新しくShift-JISとUTF-8を読める文字列にする処理を行なった。入口はHeaderAnalizer.mの、HeaderAnalizer#popに入れ込む事にしました。シフトJISとUTF-8が全然なかったら、スルーして今までの処理をやってもらう事にします。統合する時にISO-2022-JPの上手い処理を崩してしまいそうだから、自作のC言語の関数も多めなので、下手に手を出すと不具合が生じかねない。
インプリして動かしたら、しばらくはうまく動かなかったけど、やっとメモリをやたら食う処理を直す事ができた。C言語のcharの文字列と、Cocoaで使っているNSString周りの関数が随分違っていて、Obj-C的な知識が少々必要だったので面倒だった。今更、そんな言語使いたくないよ。
文字コードが２種、MIMEエンコーディングが２種、それぞれの組み合わせで動くようにはした。とはいえ、Quoted-Printableなメールが来なくて試験ができなかったりする。Twitterのアカウントとって、自分宛にTwitterの通知メールを送って試験しようかな。
DeprecatedなCocoaの関数は、少し直したら、何だかメモリの使用料が減ったと思ったら、自分の単なる思い違いでした。バグでメモリを800MBぐらい消費しちゃったのを見てたから、今までに戻っただけですごくまともに見えてしまうのであった。続けて使うと10MBから20MBくらいに肥大してしまうのですが、少しずつ肥大してるんだろうなぁ。Obj-Cってメモリリークを探しにくい感じがするし、実際そうだからガーベッジコレクションが導入されたんだろうし。
えーと、
前に作ったブランチに切り替えて (git checkout test1)、
gitにコミットして (git commit -a -m 'hogehoge')、
GitHubに上げたい (git push origin test1)
やっとgitの実体に慣れてきた。でも、もっとお手軽なGUIツールが出てくるか、Xcodeでgitをプラグインとかで実装できないものかね。なんかそういうのって覚えきれないし、汎用性がない事ならば覚えたくない。
今度書くときは、gitのやる事はmerge作業ってことになりそう。一人プロジェクトなので、んな事気にする必要は全くないのだけれど、周りに人がそれなりにいるのを考慮できた方が良いに決まってる。そのためのgitでもあるわけだしね。
とあるメールチェッカーのUTF-8のみの対応が、お手軽にできそうなので、Shift_JISとかも欲張って実装しちゃおうという野望。というか野暮用。
既に実装しているところがあって、それはBASE64でエンコードしてあるISO-2022-JPなんだけど、既にきちんと動いているから、参考にしたいと思う。
http://homepage1.nifty.com/glass/tom_neko/web/web_03.html#Base64
ここ↑だと、
＞ 元のデータの6bitを0～63の数字としてA～Za～z0～9+/の64文字で置き換えます。
＞ 元のデータが8bitと6bitの最小公倍数である24bitで割り切れない場合、
＞ 6bitに足りないbitには0を代入して変換し、変換後の文字列の最後には
＞ 「=」を１つないし２つ付け足して割り切れるbit数にします。
＞ 変換前よりデータサイズが一律33%大きくなります。
そうそう、少しでかくなるんだよね、メールに添付したファイルって。そんでファイルの日付とかファイルシステムに依存する部分は全部消えちゃうんだよね。そういう属性残すために、テキストをZIPで圧縮して、Base64でASCIIコードにエンコーディングして、って何か間違っている気はしてたけど。ASCIIテキストで送らなきゃダメって以前には言っていたから仕方なかったんだね。
ソースを読む。シフトとか普段はあんまり使わないからすぐにしっくりこない。
Base64の処理とメールヘッダの構造がそのままソースにした感じで、動いているから間違いではないのだけど、なんつーか今回必要となるメインとなるところの全部が、ダラダラ書かれていて、関数分割としてはうまくない感じ。人の事全然言えないけど、他のBase64のサンプルコードを読んで、始めて全体像が掴めたので、こういうコーディングはちょっと困る。同じ文字列を長いこと引っ張り回すのは私の趣味ではない。
元ネタのソースを読んでいくと、やっとメールのヘッダのフォーマットが見えてきた。普通ならRFCなどからメールヘッダのお作法を一通り読んでから、コーディングって形なんだろうけど、動いてるところをデバッガで追い回した方が、実際にやっている事が何なのかははっきりする。実際のメールのヘッダを見てみて、コードと照らし合わせると、実際の意味が読み取れてくるのだ。GUIな時代に産まれたので、GDBとかコマンドラインで使えないっすよ。まぁこのくらいの認識でもソフトは作れるってことです。
つーか、strstr_toupperedとか、ググっても世界中に一つもないと思ったら、自前で作った関数でした。こういう紛らわしい関数名をマクロとかで軽く隠蔽されても困るんだよな。やっぱり人の作ったソースって色々気になるから、できれば触りたくないんだよね。インデントとか動作には全く関係ないんだけど、キモイ見た目だと全部直すか、新しくスクラッチしたくなるもの。
とはいえ、動いているものを再検証しながら、また同じ物を書くのは色々無駄が多いので、ラッパー関数使って隠蔽するってのが普通のやり方かな。前にリファクタリングが流行った気がするけど、相当な事がなければやらない方が良い。変数名がカウンタでもないのに、一文字だけなどで情報がなさすぎで散々使われているとかはまだ分かるけど、色々へたくそなソースの大幅な改変ってのはやりたくない。
今回は比較的読みやすい部類だけど、英語以外の他の言語のコメントだったらまず触らないかも。なんか文字列探すのと、Base64のデコードと、ISO-2022-JPの操作がごっちゃになっていて、読むのが面倒臭くなってきた。ISO-2022-JP以外のデコード操作は、別途やる事にした。元ソースになるべく干渉しないようにしないと痛い目を見るし、更に読みにくくしてどうする、な状態になりそうだし。
とりあえず、ISO-2202-JPの機能をなるべく殺さないようにして、新しくShift-JISとUTF-8を読める文字列にする処理を行なった。入口はHeaderAnalizer.mの、HeaderAnalizer#popに入れ込む事にしました。シフトJISとUTF-8が全然なかったら、スルーして今までの処理をやってもらう事にします。統合する時にISO-2022-JPの上手い処理を崩してしまいそうだから、自作のC言語の関数も多めなので、下手に手を出すと不具合が生じかねない。
インプリして動かしたら、しばらくはうまく動かなかったけど、やっとメモリをやたら食う処理を直す事ができた。C言語のcharの文字列と、Cocoaで使っているNSString周りの関数が随分違っていて、Obj-C的な知識が少々必要だったので面倒だった。今更、そんな言語使いたくないよ。
文字コードが２種、MIMEエンコーディングが２種、それぞれの組み合わせで動くようにはした。とはいえ、Quoted-Printableなメールが来なくて試験ができなかったりする。Twitterのアカウントとって、自分宛にTwitterの通知メールを送って試験しようかな。
DeprecatedなCocoaの関数は、少し直したら、何だかメモリの使用料が減ったと思ったら、自分の単なる思い違いでした。バグでメモリを800MBぐらい消費しちゃったのを見てたから、今までに戻っただけですごくまともに見えてしまうのであった。続けて使うと10MBから20MBくらいに肥大してしまうのですが、少しずつ肥大してるんだろうなぁ。Obj-Cってメモリリークを探しにくい感じがするし、実際そうだからガーベッジコレクションが導入されたんだろうし。
えーと、
前に作ったブランチに切り替えて (git checkout test1)、
gitにコミットして (git commit -a -m 'hogehoge')、
GitHubに上げたい (git push origin test1)
やっとgitの実体に慣れてきた。でも、もっとお手軽なGUIツールが出てくるか、Xcodeでgitをプラグインとかで実装できないものかね。なんかそういうのって覚えきれないし、汎用性がない事ならば覚えたくない。
今度書くときは、gitのやる事はmerge作業ってことになりそう。一人プロジェクトなので、んな事気にする必要は全くないのだけれど、周りに人がそれなりにいるのを考慮できた方が良いに決まってる。そのためのgitでもあるわけだしね。
タグ：freesoft
コメント 0