今回のおもな内容 アクティビティとキー変数 CGIやデータベースなどとの連携を図る デバイスレイヤーとCGIの連携 https://を使用したい、basic認証・クッキーなどの扱い メール機能等の連携を考える

　前回「HTMLをHDMLに移植してみる」では、HDMLの主要なタグについて詳細な記述方法を解説しました。最終回となる今回は、前回説明できなかったHDML特有のアクティビティについて解説し、ユーザビリティの向上を図ってみましょう。また、CGIやメール機能との連携など、やや高度なコンテンツ作成のためのノウハウなども紹介します。

■アクティビティとは？

　前回「HTMLをHDMLに移植してみる」の記事で、個々のページを作成したり表示する上でのポイントを押さえました。しかし、複数のページを作成して、1つのサイトとして構成していく上では、これだけでは機能不足です。操作性などの点で、いまだに「使いにくい」とされがちな携帯電話というプラットフォームでPC並みの快適なブラウジングを実現するために、HDMLではカード＆デッキとアクティビティという機能が用意されています（「HDMLの特徴とその記述方法」を参照）。各ページをカードという操作体系で処理し、データをデッキという上位概念でまとめてリクエスト・ダウンロードさせるわけです。

　アクティビティとは、携帯電話上の細分化された1つ1つのページ（カード）、1つ1つの操作、そしてナビゲーションステップのそれぞれを、一連のつながったものとして意味付けをし、操作性をあげるための概念です。

　例えば、PCであれば1ページですむものを、携帯電話向けにはキャッシュ制限の関係で3つのページに分割することがあります。この3つのページを、1つのつながったページ、1つの操作体系の中のページとして認識・位置付けさせるときに使うのが、アクティビティです。これは、戻る・進むの操作を行う際、利用ユーザーに混乱を起こさせずにスムーズなブラウジングを行わせるうえで、意外と重要になってきます。

図1　とある新聞社のサイトのページ構成

　アクティビティを使用すると、図1中の2〜4（アクティビティA）と5〜7（アクティビティB）をそれぞれ1つの連続したまとまりとしてブラウザに認識させることができます。

　例えば、ある人が「1→2→3→4→1」とブラウジングし、次に進んだり戻ったりする場合、ニュースインデックスからアクティビティAをたどり、終了してトップページに戻ったとブラウザに認識されることになります（戻る機能で4に戻らない）。

　またアクティビティAの操作中、それを終了する（1に戻る）のにわざわざURLを指定する必要がありません。iモードなどと比較して、キャッシュを効果的に使用するEZwebにおいては、ブラウザに正しい形でキャッシュを参照させるためにも、アクティビティを正しく使う必要がります。アクティビティは、入れ子構造で設定することもできます。

■変数とアクティビティ

　以上、簡単にアクティビティについて見てみましたが、アクティビティの2つめの意味として重要になってくるのが変数との関係です。

　変数とは、HDMLては「key value」と呼ばれるもので、「キー変数」と呼ぶ場合もあります。ローカル上（端末上）で、変数を格納することができる機能です。JavaScriptやクッキーなどを使って実現していた、ローカル上の入力情報の保存・活用が実現できるものです。HTMLでは、フォームを使って入力情報を管理するときには、「name="****"value="****"」でデータ名や値を管理していますが、HDMLではそれぞれ「key="****"value="*****"」で管理しているので、keyvalueと呼びます。

　keyで指定した名称であれば、ほかのカードでvalueの値を簡単に呼び出すことができます。HDMLにおいては、ほとんどすべての状態で「key="****"」が使用できるようになっているので、かなり便利です。これを使いこなせば、あらかじめ入力された状態で入力フォームを開いたり、CGIなどを使って確認のプロセスのためにサーバやネットワーク環境を使用することなく、少ないセッションで正しい入力情報のみを利用者から集めることも可能となります（ユーザーにとっても、携帯電話という不安定なネットワークシステムにとっても、やさしい構造と言えます）。

図2　リスト1の実行画面（「携帯電話向けサイト」と入力）

　この変数の機能は、端末のフラッシュROMに入力情報をキャッシュする形で実現されています。すなわちコンテンツ提供者のHDMLの書き方によっては、端末上に保存された過去に入力済みのデータを転用する、ということもあり得るのです。悪意を持ったHDMLコンテンツを提供する第三者が存在する前提で考えてみると、これはセキュリティ上大きな問題となります。

