ueblog » Mobile

WordPressでライフログしてみる

ueblog — Sun, 24 Aug 2008 13:00:44 +0000

最近流行？なライフログサービス。ミニブログやSNSといったサービスとあわせて、ライフログに結びつける動きであったり、独自でライフログのサービスをはじめている会社もあるが、どうも決め手というものがない気がする。

であれば、独自に作ったほうが早くない？と思ったりもするが、それなら使い慣れたWordPressとプラグインで何とかならんかと言う訳で調べてみた。

何ができればいいのか

基本的には

遠隔地から投稿できる。
画像や動画を投稿できる。
遠隔地から閲覧できる。
遠隔地から投稿する場合、位置情報が結びついている。
アクセス制限（個人のみ、友人のみ、全体など）

このあたりを満たせばいいかなと。要は、携帯などから遠隔で投稿、操作できるってこと。でこれを満たすための機能として、

携帯電話からの投稿、閲覧
携帯メールからの投稿（画像含め）
iPhoneからの投稿、閲覧
位置情報との紐付け
アクセス制限機能

があれば、とりあえずはよさげ。

携帯電話からの投稿、閲覧

まずは携帯電話からの投稿と閲覧。いろいろとプラグインはあるが、おすすめはこれ。

Ktai Style (携帯対応プラグイン)

基本的には、プラグインを有効にするだけで、携帯のUSER_AGENTを判定して携帯用のページを表示してくれるが、そのほかにも、携帯用のテーマファイルが複数用意されていて、デザインをキャリアごとに選択できたり、画面の分割、絵文字の対応と日本の携帯にあった細かい配慮がされているのが特徴。

また、管理画面にもログインできるので、投稿や簡単な管理機能に対応している。

携帯メールからの投稿

携帯であれば、メールでの投稿に対応してほしいところ。また、ファイルアップロードができないので、メールの添付ファイルにより画像をアップさせたい。これを満たす最適なプラグインはこれだ。

Ktai Entry (メール投稿プラグイン)

メールの添付ファイルに対応しているだけではなく、絵文字や投稿時のカテゴリ、日時、画像の編集といった操作もメールに書くMETA情報（CAT:だったりDATE:といった独自書式）を書くことで投稿できる、本当にかゆいところに手が届くプラグインだ。

メールサーバ側の対応方法は2つ。

1つ目は、メールが送信された場合に即反映させるため、メールアカウントに対してプログラムを実行させるように仕込む方法。こちらは、Webサーバとメールサーバが同じサーバの必要がある。主に自宅サーバの人向け。

2つ目は、POPサーバへ定期的にメールをとりに行くように設定する方法。こちらであれば、メールサーバは自前で必要なく、フリーメールなども利用できるが、取りに行くためのタイムラグが発生するので、すぐには反映することができない。

iPhoneからの投稿、閲覧

携帯以外に、iPhoneやiPod Touchを利用しているならそちらで投稿、閲覧したいだろう。その場合はこのブログでも紹介した、

WordPress for iPhone

WPtouch: WordPress On iPhone

あたりを駆使すればよいだろう。

位置情報との紐付け

位置情報も意外と簡単に連携できる。

Ktai Location (携帯の位置情報活用プラグイン)

こちらを利用すれば、上述のKtai Entryでメール投稿する際に、画像にGPS情報をくっつけたり、GPSに非対応の場合もMAPのURLをくっつけるだけで、後ほど紹介する、GoogleMapプラグインに必要な位置座標情報を投稿記事に紐付けて投稿できる。

Lightweight Google Maps (地図プラグイン)

Ktai Locationで投稿される座標情報から、Google Mapを表示してくれるプラグイン。WordPress記事の「カスタムフィールド」に位置情報が入っていれば地図を表示してくれる。そして記事全体の地図も表示できるので、座標情報のある記事の地図全体も閲覧可能だ。

アクセス制限機能

