１）外字ファイルの登録
DOCOMOサイトから”i絵文字”をダウンロード、解凍し、インストールする
→IEなどでDOCOMOの絵文字が見れるようになる。
ソフトバンクやauの絵文字は、基本のものは3キャリアで絵文字置き換えプログラムによって変換するからこれでOK。

２）FIREFOXでも絵文字を見る場合（シミュレーターなどで）

1. コントロールパネルから、フォントフォルダを開き(Vista では、[デスクトップのカスタマイズ] [フォント])、i絵文字をインストールしたディレクトリにある外字フォント「docomo.tte」をインストールする。
2. FireFox3でアドレスバーに 「about:config」 と入力して [Enter]キーを押す。
3. 「フィルタ」の入力欄に 「font.name-list.*.ja」 と入力する。
4. 表示された項目それぞれ、現在の設定文字列の先頭に「EUDC, 」を追加。

おお～。確認できた♪

３）FIREFOXの携帯エミュレータ

FIREFOXで携帯のサイト確認ができる。ユーザーエージェントを携帯のものに置き換えて、見た目をシミュレートする。

http://firemobilesimulator.org/　（携帯用シミュレータ）

http://www.qooin.com/firefox/useragent.html　（ユーザーエージェントをスイッチする）

3キャリア共通でコード利用したいのであれば、基本3G以上を対応機種と考えて、古い機種についてはある程度の割りきりが必要。

XHTMLで記述
コンテンツのMIMEタイプもHTTPヘッダーも「application/xhtml+xml」
文字コードは、Shift-JIS
CSSは基本インライン
画像の全画面表示サイズは、240pxで作成してwidth=100%としておく
画像フォーマットは、JPEGかGIF
ページ全体の容量は、トップページで100KB以内（広範囲で対応させるには5KB）
文字サイズは、標準で全角10文字程度（小で13文字程度）
絵文字を共通化するにはPHPなどの絵文字共通化プログラムが必要
コーディングでインデントを使わない

【デザインのポイント】
<hr>はキャリアによって指定・表示に癖が出る
・ドコモでは、XHMLでは全ての属性に非対応
・ソフトバンクは、罫線の上下にマージンができる、hrの余白調整はmargin/paddingプロパティで対応可能、noshadeにも対応
・auは、ライン色はcolorで指定可能、height/borderは指定できない、text-alignプロパティが使用可能（au以外では、align属性を使用する）
・WIDTHは全キャリア使用可能
・hrを使うより画像使用したほうがキレイにできる

画像
・ドコモXHTMLではalign属性が非対応、CSSでのフロートはauが非対応のため、画像の回り込みをするには、両方の属性を併用しなければならない
・回り込みの解除は、<br clear=”all” />だが、ドコモ非対応、ドコモでは、「blockquote」「dl」「div」「form」「hr」「h1-h6」「ol」「ul」「p」「pre」にclear属性を記述すれば旧機種でも対応できる。
・画像のmarginはドコモでも対応
・画像のborderはドコモ非対応

リンク
・ドコモxhtmlは、<a>タグのname属性に非対応なので、<a>タグには、nameとidを両方使用する

・auでは、auではdivなどのブロックレベル要素間で1pxほどのすき間が生じてしまうというバグがある
・ドコモとau／ソフトバンクの違いということであれば、外部CSSにau／ソフトバンク用のCSSを書いておいて、ドコモにはインライン指定のCSSを優先させるといった手順をふむことで、違いを吸収するということが可能
・CSSはstyle属性が優先されるので、ドコモのインラインCSSとソフトバンク/auの外部CSSを共存する場合は、<DIV>タグを入れ子にして外側をインラインCSSにして内側のdivにソフトバンク/au用のクラスを指定する
・アクセスキーの設定：一般的には「[0]がトップページ」「[9]が1つ前のページへ戻る」「[5]更新」としているサイトが多い
・入力モードの設定：ドコモのiモードHTMLの場合は、「istyle」属性を、iモードXHTMLの場合は、style属性で「-wap-input-format（WCSS）」を指定します。auの場合は「format」属性で、ソフトバンクの場合は「mode」属性をinputタグに指定します。3キャリア対応で書く場合は、それぞれの属性をinputタグに併記すれば問題ない。ただし、-wap-input-format（WCSS）をソフトバンクで読み込むと入力制限がかかるバグがある。このため、入力設定をしたいフォームでは、スクリプト側でキャリアごとの振り分けをするとよい。
振り分けをする場合は
DoCoMo
style=-wap-input-formatのみ
au/SoftBank
istyle、format、modeをすべて記述
という感じになるように切り替えてやると、おかしな状況にも対応でき、きちんとした入力モードの切り替えが実装できる。

