Web制作（携帯用）の最近のブログ記事

当社の中心的事業である携帯有料コンテンツのアクセス解析というのは、とりあえずページビューが分かればよいというような単純なものではなく、サイトの性質によっても欲しいデータが全然変わってくるので、今まで決定的な方法を持たずになんとなくオープンソースのアレやコレでお茶を濁してみたり、URLを正規表現で集計する自作のアクセス解析を作ってはみたもののあまり役に立たず放置してみたりしていました。

そもそも、コンテンツやシステム作る方にいっぱいいっぱいでその辺（解析・分析）をおろそかにしていたというのもあります。

で、最近その件について改めて考えたのですが、結局、欲しいデータがその時々で様々なのに加え、単純集計をエクセルでいろいろいじってみて初めて欲しいものが分かるといったこともあるので、一番有効な方法はやはりギリギリまでフレキシブルな集計システムであるな、ということでこんな感じにしようと思いました。

基本的には以下の入力を保存しておいてバッチ処理でレポートを出力するのだけど、レポートの有効性にあたりをつけるために入力時に少しだけお試し集計してくれると嬉しい。

[入力1] 集計対象URLの正規表現、ただし正規表現の一部をパラメータとして指定できる

例）\/hoge\/([a-zA-Z]+)\/fuga\/([0-9]+)\.html ※サブパターンに指定した部分がパラメータ

[入力2] 集計期間 YYYYMMDD～YYYYMMDD

[入力3] 対象キャリア（対象キャリアのアクセス数を合算する）

[出力] 「(パラメータ1)\t(パラメータ2)\t...(パラメータn)...\t(日付)\t(ユニークアクセス数)\t(合計アクセス数)」を1レコードとするtsvデータ

• 過去に作成したレポートの履歴はラベル付きで残しておく。

オープンソースの集計システムで概要をつかんだ上で、気になる部分を上記システムで補足するわけです。

パラメータが1つのときは日付とのクロス集計表で出るとさらに良いような気はするけど、そうするとユニークが一つのレポートに入らないし、その辺はエクセルでなんとでもなるのでまあそれで十分じゃないかな。

Yahoo!ケータイ（Vodafone live!）のリダイレクト回数が最大3回（C型は最大2回）までという事実はわりと有名かと思います。そして、最近気づいたのだけどドコモ/iモードでも最大5回、au/EZwebではもう少し上に（7-8回？一度確認したのだけど記録していませんでした）の制限がある。少なくとも、この回数で「無効なデータを受信しました」などのエラーになる機種が存在する。

ググってもなぜかその情報はヒットしないようなので、一応書いておきます。仕様書をちゃんと見れば書いてあるとは思いますが。

こういうサイトを発見。携帯機種情報検索サービス

以下の理由から、Webアプリへ組み込むなどのご利用はお控えください
    * 構成上、応答速度はあまり速くできません
    * 表示レイアウトは適宜変更される可能性があります
    * 突然メンテナンスに入ることがあります

ということなのだけど、同様の商用ウェブAPIサービスってのはやっぱりありだよなぁ。サーバーのコストが問題と言えば問題だけど、単位時間あたりのリクエスト数を制限（＝ユーザーサイト側で適切にキャッシングしてもらう）すれば解決することなので、商用サービスとしては成り立つと思う。1サービスあたり年間19,800円くらいでなんとか（高い？）。

なんなら通信＋キャッシング＋取得したデータのデコードまでしてあげるモジュールっぽいものくらいは提供しちゃう。

画面はVGAだがブラウザ表示領域はQVGA。画像も文字も縦横2倍に拡大されて表示されます。でも何気にVGAサイズの画像はブラウザ内でもVGA画像として表示することができます。

こんな挙動は当然全く想定していないので、某グラビアサイトのシステムでこの挙動をうまくさばけるようにするのに半日使ってしまいました。VGA対応は結構ですが、なかなか迷惑な話です。

同じVGA画像をPCで表示してみると、携帯の液晶画面の解像度の高さに恐れ入る今日この頃です。

ゲームiガイド載せて欲しさに、最近話題の動作認識を使ったiアプリでも作ろうかと思ってドキュメントをひもといてみたところ、てっきり加速度センサーを使っているかと思っていたらカメラデバイスからの入力を使って動作認識をしていたという事実に驚愕。なるほどその手があったか。

真っ白な机の上で振ってもシカトってことですかとか思ったんだけどまあそんなことは滅多にないんだろう。レンズに指がかぶっちゃってますよってのは意外とありそうですが、904i はその辺考慮されたデザインになってるのかな。（追記：内側のカメラを使うことでいずれの問題も解決することが判明...）

ちなみにAPI的には加速度も使えますが、今のところDだけしかセンサが入ってないっぽいです。

そのせいで長らく iモードのブラウザ全くいけてねぇとか思っていたのですが、実は、画像のサイズ指定をしていないせいでした...。サイズ指定をしたら、EZweb 並とまではいかないながら、わりとサクサクになった。なるほど。

PC用のページでは画像のサイズ指定をしないというのはまずあり得ないのだけど、iモード用は書く道具がテキストエディタなのに加えて"たかがCompactHTML"という意識があって全くマジメに書いていないのでこういうことが起こる。

lt パラメータが渡っていない、と思いきや、実はその手前の tu パラメータもしくは nu パラメータに '?' が含まれていて、かつ、それらのパラメータがシングルクォーテーションでくくられていないことが原因の可能性大。

映像がなく音声だけの 3gpp ファイルは audio/3gpp なる Content-Type を吐かなければならない（映像つきの場合はもちろん video/3gpp。拡張子が同じなので、何らかの形で別途映像の有無情報を持つ必要がある、しかも SoftBank のためだけに）。

さらに、Content-Type: audio/3gpp な時は、同時に

Cache-Control: no-cache
x-jphone-copyright: no-transfer

的なヘッダも吐いてやらないと（詳細未検証）

エラーが発生しました。レスポンスが不正です。 （WJ46098E）

とかいうエラーを吐く。

しかも上記のエラー、公式のドキュメントを見ると

エラーが発生しました。リクエストが不正です。 （WJ46098E）

とウソが書いてあるので、その解説「指定されたファイルは Forward Lock 方式で配信する必要がある」もウソなのではないかと疑心暗鬼になる。

堪忍してください。SoftBank がいけてるのはPDFドキュメントにきちんと栞が付いていることくらいだ。

<a href="mailto:mail@to.you?subject=URLエンコードされた文字列">メール送信</a>

とやる場合、DoCoMo と au では、「URLエンコードされた文字列」の文字コードはHTMLの文字コードとそろえておけばよい。

一方、SoftBank 911T（おそらくほかの 3GC 端末もそうでは・・・）では、HTMLの文字コードが SJIS なのに、「URLエンコードされた文字列」の部分は UTF-8 でないと化ける。ちょっと手抜きすぎやしないか？それとも自分がなんか間違ってるのかな。

XHTML に対応しているはずのバージョンなのに

<div sytle="background-color: #FFFFFF;">ほげ</div>

とか書いても認識されず、シミュレーターで見ても style は存在しない要素名ですとか言われる・・・と困っていたら、レスポンスヘッダに

Content-Type: application/xhtml+xml

が必要なのね。そんなところで処理を分岐しなくていいから、EZwebくらいにきびきび動くブラウザになってください。

やれやれ、こいつはちょっとしたはまりポイントだぜ。