Neutoria: 2008

2008年12月29日月曜日

Web2.0(Ajax)時代の標準文字コードはUTF-8？

今から3年ぐらい前、Web2.0なんて言葉が出始め、Ajaxはまさに黎明期、Google Mapsとかにみんな驚き、JavaScriptが威厳を取り戻しつつあった時代がありました(そんなに昔の話じゃないですよ。3年前の話ですよ)。私もご多分にもれずそれに感化され、卒研では意味もなくXHTML+JavaScript+PHPをAjaxでつないでいました。

その頃は若かった(?)ため、HTMLに当たり前のようにUTF-8を使い、サーバとのやり取りもすべてUTF-8で行っていました。若い時は「XMLはUTF-8がいい」なんて聞いたら、それ以外を使うのはすべて悪であるかのような錯覚をしていたので、特に違和感もありませんでした。

しかしそれから3年が過ぎ、ふと別件でAjaxについて(今更)調べる中で「decodeURIComponentはUTF-8しかデコードできない」という事実を知り驚きました。それってつまり、HTMLもUTF-8にしなきゃならないってこと?

と思ったら、なぜかデコード後の文字列は、HTML自体がShift_JISの場合はShift_JISになる！どういうこと？

そもそもdecodeURIComponentにUTF-8以外の文字列をエンコードした文字列を渡すと、「error: malformed URI sequence」になってしまいます。UTF-8以外はデコードできないからですね。それを回避するためにサーバはresponseTextに常にUTF-8文字列が返るように実装しなければなりません。イマドキそんな制限ないっすよ～

decodeURIComponentはRFC2396に準拠しているんですってね。そこにUTF-8以外は認めないとか書いてあるんでしょうか。そのうち勉強します。

2008年12月22日月曜日

CDに対する愛着の薄れ

大塚愛さんの「Love Letter」を購入しました。大塚さんのステキな笑顔のアップというインパクトのあるジャケットです。グッときます。ドキッとします。:*)

思えば昔はCDを1枚買うごとに、CDプレーヤで再生しつつ歌詞カードをじっと眺め、1曲1曲をかみしめながら目と耳で楽しんでいました。もっと言えば、ジャケットの絵や写真だけでも友達と一緒にいい悪い、好きだ嫌いだと話したものです(そんなに昔の話でもないですが)。CDがバカ売れた時代(そう、小室全盛期の頃です)のようにCDという、音楽ではなく、ものをとてもありがたがる、ということを最近しなくなったなーと感じました。今20～30代の人、そうじゃないですか？

ものとしての価値を上げるため、今はDVDが付いてきたりしますが、それも当たり前になってきて、DVDが付いていること自体は特別感はあまりありません。そしてプロモーションビデオを見ても何かおまけのような感じがして、有難味もだんだん薄れてきた気がします(それでも他に合法的に入手する手段のないプロモーションビデオを見ることができるのはありがたいです)。

ファイル共有ソフト黎明期(今から5、6年前のことです)に「CDが売れなくなった」とレコード会社が騒いだこともありましたが、遅かれ早かれ、音楽が日常により近いものになり、音楽はパソコンやiPodで聞く今のような時代は来たと思います。そしてそれとともに、CDに対する愛着はどんどん薄れ、買ってパソコンでエンコードしたら、あとは棚に並べて背表紙だけが日焼けしてゆくという、何とも寂しい時代になってしまいました。

レコード会社の人、今一度ものとしてのCDを再起させるべく、何かいい案考えてください！

2008年12月7日日曜日

Excelファイルがデファクトであることの障害: プログラムとの親和性の低さ

会社で使っているデータの多くがExcelファイル。これらをプログラム(PHP, Perl等)から利用できれば、作業の多くを自動化できるのにな～と思っています。

「思っています」というのは、色々考えてみましたが、有効な方法が思い当たらないからです。

一番一般的なのはCOMを使ってVBAを外部から使う方法ですが、これはWindowsでしか使えません。そのため、私のPCでは動かすことができますが、みんなに使ってもらうためにサーバに配置する、というようなことはできません(みんなが使えるWindowsサーバがないため)。

