unoh.github.com by unoh

こんばんは、五十川です。

ご存知の通り、5月以降に発売開始されたNTTドコモの携帯電話の殆どには、新しいiモードブラウザ 2.0が搭載されています。iモードブラウザの大幅な仕様の拡張はi-XHTMLの登場以来ということになりますが、iモードの登場から10年経って登場した新しいブラウザは、i-XHTMLのときよりも遥かに大きな、過去最大の変化を遂げています。

iモードブラウザ 2.0の詳細は、ドコモ公式のiモードブラウザ 2.0にまとめられています。以下では主要な変更点を確認していこうと思います。

キャッシュ容量拡大

1画面あたり読み込めるデータの最大量が、従来の100Kバイトから500Kバイトに、大幅に拡大されました。ご存知の通りiモードの場合この値は、画像などの外部リソースもすべてひっくるめた値ですが、iモードブラウザ 2.0では、新たにCSSファイルやJavaScriptファイルも外部から読み込めるようになりましたので、これらのデータ量もこの制限の対象になります。

なお従来は、最大データ量を超過した場合には、単に警告が表示されるだけというのが一般的だったと思いますが、iモードブラウザ 2.0搭載機種では、機種によるのかもしれませんが、「フルブラウザに切り替えると見れます。切り替えますか？」といった旨のダイアログが表示されるようになっているようです。

なお、サーバサイドでブラウザのバージョンを判定する必要がある場合は、User-Agent文字列中のキャッシュサイズを示す箇所の値が“500”（以上）であるかどうかで行います。

Cookie対応

これまではCookieが利用できなかったため、ドコモ端末に対応したウェブアプリケーションでは、セッションIDをURLに付与する実装が広く行われてきました。他のキャリアはCookieが使えるため、ドコモのみ他と異なる実装が必要で、かつセッションフィクセーションなどの攻撃に対して細心の注意を払う必要がありましたが、ついにCookieがサポートされたことで、iモードブラウザ 2.0を搭載した端末に限っては、他のキャリアと同様の実装が行えるようになったということになります。

iモードブラウザ 2.0のCookieの仕様は以下のようになっています。

端末で有効無効の設定可能（デフォルトは有効）
1件あたり4Kbytesまで、1ドメインあたり20件まで保存
SIM単位

余談ですが、これまでドコモユーザは、Cookie利用を前提とした海外のケータイサイトを利用できず、一方日本のケータイサイトは、攻撃に対する安易な防衛策として、IPネットワークによるアクセス制限が広く実施されてきました。個人的には最大手キャリアのこの仕様が、日本のケータイサイトの、いわゆるガラパゴス化の一因であったのではないかと思っているので、今回のCookie対応は望ましことではないかと考えています。いや、時既に遅しな気もしますけどね。

Referer対応

これはiモードブラウザ 2.0で最も注意しなければならない変更です。

Cookieの項でも述べた通り、ドコモ対応のウェブアプリケーションではセッションIDをURLに付与する実装が広く行われてきました（iモードIDを利用することでこれを回避できますが、iモードIDが登場したのは比較的最近で、それ以前は、公式サイト以外では、URLにセッションIDを付与するか、すべての遷移でUTN属性を使用した個体識別番号の取得を行い続ける以外に、持続的なセッションを管理する方法はありませんでした）。セッションIDが第三者に漏れるとセッションフィクセーションなどの攻撃に晒される危険が生じるわけですが、これまでのiモード端末はRefererを送出しないため、少なくともこれによるセッションIDの漏洩の危険はなかったわけです。しかし、Refererを送出するiモードブラウザ 2.0に対してもセッションIDを含むURLにアクセスさせている場合は、RefererによるセッションIDの漏洩の危険が生じますので、Cookieを利用する（あるいはiモードIDを利用する）ように変更する必要があるかもしれません。

Refererの送出も、Cookieと同様に端末で有効無効の設定が可能です（デフォルトは有効）。

