スタイルシート、JavaScript、DOM、ブラウザ判別、PHP 等ウェブ制作関連の各種情報
これからおそらく情報端末としてかなり重要な位置を占めていくであろう携帯用のサイト構築について。
i モードでウェブ閲覧が可能になった時から制作者として興味を持って対処していました。自分は「専用のページを作ればそれでよい」とは最初から考えていませんでした。できることなら「すでに制作されているサイトをなるべくそのままに、ユーザーエージェントに対して最適化をして送出する」ことによってどんどんリソースを増加させ管理を複雑にしないようなことが希望でした。そのためにはまず通常のサイト構築に関する様々なテクニックとユーザーエージェントを携帯端末とした場合にそのまま使える手法や専用にしなければならない記述等の様式を整理することが必要でした。
i モードが送出情報量制限をすること以外にほぼソースの記述に関しては HTML のサブセットであることからそのへんの共用化はそう難しいものではなさそうだと考えました。また逆に以前の i モード以外の機種はそうではなかったため、その対処は面倒だとしか考えられず、また当然「自分が使っていないブツだとチェックも手間がかかる」ので他との違いを知識としては覚えましたが対処はほとんどしませんでした。
官公庁関連のサイト構築等を業務で行っていると、通常のウェブサイト構築に関しては「ウインドウズIEで見れればそれでよい」というのが現実的な状況です。（今現在も！あとは制作者が「頼まれなくてもきちんとひとつのブラウザ依存をしない」ように作るかどうかであって、様々な絡みからそういう技術すら持たない制作業者が ウインドウズIE でしかマトモにみることができないウェブを作り、高額報酬を得ていたりするのはなによりも問題であるわけですが、ま、それはここの話題とは別なので）そういう状況下においてなぜか携帯対応に関してはほぼ「主要 3 社対応」と発注されます。（そこに至るまでも結構時間がかかっていますが）さて、そしてウェブ制作会社はそれぞれの携帯用のウェブ制作に関する知識を有する技術者を使うか、調べて 3 社用にセッセと普段の 3 倍のリソースを作るか等という作業を行なう訳です。なにから仕入れたのか「iモードはこうでなければならない」「EZweb はこうでなければならない」「J-PHONE だとこうでなくちゃダメ」みたいに苦労してなんとかしているのが普通なのでしょう。
時期はよく覚えていませんが、i モード用に HTML サブセットの「対応している」といわれている記述をしたテストページを作って、他も含めて閲覧チェックを行ったことがあります。それが 3社で ほとんど普通にみることができる という事実を知り、自分はニヤリと笑っていました。この事実を知らずにセッセとハナッから専用記述書式を覚えた方は多い筈。当然、専用に記述変更をしなければならない箇所はあるし、例えば「公式サイト」になるには専用でなければならない場合はあります。しかし単純明快に「テキスト情報を携帯端末で閲覧する」ということであれば（EZweb にしろ J-フォンにしろ、基本的に「HTMLを変換する」機能がほとんど最初からありました。機種依存もなくはないですが、サーバー側で変換している場合も多いです。詳しくは調べてください）なにも苦労して 3社別にページを作る必要は最初からなかったのです。（きっと。あんまりムカシのことは知らないし、必要ないでしょう）
もっとも現在は、専用記述様式をとっていた au が「標準化」を先行して押し進めて基準の記述は「Basic XHTML」で行ないます。遅れをとっている他社の携帯ブラウザに関しては、XHTML を XHTML としては扱えませんが、基本的にもともと XHTML が HTML と互換を持ちます。また逆も大丈夫で au のブラウザは HTML も扱えます（内部等で変換しているのかもしれません）。従って共通の「HTML要素を使って記述されたもの」は、3社互換が保てます。
とはいっても「サイト構築」として PC用の通常サイトと携帯の閲覧、ユーザーエージェント判別は必須であるため、サーバーサイドスクリプトの利用等ができることが大前提ではあります。PC閲覧ページが携帯用と同様でいいのであれば 1ページでなにからなにまでで大丈夫な HTML をかくことは可能です。
業務で頼まれて「全部同じアドレスでアクセスできます」というと便利だと思われるより前にうさん臭く思われたり。どうやっているのか説明を頼まれたりするのでそういう場合は「CompactHTML という互換を持った記述で対処してます」といってます。CompactHTML の厳密な仕様通りとは違いますので、正確ではないと思いますが。結局単純に「互換あるタグしか使ってない」ということなんですが。また「頼んでないのに携帯版も作った」とビクつかれる（請求される、と思ったらしい）とか怒られる（チャンと携帯用を別に作るツモリだったんだ！。。。みれるんだからいいじゃないですか）とかということもあります。こんなふうに（一応真面目に）制作業務をしていると困惑することがある。見られて困るサイトなら最初から作るな！
もし「自分で HTML や XHTML を記述できる」のであれば「ここは携帯でこうなれば見れるな」と常に携帯閲覧を意識していれば、後にユーザーエージェント別の判断して、ひとつのファイルで携帯対応を考えることはそう難しくない筈だ、というハナシです。あ、根本的に「ページレイアウトにテーブルを使う」「画像だらけでテキスト情報が全く記述されていない」ようなコトをやっていると、そういうことには気づかないでしょう。「シンプルな HTML を書いて、必要に応じてスタイルシートを使う」という制作手法であることが、まず何よりも基本です。「PC ブラウザだと画像がなんでも使えてテーブルでレイアウトできるが、携帯はそれができないから別に作る」というのは自分だったらそのほうが面倒臭くてやってられません。
昨今の携帯端末ブラウザ、プラス一般的なビジブルブラウザで別の記述が必要なのは以下のような箇所があった場合です。
情報量に関しては携帯最適化を考えると少ないにこしたことはなく、例えばこのサイトのように文字情報自体が 1ページに大量に含まれていれば携帯の場合だけページ分割等の処理が必要です。しかしながら一般的によくある見た目に大量の画像で制作されているページであれば、逆に「画像を直接記述せずにスタイルシート側で指定する」制作手法をとり、必要な情報をテキストとして掲載し、PC等ではスタイルシートでそのテキストを隠すことでだいぶいいセンまで対処可能です。こういうことについてハッキリと言明している情報は少ない気がします。また今後携帯端末用ブラウザの機能にスタイルシート機能が付加されれば、もっと専用のレイアウト構築が可能になるでしょう。
対応画像形式が少ないこと、各社マチマチなのは戦略等もあるのかもしれませんが、昨今のカメラ付き携帯では JPEG には対応しているに決まっているので、ひとつで全部に対応させることが不可能ではありません。ただ「ムカシのケータイ」まで考慮させられたら JPEG 非対応の機種があるので、判別の上、対応画像を送出する必要があります。また最近ではなにしろ機種（キャリア別ではない）によって画面解像度が違うので表示サイズを揃えることは現状では非常に難解な問題です。また、もとネタのサイズ自体が大きければ携帯には辛いことになりますから、送出自体をしないようにするか、送出画像を必要な数用意してブラウザによって変えるかという必要がでてきます。自分の場合は PHP プラス GD 環境でサーバーサイドで処理するようなことを最近はよくしています。おかげで楽できます。
共通対応要素を使ってなんとかなる部分もありますが、そうでない箇所が多く動作チェックが非常に大変です。とはいっても結局フォームを必要とする場合はサーバーサイド処理を使うのが普通ですから、そこで判別して処理を変えればいいということです。自分の場合これまで一番難解だったのは input type="file" を使って画像投稿を必要とした箇所です。この input は非対応の携帯ブラウザが多く、携帯端末各種で共通の動作をさせるためには結果として「メール添付送信」を使う必要があるということで対処しました。こうしてしまえば PC でも逆にメールで送信することで共通化できますが、それは逆に面倒なことになる場合がほとんどですから、携帯と PC で処理（フォーム自体の構成）を変更したほうがいいことになります。
人から頼まれたり、業務ではないのですが、自分がこの楽しい携帯専用機能をいかさなきゃと考えているので地道に PHP で「絵文字テーブル（リスト）」を作っていたりします。また楽しいという理由以外に携帯では通常の画像やテキストや他の記号を使うよりもリソース容量が少なくて済むとか、処理はそれぞれの端末（ブラウザ）で専用なので安定している、ということもあります。
ほとんど完成に近いモノは持っていますが、実稼働させたことが少ないのでエバれませんが（笑）現在とある管理サイトの携帯版をリニューアル中なのでそこで活躍させようと思っています。チェック用に PC では iモード絵文字の画像を送出するように作りましたが、このへんで著作権、版権等が絡むのでどうもこのままでは公開できません。自分なりにアイコン画像作れば大丈夫なんで、セッセとなんびゃっこかの絵文字互換アイコンを作るようなことができたら公開するかもしれません。といっているうちにどんどん絵文字の種類が増加していったりするから。
そんなわけでサーバー側での処理を前提に絵文字を使うページ（携帯の場合は絵文字を出し、PCだとださないか代替え画像を出す等）を作ることは可能です。問題は「絵文字テーブルを作るのが大変」だということくらいです。（他、プログラム上は文字コード等の絡みもあります）
現状ではこのへんは逆に非対応なことを使って判別処理動作として使えます。携帯はJavaScriptが使えないからツマラナイ、のではなくて、JavaScript が動作しないから noscript に携帯用の表記をできる、ということ。フレームも同様、 noframes 使った中身は携帯用と考えて構築できるということです。現実的に「テキストブラウザ」を利用する環境は少ないのでどうもこのへんの記述に関して気を使うことはあまりないようですが「ここは携帯で見える」と思えば気遣いが必要だと意識が変わる筈です。ノーフレーム要素内に「フレーム未対応ブラウザなんかそんなもんツカウナー」みたいなジョークを書いているような方もいますが、そんなことかくなら「携帯専用の特別コンテンツ」等を用意しておくともしもなんらかでアクセスされた場合にユーザーにイヤな思いをさせることなく、むしろ喜ばれるでしょう。
また、やり過ぎには注意しなければなりませんが、この noscript 、 noframes を使うことは、SEO 対策になります。ホントに JavaScript をつかっていないページ、ホントにフレームを使っていないページでは逆にスパムと思われますが、普通にちゃんと記述している状況であれば、その中身はスパイダーにインデックスされることになるので、ちゃんと気を使って間違いない内容を記述しておくことがトテモ大切なことなのですが、これ、SEO やさん以外は発注されているわけでないからどうでも良い、ということなのか「このサイトはフレーム対応ブラウザでご覧ください」とロボットにインデックスされているページの多いこと。自分はとても勿体無いことだと思います。いや、結局そういう制作者は「何も考えていない。デザインのためにフレーム使っている」というだけであって、シロートはともかくそーゆー制作して高額請求しているような業者の方々は早急に消えていただきたいと願っています。キチンと作っていてもそれがクライアントには分からない。どうも特に日本人はムカシっから人がよすぎて騙されやすいような気がします。真面目にやっても全然儲からないのに方針を変えるなんて事は考えないというのが自分の現状。
以前から携帯用にサーバーサイド側処理をするときに「ファイルパスは絶対パスにする」とか「リダイレクトの動作が怪しい」ということは指摘されていました。別のサーバーにリダイレクトで飛ばすような処理を実際に使っていて、最初問題なかったのですが、今年の夏くらいにいきなりエラーになった、という現象にもあいました。原因は完全に追求できていませんでしたが、このリダイレクトに関しては、ロボット検索のスパイダーに対して「クローキング」ととられてしまうようなこの状況で、携帯ということ以前に利用に気をつけなければならないワケで、意味なく（だいたい使う意味は公開者の都合が多く、ユーザーにはなんら関係ないことの筈）使うことは最初から避けるべきで、本当に必要ならその代替え処理（自動的にリダイレクトするのではなく、ちゃんとユーザーにハイパーリンクで飛んでもらう）を用意するのがもはや「必然」です。自動制御のおかげでユーザーが楽になるということばかりではないのであった。
iモードが シフトJIS （の基本的に固定）で半角カナを使って軽量化を図るのが基本テクニックみたいですが「そうでなければイカン」ということではないので勘違いしないように。特に「そういうことだから PC と別に作らなければナラナイ」と考えちゃってる人はちょっと真面目すぎ。軽量化は重要ですが、そのために別ページにしなくても、そういうのはなるべくサーバーサイド処理等で一括変換する、ということしか自分はやりません。
最近の PHP 環境では内部エンコードと送出コードを変更（バッファ使う）できますし、覚えたら面倒な「変換力技作業」からは逃れることができます。そういえば、このサイトも準備だけして途中でした。Nucleus は、それよう（携帯閲覧用）のプラグインあります。あー簡単。そうそう現在は以前の状況をひきずって、ひとまず携帯の場合は専用メニュー（携帯でみれるコンテンツへのリンクだけのホーム）を出してます。
自分は携帯に関する情報としてはおそらくかなり早い時期からあった CGIぽん を最初参考にしたと思います。そこから自分なりに状況に応じて変更しながら最近は以下のようなものでやっているみたい（笑）です。
$keitai = 0;
$ua = $_SERVER['HTTP_USER_AGENT'];
$ualist = explode("/",$ua);
// dot i
if ($ualist[0] == 'ASTEL') {
$keitai = 1;
// EZweb old
} elseif ($ualist[0] == 'UP.Browser') {
$keitai = 2;
// EZweb
} elseif (ereg("^KDDI","$ualist[0]")) {
$keitai = 3;
// H"
} elseif ($ualist[0] == 'PDXGW') {
$keitai = 4;
// Vodafone, J-SKY
} elseif ($ualist[0] == 'J-PHONE') {
$keitai = 5;
// i-mode
} elseif ($ualist[0] == 'DoCoMo') {
$keitai = 6;
// L-mode
} elseif ($ualist[0] == 'L-mode') {
$keitai = 7;
} else {
$keitai = 0;
}
// 携帯（扱い）ブラウザ処理
if ($keitai) {
$qvga = 0;
// au の画面解像度 x,yを返す
$set_a = "HTTP_X_UP_DEVCAP_SCREENPIXELS";
// JPHONE の画面解像度 x,yを返す？
$set_b = "HTTP_X_JPHONE_DISPLAY";
// QVGA 判定
switch ($keitai) {
// au
case 2:
case 3:
$xy = explode(",",$_SERVER[$set_a]);
if ($xy[0] >= 240) {
$qvga = 1;
}
break;
// J-PHONE
case 5:
$xy = explode(",",$_SERVER[$set_b]);
if ($xy[0] >= 240) {
$qvga = 1;
}
break;
// DoCoMo
case 6:
if (substr($ua[1],0,3) == '2.0') {
$qvga = 1;
} elseif (ereg("505",$ua[2])) {
$qvga = 1;
} elseif (ereg("506",$ua[2])) {
$qvga = 1;
} else {
// SH252i, F880iES
if ($ua[2] == 'SH252i') { $qvga = 1; }
if ($ua[2] == 'F880iES') { $qvga = 1; }
}
break;
// あとはよくわからん（笑）
default:
$qvga = 0;
}
// 携帯ブラウザの解像度にあわせてサムネール（最大）サイズを決める
// GD使ったサムネール生成スクリプトを別途作ります
if ($qvga) {
$thumbx = 180;
$thumby = 240;
} else {
if ($keitai) {
$thumbx = 100;
$thumby = 120;
} else {
$thumbx = 320;
$thumby = 320;
}
}
} else {
// 携帯以外ブラウザ処理
// 他のエージェントチェック
// 他に知ってて専用処理するなら増やしてください
$Mac = preg_match("/Mac/",$ua)?true:false;
$Win = preg_match("/Win/",$ua)?true:false;
$IE = preg_match("/IE/",$ua)?true:false;
$Moz = preg_match("/Gecko/",$ua)?true:false;
$Safari = preg_match("/Safari/",$ua)?true:false;
$NN = preg_match("/Netscape/",$ua)?true:false;
$iCab = preg_match("/iCab/",$ua)?true:false;
$Opera = preg_match("/Opera/",$ua)?true:false;
}検索してこのページを見にくる方で「ブラウザ判別 携帯」が非常に多いのでかいとくことにしました。尚それプラス JavaScript というキーワードのもあるんですが、携帯ブラウザで JavaScript 対応しているものは（Opera がどうなのかまだ未チェック）一部（または皆無）なので基本的に個別の機種判別はできません。上記でかいたように <noscript> に書いたものは携帯で見える、という判別は一応可能です。
検索サイト上位にあると本文に責任を感じます（笑）自分なんかより詳しい携帯サイト制作専門の方はいっぱいいる筈なんですが。
さて、いいたい放題書いてきました。携帯対応サイト構築については今後も研究課題です。以前は面倒臭いことのひとつでした。でも状況は携帯用ブラウザも「標準化」が進んでおり、今ある程度の制作手法を取得すれば今後は楽になる筈です。ユーザーがもっと使うようになるかどうかは結局のトコロアクセスしてもらうコンテンツを作るソフト制作側の問題であって、全部が全部端末を作っているメーカー側の問題ではありません。
だいたい、通常のウェブであっても最初はこんな制限だらけの環境で一体ナニをすればよいのかをウェブデザイナーが工夫してきたおかげでこんなに爆発的に広がったのです。携帯用ウェブサイト構築はそんな当時を知っている方なら「普通のウェブ制作よりむしろ制限が多いからいろいろ工夫を考えてやることが楽しい」と考えることもできるのではないでしょうか？そして、常に「ウェブ制作」として「標準準拠」を目指した一貫した制作手法をとっていけば、PC用、携帯用、その他どんなユーザーエージェントでも扱える情報提供の仕組みとして通用する筈なのですから、多種メディア対応させることは難解ではない点に気づくべきです。
また上記で「サーバーサイド処理での判別が必要」云々とかかいてますが「PHP とか CGI とか使えない自分は無理じゃん」ということではないので念のため。当然ながらそういう環境によって行えることは増えます。覚えるべきことも増えます。でも常にいっているように「最初にコンテンツありき」であって「携帯でみれるようにする」ということが最終目的ではない筈です。そのコンテンツが「携帯で閲覧したいような情報」であれば、それができる環境を整備するのは必然です。「このサーバーじゃできない」ではなく、そういうコンテンツを提供するならそういう環境を構築しましょう。少なくとも現在は以前とは驚く程簡単にお金もかけずにできることです。そのために必要な知識を吸収すること自体もなんらお金がかかったり面倒くさいものじゃあありません。インターネットを自分で存分に活用すればいいだけのことだと思います。
現在自分は「着メロダウンロード」だとか「携帯用 FLASH 生成」だとか、「JAVA で携帯用アプリ」だとか「京ぽん」だとかについて興味を持って調査をしておりますが、なんだかこの先結局のトコロ、PC のブラウザと同じような機能までは突き進むことでしょうからあんまり「携帯専門の知識」を得るために時間を費やすのはどうか、とも考えてます。「情報端末」としては重要ですがだからこそそこで得られるコンテンツは他と異なって専用形式であることは望ましくないことです。このへんは「コンテンツ制作側」ではなくてハードやソフト制作側が目標にしていることでしょう。
最近の携帯ブラウザが UTF-8 に対応してたりするのをついこないだ知りました！
更新 2007-08-02 13:17 初回投稿 2005年04月24日 10:56
フリーのウェブサイトディレクター。音響オペレーター。北海道札幌にて活動中。
Web Site designed by Studio Susto