Googleのウェブサービスを使って日本語住所から緯度経度を取得する方法については何度かブログに書いてきたが、今日少しだけ時間に余裕ができたので、少し調べてみた、「Google Maps APIだけで日本語ジオコーディングできるか」について。
結論：できる！
今書いておきたいプログラムはジオコーディングで取得した緯度と経度をデータベースに保存できるようにする仕組み。難しい（というか自分自身の経験が少ない）のはJavaScriptで経度と緯度を取得してデータベースに放り込むところまでだ（実際のデータベースへの登録作業はPHPで書くけどね）。
いちおう頭の中では構想ができているので、近々で構築する予定。
できたときに何に使うかは内緒（役立たずかもしれないから）。
とあるお客さんからプログラムを移設して欲しい旨連絡をいただいた。基本的にファイルを移行して、データベースを移行して、キャッシュ用ディレクトリのパーミッションを変更するだけで動くはず、だった。
しかしファイルを設置しても、インターナルサーバエラー（レスポンスコード500）が返される。
ちょっと困ったなぁ、と思いつつhtaccessファイルに記述した特殊な設定をコメントアウトしてみた。しかしそれでもNG。諸々調べてみて、CPIの専用サーバプランであることがわかった。そしてそのサーバのPHPは、CGI版！。
「できません」と放置するわけにもいかないので、最低限の設定をしてみることにした。
まずhtaccessファイルで記述してある、PHP関連の設定を全てコメントアウト。次にhtaccessファイルの末尾に、拡張子phpがついたものはCGIとして動作するよう以下のように記述した。
AddType application/x-httpd-cgi .php
これで拡張子phpがついたファイルをCGIとして認識してくれるようになる。
次にPHPファイルの一行目にCGI版PHPへのパスを記述。これはPerlなどでおなじみの記述だ。記述したのは以下の一行。
#!/usr/local/bin/php-cgi-4.3.11
この記述は関連するPHPファイル全てに記述する必要はない（つまりrequireやincludeで呼び出されるようなファイルはそのままでよい）。実際にapacheから呼ばれるファイルの一行目にだけ記述すればよい。
そして最後。CGIなのでPHPファイルに実行権限を与えなくてはいけない。いわゆるパーミッション。パーミッションはとりあえず755を設定しておいた（最近はFTPソフトからでもパーミッション変更できるので楽チン）。
これで何とか動作してくれた。PHPプログラムを実行しようとしたときに、プログラムのソースがそのまま表示されてしまうような場合は、モジュール版ではなく、CGI版が入っている可能性もある。そういった場合は上記の手順を踏めば、CPIに限らず動くようになるはず・・・（上記手順だとhtaccessが使えるという条件は必要だが・・・）。
PHPはその機能で出力を各種文字コードに自動変換して出力することができる。例えばLinux使いなプログラマが、社内システムなんかを構築する場合、通常のサイトやデータベースはEUCで作ったとしても何の問題もないが、CSVファイルをダウンロードさせるような仕組みを作る場合はShift_JISにテキスト変換してやらないと、誰もそのファイルをエクセルで開くことができなくなる。
以下のコードを出力に際して書き込んでやればよい。
mb_http_output(‘SJIS’);
ob_start(‘mb_output_handler’);
珍しく上記2行の意味を考えてみた。
1行目は出力をSJISにしましょう、ということだ。しかしそれだけではだめ。つまり「SJISにしましょう」ということではなく、「SJISにしたいです」という宣言でしかない。これを実行するのが2行目。
ob_startというのはバッファリングを有効にするための関数だ。つまりprint構文などが呼ばれた場合に逐一ブラウザに出力するのではなく、サーバ側で全てのPHP処理が完了するまで待ちましょう、という関数だ。で、その引数で指定されているmb_output_hander。これはいわゆるコールバック関数というやつだ。コールバック関数とは、親関数（ここではob_start）が呼ばれた際に、そのついでに処理してくれ、というような関数だ（突き詰めて書けば違うけど、おおむねこんな感じ）。
mb_output_handerはコールバック専門の関数でob_startによって出力バッファにためられたデータを、出力用文字コードに変換するという機能を持つ。ということで上記2行のプログラムは、1行目で「出力をSJISにしたい」と宣言し、2行目のob_startで、出力をいったんバッファにためる、と設定し、mb_output_handerでバッファ内の文字列を指定どおりに文字コード変換する、という処理をすることになる。
なおmb_output_handerはいろいろ条件があって、header関数でcontent-typeを出力していない、とか、もし設定されていた場合はtext/で始まるmimeが指定されている、とかある。もちろんhttp_outputがpassに設定されていたら変換のしようがないのは言うまでもない。
ということで諸々制約が多い。プログラム書き始めの人にとってはかなり使いにくい関数といえる（理屈を考えず、2行書いておけばいいという話もあるが・・・）。
Smartyの修正子は、標準装備の修正子のほかに、カスタムで作成した修正子も使用できるし、PHPの関数も修正子として利用できる（普段、普通に使用していた）。
しかし修正子としてstr_replaceを使うと、なぜかうまく動いてくれなくて、理由がわからない（例によってSmartyのソースを読むのが嫌だから）。いろいろ調べて、Smarty標準装備のreplaceという修正子で対応できることがわかった（当然こちらを使うのが正統派）。
ではなぜstr_replaceはダメなのか。
ウェブを調べていたら「暗黙的な修正子としてPHP関数を・・・」という記述があった。どうやらPHP関数によってはうまく動作しないものがあるようだ（だから標準の修正子を使えって話なのだろう）。
HTMLフォームの処理でユーザインターフェースを考えた際のもんんだいに対する対応。
例えば入力フォーム中のテキストボックス（<input type="text">）に入力する時で[Enter]エンターキーが押されると、サブミットするつもりでないのにフォームを処理してしまうことがある。フォームの作り方にもよるが、これだとフォームがサブミットされてしまい、最悪の場合、今まで入力したデータがパーになってしまうこともある。
これを防ぐ方法。<input type="submit">を使わない方法で対応するのがよさそうだ。どうも[Enter]キーが押される＝サブミットという図式が成り立つので、<input type="submit">をなくしてしまえばよい、というわけだ。
しかしそれではフォームをサブミットする方法がなくなるので代替の方法を用意しておかないといけない。ここでは簡単なJavaScriptを使う。
<input type="button" onClick="document.（フォーム名）.submit()">
これで意図しないサブミット処理をなくすことができる（ただしJavaScriptが動作することが前提であるわけだが）。今はエンドユーザの使い勝手をよくするためにJavaScriptは必須な機能。昔は「JavaScriptをOnにしてください」なんて書いてあるサイトを見ると、ちょっとナンセンスと思っていた。できれば「JavaScriptはOnであることが当たり前」として、そうじゃない設定をしてあるブラウザは、イレギュラーなブラウザとしてブラウザ側で何らかの機能を実装して欲しいと思う（例えばJavaScriptを使ったページを見たら「このページはJavaScriptが使われているので、Onにしないと表示が乱れます」といったダイアログを出すとか・・・）。
そもそもセキュリティホールが多すぎるんだろうね。でも、これはActivXに絡んだIEの問題なように思うけれど・・・（もちろんIE以外でもバグはあるわけなんだけどね）。
流行はAjaxを初めとするJavaScript。
難しい・・・。