こちらはいまいち素晴らしいプラグインを見つけることができなかったが、単純に全体に対して認証をかける場合は、こちらが利用できる。

Angsuman’s Authenticated WordPress Plugin

これで一通り、遠隔地からの投稿や位置情報などの取得が可能なわけだが、画像に関しては、

WP lightbox 2

を利用すれば、かっこよく画像が表示できる。

ここで紹介したプラグインのほとんどは

http://www.yuriko.net/travel/

こちらの方が作成されたもののようですね。いや～素晴らしい！

Googlebot-Mobileについて

ueblog — Sat, 28 Jun 2008 15:41:04 +0000

Googleのモバイル検索エンジンがAUとDoCoMoの公式サイトで導入されているが、実際にどういった手順でGoogleの「携帯サイト」として結果が表示されるかは、あまり知られていない（気がする）。

今日は、モバイルサイトにてGoogleのモバイルクローラーがどういった形で、クロールしにくるか、また検索結果に反映されるのか自分のモバイルサイトで少し調べてみた。

前提

まずは、前提として日本のGoogleモバイル検索は3種類ある。

DoCoMo iMenuのGoogle検索
Ezweb 公式Google検索
一般Googleモバイル検索

そして、検索結果は

公式サイト（一般Googleモバイル検索にはない）
携帯サイト
PCサイト

と分かれて表示される。

PCサイトと判断されてしまうと、表示順も下になり、またGoogleの変換ゲートウェイ経由でのアクセスとなってしまうこともあり、できれば「携帯サイト」として表示させたい。

今回はそのあたりのお話。

ユーザーエージェント

Googleのモバイルクローラーは下記のようなUserAgentで来る。

xhtml用

Nokia6820/2.0 (4.83) Profile/MIDP-1.0 Configuration/CLDC-1.0 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)

chtml用

DoCoMo/1.0/N505i/c20/TB/W20H10 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)

結論から言うと、chtml用のGooglebot-Mobileがクロールしだしてから、Googleの「携帯サイト」として表示されるようになった。

ということは、chtml用のGooglebot-Mobileにクロールしてもらうようにする必要がある。

サイトマップの登録

Googleにサイトを認識させるツールとして

Google ウェブマスターツール

を使うのだが、サイトマップの登録で

「モバイル　サイトマップを追加」⇒「マークアップ言語」⇒「cHTML(iMode)」

にすることが重要。ここでマークアップ言語を「XHTMLモバイルプロファイル(WAP2.0)」にしてしまうと、何故かGoogleの携帯サイトとして認識されなかった。。

そのあたりはこちらの方が、鋭く検証されています。

googlebot-mobileのUAとDOCTYPEとインデックスの関係についての実験とその結果

そして、sitemap自体もモバイル用のネームスペース宣言を入れる。

PLAIN TEXT

XML:

<?xml version="1.0" encoding="UTF-8"?>
xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:mobile="http://www.google.com/schemas/sitemap-mobile/1.0">
>>http://www.google.com/imode>:mobile/>>
>

参考：http://www.google.com/chtmlsitemap.xml

通常のsitemap形式だと、「PCサイト」扱いだったが、このサイトマップを採用してから、chtml用のGooglebot-Mobileがクロールするようになった。

その他

こちらはよく効果がわからなかったが、DOCTYPEは下記のようにしている。

PLAIN TEXT

HTML:

あとは、携帯サイトとして認識させるために容量は10K以下？にするとか、絵文字を利用するとか半角カナを利用するといったこともあるかもしれない。

一番手っ取り早いのは、「携帯サイト」として認識されているサイトから、外部リンクを貼ってもらうことかな。

Yahooはどう？

Yahooはどうだろう？

Yahooサイトエクスプローラーには登録したが、特にモバイルなどの判別はない。（yahoo.com版にはあるけど。。）

実はまだYahooのモバイルクローラーがちゃんとクローリングしてくれてないので、なんともいえないのが現状。。。