Smartyのプラグインなり、ヘルパーにまとめるなりしてやると、簡単に使える。

参考：http://www.thinkit.co.jp/channel/0810_2.html

（http://blog.livedoor.jp/ld_directors/archives/51079649.html　より）

Web サーバは一般的に2つの方法でアクセスがモバイルからかどうかを判定します。1つはアクセス元のIP、そしてもう1つは HTTP ヘッダ中にある User-Agent です。そのため、携帯キャリアのゲートウェイ経由からのアクセスのみ閲覧を認めるサイト(つまりアクセス元の IP で閲覧制限するサイト)を除けば、モバイルコンテンツはPCから閲覧できます。User-Agent は申告制のため、PC からのアクセスでもモバイルブラウザーのUser-Agent に偽装することが可能だからです。

HTTP リクエストの User-Agent を変えたり、HTTP レスポンスを処理する方法は大きく
１．モバイルシミュレータを使う方法
２．(InternetExplorer や Firefox のような)汎用の Web ブラウザ＋プロキシを使う方法
３．ブラウザそのものの機能やアドオンやプラグインを使う方法
の3つの方法がありますので、順に紹介します。

【01】モバイルシミュレータを使う方法

モバイルのシミュレータは携帯キャリア各社のサイトからダウンロードができます。それぞれの詳細は『携帯シミュレータ入門』で紹介されていますので、こちらをご覧ください。

また、現在は有償ですがネットファームさんから高機能なシミュレータ『P1 Emulator～ケータイマルチキャリア高機能テスター』も出ていますね。

これらはモバイルに特化していますので、お手軽に絵文字の表示など文字通り忠実に再現を行い、また仕様に照らし合わせた構文チェックなどもしてくれるところが便利です。ただ、使用できるOSは現在のところ Windows のみです。

個人的には、iモード HTML シミュレータIIの全体画面をキャプチャする機能が資料作成の際に便利なので重宝しています。

【02】汎用のWebブラウザ＋プロキシを使う方法

HTTP リクエストやレスポンスの変換処理をプロキシに任せる方法です。プロキシが全てやってくれるので、汎用の Web ブラウザを表示に使えるのが利点です。

この方法には、モバイル専用のプロキシサーバを立てる方法と、自分のPC内にプロキシを立てる方法があります。ライブドアでは、社内で独自のモバイルプロキシサーバを立てています。ポート別に User-Agent やサブスクライバID を設定しておくことで、機種別での細かい挙動の差を見ることができます。モバイル関係の企業にはこのような専用プロキシがあることが多いのではないでしょうか。ただ、別途サーバが必要のため、個人ユースには向きません。

その場合には、Windows 上で動作するローカルプロキシソフトウェアである『Proxomitron』が利用できます。Proxomitron は非常に高機能で便利ですが、モバイルに特化したプロキシーではないので、モバイル向け設定を各自で行う必要があり、その分使いこなすのには時間が掛かるかもしれません。『パソコン遊戯』さんの『Proxomitron 入門』に詳しくインストールから使い方まで載っています。後ほど Proxyomitron を使用した例をご紹介します。

プロキシを使用した方法は、モバイルシミュレータと違って絵文字の表示はできませんが、どうしても絵文字を表示したい場合には、携帯電話用絵文字を Windows 外字ファイルとして登録するという方法があります。

詳しくは、
・伝伝ＰＣ倶楽部
・けーたい絵文字
・i-mode絵文字対応外字データ
などのサイトが参考になると思います。

プロキシを使う方法は使用するブラウザを選びませんので、自分の使い慣れたブラウザを使えて便利です。

【03】ブラウザそのものの機能やアドオン/プラグインを使う方法

最後はブラウザそのものの機能やアドオン/プラグインを使う方法です。
できる/できないはブラウザに依存しますが、IE, Firefox, Opera, Safari, Sleipnir, Lunascape には User-Agent を変更する方法があるので、殆どのブラウザでこの方法を取ることができるようです。