PHPやPerlにはそれぞれExcelファイルを操作するためのライブラリが用意されていますが、Excelファイルの作成こそある程度は可能ですが、読み込みは完璧ではないようです。サーバ/クライアントシステムとして、サーバ上でデータ操作をして、最終的な出力をExcelファイルとしてダウンロードさせる、といった使い方はできそうですが、サーバ上のExcelファイルを検索して、最終的な出力をHTMLで行う、という用途には向かないようです

やりたいことはまさに上記の後者の例で、サーバ上にある試験項目表のデータ(100ファイルぐらい)を検索した結果をHTMLで表示する、ということなのです。以前Pukiwikiに検索機能を付けた時は、Pukiwikiの全エントリを全文検索して結果を表示させる、という手法をとり、2,000弱のエントリで問題なく動いるのですが、Excelを100ファイルとなると、ファイルから動的にデータを読み出して処理する、というのは難しそうです。

動的なデータ読み出しができないのなら、静的にデータベースを作るなり、XMLに分解するなりすればいいのですが、ファイルが更新されるたびにデータを作り直さなければならないという問題が出てきます。1日1回だけに制限するにしても、更新するのは結局私なんだろうな、と思うとやっぱり現実的ではない気がしてきます。

Excelファイルでデータを管理すること自体、決して悪いことではないと思うのですが、自動化させる、という点からみると何とも忌々しいものです。

2008年11月30日日曜日

FileStreamのPositionがなぜかずれる

私は開発には .NET Framework 3.5 SP1 を Visual C# 2008 SP1 で使っていますが、その環境のせいか、何のせいか、FileStreamのPositionを指定しても、反映されない場合がたまにあります。これが一度出るとはまってしまう。。。そして何が原因か分からないまま、事象は解決する。。。

デバッガでPositionを変更した直後に止めてみて値を見ると、代入している値は確かに目的の値なのに、代入直後にStreamのPositionは0x0000001cになる。つまり以下のコードだけでアウト

  // set source stream position
  source.Position = 0x5000;

 // read packet ↓ここでデバッガを使ってPositionを見ると0x0000001cになっている
 FramePacket lastPacket = new FramePacket(source);

ちなみにseekを使っても同じ。なぜか入れた値のままにならない。デバッガで値を無理やり書き換えてもすぐに0x0000001cに戻る。なんだこりゃ。。。

メガバイトを超えるファイルを扱う場合、これがうまく動かない場合は致命傷です。試行錯誤を繰り返すと治るのですが、原因がよくわからないのは何とも気持ちが悪い。なんでしょうね。

生まれて初めて小説を買いました

別に特別興味があったわけでもありませんが、CMで見て、ニュースで見て、気になってついつい衝動買いしてしまいました。「ソウ―SAW (角川ホラー文庫) (表紙だけでも結構インパクトあるので気の弱い人は見ないようにしてください)」を。初めてでホラーです。映画のノベライズです。

SAWはシリーズ5まである怖い怖い映画で、最近SAW 5のCMが流れています。ストーリーはJigsaw Killer(ジグソウキラー)と呼ばれる殺人鬼が生きることを粗末にしている人間に命をかけたゲームを強いるというものです。映画はかなりグロいそうです。私は気が弱くDVDを買う勇気はいため、小説にしました。

1と2を買い、半日ぐらいで一気に読みました。読んでみて、一般にSAW1の評価がとても高い理由がよくわかりました。よくありがちな、おどろおどろしいだけ、怖いだけ、の話ではなく、人間の生きることへの執念を実にうまく表現しています。ジグソウの仕掛けるゲームも、ルールがシンプルにして深い。とてもよくできた話でした

興味がある人は読んでみてください。

2008年11月24日月曜日

井戸知事の「関東大震災はチャンス」発言の問題点

日本の報道は失言が好きなようで、近畿ブロック知事会議での井戸兵庫県知事の「関東大震災はチャンス」という発言に食いついているようですね。