Yahoo.comにモバイルサイトのURLを送信するフォームがあったので、とりあえず送信してみたが、これで動きがあれば報告する。

それにしても、何故こんなにややこしいのだろう？

携帯サイトとして報告⇒携帯サイトとして表示

単純にこれだけだと思うが。

検索結果を見ても、まだまだ精度が悪いのでこの分野もこれから改良されていくことを願う。

symfonyで携帯サイト用に出力を半角カナで統一

ueblog — Sat, 07 Jun 2008 14:35:28 +0000

携帯サイトの場合、1行あたりの文字数を増やすため、カタカナは半角で揃えるのが定石。

というわけで、symfonyで気軽にHTML出力を半角カナで統一する方法を探る。

viewの出力時にすべてフィルターをかけるようなイメージでいたが、テンプレートに直接書くものを半角カナで入力し、actionなどから出力されるオブジェクトに半角カナエスケープをかけるのがスマート？かと思い、作ってみた。

まずは、独自のカナHelper。

lib/helper/EscapingKanaHelper.php

PLAIN TEXT

PHP:

function esc_entities_kana($value)
{
$value = mb_convert_kana($value, 'k', 'UTF-8');
return is_string($value) ? htmlentities($value, ENT_QUOTES, sfConfig::get('sf_charset')) : $value;
}
define('ESC_ENTITIES_KANA', 'esc_entities_kana');
?>

ESC_ENTITIES関数をそのまま流用し、mb_convert_kana関数を付け加えるような、helperを作成した。

そしてsettings.ymlで宣言する。

apps/config/settings.yml

PLAIN TEXT

CODE:

all:
.settings:
escaping_strategy: both
escaping_method: ESC_ENTITIES_KANA
standard_helpers: [Partial, Cache, Form, EscapingKana]

テンプレートに直接、全角カナを書かれてしまうと、統一されないのが難点。

やっぱFilterかな。。

携帯の端末IDとCookieのまとめ

ueblog — Sun, 20 Apr 2008 12:45:40 +0000

携帯（DoCoMo、Ezweb、Softbank）の端末IDとCookieについてまとめてみました。

携帯の端末ID

いわゆる、携帯端末からのアクセスを一意に識別できるID。

DoCoMo

現在（2008年4月）であれば、iモードIDを利用するのが手っ取り早い。URLに"guid=ON"というパラメータをつければ、リクエストヘッダにHTTP_X_DCMGUIDという名前の値からIDを取得できる仕様。

特徴は下記。

SSL環境では取得できない
ユーザ側でIDを送出しない設定ができる
全機種対応
英数字7桁で再利用されない
POSTの場合、Body部分に"guid=ON"があっても送信されない。要はGETパラメータとして付与しないといけない（追記！）

参考：iモードIDについて：作ろうiモードコンテンツ

Ezweb

EZ番号という、リクエストヘッダにHTTP_X_UP_SUBNOという名前の値からIDを取得できる仕様。

特徴は下記。

全機種対応
ユーザ側でIDを送出しない設定ができる
xxxxxxxxxxxxxx_**.ezweb.ne.jpのようなフォーマット

ちなみにSSL環境でも問題なく取得できる。

参考：KDDI au: そのほかの技術情報 > ユーザーエージェント

Softbank

USER_AGENTに端末シリアル番号をつけてくれる。SN***********という値の*部分が端末のID。

特徴は下記

一部、IDを送出しない機種がある（MEXA搭載端末および、702MO、702sMO ）がその他は現在のところ対応している
ユーザ側で端末IDを送出しない設定ができる
15桁の数字

参考：ソフトバンク　ユーザーエージェントについて

リクエストヘッダにX_JPHONE_UIDという名前の値からIDを取得できる仕様もある。

特徴は下記

対応機種は、P型、W型、3GC型
ユーザ側で端末IDを送出しない設定ができる
16桁の英数字