　そこでHDMLでは、この変数情報を「1つのアクティビティ内」でのみ利用することが可能な構造になっています。すなわちアクティビティをまたいでの変数の連続使用はできません。

　つまり、使い勝手のよさばかりではなく、入力情報の管理という意味からもアクティビティの使用が求められているといえるのです。

　なおブラウザは、アクティビティ単位でほかにもいくつかの情報をキャッシュしています。過去にブラウジングをした際に選択した番号なども、アクティビティを終了するとすべてクリアされます（アクティビティを出ない限り、過去に選択肢2を選択したページをキャッシュから呼び出した場合、2が選択された状態でページが開かれるので注意が必要です）。

　携帯電話向けのサイトを初めて作るときは静的なページで構わないのですが、サイトの機能をアップしていくと、すぐに行き詰まってしまいます。手っ取りばやく動的なページを作るには、CGIなどのサーバーサイドで動作するスクリプトを使用します。また、EZwebでは古い端末向けに画像配信や着信メロディを配布する場合に、やや高度なCGIを使用する必要があります。すなわち、便利なサイトを実現するためには、CGIの導入は不可避な問題となっています。

　HDMLでは、現在一般にHTTPプロトコル上で一般的に使用されているCGIであれば、問題なく使用できます（Perl、C、ASP、PHPなど）。ただし、携帯電話向けのサイトの場合、特定のイベントや時間帯によってアクセスが極度に集中し、ページビューが多くなることがあります。そのため、公式サイトのようにアクセスがある一定以上見込まれるサイトでは、この使用言語の選定も、ある程度最初から慎重に行う必要があります。その中でパフォーマンス的によく使用されるのが、小規模〜中規模サイト（データベース未使用型・勝手サイトが中心）ではPerl、データベース使用型になるとMySQLとPHPを組み合わせたものなどが主流のようです。

■スクリプトを作成する上での一般的な注意点

　それでは、HDML向けにこれらのスクリプト言語を使用する上で注意しなければならないのはどのような点で、HTML向けに開発する場合との相違点とはどの部分になってくるのでしょうか。

　押さえなければならない点は、大まかには、

1. MIME形式の差異
2. HDMLにおける変数機能とスクリプト上で動作する変数記号の区別
3. URLとキャッシュデータの扱い
4. 禁則文字のエスケープ

の4点と考えればよいでしょう。

・MIME形式の差異

のようなMIMEヘッダを

と書き換えるだけです（Perlでの記述例）。PHPの場合は、

を挿入し、ASPでは

を挿入します（charset=Shift_JISの部分を正しく記述しないと、PC上で動作するSDK上では正しく日本語が表示されますが、実機では「?????」のマークが表示され、エラーとなるので注意が必要です）。

・HDMLにおける変数機能とスクリプト上で動作する変数記号の区別
　HDMLのソース内で使用するキー変数使用のための「$」をスクリプト内でそのまま使用すると、スクリプトの変数記号としてプログラムが解釈してしまう場合があるということです。HDML上において処理させたい「$」については、あらかじめエスケープします。

・URLとキャッシュデータの扱い
　同一CGIにおいて吐き出されるHDMLソース内で、TTL=""で特にキャッシュを指定しない限り、キャッシュデータを優先してブラウザが処理してしまう、ということを意味しています。

　例えば「bbs.cgi」というCGIで、POSTDATAを使ってフォームデータを連続して送受信した場合（1回目には「name=atmarkit」、2回目は「name=Takashi」と送信したかったとしましょう）、2回目のデータは正しくは送信されず1回目の処理結果がそのまま表示されてしまいます。これは.CGIプログラムが、ブラウザ上では処理後の結果データを1つのページのデータとしてブラウザが認識してしまうことが原因と考えられます。こうしたトラブルを回避するためには、

• CGIから出力されるページは常にttl="0"指定をする
• bbs.cgi?name=atmarkitのようにGET方式を使う

のような解決策をとる必要があります。なおブラウザは、GET方式でデータの送受信をした場合（上の例の場合）、「bbs.cgi」ではな「bbs.cgi?name=atmarkit」を一つのURLをとして認識しているようです。(HTMLで出力される場合は、どうやら自動的にttl=0が認識される仕組みになっているようです。)