この件も発言の趣旨を見れば大した問題ではないということは明白なのですが、報道関係者がいる前での発言ということで少しは気をつけても良かったかもしれないですね。でも何て言えば問題にならなかったのでしょうね。

元の発言

まず、東京一極集中をどうやって打破するかという旗を揚げないといけない。物理的には、関東大震災なんかが起これば相当ダメージを受ける。これはチャンスですね。チャンスを生かす、そのための準備をしておかないといけない。機能的には、金融なんです。金融とマスコミが東京一極集中になっている。東京に行った企業をもう一度、関西に戻せというカムバック作戦を展開していく必要がある。（中略）そういう意味では、防災首都機能を関西が引き受けられるように、あるいは第２首都機能を関西が引き受けられるような準備をしておかないといけない。

本件では発言後すぐに記者会見を行っていますが、そこでの井戸知事の発言が微妙でした。「なぜ問題なのかわからない」

実際に問題であるかどうかは別にして、報道がなぜ騒いでいるか、分からないわけないでしょうに。子供じゃないんだからまともなかわし方をしてください。

田母神問題は論点がずれすぎている

もうだいぶ過去の話になってしまいましたが、、、田母神さんの話に触れたいと思います。(なお、田母神前空幕長というのは面倒なので、田母神さんと呼ばせてください。)

ニュースで散々取り上げられ、退職に追いやられ、国会に参考人招致までされた田母神さんですが、この話はどこか論点がずれていると思います。大切なのは、個人としての言論の自由が認められているかという点です。

田母神さんがなんと言おうが、論文を出そうが、それが公人としてではなく、私人としてであれば、なんと言おうが問題ではなかったのです。アパグループの懸賞論文なんて完全な私人として行う行為です。それを問題として取り上げる以上、日本は今後、公人としてだけではなく、私人としての発言まで監視、規制されるべきという方針を打ち立てたことになります。麻生総理大臣もこの件を問題として取り上げていますので、やはり、発言の自由は規制されるべきという今までの慣例に一石を投じる議論であることは明白ですね。

国会参考人招致では田母神さんが過去の歴史をどう思っているかを細かく聞いていましたが、何の意味もありません。あそこで発言を撤回したら何かいいことがあるのでしょうか。極右であることがわかったら何かいいことがあるのでしょうか。時間の無駄です。ちゃんと仕事してください。文民統制がどうのとか、そこの土俵に上げる以前の問題です。

結局その論点はニュースで取り上げられませんでしたが、しかるべき所でちゃんと議論されているんですかね。大事なことですよ。

2008年11月23日日曜日

キャプチャファイルのキャプチャ終了時間を推測

Wireshark等のパケットキャプチャで収集したキャプチャファイルはただ単に取得したパケットを数珠つなぎにして保存しているため、収集を終了した時間がいつか、というのはファイルを最後まで走査してみないとわからないようです(収集開始時間は1パケット目の到着時間がそれにあたるので容易に判定できますが)。そのため、収集終了時間を知るためだけにファイル全体を走査するという面倒なことをしなければなりません。これはちょっと嫌です。というかだいぶ嫌です。ファイルサイズが500Mあったら。。。とか考えたくないですね。

要はファイル内の最後のパケットを見つけられればいい、ということで、WireWhaleではファイルの末尾から以下のバイト列を見つけることで最終パケットを推測しています。

  AA -- -- -- 00 -- -- 00 00 BB BB 00 00

  --   : 任意のバイト
  AA: 1パケット目のEpoc時間の上位1バイト
  BB BB: ファイルの末尾からのバイト数

上記はパケットのFRAMEヘッダ部の文字列です。Aは1パケット目のEpoc時間の上位1バイトで、これが1パケット目と同じということは、1パケット目を収集してから16,777,216秒(約4,660時間)経過していない、というのと同意になります。じゃあ4660時間以上のキャプチャファイルの場合はどうするんだということになりますが、そこは保証外ですよ。無茶言わないでください。

他にも細かいロジックを色々入れればもっと精度の高い推測ができるかもしれませんが、当面はこれでいきます。