JavaScriptでプルダウン（select）の値を操作する方法のメモ書き。
■メニューのうち上から何番目が選ばれているか（一番上が0）
index=document.forms[‘myForm’].elements[‘selectElement’].selectedIndex
■上記のオプション（option）内で指定されている値（value）
value=document.forms[‘myForm’].elements[‘selectElement’].options[index].value
JavaScriptは最近でこそAjaxの関係で必要になったからやっているけど、昔はぜんぜん使わなかったので、基本的なことすら覚えていない。面倒だ。
海外サーバを利用する上で欠かせないのが日付処理での一工夫だ。例えばアメリカのレンタルサーバを利用した場合、当然サーバはアメリカの現地時間に設定されている。だから、例えば掲示板プログラムを設置した場合、例えば日本でお昼の14時に投稿していたとしても、プログラムで何の工夫もされていなければ、深夜の1時に投稿した、というような具合で記録、表示されることになるだろう。海外のサーバを使う際は時差の処理が大切になってくる。
PHP5の場合はデフォルトのタイムゾーンを設定する「date_default_timezone_set」など有用な関数が装備されたので、最初に宣言すれば気にせずdate関数などを使用することができそうだ。しかしPHP4の場合はそうもいかない。やはり一工夫しなければいけないのだ。
実はこのようなことを考えていて、PHP標準で備わっている関数をいくつか試したのだが、解せない結果となって驚いている。実行したのは以下のようなプログラムだ。
(1) print(date(“Y-m-d H:i:s”,gmmktime()));
(2) print(date(“Y-m-d H:i:s”,mktime()));
(3) print(date(“Y-m-d H:i:s”,gmdate(‘U’)));
(4) print(date(“Y-m-d H:i:s”,date(‘U’)));
(5) print(gmdate(‘Y-m-d H:i:s’));
(6) print(date(‘Y-m-d H:i:s’));
GMTで処理して、逐一タイムゾーンにあわせて処理すればよいはず、と考えて上記プログラムがどのような結果になるのか試してみたのだが、意外な結果となった。
まずこれをアメリカのサーバで試すと以下の結果となった。
(1) 2008-04-08 20:28:11
(2) 2008-04-09 00:28:11
(3) 2008-04-09 00:28:11
(4) 2008-04-09 00:28:11
(5) 2008-04-09 04:28:11
(6) 2008-04-09 00:28:11
日本のPHP5サーバで試すとこんな結果になった。
(1) 2008-04-09 13:28:11
(2) 2008-04-09 13:28:11
(3) 2008-04-09 13:28:11
(4) 2008-04-09 13:28:11
(5) 2008-04-09 04:28:11
(6) 2008-04-09 13:28:11
日本のPHP4サーバで試すとこんな結果になった。
(1) 2008-04-09 22:28:11
(2) 2008-04-09 13:28:11
(3) 2008-04-09 13:28:11
(4) 2008-04-09 13:28:11
(5) 2008-04-09 04:28:11
(6) 2008-04-09 13:28:11
個人的には(1)(3)(5)は全部同じ値になって、(2)(4)(6)は時差の分だけ考えれば同じ値となる、と思っていたのだが(1)(3)(5)が期待と大きく異なる結果となった。
サーバの設定とかいろいろあるとは思うが原因がわからない（ひょっとしたら大きな勘違いをしているのかもしれないが）。とりあえず全部で同じ値を返した(5)を使うのがよさそうだ。今後しばらくはこの関数をベースに時差調整のプログラムを書くことにしよう。
現在簡単なウェブアプリを書く際は、フレームワークとしてguesswork、データベース接続にADODB、テンプレートエンジンはSmarty（もしくはPHP直接記述）という組み合わせを使い、データベースにMySQL（最近はSQLiteも）を使用することがほとんどだ。この組み合わせの中でADODBとSQLiteを使用した際に発生した問題についてメモ。
ADODBでは他のデータベースライブラリと同様に、使用するデータベースを定義することによって必要な処理が分岐されるようになっている。例えばPostgrSQLを使用する場合はpostgres、MySQLを使用する場合はmysqlといった具合だ（文字列の指定方法はデータベースライブラリによって違うので注意が必要）。ADODBでSQLiteを使う場合はドライバに2種類あり、それらは「sqlite」と「sqlitepo」だ。最初はその違いを把握せず（マニュアルなど読んでいない）、「sqlite」を使用していたが、あるとき不具合が出てしまった。
MySQLの場合は例えばselect文を投げてデータを取得した場合は以下のような配列で取得できる。
$row[‘id’]
$row[‘name’]
もちろんSQLiteでも基本的には上記のように返してくれる。しかし例えば複数のテーブルを結合したりしたselect文を発行したりすると、MySQLの場合は上記と同様に返してくれるのだが、SQLiteの場合はテーブル名をくっつけて返してしまうのだ。
$row[‘user.id’]
$row[‘user.name’]
こんな具合だ。「え〜これでは互換性が保てない・・・」と思ってよくよくマニュアルを読んでみた。そしてドライバの違いに気づいた。マニュアルによると、
—
移植性のあるSQLiteドライバ。sqliteでは他のドライバのように連想モードが機能しないため。つまり、複数テーブルを選択（結合）すると、テーブル名が”sqlite”ドライバの連想キーに含まれます。
“sqlitepo”ドライバでは、テーブル名は返されたカラム名から取り除かれます。この結果が衝突したとき、最初のフィールドが優先されます。
—
そういうことだったのね。互換性（移植性）を重視するなら「sqlitepo」を使用しなさい、と。しかしこれではどんなデータベースでも汎用的に利用できるライブラリという意味合いがなくなってしまっているような感が無きにしも非ず・・・。気を取り直して「sqlitepo」を使用することにした。
「便利に使えそう」と期待しているSQLiteだが、もろもろウェブを検索すると「断然SQLite3にすべき」という記述が多い。当然多機能だろうかバージョンが上のほうがいいに決まっているのだが・・・。
SQLite2の場合、本来は一度作ったテーブルの修正はできないらしい。つまりalterコマンドがないのだ（SQLite3から実装されたらしい）。これは確かに不便だ。
SQLiteManagerではいちおうSQLite2でもテーブルでカラムの追加や削除、修正ができる。これは以下の手順を踏んでいるらしいことがわかった。
(1) 元テーブルと同じ構造のテンポラリテーブルを作成
(2) テンポラリテーブルに元テーブルのデータを挿入
(3) 元テーブルを削除
(4) 希望のテーブルを新規で作成
(5) テンポラリテーブルに入れたデータを新規作成テーブルに挿入
(6) テンポラリテーブルを削除
上記の操作をトランザクションに囲んで処理させているようだ（本当はどうだかソースを読んでいないのでわからないけれど）。トランザクションをサポートしているのにテーブルの修正ができないとは・・・。まぁトランザクションのほうがあったほうがいいけれど、それでもテーブルの修正が容易でないというのは開発段階では致命的。
でもPHP5ではデフォルトではSQLite2しかサポートしていない。しょうがなしにSQLite2を使っていくということになるのだが・・・。早めに改善を希望する部分だな。
SQLiteManagerを活用してがんばってSQLiteを使っている。PHP4でSQLiteが使える環境があったのでそちらにも設置してみた。基本的には動作しているようだが、なぜかUTF-8化を実施すると以下のエラーが出る。
Warning: cannot yet handle MBCS in html_entity_decode()
htmlentity関連のエラーだ。マルチバイト文字はhtmlentity関数との相性がよくないような気がする。さて、これを解消する方法は以下の通り（include/common.lib.phpを修正）。
(1) 上記ファイルのどこか適当なところに以下の関数を記述する。
function unhtmlentities($string)
{
$string = preg_replace(‘~&#x([0-9a-f]+);~ei’, ‘chr(hexdec(“¥¥1″))’, $string);
$string = preg_replace(‘~&#([0-9]+);~e’, ‘chr(¥¥1)’, $string);
$trans_tbl = get_html_translation_table(HTML_ENTITIES);
$trans_tbl = array_flip($trans_tbl);
return strtr($string, $trans_tbl);
}
(2) 元ファイル中で133行目、180行目、184行目ででてくるhtml_entity_decode関数を上記のunhtmlentities関数で書き換える。その際2つ目以降の引数はばっさり切り取る。
以上でOK。正しく表示された。多分標準の関数を自前処理の関数で置き換えた、ということだろう。