・禁則文字のエスケープ
　 HDML対応ブラウザでは、ブラウザのフリーズなどを防ぐため、コンパイルエラーというエラーコードが頻発しているようです。これは、タグの一部に誤りがある、「$」「&」などあらかじめ何らかのブラウザ上での特殊機能のために割り当てられた文字が予定外の場所で使用されている、i-モードやJ-スカイなどで使用できる一部の絵文字を読み込む際に、こうした問題が起こります（自動的にエラーをハンドリングする機能がないので注意が必要です）。

　こうしたエラーを防ぐために、エラーが発生する可能性のある文字列をエスケープしておくことが必要です。特にコミュニケーションサイトなどでは対応が求められています。

　例えばPerlの正規表現を使えば、

といったスクリプトが書けます。i-モードなどの絵文字処理については、消去してしまうか特定の文字に変換してしまうのが簡単ですが、最近EZwebの絵文字がバージョンアップされたのでi-モードの絵文字については、ほぼ「<img icon="">」形式で完全変換ができるようです（ただし、変換対応表は公開されていないようです）。

■HTTPヘッダー環境変数を使いこなす

　CGIを使いこなす上で重要になってくるのは、HTTPヘッダの環境変数です。EZweb特有なものとしては、カラー端末／モノクロ端末の識別のための変数、高度なユーザー管理、セッション管理ができる環境変数、アクセス端末を識別できる環境変数などがあります。詳細については、非公式サイトながら、よくまとまっているものとして「CGIぽん」の「モバイルCGI研究（EZweb編）」があります（@MAIL識別のための環境変数は現時点ではありません）。

　以下に、よく使用する環境変数をまとめておきます。

HTTP_USER_AGENT
　端末を識別するものです。公式サイトの「技術情報」 に仕様があります。端末識別情報のことを、業界的にはdeviceIDと呼んだりすることがあります。i-モード、J-スカイでも使用されている環境変数なので、マルチキャリア対応コンテンツなどのゲートウェイとして設置するときに利用すると便利です。

HTTP_X_UP_DEVCAP_SCREENPIXELS
　画面サイズを識別します。壁紙ダウンロードサイトなどで使うと効果的です。横ピクセル数、縦ピクセル数で出力されます。

HTTP_X_UP_DEVCAP_ISCOLOR
　カラー画像が使用できる場合は、「1」が格納されています､

REMOTE_HOST
　アクセス元を表します。EZwebの場合、UPLinkserver（ゲートウェイサーバ）のURLが書かれています。@mail対応のもの・旧セルラー地域のもの・ツーカー端末からのものは「xxx.ezweb.ne.jp」、旧IDO地域のものは「xxx.ido.ne.jp」となっています（さらに細かく分類することもできます）。

HTTP_X_UP_SUBNO
　サブスクライバーIDと呼ばれるものです。各端末に1つずつ与えられた固有のユーザーIDとお考え下さい。これを使用することで、手間のかかるユーザー認証を省いたり成りすましを防いだりすることができます。公式サイト・非公式サイトの区別なく自由に使用することが可能です。「0123456789_a1.ezweb.ne.jp」のような文字列が入ります。

HTTP_COOKIE
　EZweb対応端末では、クッキー機能が使用できます。ただしクッキーデータはすべてUplinkサーバに格納され、通常のPCクライアントのブラウザのように、わざわざアクセスして情報を修正したり削除したりすることはできません。また機能をOFFにすることはできないようになっています。一般に公開されているクッキーの仕様は下記の通りです。

　上記の制限よりも長い文字列に関しては、制限値までのみ格納され、残りは切り捨てられます。VALUEのサイズについては、もう少し余裕がありますが、最低保証サイズという意味で上記の4096バイトを利用するといいでしょう。

　また特に、無期限のクッキーを設定した場合、Netscape NavigatorやInternet Explorer、そしてSDKなどでは、ブラウザを終了させるなどのタイミングでクッキーが無効となります。しかし、実機では、UP.Linkでクッキーを管理しているので、永遠に有効なクッキーとなってしまうようです。

　HDMLの仕様は、携帯電話が今日ほど多機能ではない時代に策定されました。文字を読んだり、入力したり、快適にナビゲーションできたり、そうした機能で十分でした。ところが、日本のようにモバイルで世界最先端を先走るような環境においては、着信メロディーやら、待受け画像やらカラオケデータやらさまざまなものが登場しています。