以下では様々なプラットフォームで利用することができ、アドオンの充実しているFirefoxでの方法を紹介したいと思います。(以前のディレクターズブログ『仕事を加速する FireFox アドオン』)でも書いていますように、ウェブ制作の現場では、私もFirefoxをオススメしたいと思います)

※http://firemobilesimulator.org/　FIREFOXのモバイルシミュレーター。こちらを使えば、携帯端末ごとの表示シミュレーションもできる。現状、これと、Ｕｓｅｒ アｇｅｎｔSwitcherをしようするとテストは便利。

User-Agentを変えるのには、HTTP リクエストヘッダを変更する『Modify Headers』アドオンを利用してもいいですが、User-Agentを簡単に切り替えられる『User Agent Switcher』アドオンを利用する方が楽にできますのでオススメです。携帯用のUser-Agentは、『我流天性 – がらくた屋』さんのサイトで『User Agent Switcher の携帯用のXML』を公開して下さっているので、それをimportするといいでしょう。

「Modify Headers」では、User-Agent だけではなく、HTTP ヘッダ全般を書き換えることができますので、端末 ID の設定など他の応用も可能です。『端末IDを設定でき、ケータイサイトの開発に便利な Firefox アドオン「Modify Headers」』でその方法が紹介されています。

【04】User-Agentを偽装しても、XML パースエラーでページが表示できない場合について

例えば、『http://mobile.nifty.com/i/index.xhtml(http://mobile.nifty.com/i/index.xhtml)』や『モバイルgoo(http://mobile.goo.ne.jp/)』のように、User-Agentを偽装してもFirefoxで閲覧しようとすると、以下のようなパースエラーでページが表示できないことがあります。

ﾓﾊﾞｲﾙ@niftyにアクセス時のエラーメッセージ

ﾓﾊﾞｲﾙgooにアクセス時のエラーメッセージ

HTTP レスポンスヘッダの Content-Type が application/xhtml+xml の場合には、Firefox は XML 整形式のチェックを行うため、モバイルページ自体は HTML で書かれているサイトでは、整形式になっていないと判定し、今回のような XML パースエラーを起こすようです。

正統的な方法ではありませんが、これを強引でも表示させる方法として、レスポンスの Content-Type を text/html に変えて上記パースエラーを回避することができます。先ほど紹介した Proxomitron を使ってやってみましょう。

まず、「フィルタの編集」の「ヘッダ」を押して、「オプション」の「新規」を押します。

次に、ヘッダ値のマッチと置換するテキストをセットします。

最後に「In」にチェックを入れれば完了です。

proxomitron のプロキシを有効にすると、閲覧できるようになります。プロキシの設定には、切り替えを簡単に行えるアドオン『SwitchProxy Tool』が便利です。

SwitchProxy Toolアドオンのプロキシの設定画面と内容

SwitchProxy Toolアドオンのプロキシ設定の切り替え画面

また、実際にContent-Typeがtext/htmlになっているかをHTTPヘッダ情報を確認する『Live HTTP Headers』アドオンで確認してみましょう。

Content-Typeを変換する前のヘッダ情報

↓
Content-Typeを変換した後のヘッダ情報

ちゃんと Content-Type が変わっていることが確認できました。

【05】最後に

上記の方法でPC上でモバイルサイトを見ていても、最後は実機で確認したい！ということになります。そのような時、今まではメールでURLを送っていましたが、Firefoxアドオンの『Mobile Barcoder』を使うと現在表示しているURLのQRコードを表示できるので、メール送信が不要になり便利です。以前はURLが長いと表示できないという問題がありましたが、バージョンアップして問題なく使えるようになりました。

ステータスバーの右下の Barcode 部分にカーソルを載せるとQRコードがポップアップします。これを携帯の QR コードリーダーで読み取りましょう。

以上、PC でモバイルサイトを見る方法を書いてきました。全てを端末からチェックするのは膨大な時間が掛かりますので、開発の場合には、最初は PC を使って効率的にデバッグを行い、最後に実機で最終確認をするという方法がよく用いられると思います。その中で、状況やニーズに合わせて3つの方法をうまく使い分けられればいいのではないかと思います。