Cookie

携帯のCookieの仕様について。

DoCoMo

全機種非対応

※更新

iモードブラウザ2.0から正式に対応が決定してます。
作ろうiモード：iモードブラウザ2.0新機能一覧

Ezweb

特徴は下記

全機種対応
クッキーはEzwebのゲートウェイサーバに保存される。ただしWAP2.0端末はSSL通信時、端末に保存される。
期限型のみ。期限がないものはデフォルト1日
CookieのValueは4096バイト以内。SSL通信時は1024バイト以内。

参考：KDDI au: そのほかの技術情報 > Cookie

Softbank

特徴は下記

W型、3GC型機種のみ対応
一時型（ブラウザが切られれば無効となる）、期限型両方対応
Secure Cookie対応

iモードID仕様公開

ueblog — Mon, 31 Mar 2008 02:35:28 +0000

約束どおりドコモのiモードIDの仕様が公開されていました。

iモードIDについて

仕様は、予想通りURLに"guid=ON"というパラメータをくっつけると、リクエストヘッダにuidパラメータが付与されてサーバに送信されるようです。

http://domain.com/?guid=ON

↓

X-DCMGUID: XXXXXXX (7桁の英数字)

GET,POST両方とも対応。また、解約等でも再利用されないIDなので一意が確保できます。ただしSSL環境では取得できない模様。

シンプルですが、URLパラメータにくっつけるっていうのが微妙ですね。

iモードIDの件

ueblog — Sun, 02 Mar 2008 17:04:15 +0000

DoCoMoのiモードIDの件はどうなんだろう。

ドコモ、iモードサイトに共通の利用者ID機能「iモードID」の提供を開始

ユーザごとにユニークなIDが振られる、デフォルトで「通知する」設定となっている、Fomaだけでなく、movaも対応などなど・・・

勝手サイトを運営するコンテンツプロバイダーにとって、ログインのシームレスさ＋アクセス解析のユニーク数がほぼ正確に出せるなど、かなり良い施策だ。

でも、よくよく資料を読んでみると、

重要なお知らせ : 『iモードID』の提供開始について | お知らせ | NTTドコモ

●iモードIDの通知について
iモード対応サイトにおいて、アクセス先URL内に予めiモードID用のパラメータを記述しておくことにより、お客様がサイトアクセスした際にiモードIDの通知が行われます。

やっぱ、uid=NULLGWDOCOMO的な、URLにパラメータをつけたときにだけ取得できるようだ。

また、パラメータの予約語を増やす気か・・・

せめて、リクエストヘッダーにしてくれ・・・

symfonyで携帯のセッションIDを扱う

ueblog — Sat, 16 Feb 2008 16:22:59 +0000

さて、symfonyで携帯開発第2弾。

セッションIDは、DoCoMoは埋め込み、AU、SoftbankはCookieを利用

これを実現する。セッション部分をオーバーライドして対応するので、複数サーバになった時に対応できるようにセッションをmysqlで管理するようについでに変更する。

まずは、sfMySQLSessionStorageをオーバーライドするクラスを作成する。
lib/storage/myMobileSessionStorage.class.php

PLAIN TEXT

PHP:

class myMobileSessionStorage extends sfMySQLSessionStorage
{
public function initialize($context, $parameters = null)
{
//E_STRICT NOTERROR VIEW
$er = error_reporting();
if ($er> E_STRICT) {
error_reporting($er - E_STRICT);
}
require_once('Net/UserAgent/Mobile.php');
$agent = &Net_UserAgent_Mobile::singleton();
if ($agent->isDoCoMo())
{
ini_set("session.use_trans_sid", 1);
}
parent::initialize($context, $parameters);
}
}

通常は、factories.ymlにsfMySQLSessionStorageを利用するように宣言するのだが、ソースのようにしてそれを携帯のアプリケーションの場合は登録するようにする。ちなみにドコモの場合のみini_setし、それ以外は通常通りクッキーを利用する。

