とても日記なんてレベルでは更新できないので。
ここをほったらかしてはや数年(?)^^;;。ちょっと毛色が違うところで日記を書きはじめたので、リンクしておきます。
ここはだいぶ放置度合いが激しいです_o_。
既に古いですが、雑誌記事の一部(コラム)に仕様としていて入りきらなかった
やつを貼っとく^^;。
2002/6/26 に JavaMail 1.3 が公開されています。
詳細は changes をご覧いただくとして、JavaMail 1.3 では、
以下のようなコードを含めておくとすこし幸せになれるかもしれません。
/*
Message#setText() などで、文字エンコーディングの指定を
省略した場合のエンコーディング名
*/
System.setProperty("mail.mime.charset", "ISO-2022-JP");
/*
To: などにどんなアドレスが書かれていても、とりあえず
InternetAddress クラスとして取り出せるようにする
*/
System.setProperty("mail.mime.address.strict", "false");
/*
RFC2047 に完全に従っていない形式でもデコードできるようにする
*/
System.setProperty("mail.mime.decodetext.strict", "false");
また、Session#setDebugOut(PrintStream out) メソッドが追加
されています。今まではデバッグ出力を On にしていても標準出力
にしか出力されなかったため、他の表示と混ざってしまうといった
問題がありましたが、これによって、JavaMail のデバッグ情報だ
けをファイルに出力するといったことが可能になります。
届きました。まだ読む暇もないんですがT_T。
今回の記事はかなーり自身なしです。なんか当たり前なことのほかに
ちょっと反駁するようなことも書いてみた気がしますが、運用経験が
乏しいので(Servlet なんてだいぶ作ってない-_-)、主張の信憑性が
計れないかもです。
そんなちょっと恥ずかしい感じなんで、次回/次々回は気合入れないと
と思っております。次回は Servlet から離れたところなので、まとも
な記事が書けるかなっと^^;。
へろへろですぅT_T。
本業忙しくてほとんど手をつけられずにいた Majavdomo ですが、
少し進めはじめています。
http://www.li18nux.org/subgroups/majavdomo/
# ほんとここ４ヶ月は生涯かつて無い精神的忙しさな感じ。
# 8月くらいにはだいぶ変わってきていると思うので、それまで踏ん張る。
自分の会社の ML を乗っ取ろうとして思ったのは、ML の追加手順を
もっともーっと単純化する必要がありそうってこと。
今は設定ファイルをコピーして編集して、だけど、/etc/aliases の
雛形まで出してあげないとなぁ。
そういった運用上の手続き面以外では、さしたる問題もなく運用出
来そうな感じ。みんなも使ってぇ
んにゃ。今日は Servlet-WG-meeting じゃないかぁ。
なにしゃべるか全然まとめてないや…。
ここんところ忙しくて、Majavdomo も全然手をつけられて無いしT_T。
ちなみに発表は
http://www.sk-jp.com/java/library/skutility/textformatter.html
これについてなんですが、正直もう二年前のものだし、今の数多の
フレームワークをほとんど知らない身としては、何についてプッシュ
すればいいのかいまいち解って無い状態^^;。
自分ではシンプルでそれなりに使いやすいと思ってるんですけどね。
大規模なのに対応できるのか検証してないしなぁ…。
後に続く皆さんの発表に期待しよう。
ちょうど一念ほど前に[JavaHouse-Brewers:39058]こんなことを書いていたりしたかも。
Mozzilaはちょっとソースを見る限りでは、RFC2231はまったく意識していないように
見えます。# ちゃんとみてないです。直接レスポンスヘッダを解釈する部分がどこか
わかんなかったので適当に^^;
おそらく渡されたバイト列をそのままクライアントの保存ダイアログボックスに表示
するんじゃないかなぁ。そうするとShift_JISコードで書いてしまえば一応ちゃんと
でてくれても良さそうなものですが、ちゃんと出ないのかな?
結局この件も数年前から言われていつつもまったく統一方針が無いということでしょうか。
取り合えずShift_JISの場合、2バイト目に妙なコードが入るとおかしな挙動になって
しまうし日本限定になってしまうしなので、やはりここもUTF-8とはっきりいっちゃえ
ば良さそうなものなんですけどねぇ。
ふー、原稿締め切りすぎてるのにまだ出来てないしー、JavaOneに
誘っていただいたのに、泣く泣く諦めていながらその原因となる
本業とともに進みがよろしくないです。
そういう時に限って逃避の口(掲示板とか^^)をチェックしていたり
するのね…。
なんだかそろそろ個人の環境がWindows98じゃどうしようもなくな
りつつあり、とはいってもなかなかお金出してWindows2000以降を
買う気になれず、Free UnixはDatulaがないし…。
# Sylpheed等は操作性/機能ともDatulaの粋には足りず。
とはいえ今自分をWindowsに引き止めているのはDatulaと秀丸エデ
ィッタくらいかもしれない^^;。でもうっかりしてるだけで他にも
あるかも…。慣れとは恐ろしや-_-。
さすがに原稿落としかねない気配なのでちょっとそっちに力を入れなきゃ
モードT_T。
しかし、ボランティア活動もまさにがんばり時って感じだし、退職前に
区切りつけなきゃなぁ。
今月発売されるJavaPressにServlet Filter関連の記事を書いたんですが、
書き漏らしというかサンプルプログラムのバグがありました^^。
GZIPEncodingFilterなるものを書いていまして、Accept-Encoding: gzip
の場合にgzip圧縮したレスポンスを返すようにするというものなのですが、
圧縮を実施した場合にVaryレスポンスヘッダを付けるべきだったのに、
そのことを知らずに付ける処理を忘れてました^^;。
response.setHeader("Vary", "Accept-Encoding");
こんな感じですか。
Varyを付けておけば、キャッシュをともなうプロキシサーバなどで、返送
データが通常時のレスポンスと異なることを認識してキャッシュ方法を変える
(通常時のものとは別個にキャッシュするなど)ことが可能になります。
が、プロキシサーバ自体もこのレスポンスヘッダを解釈しないものが多いら
しいので、効果のほどは解りませんけど^^;;;。
HTTPもいろいろ機能が増えてますねぇ。
去年の6月にJava-Houseの有志が集まって始まった、Majavdomo projectと
いうメイリングリスト管理システム開発プロジェクトがあるのですが
(6/13にも少し書いてます)、公開されてますねぇ…^^;。
http://java-house.etl.go.jp/majavdomo/
# li18nux.orgですよ!
まだどこにも正式なアナウンスはされていないのですが、検討中ということで_o_。
公開が遅れたことの多く(というか鍵)は私の意識/考え方の問題にありまして、
プログラム自体は一年以上前に取り敢えず動くものがあったのですが、
私のやる気ばかりが先行して、他の方の動きを封じてしまっていたのですねT_T。
たくさんのありがたいアドバイスをいただきまして、今後は意識を新たに進めて
いきたいところです。正式なアナウンスも考えなければならないのですが、
現在でも新規開発者の参入は可能になっていますので、興味を持たれた方はどうぞ。
MLもMajavdomoで運用していますし、先行して誰か入ってくるかな?^^
もうここのところJavaMail完全解説の補足に書く事項も溜まっているにもかかわらず、
全然記述/更新出来ない状況です_o_。
当面JavaMailに関する追加情報等は掲示板の方で行っております。ということに_o__o_。
皆さんの御協力のおかげで、掲示板の内容はJavaMailについての
結構質の高いデータベースになってきていると思います。
大変ありがたいことですぅ。
BBSスクリプトが大量記事の保管に向いていないという問題があったりするんですが、
これもそろそろ対策を考えないとかも…。
# ほとんど月記と化していますが^^;
JPhone SH-07の送り出す画像添付メイル(写メール)が不正なため、JavaMailで
デコードできないという問題があるようです。
http://www.sk-jp.com/cgibin/treebbs.cgi?all=179&s=179
multipart/*のパートがbase64エンコードされていると宣言しているくせに、
実際にはそんなことはしていないというものです。
Becky!などは受信可能だそうで、これはすなわち、multipart/*のパートが
エンコードされているわけが無いとたかをくくった実装をしていたのか、あ
るいは、すでにJPhoneのような不正なメッセージが流れていることを発見し
てそのような対応を取ったのか…。
携帯電話なんて一度不正なメッセージを送出する状態で流通したら、もう受
信側が対応しないといけないわけで(致命的な問題なら回収にもなるでしょう
けど)、うっとおしいったらありゃしないって感じですね。
大体こういうもののテストってRFCのような約束事よりも流通しているメジ
ャーなMUAで正常に受信できるか?でしか見られていないんじゃなかろうか?
と勘ぐってしまいますねぇ。
忙しい上にネタも湧いてこないのでずっとここを更新できていませんT_T。
やっぱせっかく書くなら、読む価値のある内容にしようなんてことを
考えるから駄目なんですが…。
いま、某文書書きに追われています。それに関連して、自分の業務と全く
無関係なJSPの文字コード問題とかHTTPのUTF-8統一の話題とかを、調べ
たり聞いてみたりしてみたりして^^。
世の中の動きは速いようでいて、一度普及した技術が変わりゆくのは案外
ゆっくりなんだなぁと実感。
あーやっぱり落ちない。こんな価値のなさそうな文が許されていいのだろうか。
今日は娘の一歳の誕生日です。が、未だ写真のアップロードは出来ていません。
最近はゾンビの様に手をばたばたさせながらよって来るのでなんか嬉しい。
週末などなかなか目が離せないので、子供の相手をしているだけで作業もろく
にできずに終わってしまいます。
それはそうと、今日はMajavdomo Projectも一歳の誕生日ということになります。
http://java-house.etl.go.jp/majavdomo/
情熱と現実の生活との板挟みといいますか、クローズドで進められてきていて外
向きにはどうなっているかわからないわけですが、みんなボランティアというこ
ともあって、自分たちの本業が忙しい時などなかなか手をつけられない時期もあ
りましたが、物自体は最低限の機能が動く状態になってきてます。
もうすぐ公開されるかもね。
# と独り言のページで言ってみるテスト。
あーついに私もTomcat環境に移行を開始することにしてしまいました。
ずっとJServと仲良くやってきたのですが、公開してるライブラリを
JServのみ対応といつまでも言ってられない状況になってきましたので。
でも、今無料で使わせていただいている忙サーバがTomcat環境になるのは、
管理者殿多忙ですのでそんなにすぐというわけにはいかないはず^^;。
その間にスタンドアローン環境で勉強させていただきます^^。
最初、WebApp形式を見た時はとにかく面倒くさそうという感じで見て
たんですが、Tomcat3.3m2を導入して使ってみたところ、WARファイル
を所定のディレクトリに置くだけで、Webアプリケーションが実行でき
るようになってるんですね。
サーバ側の設定は全くいじらなくても大丈夫でした。そういうのを目指
して、Class#getResource()でCLASSPATHからリソースや設定ファイル
を読むように実装していたのが無駄になったようで良かったです。
さて、まずはServletAPI 2.3とJSP1.2のお勉強から参りましょうかね…。
# 本業があまりにこの辺と無関係だからなかなかねぇ^^。
はい。いままともに動いていません_o_。
家に帰ったら直しますぅ。
昨日の夜アップロードした時は、この週記の入力ページのレスポンスの
Content-Typeが charset=ISO-2022-JPになってしまってました。
このサイト自体はISO-2022-JPをベースにしていたからそうなるわけ
ですが、CGIにISO-2022-JP文字列を埋めておくとperlが正常にparse
できないため、EUC-JPで書くか迷ったのですが、Shift_JISで書くこと
にしました。
で、CGIにPOSTするFORMをShift_JISで書いていたのですが、先頭に
書いた通り、レスポンスヘッダはISO-2022-JPだったというわけです。
ブラウザ(IE)はレスポンスヘッダと内容が食い違っていても、自動認識
でShift_JISと認識していました。しかし、POSTされたデータは
ISO-2022-JPコードだった為、Shift_JISの週記中にISO-2022-JPの
コードが交じってしまったのでした。
# 現在は壊れた部分は直してしまっているのでどういう現象か解りにく
# いかも知れませんけど^^
Tips
/.htaccessに
AddType "text/html; charset=ISO-2022-JP" html
と、そのディレクトリ配下のhtmlのcharsetを指定しておけば、
Apacheがレスポンスヘッダでこのcharsetを宣言してくれるので、
<META>タグやブラウザの自動認識に頼ることなく、正確なエンコーディ
ングをブラウザに教えることができます。
また、IEの場合、レスポンスヘッダで返されたエンコーディングは、
次回のPOST時のエンコーディングとして使われます。これには実際の
コンテンツのエンコーディングは関係しないようです。
もう、UTF-8にするならするでばしっとやっちゃえばいいのに。
UTF-8で送信する時はリクエストヘッダで宣言するようにすれば、既存の
ごちゃまぜ日本語エンコーディングとの区別も付くと思う…。
「変数」それは変わり得る数…。
昔BASICやってた頃から「箱」という説明をたくさん見てきました。
箱にはさまざまな値を入れることができ、変数を参照する(ソースコ
ードに記述する:より厳密には右辺値として)と、その箱の中身を参照
することになる、すなわちその値はそのときどきに応じて変わり得る、
と。
Javaの場合もその説明は成り立ち、a = 1;と書けばaという名前の箱
に1という値が代入されます。
でも、a = new Object();と書くとaという名前の箱にObjectクラス
のインスタンスが代入されるわけではありません。
この説明として一般的なのは、「オブジェクトへの参照が代入されま
す」ってやつ。しかしこれは理解しにくいだろうなぁと常々思います。
でも、「オブジェクトへのポインタが代入されます」と言えば、ある
向きにはすごく自然に理解出来ると思われます(自分はそのクチ)。
初学者向けの説明方法を考える時皆さんどうしてます?
ある方(Ruby方面)の説を元に自分なりに解釈した考え方おば。
ただし、これは「全てがオブジェクトで全てが参照」という言語でこそ
自然ですが、Javaではprimitive typeがあるので一貫した説明にはなら
ない、reference typeでのみ使える考え方であることを予めお断りして
おきます。
まず、reference typeの変数とは、オブジェクトに付ける名札と考えら
れます。変数名が名札の名前(ラベル名)です。
Canvas banner = new ImageCanvas();
とあればImageCanvasオブジェクトに対して、bannerという名前の書かれ
た名札を付けて、これからその名札はここでnewしたImageCanvasオブジ
ェクトとして使いますよ、というふうに宣言的に解釈します。
new ImageCanvas()という記述は、ImageCanvasオブジェクトを作成はした
けど、まだどのような名札も付けられていません。
オブジェクトはぷかぷか浮いた状態です。
この状態のままだと、それがThreadのような自立的なオブジェクトでなけ
れば、そのままGCの対象(いつかVMに昇天させられる)です。
そのオブジェクトを使いつづけるためには、そいつに対して名札を付けて
名札越しにアクセス出来るようにしてやらなければなりません。
banner = new ImageCanvas();
これで取り合えずbannerという名札が生きている間はImageCanvasオブジェ
クトにアクセス可能ということになります。
bannerという名札を付けられたオブジェクトに対して何か要求を出す場合は
例えば、
size = banner.getSize();
のように書けばいいわけです。
bannerという名札を付けられたオブジェクトに、さらに別の名札を付けるこ
ともできます。
Component part = banner;
同じ感覚でメソッドのパラメタに渡す時にも、bannerという名札を付けられ
たオブジェクトにメソッドの仮引数である名札を付けることになります。
:
foo.addComponent(banner);
:
void addComponent(Component component) {
:
}
この場合、ImageCanvasオブジェクトには、banner/part/componentという三
つの名札がついたことになります。どの名札を使っても同じオブジェクトに
アクセス出来るわけです。
こういうイメージでのメソッドの引き数受け渡し機構をcall by sharing
(共有(というパラメタ受け渡し方法)による呼び出し)と呼んだりします。
ここまでどうでしょう?
次に(ちょっと変数から離れますが)call by sharingの方から話を広げて、メ
ソッドの戻り値についても考えてみます。
:
Foo foo = getFoo();
:
Foo getFoo() {
Foo result = new Foo();
:
return result;
}
登場するのはFooオブジェクト一つです。説明のためにresultという名札を付
けてみました。ここもcall by sharingの考え方で見てみると、Fooオブジェク
トはメソッド内部で生成されて、呼び出し元のfoo変数と共有されると考える
ことができます。resultという名札が付けられていたオブジェクトに、fooと
いう名札も付けているわけです。
(もちろんgetFoo()メソッドのローカル変数はいなくなってしまうので、Fooオ
ブジェクトに付けられていたresultという名札は剥がされるんですが)
まあ、なんにしてもオブジェクトというものと変数(名札)というものの違いは
箱という説明よりも解りやすいかなという気になってます。
しかしJavaの場合はprimitive typeなんてものがあるのでしたT_T。
あーあこんなに書いたのに^^;。
なお、この説明の元となる文書は以下です。前田さんありがとうございます。
# 勝手に感謝
http://galaxy.rwcp.or.jp/text/cgi-bin/newsarticle2?ng=fj.comp.oops&nb=4293
やば。壊した…POSTがISO-2022-JPになっちまってる…
家に帰らないと直せないよーT_T。
この日記システムを自作のものに作り替えました。
はじめてperlでらしいプログラムを書いた気がします。
しかしまあ、なんちゅうかハンドアセンブルが必要な言語ですね…。
1バイトでも短く書けるようにする為なら命でも投げ打つと言わん
ばかりの言語仕様だ…。っという印象(ファンはいるだろうし^^;)。
三ヶ月もperlコードを書いていない時期があれば、すっぱりあの
記号群は忘れることができるのではないでしょうか。
# それでもシェルスクリプトよりは扱いやすいんですけど。
ほんとはRubyで書きたかったんですが、このレンタルサーバは
Rubyは使えないのでした…。
# PHPは使えるけど^^;
本日はネポルに来ております。
@see http://www.netpotlet.com/
現在潜伏人数5名、これからおちゃら|ナプログラマ達がさらに続々集まる模様。
さーて、銀座にまいりますか。
集まる人々は以下から半数＋αの豪華メンバです。たのしみたのしみ。
http://www.ocharake.org/members/
昨日の夜勢いで侍魂全部読んじゃいました^^;。彼は大した才能です。
うらやましい。
# どんどん技術ねたからそれてゆく
ここに書けるようなネタが次々に出てくるほど発想が豊かじゃない
ことを思い知ってますT_T。
侍魂
http://www6.plala.or.jp/private-hp/samuraidamasii/index.htm
とか、ろじっくぱらだいす
http://www.juno.dti.ne.jp/~logicp/index.html
とか、毎日よくそんなにおもろいことを考えていられるなぁと感心しきり^^
所詮プログラマーだねおいらは。
下のを書いた後外に出ていて書けませんでしたが、結局のところ日本語的には
BackReferenceは「後方参照」と訳すのが正しいといえそうです。
(そりゃForward=前、Back=後だもんな、forward referenceを後方とは訳せまい)
でもBackReferenceを前方と訳しているものの方が多く、しかもそれは結構浸透
してしまっている気がしますねぇ。
ネタ提供(って勝手にネタにしちった)は前橋さんなり_o_。
前方参照といえば何を思い浮かべるでしょう?
最近の人なら正規表現のBackReferenceを想像して「手前に書かれていたもの」
を参照出来ること、となるかもしれません。
(私も最近正規表現をよく使うようになったのでそういうクチ)
しかし、プログラミング用語としては前方参照はまだ処理されていない部分
(前方=前の方)を参照する、すなわちC言語などで関数定義より先に関数呼び
出し文が出現した場合のことを指します。
Javaの場合前方参照が可能なので、クラス内のメソッドの定義位置はコンパ
イル時に何の影響も与えませんね。
ここで言う前方参照はForward Referenceのことになります。
しかしこれって…困ったもんだね。
BackとForwardが日本語にされるとどっちも「前方」とは…。
さっそくぽかをやったというか、Message#reply(true)メソッドの挙動は
一応そういう挙動(宛て先の設定)をするMUAも実際にあるようです。
私の使っているDatulaでは「全員に返信」という機能がなく、必要性も全く
感じていなかったし、返信先を希望してるにもかかわらず、その他のアドレ
スも列挙されるのは気持ち悪いので、まあ気にも止めないものではあります
が、全くおかしいというほどのものではないということでした。
# 良かった補足に入れなくて^^
でも結構こういうのはMUA毎に個性がある部分なのに、JavaMailでreply()
を使う限りそういった挙動が強制されることに変わりはないですので、結局
reply()メソッド相当機能は自分で実装しましょういう主張にも変わりは
ないす。
JavaMailの補足に書く為のメモがわりに^^。
Message#getReplyTo()メソッドは、書籍でも触れた通りReply-To:が
存在すればその内容を返しますが、存在しない場合はなんとFrom:の内容
を返してくれちゃいます。
これは、滅入る^H^H^Hメイルクライアントを作成することを想定しての
挙動ですが、さらに突っ込んで、悪しきreply()メソッドについて見てみ
るます。
Message#reply(true)では、全ての宛て先を返信メッセージに含める、
という仕様です。このメソッドは内部的にgetReplyTo()を用いて返信時
の宛て先を生成するのですが、reply(true)だと、Reply-To:が指定され
ていても全ての宛て先を返信アドレスに含めてしまいます。
少なくとも日本では、Reply-To:はそのアドレスに対してのみ返信を希望
すると言う意味で利用されており、Reply-To:が指定されている時に、
他のアドレスが送信先に含まれるようなMUAは見当たりません。
本に書きそびれたMessage#reply()って使えねーを補強するネタでした。
おわり。
補足とするまでもない駄文だからここだけでいいか^^。
トップページにもひっそり紹介している、ブラウザ脆弱性リポートと、
セキュリティ意識調査のアンケートのページですが、最近、
http://itpro.nikkeibp.co.jp/members/NNW/NETHOT/20010309/1/
「インターネットの怖さはどれくらい？ セキュリティ・ホールを“体験”する」
このように紹介されているらしく、再びアンケートへのアクセスも増えているようです。
集計作業の方はもうしばらくしてからおこなうとのことですので、回答していらっしゃ
らない方は是非ご回答くださいませ。
トップページからアクセス出来ます。
http://www.sk-jp.com/
逆に、回答してるのにまだ集計結果出さないのかーという方、すみません。
もう少し後になるそうです。
今週から心機一転といいますか、Majavdomo開発を再開します。
そのために、ため込んだ作業を片付けないといけないのですが、
ひとまず、これまたやはりできていなかった、書籍で公開すると
いっていて未だに準備できていなかったライブラリの公開を行
いました。
http://www.sk-jp.com/book/javamail/
http://www.sk-jp.com/java/library/
今日はもう本業をしないとT_T。
作業を止めているものがあるにもかかわらず、TODOが溜まっていく
という事は、ようするに作業を受け過ぎているということです。
自分の尺度と責任感が甘かったせいで関係者の方にご迷惑をおかけ
してしまい申し訳無い事です_o_。
書籍のサポートをやっていけるようにする為に掲示板を取ってきて置きました。
http://www.sk-jp.com/book/javamail/
この掲示板と、この日記スクリプトをきっかけにずっと逃げていたPERL
も再確認し始めています。
# このレンタルサーバもPERLかPHPなのね…。
# Servletつかえりゃねー。
この日記用スクリプトもちょっとした改造で正誤表とかにも適用できそう
ですので、余力が出来たらやってみたいと思います。
本は売れてるかな…(噂ではその筋には結構売れているらしい^^)。
娘が40度の熱を出してへらへら笑っているのを看病?する為に
会社を休んだら自分が発熱しましたT_T。
書籍にはサンプルコードはWebから取得出来ると書いたにもかかわらず、
未だドキュメントの準備が出来ておらず掲載できていません。
ライブラリを公開してしまうと、以降簡単にはインターフェイスを
変えられなくなるので(おいおい^^)、吟味中ということで。
すみませーん。