たたみラボ

  • about
  • member
  • r&d
  • blog
  • tatamicast

blog

RSS

ケータイ飲食検索、au・ソフトバンク端末に対応

icon February 26, 2007 11:00 PM by ooi1 このエントリーを含むはてなブックマーク

大井宏友です。先日リリースした「ケータイ飲食検索」。本日Docomoに加えてau、SoftBankに対応しました。

ケータイ飲食検索でできること

  1. 「銀座 焼肉」「カフェ」など、フリーワードによるグルメ検索。
  2. ケータイのGPS機能を利用して「近くのお店を検索」(ドコモ、auのみ)

実はどちらも本家ホットペッパー.jpにはない機能だったりしますが(訂正:GPSを使った検索は、各地域のページにありました。お詫びいたします。)、本家よりも簡単な操作でホットペッパー.jpのグルメ情報が検索できると思います。

ちなみに対応機種はドコモ、au、SoftBankの新し目の端末(ブラウザがutf-8対応しているもの)になります。

感想・不具合報告・改善要望等などありましたら、ぜひ問い合わせフォームからご一報ください。

今後ともケータイ飲食検索をどうぞよろしくお願いします。

ソースコードの解説

同時に公開したPHPのソースコードもリニュアルしています。作っていく中でパソコン用とはちょっと違うなあと勉強になったことがいくつかありますので、それを紹介します。

ソースコードを、利用規約に同意してダウンロード※2007.8.21のDL以降、左記利用規約が適用されます。

敢えてUTF-8で作ってみた。

各社ともXHTMLでページを作ることができるのですが、キャリア各社の仕様を見ていると、ドコモ以外はSJISで作りなさい、と書いてあるため、携帯用のサイトはSJISで作るのが常識のようですが、最近の端末はほぼ全部がUTF-8でも問題なく表示ができる事実もありますので、「ケータイ飲食検索」は常識を覆してUTF-8で作ってみることにしました。

auのフォームはSJISで送られてくる

UTF-8対応と公表しているドコモはもちろんSoftBankも、ページの表示がUTF-8の場合はそのフォームから送られてくるクエリーもUTF-8でしたが、auはなんとページの表示がUTF-8だろうと、そのフォームに入力した文字列はSJISで送られてくることがわかりました。新旧8機種試して全てそうだったのでauはそういう仕様なのかなと思います。

そこでフリーワード検索のクエリーを扱うときは一旦文字コードをUTF-8に変換する処理をはさんでいます。ソースコードでは、

$keyword = mb_convert_kana(mb_convert_encoding($_GET["Keyword"],'UTF-8','UTF-8,SJIS,EUC-JP'),'s');

のmb_convert_encodingsがそれに該当します。ここで気をつけないといけないのは、phpの自動文字コード判別機能のデフォルトではいくつかの言葉がEUCと判断される(「焼肉」とかが該当)ことがあるため、'auto'は使わずに自動判別の優先度をちゃんと指定する必要があります。サンプルソースでは、 UTF-8,SJIS,EUCの順に判別するように指定しています。

また、mb_convert_kanaは、全角スペースを半角に置換するためのものです。ホットペッパーのグルメサーチAPIのフリーワード検索は単語間を半角スペースにするとand検索になるのですが、全角スペースだと(Googleとは違い)スペースを含んだ一つの単語として扱われます。ケータイで漢字を入力している時に半角スペースを入れようとするとモード切替とかをしなければいけない機種も多いので、全角スペースでもand検索が行われるよう、サーバ側で半角スペースに置換しています。

auのGPSリンクは絶対パス指定で

ドコモとauのGPS機能を利用するためのリンクは以下の通りです。

<a href="place.php" lcs> //Docomo

<a href="device:gpsone?url=http://hoge.com/place.php&amp;ver=1&amp;datum=0&amp;unit=0">//au

ドコモの場合は相対パスで大丈夫(そう)なのですが、auで相対パス指定をすると一部の機種では位置情報をサーバに送ろうとしなかったり、エラーになります。テストした限りではW44S、PENCKが該当します。

サンプルソースでは、auのGPSリンクは$_SERVER['SERVER_NAME']、$_SERVER['SCRIPT_NAME']を用いて生成しています。ここはお使いの環境にあわせて不整合があれば修正する感じでお使いください。

HTTP_USER_AGENTでキャリア別に処理を振り分け

各キャリアともXHTMLはXHTML Basicをベースにそれぞれ独自拡張しているため、DOCTYPE宣言が各社異なります。それだけではなく絵文字も、指定の仕方から各社異なっています。さらに前述の通りGPSのリンクもキャリアで違いますから、携帯用のサイトを作るときはちょっと凝ったことをやろうと思ったら、HTTP_USER_AGENTでキャリアや機種を判別してそれぞれ用のページへ飛ばすなり処理を変えたりする必要が出てきます。

サンプルソースでは、以下のような大雑把にキャリア別に分岐をして、DOCTYPE、絵文字、GPSリンクの切り替えをしています。

  • WAPブラウザ搭載au端末
  • ドコモFOMA端末
  • ソフトバンク3G端末
  • それ以外(XHTML Basicとして扱う)

本来ならばさらに端末名まで判断して、GPS搭載機種だけにGPS機能を表示するとか、古い機種だったらSJISにするとかをやったほうがいいと思いますが、今回はこのレベルにとどめています。ここも、必要に応じて条件を増やしたり減らしたりしてお使いください。

ホットペッパーWebサービスのTips

ちょっとケータイとは離れて、おまけとしてホットペッパーWebサービスを使うに当たっての細かなTipsみたいなものを紹介します。

DisplayPerPageはXML中の店の数じゃない

検索結果に含まれるDisplayPerPageは、リクエストで指定したCountの値(指定しなかった場合は10)がそのまま入ります。なので、ヒット数が8件でCount=5と指定した場合、ページングでStart=6としたときのレスポンスは、XML中の店の数は3ですがDisplayPerPageは5のままです。

データは毎月変わる

ホットペッパー.jpのサイト内のデータは月末に更新されます。なのでAPIのデータも毎月変わります。 ちなみに2月は22日に更新されていて、グルメサーチで引っかかるデータの数も1月末~2月までと比べて1000件以上増加しているっぽいです。またマスタ類も毎月必ずではないけれど更新されるようです。例えば2/22でいうと中エリア、小エリアに「高田馬場」が追加されていました。

このようにホットペッパーAPIの提供データは、(ほかのリクルートの媒体・WEBサービスと同様に)常に更新されていると考えて、自前のDBにためこんで使うのではなく、データが必要になった段階でAPIをリアルタイムにたたくという設計にしたほうが無難ですね。

参考にしてください。

TRACKBACKS

ページトップへ



(C) RECRUIT MEDIA COMMUNICATIONS CO., LTD.