VGA対応

ブラウザ画面のVGAサイズでの表示が可能になりました（以下、ドコモの記述に合わせてVGA/QVGAという表現を使いますが、従来もQVGAが必ずしも240×320ピクセルではなかったのと同様に、VGAと言っても必ずしも480×640ピクセルというわけではありません）。

表示モードは、サイト側が以下のようなMETA要素を記述することで決定します。

<meta
 name="disparea"
 content="{qvga|vga}"/>

content属性値が“vga”であれば、VGAモードになります。値が“qvga”であるか、このMETA要素がないHTMLはQVGAサイズで描画されます。

三大キャリの中でいち早くVGAに対応したソフトバンクでは、VGAかQVGAかはユーザが端末で設定して切り替えますが、ドコモの場合はユーザが変更することはできません。これは、従来との互換性を最大限保つために決定された仕様なのでしょう。

しかし、この画面サイズの変更によって問題が生じる場合もあります。

画面サイズの管理

ひとつは画面サイズの管理です。ご承知の通り、auやソフトバンクと異なり、iモードブラウザはHTTPヘッダに画面サイズ情報を含まないため、画面サイズを特定する必要があるケータイサイトでは、端末ごとの画面サイズを独自に管理する必要があり、これはiモードブラウザ 2.0でも同様です。しかし、これまでブラウザの画面サイズは、原則1端末あたり1種類でしたが、iモードブラウザ 2.0では、VGAとQVGAの2種類の画面サイズが存在するため、サイトが対応する画面サイズに応じて、適切な値を管理しなければなりません。

携帯端末の判別を行うライブラリとしては、PerlではHTTP::MobileAgent、PHPではNet_UserAgent_Mobileがよく利用されているかと思われますが、いずれも現時点での最新バージョン（HTTP::MobileAgentは2009年7月7日付けの0.28、Net_UserAgent_Mobileは2009年6月23日付けの1.0.0）に含まれる画面サイズは、iモードブラウザ 2.0搭載端末のものはVGAのもののみとなっているようです。

以下は、Net_UserAgent_Mobile 1.0.0の構成ファイル中、画面サイズデータを管理しているNet/UserAgent/Mobile/DoCoMo/ScreenInfo.phpの、P-07Aの箇所ですが、縦横のサイズはそれぞれ1種類、VGAのもののみとなっています。

...
// i-mode browser 2.0
'P07A3' => array(
                'width'  => 480,
                'height' => 662,
                'depth'  => 262144,
                'color'  => 1
                ),
...

従って以下のようなコードでは、画面の幅を返すNet_UserAgent_Mobile_Display->getWidth()は、VGAの値である“480”を返します。

// As of Net_UserAgent_Mobile 1.0.0
$mobile  = Net_UserAgent_Mobile::singleton('DoCoMo/2.0 P07A3(c500;TB;W24H15)');
$display = $mobile->makeDisplay();
$display->getWidth(); // 480

もしこれらのライブラリを利用しているウェブアプリケーションがQVGAサイズを想定したものである場合は、これらの値を独自にメンテナンスする必要があるかもしれません。幸いどちらのライブラリも、クラスファイルに直接手を入れる必要はなく、別途にXMLファイルで画面サイズを管理できるようになっているので、サイトがQVGAに対応したものであれば、QVGAの値を入れたXMLファイルを用意すればよいでしょう。

あるいはもし、アプリケーションがVGAとQVGAの両方をページによって切り替えるようなものである場合は、これらのライブラリの現時点での実装では要件を満たせないかもしれません。

横画面のサイズ

もうひとつの問題は横画面のサイズです。これまでにも横画面をサポートした端末は存在しましたが、その画面サイズはいずれも240×240ピクセルでした（画面の横方向に余白があり、そこには時計などが表示されていました）。つまり、縦画面でも横画面でも、画面の幅はいずれも240ピクセルだったわけです。しかしiモードブラウザ 2.0搭載端末の横画面サイズは、従来と同じ240×240ピクセルのものもある一方で、そうではないものも登場しています。iモードブラウザ 2.0の仕様は下位互換性の維持に極力留意されていますが、この点はそうではありません。

