2010-12-12

はじめに

この記事は「PHP Advent Calendar jp 2010 : ATND」の12日目です。

昨日はyuyakさんの「PHPマニュアルを読み解く」でした。

PHPで携帯対応とか

最近はフレームワークを利用した開発が主流なこともあり、（CakePHPであればKtai Libraryと言った具合に）フレームワークごとのライブラリで対応することも多いかと思います。

ですが、仕事で自社独自のフレームワークを利用していたり、昔から運用されているシステムだったり、何らかの理由で携帯対応のライブラリが簡単に導入できない場合もあります。

そういった場合に「このあたりを知っておくと何とかなるんじゃない？」的なものを書いてみます。*1

前提条件

前提条件としては、3G以上の携帯前提です。

また、3G以上の携帯に対応させるための基礎知識としては、

にわかりやすくまとまっています。どちらの記事もぜひ参考にしてください。

文字コード

出力する際は、docomoとauであればSJIS, SoftBankであればUTF-8とするのが良いようです。

数年前であればSJIS統一で問題なかったのですが、SoftBankの3G端末以降だと一部はまる場合があります。逆に、UTF-8で統一してしまうとdocomoの端末やSSL状態のauで問題が出ることがあります。特に、ユーザからの入力が可能なWEBアプリケーションの場合は、絵文字や機種依存文字で抜け落ちが発生することもあるので注意が必要です。

キャリアごとに文字コードを使い分ける方法としては、リクエストを受け取った直後 & 最終出力時に文字コード変換+絵文字変換を行うのが良いでしょう。*2

なお、SJISを使う場合はPHPで文字コード変換を行う場合に「SJIS-win」を利用しないと一部の文字が使えなくなりますので注意が必要です。また、HTTPレスポンスヘッダでtypoしたりと、細かい部分でも気を配る必要があります。

一報、内部文字コードは、これから新規に開発するのであればUTF-8にしておくのが一番無難です。これは、文字化け等の問題以外に、セキュリティ的な観点からもです。特に、SJISの場合には5C問題など色々とはまることがあるので注意が必要です。*3

キャリア・機種判定

キャリア判定などは、PEAR::Net_UserAgent_Mobileなどを使うのがお手軽です。ただし、2009年6月が最後のリリースバージョンが最後となっていますので、最新端末に対応させる場合は自分で対応させる必要があるかも知れません。*4

自前でキャリア・機種判定を行う場合は、アクセス元のIPアドレスで判定する方法とユーザエージェントで判定する方法があります。

IPアドレスで判定する場合は、Net_IPv4_NetworkGroupを用いたりsfMobileIPPluginを参考に自前で判定させるのが良さそうです。ただし、IPアドレス情報は自前で管理する必要があります。

携帯以外でもアクセスさせて構わない場合は、ユーザエージェントで判定する方がお手軽です。

ユーザエージェントで判定する方法はインターネット上に多数公開されているので、そちらを参考にしてください^^;

絵文字

PictgramConverter、Japanese_Mobile_Emoji、Text_Pictogram_Mobile、HTML_Emojiなど、絵文字変換ライブラリが複数公開されていますので、ライセンスや要件に合わせて選択してください。*5

なお、ウノウラボで公開されている文字コードと携帯絵文字については、一度読んでおくことをお勧めします！

デザイン（CSS）

基本的には、XHTML+CSSで構築するのがよいでしょう。ただ、docomoのiモードブラウザ1.0が外部CSSに対応していなかったり、auの一部端末が子孫セレクタをうまく解釈できなかったりと、PCと同じようにデザインを組むと面倒です。

インラインCSSであれば、3キャリアともにだいたい同じ記述ができるのですが、すべてのテンプレートでインライン形式の記述を行うのは結構骨だと思います。

そのような場合はHTML_CSS_Mobileの導入を検討してみてください。*6

なお、上記で「だいたい同じ」と書いた理由ですが、CSSとして同じ記述をしていてもキャリアや端末によって解釈が異なることが多々あります。特に、文字サイズに関しては、キャリアごとに記述を分ける or テンプレート上の記述を出力時にキャリアごとに書き換えるなどの処理が必要になります。

セキュリティ

携帯対応をさせる際には、セッションに関するセキュリティを必ず意識する必要があります。

というのも、iモードブラウザ1.0はCOOKIEに対応していませんし、auやSoftBank端末であってもSSLが絡んだ場合にはCOOKIEの扱いで微妙な挙動をすることもあります*7 とはいえ、無制限にセッションIDをURLに付与すると、今度はセッションIDの漏洩に繋がりセッションハイジャックのリスクが上がります。

かと言って、契約者固有ID（正確にはiモードIDだったりサブスクライバIDだったり端末シリアル番号だったり、キャリアごとに呼称が異なるので、文中ではこの表記とします）をセッションID代わりに使用したりすると、どこのサイトでも取得出来る情報を使ってセッション管理するという、とんでもない状態になってしまいます。

基本的には、COOKIEを利用できる端末であれば（SSL時の挙動の対応も実装して）COOKIEでセッションを管理し、COOKIEが利用できない一部の端末の場合は生存時間を短くしたりセッションID以外の情報によるチェックを実装した上でのセッションID付与、というのが現実的なラインじゃないかと思います。とはいえ「どの程度なら安全なのさ？」と言われると難しいのですが。。。

また、2009年の半ばくらいからJavaScriptを利用できる端末が増えてきていますが、これによりXSSによるかんたんログインのなりすましなども報告されています。*8

明示的にJavaScriptを利用するのでなければJavaScriptのタグを消去したり、PCサイトと同様にXSSやScript挿入攻撃への対応を行う必要があります。