apps/app_dir/config/factories.yml

PLAIN TEXT

CODE:

all:
storage:
class: myMobileSessionStorage
param:
db_table: session
db_id_col: id
db_data_col: data
db_time_col: updated_at
database: propel
session_cookie_domain: .domain.com
session_name: s

これで、app_dirアプリケーション以下のドコモの場合のみ、URLにセッションIDがリンクに付与されるようになる。

そう、セッションテーブルを作成するのを忘れてはいけない。
config/schema.yml

PLAIN TEXT

CODE:

propel:
session:
_attributes: { phpName: Session }
id: { type: varchar(32), primaryKey: true, required: true }
data: { type: longvarchar }
updated_at: { type: integer }

これをsymfonyコマンドを利用して、テーブル作成する。

じつは、これだけでは足りない。actionクラスなどで、リダイレクトする場合はセッションIDが付与されない。そのため、

PLAIN TEXT

PHP:

$this->redirect('module/action?'.SID);

このように引き継がないといけない。これもドコモだったらみたいなif文を書かないといけないのか、それとも害はなさそうなので全部そうしてしまうか・・・

redirect関数もオーバーライドすればいけそうだが、そこに関してはまた後で研究することにする（手抜き）

symfonyでPEAR::Net_UserAgent_Mobileを使う

ueblog — Fri, 15 Feb 2008 15:25:35 +0000

symfonyで携帯開発、第1弾。

機種の判定をテンプレートとプログラムでできるようにする

を実現する。

Perlでは有名なcpanモジュール、HTTP::MobileAgent。PHPでも同じようなモジュール、 PEAR::Net_UserAgent_Mobileがあるようだ。

さっそくインストール。pearを使って、簡単にインストールできる。

pear install -f -o net_userAgent_mobile

さてsymfonyで、どのように利用するのがいいのか。その場でrequire_onceしてしまっても問題ないが、symfonyの場合、フィルターを使えば、共通なインターフェースで利用できそうなので、フィルターを作ってみる。

app/app_dir/lib/myMobileFilter.class.php

PLAIN TEXT

PHP:

class myMobileFilter extends sfFilter
{
public function execute ($filterChain)
{
if ($this->isFirstCall())
{
$er = error_reporting();
if ($er> E_STRICT) {
error_reporting($er - E_STRICT);
}
require_once('Net/UserAgent/Mobile.php');
$agent = Net_UserAgent_Mobile::singleton();
$this->getContext()->getRequest()->setAttribute('agent', $agent);
}
// execute next filter
$filterChain->execute();
}
}

フィルターのご作法にのっとり、とりあえず書いてみた。14行目で"agent"という属性を予約して、オブジェクトをぶち込んでいる。

8～11行目のエラーの取り扱いは、なぜかdevモードでNet_UserAgent_Mobileをrequire_onceすると、Strict Standards:~というwarningが気になったので、入れている。

filterを登録するには下記のようにfilters.ymlを編集する。

app/app_dir/config/filters.yml

PLAIN TEXT

CODE:

rendering: ~
web_debug: ~
security: ~
myMobileFilter:
class: myMobileFilter
cache: ~
common: ~
flash: ~
execution: ~

そして利用する場合、actionクラス内なら

PLAIN TEXT

PHP:

if ($this->getRequest()->getAttribute('agent')->isDoCoMo()){
}

view内なら

PLAIN TEXT

PHP:

if $sf_request->getAttribute('agent')->isDoCoMo()): ?>

こんな感じで呼び出し可能。

sfRequestに詰め込むのが、ちょっと気持ち悪い気もするが、これでいいのか、もう少し検証が必要。

なお、Net_UserAgent_Mobileは、結構更新されるようなので、Pearの更新RSSフィードを取得しておけば、運用面も安心だ。

symfonyで携帯開発の指針