例えばP-07Aの場合、QVGAの画面サイズは、縦画面では240×331ピクセル、横画面では427×178ピクセルと、単純に幅と高さが入れ替わった値ですらありません。

従って、画面の横幅を必要とするケータイサイトは、横画面にも対応しなければならない場合は改修が必要かもしれないのですが、困ったことに、サーバサイドのプログラムだけで、アクセスしてきたケータイが横画面であるか縦画面であるかを区別し、その画面サイズを特定するのは容易ではありません。

サーバプログラムが画面の縦横を判定する手がかりとなる、つまり端末から送られてくる情報の中で、画面の縦横で変化するのは、唯一User-Agentに含まれる、表示可能な文字数の値です。従って、この値に、それぞれの画面サイズを紐付けて管理しておけばよいわけですが、悪いことに、この値はユーザが端末で設定するフォントサイズによっても変化します。

縦/横	User-Agent	文字サイズ設定
縦画面	DoCoMo/2.0 P07A3(c500;TB;W16H10)	特大
	DoCoMo/2.0 P07A3(c500;TB;W20H12)	拡大
	DoCoMo/2.0 P07A3(c500;TB;W24H15)	標準
	DoCoMo/2.0 P07A3(c500;TB;W30H18)	縮小
横画面	DoCoMo/2.0 P07A3(c500;TB;W28H05)	特大
	DoCoMo/2.0 P07A3(c500;TB;W35H06)	拡大
	DoCoMo/2.0 P07A3(c500;TB;W42H08)	標準
	DoCoMo/2.0 P07A3(c500;TB;W53H09)	縮小

これらの値をどうにか管理することで縦画面か横画面かの判定が可能かと思われますが、やはり従来に比べれば煩雑な管理を強いられてしまうでしょう。

i-CSS2

これまでのiモードのCSS（i-CSS）で指定できるのは、基本的にはHTMLの要素/属性で表現可能なものに限られていました。また、その記述は一部の例外を除いて要素のstyle属性で行わなければならず、CSSを有効にするにはContent-Type: application/xhtml+xmlの出力が必須であるなど、他の携帯キャリアとも互換性に乏しいものでした。

これに対してiモードブラウザ 2.0のCSS（i-CSS2）は、以下の改善がなされています。

STYLE要素に普通に記述でき、LINK要素による外部ファイルの読み込みもおk
Content-Typeに依存しない（text/htmlでもおｋ）

対応する記述も大幅に増え、より標準に近い指定が可能になりました。ただし制限事項も多くあり、標準的なCSSがそのまま再現できるというわけではありません。

@importなどは無視される
対応するセレクタは、以下の基本的な書式のみ
- *
- E
- E F
- E#myId
- E.myClass

またもちろん、フォント関連の各種指定やoverflow:autoなどのように、ブラウザの実装などの制約に制限されるものは利用できません。

以下はiモードシミュレータでAcid2テストを実行した画面ですが、残念ながらテストのクリアにはほど遠い状態です（それでももちろん、これまでのi-CSSよりは格段の進歩ではありますが）。

iモードシミュレータでAcid2テストを実行した図

font-sizeについて

これまでのiモードのCSS（i-CSS）ではfont-sizeはlarge/medium/small系の指定しかできませんでした。また、表示上有効なサイズは、原則として大中小の3段階で、本来の7段階の指定は反映されませんでした。

従来のiモードブラウザのlarge/medium/smallの表示

iモードブラウザ 2.0のCSS（i-CSS2）でも、large/medium/small系の指定は従来と同じです。これは、おそらく下位互換性を考慮しての決定だと思われます。

