前回はMobaSiFでのWebアプリケーション実装例を示し、実行時の内部処理を説明しました。今回はMobaSiFに含まれる個々のPerlモジュールを解説していきます。
MobileEnvモジュール
MobileEnvモジュール(pm/MobileEnv.pmファイル)は、
- 接続元IPアドレスでのケータイキャリア判別
- ケータイ機種情報、端末IDの取得
を行います。リスト6のようにして使用します。
MobileEnv::set( )を行うと、以後は表2に示した値を「MB_」から始まる名前の環境変数より取得できるようになります(MobaSiFのディスパッチャを利用してWebアプリケーションを記述する場合、pm/Page/Main.pm内で実行されるため、常にこれらの環境変数を利用できます)。
IPアドレスとMB_CARRIER_IPの関係は、D、A、Vについてはconf/ipident.confファイルで、I、Xについてはconf/ipident_local.confの各ファイルで指定します。したがって、キャリア側でIPアドレスの変更があるたびにconf/ipident.confの更新が必要になります。
表2 MobileEnvモジュールにより取得できるデータの例
環境変数名 | データ内容 | とり得る値 |
MB_CARRIER_IP | 接続元IPアドレスに基づいたキャリア判別 | “D”=NTTドコモ “A”=au “V”=ソフトバンクモバイル(VはVodafoneの名残) “I”=社内からのアクセス “X”=リバースプロキシ経由 “-”=上記以外(一般のPCからの接続など) |
MB_CARRIER_UA | User-Agentから判別したケータイキャリア | “D”、“A”、“V”(上記と同じ) |
MB_MODEL_TYPE | ケータイ機種(世代)分類 | “DM”=ドコモmova端末 “DF”=NTTドコモ FOMA端末 “AH”=auHDMLブラウザ搭載端末 “AU”=au WAP2.0ブラウザ搭載端末 “VC”=ソフトバンクモバイルC型端末 “VP”=ソフトバンクモバイルP型端末 “VW”=ソフトバンクモバイルW型端末 “VG”=ソフトバンクモバイル3GC型端末 |
MB_MODEL_NAME | 機種名 | 機種名を示す文字列(auは2章19ページ表3で説明した「デバイスID」) |
MB_SERV_LV | 対応端末判定結果 | “-1”=非対応端末(判断ロジックはMobileEnv.pmに埋め込み) |
MB_UID | (ユーザが拒否設定しない限り)常時取得できる端末ID | NTTドコモの場合:iモードID auの場合:EZ番号 ソフトバンクモバイルの場合:UID |
MB_SERIAL | 端末ID | NTTドコモ mova端末でutn取得の場合:製造番号(先頭のserを除く) NTTドコモ FOMA端末でutn取得の場合:FOMAカード製造番号(先頭のiccを除く) |
MB_SERIAL2 | 付加的な端末ID情報 | NTTドコモ FOMA端末でutn取得の場合:FOMA端末製造番号(先頭のserを除く) |
Requestモジュール
Requestモジュール(pm/Request.pmファイル)は、ユーザがFORMに入力した値、あるいはURLのquery stringに設定した値をハッシュリファレンスの形で利用できるようにします。リスト7のようにして使用します。
MobaSiFのディスパッチャを利用したWebアプリケーションでは、pm/Page/Main.pm内で自動的に実行されるため、$_::FでReqeustインスタンスを利用できます。
UserDataモジュール
ユーザ情報は、MobileEnvモジュールで提供される環境変数MB_UID(端末ID)に基づいてuser_dataテーブルから取得します。リスト8のようにして使用します。配布されるUserDataモジュールでは、表3にまとめたキーを利用して、対応する値を取得できます。なお、環境変数MB_UIDに対応する行がuser_dataテーブルにない場合は、これらの値は未定義になります。
このほかの値の登録/取得が必要な場合は、user_dataテーブルへのカラム追加とUserData.pm中のSQL文の変更が必要になります。
表3 UserDataモジュールで使用するキー一覧
キー名 | 取得できる値 |
USER_ID | ユーザを特定するユニークな番号 |
USER_ST | conf/pages.confで要求される会員登録状態 |
SERV_ST | conf/pages.confで要求される操作に対する制限状態 |
REG_MODEL | 登録時のケータイ機種名 |
MobaSiFのディスパッチャを利用してWebアプリケーションを記述する場合、pm/Page/Main.pm内で自動実行されるため、$_::UでUserDataインスタンスを利用できます。また、この値はディパッチャ自身でもconf/pages.confで要求する各種ステータスのチェックに利用されます。
絵文字変換Mcode、SoftbankEncodeモジュール
絵文字変換には、McodeとSoftbankEncodeモジュールを使用します。これらのモジュールはXSで実装されており、処理が高速という特徴があります。
MobaSiFでの絵文字処理の流れ
MobaSiFでは、次のようなことを簡単に実現するための絵文字処理系を持っています。
- ユーザはFORMから絵文字を入力可能
- Webアプリケーション開発者は3キャリア共通のテンプレートを1ファイルで記述可能(=キャリアごとの絵文字の使い分けが不要)
- 同じケータイキャリアを利用するユーザ間では、入力された絵文字そのままの絵文字を表示可能
- 異なるケータイキャリアを利用するユーザ間では、独自のマッピングを利用して近似した絵文字を表示可能
- 上記を実現するためのDB保存用独自統合コード
図1を見てください。MobaSiFでは、絵文字はこのように処理されています。d-sjisはNTTドコモ絵文字のShift-JISバイナリコード表現を、a-sjisはKDDI絵文字用Shift-JISコードを、v-utf8はソフトバンクモバイルのUTF-8コード(&#x????;というような数値文字参照形式ではなく3バイトのもの)をそれぞれ示します[1]。
v-sjis-uは、ソフトバンクモバイルの絵文字をMobaSiF内部で扱うためのMobaSiF独自形式です。ソフトバンクモバイルにはv-utf8以外にWebコードという公開された表現方法を持っており、このコード体系は16進数表記で1B 24 {C1} {C2} 0F(計5バイト)となっています(本稿ではこれをv-sjis-wと呼びます)。v-sjis-uはこのうち{C1} {C2}部分を取り出し、16進数表記で0B {C1} {C2}というコードに変換したものです。
ユーザからの入力
NTTドコモとauの端末にはShift-JISのページを出力するので、FORMから入力された絵文字コードはそれぞれd-sjis、a-sjisでサーバに届きます。一方、ソフトバンクモバイル端末にはUTF-8のページを出力するので、FORMから入力された絵文字コードはv-utf-8でサーバに届きます。
DB保存のための統合コード
サーバ側では、NTTドコモとauの端末からの入力を、Mcode::any2u( )を使って独自の統合コードに変換することになっています。実際は、入力されたd-sjis、a-sjisについては特に処理を行わずスルーしています。一方、ソフトバンクモバイル端末から入力されたv-utf-8は、SoftbankEncode::utf8_to_sjis( )を使ってv-sjis-wに変換してからMcode::any2u( )に渡され、v-sjis-u に変換されます。
d-sjis、a-sjis、v-sjis-uはそれぞれ重なり合わないコード体系ですので、各キャリア端末から入力された絵文字コードがそれぞれ別々のコードとしてDBに保存されます。これが独自統合コードの実体です。「混在コード」と呼ぶほうが意味的には正しいかもしれません。
テンプレートでの扱い
MobaSiFのテンプレートエンジンでは、1枚のShift-JISで記述されたテキストテンプレートを事前にコンパイルして、バイナリテンプレートをキャリアごとに出力します(=計3枚のバイナリテンプレート)。テキストテンプレートに絵文字を入力する場合、d-sjisで記述します(したがってNTTドコモ提供の「i絵文字」アプリケーションを利用できます)。バイナリテンプレート中の絵文字は、3キャリアともd-sjisで表現されます。
テンプレートへDBから取得した値をセットして出力
DBから取得した統合コードはそのままテンプレートにセットされ、その後バイナリテンプレート中のd-sjisコードとともにMcode::u2any( )サブルーチンで変換されます。この変換は、入力がどんなコードであっても、出力先がNTTドコモ端末の場合はd-sjis、au端末の場合はa-sjis、ソフトバンクモバイル端末の場合はv-sjis-wになるように行われます。
ソフトバンクモバイル端末に出力する際は、その後SoftbankEncode::sjis_to_utf8( )に通してv-utf-8に変換されます。この際、絵文字だけでなくテキストの文字コードもUTF-8に変換されます。したがって、各キャリアの端末が受信するページの文字コードと絵文字コードは
- NTTドコモ:Shift-JIS、d-sjis
- au:Shift-JIS、a-sjis
- ソフトバンクモバイル:UTF-8、v-utf-8
となります。
Mcodeモジュール、SoftbankEncodeモジュールの利用例
MobaSiFのディスパッチャとResponseモジュールを利用する場合、ここまでで説明したMcodeモジュール、SoftbankEncodeモジュールのサブルーチン実行はRequest、Responseモジュール内で自動的に行われるため、意識する必要はありません。
個別にモジュールを利用する場合、Mcodeモジュールはリスト9、SoftbankEncodeモジュールはリスト10のように使います。リスト9では、any2u( )で端末から受け取った絵文字コードを統合コードに変換する例と、u2any( )で文字列$strに含まれた統合コードを$carrierで指定されたケータイキャリア端末向け絵文字コードに変換する例を示しています。$carrierは'D'(NTTドコモ)、'A'(au)、'V'(ソフトバンクモバイル)が指定できます。リスト10はutf8_to_sjis( )で$str中のv-utf-8をv-sjis-wに、sjis_to_utf8( )で$str中のv-sjis-wをv-utf-8に変換する例を示しています。
今回はMobaSiFに含まれる個々のPerlモジュールを解説しました。次回は、MobaSiFに含まれる高速でケータイ対応されたテンプレートエンジンMTemplateについて説明します。