　EZwebとしては、これらをHDMLという規格上で行うこと自体が難しいと判断して、別の方法を使用することになりました。それが、ネットワークプロトコルを効果的に使用する方法です。（この方法は、韓国などWAP対応サービスが行われている地域でも導入されています）。

　詳細は「携帯電話ダウンロードサービスの違いと通信プロトコル」 に記述がありますが、デバイスレイヤーと呼ばれる、HDML以外のマルチメディアデータを格納できる物理レイヤー上から、直接ダウンロードを要求し、直接ダウンロードさせる仕組みです。

　EZwebではこの仕組みを使用して、着信メロディー、待受け画像、カラオケデータ（CMX）、EZナビゲーション・ezplus（Javaアプリケーション）などの拡張サービスを実現しました。これらのサービスは、長らく公式コンテンツプロバイダのみに技術仕様が公開されてきました。しかし、最近になって、これらの情報の一部分の公開に踏み切り始めています（もっとも待受け画像に関しては、その後ブラウザの機能としてサポートされるようになったので、特にこうした特殊な仕組みを使用する必要はなくなりました）。

　こうしたデバイスレイヤーを使用する場合は、特殊なCGIを使用する必要があります。公式サイトの「技術情報／ダウンロードCGI」に詳細が記述されていますが、ダウンロードを行うための確認のためのプログラム（端末にデータをダウンロードできるのか相互に確認するためのプログラム、ダウンロードデータをネットワークに合わせて分割配信したりするプログラムなどが搭載されている）を使用しています。Perlで作成できますが、やや高度なプログラムに関する知識が求められています。いずれにせよ、本格的にダウンロードデータの配布で勝負をかけたい場合、EZwebにおいては公式サイト申請をすることが定石のようです。

　オンラインショッピングやオンラインバンキングなどのeコマースが関連したサイトを構築したときに、HTTPSを使って入力情報を暗号化処理したい場合があります。EZwebでは、https://を使用することができますが、https://を使用した場合

• 認証局との認証では、クライアント認証が各端末ではなくゲートウェイサーバ間と認証局との手続きとなる
• https://からhttp://ページに戻る場合「ここでセキュリティが確保されているエリアは終わりです」というカードが自動的に挿入される（回避不可）
• 暗号処理されたデータはプロトコル変換のため、UPLinkサーバー上でいったん暗号がほどかれる形となる※1
• 開発段階で、SDK単体によるシュミレーションができない（Openwaveなどが用意した一般に利用ができる開発者向けのUPLinkserverを使用する必要があります）
  
  ※1：WAP2.0ではend to endのセキュリティが保障されています。

といった点に注意する必要があります。

　また、EZwebにおいては、Basic認証やクッキーの扱いは、通常のHTMLの場合と同様、特に差異なく使用することができます。

　従来、EZメールに記述されたURLに自動リンクさせることができなかったので、EZreplyと呼ばれるEZメールの一機能を使った特殊なリンク方法（メールにHDMLの添付ファイルをつけた形で送信する）ことで、メールマガジンや、お友達に紹介するツールを実現していました（サーバ側ではsendmailなどを使用する必要がありました）。また、リンク処理では、HTMLにおける

と指定することも特殊な記述方法を書かない限りできませんでした。ただし、これらはすべての端末（過去に発売されたすべてのEZweb対応端末）において改善が実施されたので、特に問題なく実現できるようになっています。

　ただし、

• メールにURLを添付する場合は半角英数で75文字程度に抑える
• 「<a task=gosub dest=mailto:xxx@xxx.com>メール</a>」とする場合は、subjectや本文をあらかじめ変数として渡すことはできない

といった点に気を付ける必要があります。

◇

　4月の第1回から今回まで、4回にわたってHDMLに関連した連載を続けてきました。この約半年間あまりの間にも、EZweb対応サイトはどんどん増えています。ただ、コンテンツ制作者の悩みとして、WAP 2.0とのからみ・移行が厄介であるためになかなかスムーズな増加が見込めていない、という現状があると思います。今後は、WAP 2.0を見据えて、XHTMLに焦点を当てていく必要があるでしょう。今後は、HDMLやHTMLからXHTMLへの変換などをテーマとして取り上げられればと考えています。

「連載 HDMLでEZweb対応のページを作る」