ueblog — Mon, 11 Feb 2008 17:17:42 +0000

PHPのsymfonyフレームワークを使って、携帯Web開発する場合の指針を書いてみた。

指針

対応機種は、DoCoMoのFoma,PDC、AUは3GC対応端末、Softbankも3GCのみ
Web、メールともに絵文字変換はキャリア側の変換に頼る
画像はjpeg,gifのみを利用
ページサイズはxhtmlが9KB以内、全体で100KB以内
1テンプレートで全キャリア対応

jkondoに憧れて » 超手抜きでウェブサイトをモバイル対応 2008

こちらの方に影響されてます・・・

そして、 やるべきことは、

機種の判定をテンプレートとプログラムでできるようにする
セッションIDは、DoCoMoは埋め込み、AU、SoftbankはCookieを利用
ログイン時などは、セッションIDを入れ替える
携帯キャリアGWからのIPチェックを判定できるようにする
絵文字入力を永続層へ格納、出力できるようにする
CSSはインラインで書き、HTMLはxhtml basicで書く（PDCはHTML）
Webの文字コードはShift_JIS
uidを取得できない端末は非対応ページに飛ばすようにする
Webアクセスのユニーク数の計測をできるようにする
デコメール送信できるようにする

と、こんな感じ。

なお、プロジェクトの中に、PC用ページ、携帯用ページが混在し、アプリケーションレベルで分けることを意識する。

次回以降、ひとつずつ解決していくのでお楽しみに。

携帯端末IDのはなし

ueblog — Wed, 05 Dec 2007 15:43:54 +0000

携帯コンテンツを作成するにあたって、セッション管理をするために何をセッションIDとするか。クッキーを利用できない端末でユーザーにデータを保持させることができないという壁があるため、リクエストパラメーターにセッションIDを埋め込む、もしくは携帯端末特有の端末IDをセッション代わりに利用するという2つの方法がある。

セッションIDをリクエストパラメーターに含めてしまうと、ブックマークしたURLを他人に渡してしまうことで、簡単に他人になりすますことができる。セッションIDに何かしら意味を持たせる、もしくはセッションコンテナーにUSER_AGENTなどの情報を入れて付き合わせる、などの方法である程度は、なりすましが防げるが全く完璧な方法ではない。

そこで、携帯端末のIDを利用する方法がよく使われる。

DoCoMo(非公式サイト)　utnをformタグに書くことにより、USER_AGENTから端末IDの取得が可能。

DoCoMo(公式サイト)　リクエストパラメータにuid=12バイト文字列(NULLGWDOCOMOなど)を与えることでDoCoMoのGWで端末固有のidに変換してくれる。

AU　リクエストヘッダ　x-up-subno

SoftBank リクエストヘッダ x-jphone-uid

サーバーに携帯GWからのIP制限をすることにより、DoCoMo公式サイトによる方法の場合、偽装することは不可能。

しかしAUとSoftBankのような、リクエストヘッダ形式を利用する場合は、サーバー側で偽装に気づくことは難しい。
携帯GWからのIP制限をすれば、現状のモバイルフォンブラウザにヘッダを書き換えるような機能がない（はず）ため、偽装することは不可能となっている。

しかししかし！こんなキャリアに思いっきり依存する、あやうい実装でいいのか！今どき端末でJavaも動くし、これからGoogleのAndroidのようなオープンな環境が携帯端末に実装されれば、いろんなブラウザが入る可能性がこれから見えているのである。

どうする、どうする。

いや、答えは簡単。
「早くクッキーを使えるようにしろ！」
というだけ。PCと同じ環境ですよ。アフィリエイト業界も喜ぶでしょう。

端末IDについていろいろ調べていると、
携帯業界の認証事情 Part2

携帯で端末ID詐称は可能かもしれない話CommentsAdd Star
で言及されてました。

ついでにDoCoMoは、「Refererを早く開放しろ！！」