iモードブラウザ 2.0/QVGAのlarge/medium/smallの表示

また、large/medium/small系の指定は、VGAとQVGAで画面上の「見た目」が同じになるようになっています。

iモードブラウザ 2.0/VGAのlarge/medium/smallの表示

一方i-CSS2では、%やem、px、ptなどによる指定も可能になっていますが、pxやptなどでの指定は、VGAとQVGAでは画面上の「見た目」が異なる点に注意する必要があります。

端末でのフォントサイズ設定が標準の場合、QVGAでは、medium/100%/1emは20px/15ptで描画されます。一方VGAのmedium/100%/1emは40px/30ptと、QVGAの倍のサイズで描画されます。

QVGAのフォントサイズ指定

VGAのフォントサイズ指定

つまり、large/medium/small系や、%、emなどでの指定では、VGAとQVGAで1行あたりに表示可能な文字数は同じで、つまり見た目も同じになりますが、px/ptなどでの指定では、VGAとQVGAで同じ値を指定した場合、1行あたりに表示可能な文字数は、VGAではQVGAの倍（見た目は半分）となるわけです。

JavaScript

iモードブラウザ 2.0では、ECMA-262準拠のJavaScriptが利用できることになっています。残念ながら、初期のiモードブラウザ 2.0搭載端末の一時的な発売中止以来、現時点までJavaScript機能は無効にされたままですが、今後のソフトウェアアップデートにより、いずれ利用できるようになるでしょう。

iモードブラウザ 2.0のJavaScriptは、DOMやXMLHttpRequestを含む本格的な実装となっています。CSSが標準準拠を謳いながら、あいにく標準からははまだまだかけ離れたものであるのとは対照的に、JavaScriptについては、CSSと異なり下位互換性に配慮する必要がなかったからでしょうか、CSSなど他の実装の制約に依存するものを除いては、基本的にかなり標準に忠実な実装となっており、PC向けのウェブブラウザ向けに書かれたJavaScriptが、そのままで、あるいはわずかな修正で動作する可能性があります。

以下は試しに、clippのJSONP形式フィードをパースして表示するJavaScriptのサンプルプログラムを、iモードシミュレータで動作させてみた図です。

JSONPフィードを表示するサンプルプログラムを動作させてみた図

これはその作りがそもそも非常に簡単なものであるためというのもありますが、CSSとそれに関連する箇所のわずかな修正だけですんなりと動作させることができました。

さらに、iPhone向けサイトのJavaScriptフレームワークの定番であるiUIを修正して、iモードシミュレータで動作させてみました。

iUI修正して動作させてみた図

CSSについては結構手を加える必要がありましたが（そしてまだまだiUI本来のものの再現にはほど遠い出来映えですが）、JavaScriptについては一切手を加えることなく、iUIのサンプルをシミュレータで動作させることができました。iUIのJavaScriptは結構複雑ですが、それが概ねきちんと動作するというのは、iモードブラウザ 2.0のJavaScript機能には大きな期待を抱かずにはいられません。

マルチメディア関連

PNGとBMPに対応

PNGが表示できるようになりました。これでようやく三大キャリアの端末がGIF、JPEG、PNGのいずれにも対応するということになります。

Flash Video対応

FLVファイルが再生できるようになりました。再生方式はインラインとプログレッシブダウンロードが利用できます。インライン再生の場合は、データ容量は、1画面あたり読み込めるデータの最大量（500Kbytes）で制限されます。一方プログレッシブダウンロードでは、iモーションと同様10Mbytesまでの動画を配信できます。

Windows Media対応

初期のFOMAには、ASFコンテナを採用したASF対応iモーション（コーデックはMPEG4/AMR）というものがありましたが、決してそれが復活したわけではなく、一般的なWindows Mediaが再生できるようになりました。

