Ajax対応その他
いやー、Old TypeのWebプログラマは困っちゃうね。俺の事だけど。
元々、Web1.0バブル以前からWebプログラミングの仕事してたんだけど、その後携帯のコンテンツ中心の仕事になって本格的なWeb制作からは遠のいていた。そして知らぬ間にWeb2.0の時代になって来てそれを横目で見ながら過ごしていて、再挑戦しようとしている訳だ。
テーブルレイアウトから整形XHTMLによるCSSレイアウトへ。
Ajaxの使用（ただしどの程度使いまくればいいのか、いまいち疑問がある。後述）
そして今回すこしはまってしまった文字コード。UTF-8への変化。
Permalinkに耐えうるURL設計。やたら長いクエリーストリングの排除。
今、仕事で使っているサーバで新しくWebのプロジェクトを始めようとしてるんだけど、プログラミングはなれたPHPでやろうとしている。新しいWebの流れに対応した自己流のフレームワークをRuby on Railsとそれを参考にしたCakePHPを参考にして作っても見た。そしてそれを実践する為に今自分用のメモ帳アプリケーションを作っている。実は俺は今でもPalm Desktopを一部使っており、スケジュールとかTodoはGoogle Calenderに以降したり、もう既にPalm自体も使っていないのだが、メモだけはまだPalm Desktopに残ったままでそれを参照している。そこで、それをオンラインに移行しようと思った訳だ。作るのは目的が完全にツールということで、であれば、Ajaxも使った方が実践になる。という事で始めた。
そこでまず簡単な問題につきあたった。Ajaxを使うと言う事は文字コードはUTF-8である必要があるという事だ。
responseTextもresponseXMLも大概のブラウザではAjaxでのサーバからのデータ取得はUTF-8で行われる。
それを抜きにしても、他の公開WebAPIを使ったりとか、他言語対応を考えたりとかいう事を考えてもUTF-8の方が有利。現在の趨勢もUTF-8という事になっているようだ。
俺は今はずっと携帯のプロジェクトをやって来たので、PHPやMySQLの環境がShift_JISで統一されている。
具体的にはphp.iniのmbstringのhttp_outputやinternal_encodingはもちろん、http_inputまでShift_JISで決めうちしている。script_encodingまでShift_JISである。当然、encoding_translationなんてOffである。完全に携帯電話のブラウザを意識した設定になっている訳だ。そんな事だからMySQL4.0のdefault_charsetもSJISになっている。
これではいけない、とわかったのはコーディングを少し初めてからだった。（あほな俺）
で、設定を変えたいけど、他のプロジェクトに影響があるからphp.ini本体を買える訳にはいかない。
ということで、.htaccessの中でphp_valueとかでUTF-8用の設定をすれば良いと考えた。
で、設定したのだが、うまくいかない。
display_errorはOffにしてありlog_errorsはOnなのでerror_logをみるとemalloc()のエラーでなんかバイト数が出てる。PHPが内部でエラーして強制終了しているらしい。。。これで数時間いろいろ試行錯誤したんですが、全く解決できず昨日はそれで終了。
そこで対策。
まずは.htaccessでなく、http.confの
これはあまり可能性は少ないけど一応やってみる。
次にだめなら、素直に新しいサーバでやってみる。
ただしそこも基本のini設定はShift_JISになっているので、昨日の疑問もあるので、.htaccessでのini設定をやってみたい。それでだめなら、ここのサーバのini本体をUTF-8用に書き換える。このサーバではPHP使ってるのが一カ所しかないので、そこを書き換えてあげればなんとか対応できよう。
ただしこのサーバはRapidsiteのVPSサーバなので、MySQLの設定がまだきちんと出来ていない。
そっちの設定もしなければならないし、MySQL自体がVer3代なのでちょっと不安。たしかUTF-8をデフォルトには出来まい。するとツールの関係上default_charsetはSJISになるのだろうが、おそらくそうするとPHPのinternal_encodingもあわせてSJISにせねばなるまい。でもPHPの変換機構を考えるに、http_inputをautoにしてencoding_translationをOnにしてあげれば、自動的にHTTP入力の文字コードを判別してinternal_encodingのSJISに変換してくれるはずだ。たしかencoding_translationを有効にしてやれば、script_encodingがUTF-8でもそれもinternal_encodingに変換してくれるはずだ。そしてhttp_outputをUTF-8にすればmb_output_handlerが自動的にHTTP出力をUTF-8に変えてくれるはずだ。
あともう一つの可能性はプログラム内で対処するという方法。
今回のフレームワークでは最終的にたった一つにフロントコントローラが全てを処理するので、そのフロントコントローラプログラムにエンコード機能を付け加えてあげればよいかも。
具体的には、必ず頭に、header( "Content-Type: text/html: charset=UTF-8" ); を入れてやる。
mb_output( "UTF-8" ); してやる。
ob_start( "mb_output_handler" ); してやる。
その後プログラムの出力をしてやって、
最後に、ob_end_flush(); してやって終了してやる。
これで出力関係はなんとかうまくいくかも。
入力関係は、php.ini本体を、mbstring.encoding_translation = On と、mbstring_http_input = autoにしてやっても別に他の携帯プロジェクトに影響は無いだろう。どっちみち内部ではSJISに変換されるのだから。
でもこの場合もscript_encodingはSJISのままなので、HTMLも含め文字コードSJISで書かなければならない。
ヘッダのmetaタグではUTF-8に記述しながら。。。
なんか最後の手は変態的な感じがする。正当な方法でなくバッドノウハウになりそう。
こんなのチャレンジしても今後に生きないしね。
ということで、今日はすこしずつ上記にTryしてみる予定。
しかし話は変わるけど、AjaxとSEOに関して悩むところがある。
Ajaxは基本的に画面遷移をなくす。一つの画面で非同期で取得したデータを動的に画面に流し込んで画面を変えて行く。ということはPermalinkは一つのままである。つまり、Ajaxを使って一つの画面で、いろいろな情報を動的にサーバから非同期取得して画面に表示するようになると、普通数画面に遷移させるパターンと比べて、Permalinkが圧倒的に少なくなるのだ。これはSEO的に不利ではないか。簡単に言うとGoogleやYahooに引っかからない。
そこで考えるのは、Webサービスには二つの面があるという事だ。
一つはメディアとしての側面、もう一つはツール（ソフトウェア）としての側面。
メディアとしての側面を考える場合は、ちゃんと情報単位毎に画面遷移をさせてやり、それぞれにPermalinkを持たせてやった方が良い。
ツール（ソフトウェア）としての側面を考える場合はAjaxを使ってあげた方が使い勝手が良い。
要はこのバランスなんだと思う。
何でもかんでも全てAjaxを使いまくるというのには反対である。Permalinkがなくなるからコミュニケーションが生まれにくい。
つまり、友達にある情報をみてそれを教える場合にPermalinkがある場合はそれをおしえればそれで済む。
しかしそれがAjaxアプリの場合だと、あのページにアクセスして、左の上から３番目をクリックして、その後ラジオボタンをクリックして下のボタンを押すとみれるよ、とか言うようになってしまう。これは不便。
やはりWebサービスの内、本当にツール性の求められる最低限の部分だけにAjaxを使用すべきで過度の使い過ぎは問題だろう。ちゃんとメディアとしての側面とのバランスを取るべきである。
そんな事も考えた昨日今日でありました。
