2003年1月
2003年1月30日(木曜日)
大量
大量の spam メールを受け取ってげんなり。軽くFMHPG 全フォーラムを除名されておつりが来るくらいの量。
ちょっと頑張って spam 警戒エージェントを作ろうかしら……。
- 「大量」にコメントを書く
2003年1月29日(水曜日)
2003年1月28日(火曜日)
Another HTML-list Gateway
"n" のキーと "s" のキーってけっこう離れたところにあるので、Another HTML-list Gateway って typo は難しいんじゃないかと思います。
しかし google で検索すると 4件ヒット。うち 1件は被害者なので、全世界に 3 人くらいはそういう typo をする人がいるらしいと……。
適用出来ないはずのパッチ
「.NET Framework SDK からインストールした MSDE に対し SQL Server 2000 Service Pack が適用できない (support.microsoft.com)」。そんな、それでは私が適用した SP3 はいったい……？ ちゃんとバージョンも上がっているし……。
と思いつつ「プログラムの追加と削除」を見ると、SQL Server 2000 Desktop Engine のエントリが 2つあります。ssnetlib.dll も 2つあって、ひとつは SP3 のもの、もう 1つがセキュリティホールを含む古いもの。
とてつもなくいやーんな感じなので、いったんアンインストールしました。
再インストールはしないの。
2003年1月27日(月曜日)
謎の住所
spam 発信源を whois で調査したら、こんなのが。
Registrant:
International Racing Federation (IRFJ-DOM)
22 Cayon Street
NO CITY, NO STATE 99999
KN
NO CITY, NO STATE って……。
パーソナルファイアウォールに助けられる
なんと、うかつにも UDP ポート 1434 が開いていました。.NET Framework SDK のサンプルをインストールすると Microsoft SQL Server Desktop Engine を入れさせられたりするのです。バージョンを見ると 8.00.384 。駄目じゃん……。
パーソナルファイアウォールのログを見たら、1434 のドロップのログがたくさん。ああ、XP で良かった……。
というわけで問題なかったのですが、やはり放置は良くないので、Microsoft SQL Server - ダウンロード - SQL Server 2000 Service Pack 3 (www.microsoft.com) にアクセスして「MSDE 版」の SP3 をダウンロード。74MB というとてつもないサイズにくじけそうになりながらも、なんとか入手しました。
で、インストールしようとしたら、sa_password を設定しろと怒られてインストールできず。いろいろ調べた結果、インストーラに SAPWD= というパラメータを指定してやれば良さそうだったので、コマンドラインから setup SAPWD= と入れてインストール。これでとりあえず大丈夫でした。
※ホントはパスワードを設定した方が良いらしいですが……。
そして最後に、勝手にスタートアップに登録された SQL Server 起動のショートカットを削除して完了。
なんか、要らない物を勝手に入れさせられたあげく尻ぬぐいばかりさせられているような気がするのは、私の気のせいですよね。
2003年1月26日(日曜日)
恐怖のフォーム
とある銀行の新規会員登録フォームで、ID とパスワードを入力しろ、と求められました。入力項目の説明文は以下の通り。
ID、パスワードは1～15文字の半角英数字で入力してください。
パスワードは自分で決めれば良いのでしょうが、ID はどうやって取得すれば良いのでしょうか？ 戻ってみても ID 取得手続きなどはどこにも書かれていません。銀行なので口座番号が ID なのかとも思いましたが、口座番号の入力欄は別途存在していて、それが ID であるような記述もありません。
しばらく悩みましたが、ID も自分で勝手に決めるシステムなのだと判断。適当に "bakera" と入れて進めることにしました。結果的にこの判断は正しかったようですが……。
問題はその次。チャレンジクエスチョンの入力が必須になっていたのですが、こんなものは百害あって一利なしだと思っているので、誰にも回答できないような内容を入れて実質的に使えないようにしようと判断。特に長さ制限はないようだったので、かなり長い文字列を入力して次のステップに進もうとしました。
ところが、これがエラー。チャレンジクエスチョンの長さは 100 文字までだと怒られてしまいました。そんなこと入力フォームのどこに書いてないんですが……。この時点でかなり頭に来ますが、仕方なく削ることにしました。エラー画面には先ほど私が入力した内容でフォームが再出力されていて、その場でそのまま訂正出来るようになっています。そこで、チャレンジクエスチョンを削って次へ。
※実はこのエラー画面には一つ大きな問題があったのですが、この時点ではうかつにもそのことに気づきませんでした。
で、一通り入力したら「メールアドレスにメールを送ります」との表示。即座にメールチェックしましたが、来ていないので、しばらく置いてからメールチェックすると、来ていました。なんか、Errors-To: フィールドに知らない人のメールアドレスが入っているのですが……。
受信側のサーバがたまたまビジーだったりしたら、登録者のメールアドレスがその知らないところに送られる可能性があります。
※まあ、これは別に個人情報の盗み取りが目的で設定されているわけではないでしょう。システムのデバグ担当者が自分のメールアドレスを Errors-To: に突っ込んでいて、本番運用の際にそれを外すのを忘れているのだと思います。
※ちなみに、Errors-To: フィールドは RFC2822 では定義されていません。これに対応していないメールサーバも結構あります。
で、メールに書かれていた URL から登録手続きを行います。ID とパスワードを入れれば良いのですが、ID 入力欄に ID を入れてから tab キーを押したら、何故か submit ボタン (……だと思うのですが、ボタンが画像になっていて、私は画像を表示していなかったのでラベルは読めませんでした) にフォーカスが移りました。もう一度 tab キーを押してパスワードに有力欄にフォーカスを移し、パスワードを入れます。ここで反射的に tab を押したらどこか変なところにフォーカスが移ってしまったので、Shift + tab を二回押して送信。
いろいろありましたが、ともかく登録は出来たようなので、ログインフォームへ。そこにはこんな事が書いてありました。
cookieの設定はブラウザ上で行ってください。
……ええと、何をどう設定すれば良いのでしょうか。IE6 の場合はサードパーティ Cookie を受け入れるように設定しろとか、そういう話なのでしょうか。本気で詳細はどこにも書かれていないようなので、途方に暮れるしかないのですが……。
とりあえず、ID とパスワードを入れてログイン。
すると、「セキュリティ保護されていないところにリダイレクトしようとしている」という警告ダイアログが出現。パスワードがどこか知らないところにリダイレクトされては嫌なので、キャンセルします。
……何も起きず……。
Cookie の設定をしなければならないのか、それともリダイレクトを受け入れなければならないのか、よく分かりませんが、ともかくダメなようです。
終了。
……後日談。何気なく IE の履歴を見ていたら、この銀行の新規会員登録フォームの履歴が残っていました。何気なく表示してみたらびっくり仰天。なんと、フォームのパスワード入力欄が既に埋まっています。ソースを見ると、パスワードが生で書かれています。
恐ろしいことに、入力エラー時の訂正用フォームのソースには、生パスワードがそのまま出力されているのです。しかも、それがキャッシュされないような措置をいっさいしていません。
私のこのマシンは私しか使わないでしょうから問題ありませんが、共有 PC ではこのような事態は脅威となります。私が公共施設やネットカフェなどの公共の端末からこの申し込みを行っていたとしたら、と思うと戦慄が走ります。私が立ち去った後、他の誰かが履歴を見てソースを表示すれば、それだけでパスワードも ID も知られてしまうのですから。
関連する話題: 出来事 / コンピュータ / ネットワーク / Web / セキュリティ / ユーザビリティ / アクセシビリティ
2003年1月25日(土曜日)
パスワード破り大作戦
ご存じの方はご存じの通り、私は ASAHI ネットのユーザなのですが、なんでも只でメールアカウントがもう一つ持てるようになったらしいので、それを確認するべく ASAHIネットのサイト (www.asahi-net.or.jp)へ。そしてログインしようと思ったら……なんと、パスワード忘れてるっ!!
思い起こせば、去年の年頭くらいにパスワードを変えた記憶があります。しかし、そのパスワードが全く思い出せません。その前のパスワードは覚えていたので、念のために試してみましたが、やっぱりダメ。ってあたりまえなんですが。
実は FTP と POP3 については使っているクライアントにパスワードを記憶させていたので、問題なく利用できていたのでした。ちなみに PPP 接続にはパスワードを記憶させていなかったことが判明。まあ POP3 と FTP が使えていればとりあえず問題ないのですが、利用状況の確認も出来ないと言うのは気持ちが悪いです。というわけで、パスワード破り大作戦開始。
最初に思いついた戦法は、パスワード入力フィールドの内容を盗み見るというものです。FTP クライアントもメールクライアントも、パスワード設定画面の入力欄には「*」が表示されていて、パスワードそのものを見ることは出来ません。しかし、これはあくまでそのような表示になっているというだけで、内部的にはちゃんとパスワードの文字列が保持されているのです。
その、内部的に保持されている文字列を表示してしまうソフトがいくつかあります。私が昔使っていたのは、その名もズバリ「みえみえパスワード」というもので、名前通りの効果がありました。これはフリーソフトウェアなので、遠慮なくダウンロードして実行。
……起動はしましたが、パスワードは見えませんでした。どうも Windows XP ではうまく動作しないようです。「みえみえパスワード」以外にもいろいろなソフトウェアを試してみましたが、どれもうまくいきませんでした。Windows XP では、パスワード入力コントロールの仕組み自体が変更になっているのかもしれません。
というわけで、第一の戦法は失敗。しかし諦めません。そもそも、パスワード入力欄に「*」で表示されているパスワードは、ハードディスクのどこかに記憶されているはずです。表示が読めないなら、その大元のデータを読みとる方法があるはずです。
そこで第二作戦、名付けて「パスワードを元から断つ！」……って
まず FTP クライアントの方ですが、ホストのデータを独自のデータファイルに保存していました。これはバイナリデータですが、テキストエディタで開くと、ディレクトリのパス、ユーザ名、ホスト名などが読みとれます。期待しつつ探してみますが、パスワードらしきものはどこにもありません。試しに適当なホストの設定を追加してみましたが、やはりそれらしきものはありません。どうも、パスワードは生の文字列として保存されるわけではなく、何らかの変換処理が施されたバイナリデータとして保持されているようです。
FTP サーバには生のパスワードを送らなければなりませんから、非可逆のハッシュ変換ではないはずです。頑張って解読すれば解読できそうですが、とんでもない時間と労力がかかりそうなので断念しました。
そんなわけで、メールクライアントの方を調べます。こちらはすぐ分かりました。レジストリにその名もズバリ PassWord というキーがあって、文字列の値が指定されています。ただ、生のパスワードではないようです。使われている文字の種類や、末尾に = があることから考えて、Base64 でエンコードされていると判断しました。
Base64 デコードのツールはいっぱいありそうですが、探すより書いた方が早いような気がしたので、適当に C# で書いてデコード。パスワード文字列が得られるかと思いきや……バイナリデータでした。これも何かの変換処理がなされているようで、さすがに一筋縄では行かないようです。
……これは再発行のほうが早いか……と諦めかけたそのとき、第三の戦法が天啓のようにひららめきました。
サーバには生のパスワードが送られているのだから、サーバをつくってパスワードを受け取れば良い！
どう考えても FTP は面倒なので、ねらうのは POP3 です。計画は以下の通り。
- ニセの POP3 サーバを作る。こいつは POP3 サーバのふりをして応答し、クライアントから送られてきたデータをすべてコンソールに表示する。
- メールクライアントの設定を変更。パスワードなどは変えずに、POP3 サーバだけ変更してニセのサーバを指定する。
- メール受信作業を行う。これでニセの POP3 サーバに PASS コマンドとともにパスワードが送られるはず。
というわけで、RFC1939 を見ながら、C# でニセ POP3 サーバをプログラミング開始。.NET Framework SDK の文書の中にポート 11000 を Listen するサーバのサンプルがあったので、それをベースにして改造します。と言っても、まずは適当なバナーを出力して、あとはなにか受け取るたびに "+OK" と言ってやれば良いだけなので簡単です。……と言いつつ、Socket にもデリゲートにも慣れていないのでちょっと難儀しましたが、とりあえず完成。
一発完動など望むべくもないわけで、試行とバグ取りを繰り返しながら何度もチャレンジ。何度目かのチャレンジで、とうとう奴の送る PASS コマンドがコンソールに表示されました。そこに表示されたのは紛れもない、見覚えのある生のパスワード。
思い出したっ！
というわけで再発行せずに済みましたが、こんなのでモロに生のパスワードが見られちゃうなんて、POP3 ってコワイですね……。みなさん APOP 使いましょう。
レベル上限判明
天使のプレゼント (www.amazon.co.jp)
ちなみにレベル 9999 になったのはエリンギャーで、そのときの経験値はだいたい 3333億くらいでした。
2003年1月24日(金曜日)
凍結耐性希望
24日 0時を回ってからの話。結局バスがなくて延々歩いたのですが、昨日の朝方降っていた雪の影響で、路面があちこち凍結していてこれがまた滑る滑る。
朝になって起きてみたら、身体のあちこちが変な風に痛くて参りました。
頭に来る
知っている人は知っていると思いますが、私の一番頭に来るパターンの一つが、「HTMLなんて簡単だ！」などと言いながらいい加減な用語で人に嘘ばかり教える、というパターンです。昔は、初心者には「タグ」と「要素」の概念を一緒くたにして教えた方が良いと本気で主張する人がそこら中にいたりして、それなりにエキサイティングでした。
記憶があやふやですが、C言語についても「初心者向けと称する本に限って不正確な記述が多い」という記述をフィンローダさんがどこかに書いていたような気がします。それと同じようなことが HTML にも言えるのでしょう。
それでは、それと同じ状況が HTML ではなく、XML で発生したらどうなるのでしょうか？ これが、なんと HTML の時よりもさらに頭に来ると言うことが判明しました。HTML の場合はひどい解説書がたくさん出回っていたので、まあそのような解説書で学んでしまったのなら仕方ないか、と思わせる面がありましたが、XML の場合はそんなにひどい解説書が出回っているとも思えないのです。私が知らないだけなのかもしれませんが、少なくとも私は、「タグ」と「要素」の概念を取り違えている XML 解説書を見たことがありません。
ああ、それなのにもう……。
諸事情によりあまり詳しく書けないのが残念ですが、ダイジェストとしては以下のような感じ。
- 仕様書に頻出する「子タグ」とか「親タグ」っていったい何？
- ある「タグ」の「要素」は空にすべしなんて書いてあります。意味不明。要素の内容を空にすれば良いのかしら。
- ある「タグ」の「子タグ」は PCDATA らしい。要素の内容が #PCDATA だと言いたいのかしら。
- 文書型宣言をつけろと書いてあります。それは良いですが、ローカルでは文書型宣言を消しておけというのはどういう事？ 確かに DTD が無いからローカルでは Validate 出来ないんですが、アナタが DTD を配布すればそれでいいでしょう？ 内容は仕様書そのもので良いのですから、秘密でも何でもないはずですし。ひょっとして、DTD は恥ずかしくて見せられないの？
で、こういう事をやりながら「XML は簡単なのですぐ習得できます」とか書いちゃってるんだから頭に来ます。まずアナタが XML を習得してください。
2003年1月23日(木曜日)
横綱に土
ブラウザが落ちたとき、警告ダイアログなんか出ずにいきなり大相撲の画面になるというのは、ある意味良いのかもしれません。最低限、何が起きたのかだけ分かるように、横綱に土が付くシーンで固定にしておくとか。
サイトを閲覧していると、突然横綱が投げられるという……。
2003年1月22日(水曜日)
クロスサイトスクリプティング脆弱性
シェアウェアとして売られているログアナライザの CGI に、クロスサイトスクリプティング脆弱性を発見。はからずも、昔えむけいさんのサイトにあったログアナライザと全く同じタイプの欠陥でした。
※スクリプト無効環境を考慮している分だけ、えむけいさんのやつの方が優れていたと思う。
しかし、こんなの売るかなぁ……。素人目にはこういう品質なんて分からないのでしょうから、知らずに買ってしまう人がいたりするのかもしれません。
関連する話題: コンピュータ / プログラミング / セキュリティ / クロスサイトスクリプティング脆弱性 / もののけ / えむけいさん
バージョンナンバーのインクリメント
META の中にこのリソースを生成した Hatomaru.dll のバージョンを出力するようにしました。で、ちゃんとリビジョンが更新されていないとみっともないので、ソースの中から AssemblyVersion 属性を探し出して、その値をインクリメントするプログラムを作りました。
そしたら師匠のむらまささんに、ビルドとリビジョンの指定には * が使えると言われて、がーん。やってみたらホントに使えてがーん。
もっとも、Visual Studio .NET と Visual SourceSafe を使用したチーム開発 ビルド プロセス (www.microsoft.com)なんかを見ると、自動増分にもそれなりにデメリットがあるので手動でやるという手もある、みたいなことが書かれていて、まあそれなりに救われました。せっかくなので、コンパイルするごとに一つずつ増やして行くことにします。
2003年1月21日(火曜日)
System.Uri の MakeRelative
System.Uri.MakeRelative() は対象の URL とベース URL のスキーム、ホスト、ポートが一致しているとクエリストリングをばっさり切り落としてくれるのですが、一致していないとクエリストリングがそのままだったりするのではまりました。内部で何をしているのか何となく分かりますが……。
しかもその際、返ってくる文字列が AbsoluteUri ではなく ToString() なのがスゴイ。以下のようなコードを実行すると……
Uri baseUri = new Uri("http://www1.example.com");
Uri targetUri = new Uri("http://www2.example.com/foo?%83e%83X%83g", true);
Console.Write(baseUri.MakeRelative(targetUri));
激しく文字化けした結果が得られたりします。ちょっと使いものにならないんですが……。
というわけで、Bakera.Url を微妙に修正したり。
2003年1月20日(月曜日)
未承諾広告ならぬ
噂の (?) 「
実は既に送信元の ISP には対策をお願いしているのですが、この犯人、3ヶ月の間に送信元のサーバが 8回も変わっているという実にわかりやすい行動を取っているので、しばらくするとまた別のサーバから送ってくるのでしょう。
内容も送信方法も完全に違法ですから、とりあえず刑事告訴するという手を思いつくわけですが、昔のように警察行って相談したりしている暇があんまりないのがつらいところ。
※厳密に言うと spam については告訴、内容については告発になるのかしら。
CSS2.1 の Generic Family
CSS2.1 のワーキングドラフトには、CSS2 の Generic Family の説明 (www.w3.org)に該当する物が存在していないのですね……。
2003年1月18日(土曜日)
アドバイザー
家の郵便受けに、よく分からない、でっかい封筒が投げ込まれていました。取り上げてみると名刺がつけられていたので、不要物であることはすぐに分かりましたが、その名刺の肩書きを見てびっくり。
ブロードバンドアドバイザー
以上、うちの郵便受けに投げ込まれていた名刺 より
ごめんなさい、失礼だとは思うのですが、しばらくの間笑いが止まりませんでした。
日本一
なんとなくテレビを見るためにビックカメラへ。テレビと言っても番組ではなくて機械のほう、テレビ受信機を見たかったのです。
で、適当に見てから、ふらふらとゲーム売り場 (って言うのかしら？) へ。「ポポロクロイス はじまりの冒険」がもうベスト版で出ているのに驚いたりしつつふらふらしていると、なにやらプロモーションビデオが流れているのに気づきました。
うろ覚えですが、こんな感じのあおり文句が。
- 史上最凶のやり込みシミュレーションゲーム！
- アイテムレベル、お店のレベル……極限のやり込み要素！
- 10万超のダメージ！
……などなど。私の見ていた範囲では肝心の製品名やメーカー名が出ていなかったので、どのメーカーのどのゲームなのかは分からなかったのですが……実はダメージが 10万を超えるなどというアホなゲームには 1つだけ心当たりがあったので、google で「日本一」を検索。
……やっぱりだぁあぁーっ！
こんなのを当ててしまう自分が悲しいですが……。
ちなみに、心当たりの「10万超のダメージが出る」ゲームというのは「天使のプレゼント マール王国物語 (www.amazon.co.jp)
話はそれますが FF3 方式について説明しておきますと、元祖の FF3 (ファイナルファンタジー 3) では 9999 が表示上の上限で、それ以上のダメージが出ても表示は 9999 になっていました。FF4 以降では、そもそも一度に与えられるダメージの上限が 9999 でした。それを初めて突破したのが FF8 の「G.F. エデン」で、これは 65535 までダメージを与えることが出来ました。FF 史上初めて、表示が 5桁に達したわけです。FF9 ではまた 9999 が上限になりましたが、FF10 になると「ダメージ限界突破」という要素が現れて、再びダメージは 5桁となりました。FF10 のダメージ上限は 99999 です。
さて、話は戻って「天使のプレゼント」ですが、このゲーム、普通にやっているとダメージは 1万も行きません。最終ボスの HP は 10万に満たないので、そのくらいでちょうど良いのです。最終ボスはレベル 170 くらいあれば軽く倒せます。これ、高い！ と思うかもしれませんが、そもそも「主人公」の義理の姉にあたる人は初期レベルが 150 だったりするので、普通にやればこれくらいにはなります。特に経験値かせぎや戦術なども必要なく、漠然とやっていればクリアできてしまいます。
しかしこのゲーム、「最高でレベルいくつになるんだろう？」などと考えた瞬間に、恐怖のゲームと化すのです。
まず、初期レベル 150 の人がいるわけですから、レベル 99 が上限でないことは明白です。プログラマーなら、レベル 255 が上限ではないかと疑うでしょう。これは割と簡単に達成できます。そして、さらにレベルを上げると、何の障害もなくレベル 256 に達します。では、レベル 999 が上限だろう……と、普通は思うでしょう。実は私もそう思って、「せっかくだからレベル 999 にしてみるか」とレベル上げを開始したのです。
レベル 300 くらいになると、ダメージは 1万を超えるようになります。5桁のダメージを表示できることを確認し、「おっ、9999 を超えても表示できている」などと思ったわけです。そしてそのままレベルを上げて行き、やがてレベル 999 になり、そして……。
なんと。
なんとなんと、軽くレベル 1000 を突破してしまったのです。1001, 1002, と何の障害もなく上がって行きます。1024 を突破し、2048 を突破しても上がって行きます。
この頃になると、魔属性のモンスターに対する「覚醒」のダメージは 9万を超えるようになります。そして、レベル 3000 に達した頃でしょうか。私は、このゲームのダメージ表示桁数が 5桁であることを知りました。
しかしながらその事実は、私の常識を超える形で突きつけられたのです。
「ダメージ表示桁数が 5桁なら、ダメージ表示の上限は 99999 に違いない」
それは、このような考え方を根底から覆す、衝撃の瞬間でした。
私の目の前には、このような表示が現れていたのです。
10万
そうです。なんと、表示に「万」という漢字が入って「10万」と表示されたのです。これには正直驚きました。こんな方法があったとは……。
この後は、ダメージは「11万」「12万」という具合に表示されて行きます。1万に満たない部分は、表示上では切り捨てられます。
……そんなわけで、「ダメージ 10万超」は私の記憶に深く刻み込まれていたのでした。ちなみに、レベルの上限はまだ確認できていません。レベル 6800 くらいで力尽きました。
※ちなみに所持金の上限は確認できていて、おそらく 2147483647 (21億4748万3647イノチウム) です。これを超えると -2147483648 になります。表示が変なだけではなく本当に所持金マイナス扱いになっていて、買い物も出来ません。お金を貯め続けると少しずつマイナスが減って行き、0 に戻ると再び普通に増えます。そして 2147483647 を超えるとまたループします。
おそらく、そこでプロモートされていた「魔界戦記ディスガイア (www.amazon.co.jp)
ああ……。そんなゲームに何となく興味を持ってしまっている自分が恐ろしくてなりません。そんな暇あるわけないのに……。
関連する話題: 出来事 / ゲーム / 日本一ソフトウェア / 天使のプレゼント / ファイナルファンタジー
2003年1月17日(金曜日)
アルファチャンネル
まさか無理だろうと思いながら、半透明のアルファチャンネルを持つ PNG 画像を、あるブラウザで表示させてみたところ……。
- 表示できた。
- しかもちゃんと半透明で背景画像が透けて見えている！
- ついでに、結構かっこいい！
正直、感動しました。
※そのブラウザは CSS の解釈もかなりしっかりしていて、position: fixed や :focus 疑似クラスも効きますし、ほとんどのプロパティが私の予想通り (つまり仕様通り) の動作になります。正直なところ、当初は「どうせボロボロで使い物にならないだろう」などと考えていたのですが、とんでもない、良くできています。すばらしいです。
しかし、よく考えてみればそんなのは単に仕様通りなだけで、別に驚くことでもないはずです。むしろ出来ない方がどうかしています。
出来ないブラウザというのは具体的には IE6 なのですが、IE6 は PNG 画像を表示できて透過も扱えるのに、半透明のアルファチャンネルは扱えず、不透明の変な色で表示してしまうのでした。
そうか、半透明処理は難しいからしようがないのかなあ……などと思って許してやりたいところですが、そうは行きません。なぜなら、謎の filter: alpha(); などというプロパティで半透明の指定をすると、文字だろうが何だろうが半透明処理できるのです。PNG は処理できる、半透明も処理できるのに、どうして半透明の PNG はダメなのでしょうか……。
まったく謎としか言いようがありませんが、近い将来に対応してくれることを祈ります。
ニコチン中毒患者が病気になっても知ったこっちゃない発言に残念な思い
最近出た「美味しんぼ」83巻 (www.amazon.co.jp)
ニコチンの中毒患者がガンにかかろうと心臓病にかかろうと俺の知った事じゃないが、
ほかの人間に悪影響を与える無神経な煙草吸いは許せない。
以上、美味しんぼ 83 第3話「不注意な喫煙家」 より
このご発言には残念な思いをいたしました。
私は、喫煙者に病気になったりされては大変だと思っています。私が払った税金の中から医療費がむしり取られるからです。
たばこが原因で発生する医療費は、およそ 1兆3000億円程度と見られているようです。受動喫煙者の医療費、たばこを原因とする火災、たばこを片づけるための清掃費、喫煙習慣によって失われた労働時間などを総合すると、その損失は 5兆4500億円程度と言われています。中には 7兆円を超えるという試算もあります。
対して、たばこの税収はせいぜい 2兆4000億円なので、全然足りません。喫煙者のために、そうでない人の支払った税金がどんどん使われているという状況です。喫煙者がいなくなれば、私の税金をもっと他の、私の役に立つことに使うことができるようになるはずです。
※実は自動車についても同じ事が言えるのですが、喫煙に比べるとあまり問題にされていないようなのが残念です。いちおう、日本歩行者連盟 (www.ne.jp)あたりがにそのようなりソースが集められています。
しかし個人的には、税金よりもクリーニング代のほうが切実です。私はどうも臭いに弱い体質のようで、いろいろな臭いに苦しめられますが、特にたばこのヤニの臭いは本当に全くダメです。ヤニの臭いがしているというだけで、頭痛と吐き気がしてきてしまいます。
たばこの煙が充満しているような場所にはそもそも近づきませんが、うっかり近づいてしまった場合は悲惨です。まず手が臭くなっているので手を石鹸で洗います。帰ったら着ていた物を全て脱ぎ、ここでようやく気分が回復します。そして、ここで脱いだ物はクリーニングに出されることになります。たとえ、クリーニングから戻ってきたのが今日のことだったとしてもです。喫煙者がいなければ、このクリーニング代がまるまる浮くので助かります。
※昔はホントにことごとくクリーニングでしたが、最近は、軽微な場合はファブリーズで誤魔化すという技を身につけました。
実はまだあります。一部では知られていると思いますが、私はほとんどタクシーに乗りません。というのも、タクシーに乗るとすぐに気分が悪くなるからです。おそらく車内で喫煙する人がいるのでしょう。タクシーには極めて高い確率でヤニの臭いが染みついていて、30分もいるともうダメなのです。
同様のことが観光バスにも言えます。汚い話ですが、小学校の遠足でバスに乗ると、私はほぼ確実に吐いていました。ちなみに当時はそれを乗り物酔いだと思っていたので、酔い止めの薬を飲んで挑んだりしたものですが、ことごとく敗北。それでいて路線バスには酔わないのが不思議だったりした物です。からくりが分かれば簡単で、路線バスの車内ではたばこを吸う人がいないというだけの話だったのですが、当時はたばこが原因だとは分からなかったので、本当に悩んでいました。
そしてもちろん、煙そのものもダメなので難儀します。特に厳しいのはバスを待っているときで、近くで煙草を吸い始められたりすると、せっかく並んでいた列から離れて風上に移動しなければなりません。これが悔しいことこの上ありませんが、だからといってうっかり我慢してしまうと、服や髪に染みついたヤニの臭いで一日中体調不良に悩まされた上にクリーニング代が発生します。だったらバスの中で 30分くらい立っていたほうがずっとマシです。
このように「逃げる」という選択肢がある場合にはまだ救いがありますが、諸事情により逃げられない場合はどうしようもありません。頭痛や吐き気と戦いながら一日過ごし、服はクリーニングということになります。
そんなわけで、私にとっては喫煙者そのものがバリアですし、喫煙者が存在する場所もバリアになっているわけです。よく「密閉された場所で吸って、煙を外に出さなければ良い」などと言われますが、私の場合は喫煙者の身体に染みついた臭いでアウトなので、ほとんどどうしようもありません。実際、体中からヤニの臭いをさせている人は良くいますが、すぐに逃げないとやはり気分が悪くなってしまいます。
いやはや、困った物です。
2003年1月16日(木曜日)
System.IO.StringWriter の Encoding
C# では、System.IO.StringWriter の Encoding は UTF-16 で固定です。このプロパティは取得専用で設定できませんし、コンストラクタでエンコーディングを指定するようなことも出来ません。どうあがいても UTF-16 です。おそらく、システム実装内部のエンコーディングで固定となるのがあるべき姿なのでしょう。
それはそれで問題ない、と言いたいところなのですが一つ問題があって、System.Xml.XmlDocument.Save() メソッドに StringWriter を渡すと、そのエンコーディング指定に従って XML 宣言の encoding 疑似属性を書き換えてしまうのです。
最終的に UTF-8 で出力する事を目的として encoding="UTF-8" としておいても、途中で StringWriter に書き出すと、勝手に encoding="UTF-16" に書き換えられてしまいます。それを知らずに UTF-8 に変換して出力すると、XML 宣言の内容と実際の文字符号化方式が異なるリソースが出来るわけで、いやはや。
StringWriter ではなく System.Xml.XmlTextWriter を使えば Encoding を指定できるのですが、これだと System.Web.HttpResponse.Write() に渡せないわけで、何とも。XmlTextWriter でいったんテンポラリファイルに書き出して、System.Web.HttpResponse.WriteFile() で書き出すようにするのが良いかもしれません。
2003年1月15日(水曜日)
詭弁
目次ページ (www5b.biglobe.ne.jp)。久々にものすごい詭弁に出会って感動しました。実験のデータも計算式も出さずに口先だけでねじ伏せていくという姿勢で、ここまで論理を構築しているところがすばらしいです。勉強になります。
一番感心したのはこれ。
昔から”速度”というのは、
速度=［距離］／［時間］
で表されてきました。
それを、アインシュタインは、”時間”を速度ｃを用いて定義したのです。（ここで「はっ」と気づいた人もいるでしょう）
おかしいと思いませんか？
時間を光速度ｃを用いて定義するには、その前に時間というものが分かっていなければならない。
なぜならｃとは①の距離／時間で求められるものだからです。
アインシュタイン出現以前の素朴な時間を用いて測定されつづけてきた光速度ｃを用いてまた時間を定義するという決定的論
理ミスをやっているのです！
この馬鹿馬鹿しさ、愚かしさをしっかりと目を見開いてみてください（そして真っ当な時間が、奇妙な時間に変わった！）
以上、ｃを中心に据えてしまった相対性理論 より
希に見るすばらしい詭弁だと思います。私も一瞬「あれ？」と思ってしまいました。
これは、「速度は時間と距離から求める物である」という思いこみを利用しています。私たちが日常で速度というものを扱うときは、速度を直接測定するのではなく、距離と時間から平均速度を求めることが多いでしょう。※ここで求められるのが、あくまで「平均」速度であることにも注意しておくと良いと思います。たいていの物は静止状態からいきなりトップスピードになったりはしませんし、時に減速したりしながら移動しますので、速度は常に変化しています。そのため、常に速度よりも先に距離と時間があって、速度というのはその 2つから計算によって算出された概念上のものだ……などと思ってしまいがちです。
しかし実際には、速度 = 距離 / 時間 であると同時に 時間 = 距離 / 速度 であり、距離 = 時間 × 速度 でもあるわけです。この三者はすべて同等で、速度だけが特別な値というわけではありません。たとえば、スピードガンでまず速度を算出して、時間と掛け合わせて距離を求める事もできます。※ちなみに、スピードガンはドップラー効果を利用して速度を計測する機械です。距離や時間を測定して速度を算出しているわけではありません。
そして、おもむろに理科年表をひらき、「1メートル」という長さがどのように定義されているのか見てみましょう。ついでに、「1光年」という長さがどのように定義されているのかも見ておきましょう。それで曇りが晴れると思います。
良い頭の体操になりました。
2003年1月12日(日曜日)
新生えび日記
話題による絞り込み表示を実装できたので、えび日記ビューアはとりあえず完成しました。というわけで、ここでひそかにえび日記を続けて行く予定です。
2003年1月11日(土曜日)
System.Uri と System.Web.HttpUtility
System.Uri が自動で行う URL エンコードは %E8 のように大文字です。しかし System.Web.HttpUtility の UrlEncode() メソッドでエンコードすると、%e8 のように小文字になります。まあ大文字でも小文字でも問題はないのですが、どうして動作が一貫していないのでしょうか……。
まあそれはさておき、URL の比較の際は、%HH エンコードの大文字小文字を区別しないことに注意する必要があります。
2003年1月10日(金曜日)
System.Uri クラスに残念な思いをいたしました
.NET Framework の System.Uri クラスは URI を扱うことが出来るのですが、このクラスにはいろいろと困るところがあります。
- 一致演算子がオーバーライドされていない。同じ URI を参照する Uri を比較して false になるというのは、ちょっと違和感があります。
- Equals() メソッドの動作。Equals() はオーバーライドされていて、同じ URI なら true になります。しかし、フラグメント ID が異なっていても結果が true になったりするので、やや予想とは異なる結果になります。
- URL エンコードの動作が一貫性に欠けている。dontEscape が true の場合、"%20" は "%20" のままで問題ありません。しかし、dontEscape が false ならば "%20" は "%2520" にエンコードされなければおかしいでしょう。実際には、妙な気を利かせて %HH 形式の物はスルーしてしまいます。
- クエリストリングとフラグメント ID を持つ URI の処理がおかしい。Uri のコンストラクタに、たとえば http://example.com?foo#bar のような URI を渡すと、なんと # が %23 にエンコードされてしまいます。これはバグだと思うのですが……。
- MakeRelative() の動作に一部おかしいところがある。たとえば、http://example.com/foo?bar から http://example.com/foo?baz を参照する相対 URI は、"foo?baz" ではなく "" (空文字列) になってしまいます。http://example.com/foo から http://example.com/ を参照する相対 URI は、"./" ではなく "" (空文字列) になります。どう考えてもおかしいでしょう。
とりわけひどいのは MakeRelative() の動作です。Uri クラスの MakeRelative() メソッドで相対 URI を作るルーチンでは、クエリストリングを持つ CGI は全く扱えないわけです。
そんなわけで、System.Uri を継承してダメなメソッドや演算子を上書きする Bakera.Url クラスを作成したりしました。名前が微妙ですが、Bakera.Uri にしてしまうと単に Uri と書いたときにどちらを指すか分かりませんし (分からないと言われてコンパイルできないはず)、そもそも System.Uri は URN を扱えるというわけでもないので。
2003年1月8日(水曜日)
Red Hat Network
Red Hat Linux 8.0 には Red Hat Network というものがあります。これを利用すると、パッチが出たときに自動的にパッケージをダウンロードしてきて適用したり出来るようです。要するに Windows Update の Red Hat Linux 版です。
※むしろ Vine とかの apt-get のようなものなのかも……。あんまりよく分かってないのですが。
しかしこれは登録制で、Red Hat Linux の有料版を買ってユーザ登録しないと利用できないようです。しかも、買ったのがパーソナル版 (安い方) だと、なんと 30 日間しか使用できないらしい！ なんかほとんど意味がないような……。
いつ無効になるか分からないようなものは、最初から頼るべきではないでしょう。しようがないので、Red Hat 社の FTP サーバから "errata" と呼ばれているパッチのパッケージをごっそりとダウンロードしてきて、何も考えずに rpm -Fvh *.rpm で適用しておきました。
なんだかなあ。
2003年1月7日(火曜日)
Red Hat Linux 8.0 インストール日記
諸事情により、他人様の機械に Red Hat Linux 8.0 (www.jp.redhat.com) をインストールすることになりました。
Red Hat と言えば商用パッケージなのですが、別にパッケージを買わなくても FTP でダウンロードしてきて使うことができます (ただしその場合はノーサポート)。そんなわけで、ftp.redhat.com につないで拾ってこようかと思ったのですが……。
……………………タイムアウトで切断。
どうも本家のサーバは重いようなので、ミラーのひとつ ftp://ring.asahi-net.or.jp/pub/linux/RedHat/redhat にアクセス。
……目的の物、どこにもないんですが……。
気を取り直して、今度は ftp://ftp.kddlabs.co.jp/pub/Linux/RedHat/redhat に。探してみると、ftp://ftp.kddlabs.co.jp/pub/Linux/packages/RedHat/redhat/linux/8.0/en/ 以下に問題の物がありました。
ごっそりダウンロード開始。しばらくすると、ダウンロード完了までの予想時間が表示されました。
8 時間 33 分。
……というわけでそれからおよそ 1 時間半の後、「Red Hat Linux 8.0 パーソナル」のパッケージを手にしていた私なのでした (都内某所で 5180 円でした)。
箱を開けると、謎のシールなどに混じってディスクが 6枚。うち 2枚がソースコードというのが、さすが GPL の世界という感じです。「インストール CD 1/3」というディスクをセットしてマシンを再起動、CD-ROM ブートでインストール開始。何というか、普通の GUI なインストーラの画面が表示されてちょっと驚きます。
適当に各項目を選択しつつ進んで行き、パッケージのインストール開始。まずイメージをハードディスクにコピーして、そこから展開するようです。
すると。
ファイル /mnt/sysimage/var/tmp/glibc-common-2.2.93-5.i386.rpm を開けません。原因はファイルの欠落、パッケージ、またはメディアの不良です。<return>を押してやり直してください。
以上、Red Hat Linex 8.0 のインストーラ "Anacoda" のエラーメッセージ より
return を押せと言われていますがそんなキーはないので、あえて逆らって Enter キーを押します。すると Anaconda の未処理の例外と言われてインストーラは終了、マシンは再起動します。
……どうしろと？
その後何度やり直しても同じところで同じメッセージでお亡くなりになります。テキストモードでやってみたり、インストールするパッケージの構成を変えてみたりしても全く同じ。メッセージを素直に読むと /mnt/sysimage/var/tmp/glibc-common-2.2.93-5.i386.rpm が存在しないという事らしいのですが、コンソールで見てみるとしっかり存在しています。
そこで sagami さんの「RPM rebuild Tips」を見つつ、rpm -Kvv --nopgp /mnt/sysimage/var/tmp/glibc-common-2.2.93-5.i386.rpm とやってみると、Bad などと出る始末。RPM ファイル自体が壊れているようです。まさか買ってきたパッケージの CD-ROM が不良品なのか？ それともディスクイメージ展開のルーチンで何かが起きているのか？ などと疑いを抱きつつ、とりあえず別のマシンに入れてみることに。
すると、一発で OK。そんな……。
2003年1月1日(水曜日)
- 前(古い): 2002年9月のえび日記
- 次(新しい): 2003年2月のえび日記