対応コーデックはWindows Media Video/Audio 9で、基本的に320×240px/500Kbps/30fpsといった仕様の動画が再生可能です。配信方式はストリーミングが基本ですので、配信にはWindows Mediaサーバが必要になります（機種によってはダウンロード再生も可能ということです）。ストリーミング配信では、サーバにアクセスするのはiモードブラウザではなくWindows Mediaプレイヤーになり、そのUser-Agentは、NSPlayer/9.0 ({機種名}_iB;FOMA)のように、Windows Mediaプレイヤーの標準的なものに準じたものになります。

ページ内への埋め込みは、なぜかEMBED要素を使用することになっています（指定できる属性はSRCとTYPEのみです）。

<embed
 type="video/x-ms-asx"
 src="hoge.asx"/>

スクリーンキャプチャ、テキストのコピー＆ペースト、およびこれらの禁止設定

スクリーンキャプチャは、画面メモの保存時に、従来のものに加えて表示画面を静止画像として保存できる機能です。スクリーンキャプチャは、通常の画像とは異なり、「データ」フォルダではなく、画面メモのひとつとして保存され、再配布やコピーはできません。

テキストのコピーは、従来のフォーム要素だけではなく、ページ内のすべてのテキストがコピーできるようになりました。テキストのコピーは、iモードブラウザ 2.0で標準仕様になった疑似ポインタを利用することで、広い範囲をスムーズに選択できるようになっています。

また、新たに導入されたMETA要素によって、これらと、画像の保存および画面メモを禁止できるようになりました。なおフレームドキュメントの場合は、フレームを構成するドキュメントのいずれかひとつにでもこの指定があれば、フレームの全ドキュメントで禁止になります。

<meta
 name="prohibition"
 content="{image|text|image,text}"/>

content属性値で禁止対象を指定します。

image: スクリーンキャプチャ, 画面メモ, 画像保存を禁止
text: テキストコピーを禁止
image,text: 全部禁止

フレーム対応

iモードブラウザ 2.0はFRAMEおよびIFRAMEに対応しています。ただしPC向けのウェブブラウザと異なり、スクロールバーは表示されません（スクロールはできます）。またフレームの内外への移動は、iモードブラウザ 2.0で標準仕様になった疑似ポインタを利用するのが基本のようです。

マルチウィンドウ対応

iモードブラウザ 2.0では、最大5ヶのブラウザ画面を保持できるようになっており、“target="_blank"”などを付与したリンクなどは、新しいブラウザ画面で表示されます。

もっとも、ドコモは「ウィンドウ」という表現をしていますが、ウィンドウシステムというわけではなく、画面を切り替えるというイメージです。

マイニュース、マイリンク

マイニュース

iメニューのトップページに、登録したフィードの更新情報を簡易に表示できる機能です。フィードを登録させるには、以下のようなリンクを用意します。

<a href="http://docomo.ne.jp/cp/siteadd.cgi?
   sflg=1&amp;
   surl={フィードURL}&amp;
   nl={戻り先URL}">マイニュース登録</a>

マイリンク

iメニューのトップページに、登録したURLのリンクが表示される、簡易なオンラインブックマーク機能です。URLを登録させるには、以下のようなリンクを用意します。

<a href="http://docomo.ne.jp/cp/siteadd.cgi?
   sflg=2&amp;
   surl={ブックマークするURL}&amp;
   snm={ブックマーク名}&amp;
   nl={戻り先URL}">マイリンク登録</a>

マイニュース、マイリンクはまだユーザに馴染みの薄い機能ですので、以下のような、説明ページへのリンクを添えるとよいかもしれません。

<a href="http://docomo.ne.jp/imt/my/week/03bunsan_mynews_it">マイニュースとマイリンクとは</a>

その他

User-Agent

User-Agentの書式は従来と同じです。これだけ大きな変更にも関わらず、冒頭の“DoCoMo”に続くバージョン番号も“2.0”のままで変わりありません。これも下位互換性に配慮したものなのでしょうか。サーバサイドでブラウザのバージョンを判定する必要がある場合は、User-Agent文字列中のキャッシュサイズを示す箇所の値が"500"（以上）であるかどうかで行います。

