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以外は認めないとか書いてあるんでしょうか。そのうち勉強します。

• RFC2396 - Uniform Resource Identifiers (URI): Generic Syntax
• RFC3986 Uniform Resource Identifier (URI): 一般的構文

CDに対する愛着の薄れ

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

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

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

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

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

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