左右キーの割り当て変更

iモードブラウザ 2.0搭載端末では、ユーザインタフェースには大きな変更があります。従来十字キーの左右は、「戻る/進む」機能でしたが、戻る/進む機能は左右のソフトキーに割り当てとなり、十字キーの左右は左右のフォーカス移動に変更になりました。これはつまり、ソフトバンクのキー割当と同じです。従来の端末から機種変更したユーザは、これには戸惑うことでしょう。

Shift_JISテキスト形式の絵文字ついに廃止

ドコモでは絵文字の記述方式がいくつかありますが、そのうちのひとつ、Shift_JISテキスト形式（&#nnnn;形式）がついに廃止になりました。この書式は従来でも推奨されていませんでしたので、使用しているサイトは多くはないと思われますが、使用している場合は他の書式にあらためる必要があります。

DOCTYPE宣言

iモードブラウザ 2.0でのi-XHTMLのDOCTYPE宣言は以下のものということになっています。これは従来のものと、“Ver.=ja/2.3”の箇所のバージョン番号が変わった以外は同じで、DTDのURIすら変わっていません。また、従来通りDOCTYPE宣言はレンダリングには影響しないようです。

<!DOCTYPE html PUBLIC
 "-//i-mode group (ja)//DTD XHTML i-XHTML(Locale/Ver.=ja/2.3) 1.0//EN"
 "i-xhtml_4ja_10.dtd">

要素・属性

iモードブラウザ 2.0ではさまざまな要素・属性が追加されています。詳細はドコモ公式のiモードブラウザ 2.0を参照ください。個人的に上記以外で気になった点は以下でした。

META要素のhttp-equiv="refresh"がサポートされました。
HTML要素でxmlns属性が指定できるようになりました（もっともレンダリングには影響しないようですが）。
原則すべての要素で、id属性とclass属性が指定できるようになりました。
A要素に“ib”という属性が追加されました。この属性が付与されたリンクは、フルブラウザで開かれます。

iモードブラウザ 2.0は、画面サイズとキャッシュ容量の拡大、JavaScriptのサポート、CSSの改善などで、PC向けのブラウザに近い表現力を身につけたものになりました。しかしPC向けのブラウザと比べて遜色のないものとなったかというと、そういうわけでは決してありません。おそらく他社との差別化を図る一方で、自社のスマートフォンやフルブラウザとの差別化、および従来との下位互換性の配慮などによる、ある意味妥協の産物のようにも思えます。

個人的にはiモードブラウザ 2.0の最大の魅力はJavaScriptだと思うのですが、残念ながらこれは、最初に発売された端末の一時的な発売中止以来、現時点まで無効にされたままです。この発売中止の際のドコモの対応は、自分の知る限り過去に例をみないもので、緊急のアップデートを繰り返し、そのたびにUser-Agentを変更し、さらには期日までにアップデートを行わなかった端末はパケット通信を不能にするという、極めて切迫したものでした。そして今でもJavaScript機能は無効にされたままです。果たしてこうした対応を行わざるを得ないほどの不具合とはいったいなんだったのでしょう。なんにせよ、この機能は早々に復活して欲しいものです。

以上、先日iPhoneにMNPしてドコモとおさらばした五十川がお送りしました。

2010-02-11追記

2010年2月発売のP-03Bのブラウザには「iモードブラウザ2.0LE」という呼称が与えられ、通常のiモードブラウザ2.0とは区別されています。通常のiモードブラウザ2.0との相違は、iモードブラウザ2.0LEの対象機種と省略機能についてによると、P-03Bの場合はVGA非対応ということですが、LEがイコールVGA非対応であるのか、それ以外にもなんらかの制約があるものを総称してLEと呼ぶのかは、現時点では不明です。