ソフトバンク携帯電話の機種判別とユーザID取得

友達に携帯電話向けウェブサイトの技術相談をされて、後からいろいろ考えたら、ソフトバンク携帯電話の機種判別とユーザID取得には Jフォン時代から続く独特の流儀があるように思えてきました。

開発者の声を調べてみたら「神の子どもたちはみな腕を磨く: [PEAR::Net_UserAgent_Mobile] Vodafoneの機種名取得方法を変更しようと思いますが」に深い話が記されていました。ここでは、ここ最近の話として。

情報ソースは「ウェブコンテンツ開発ガイド [HTTP編] Version 2.0.4」です。リンク先から PDF のダウンロードをお願いします。

ソフトバンク携帯電話からの HTTP リクエストには、Jフォン時代から続く独自ヘッダがあります。

その中から、機種判別とユーザID取得に関係するものを二つ。

• x-jphone-msname ... 端末名称を送信します。これはリクエストに「必須」です
• x-jphone-uid ... ユーザIDを送信します。端末の設定で変更されます

x-jphone... と付いたあたりで、ソフトバンクのためだけに対応するのを嫌がる開発者は多いでしょう。私もそう思っていました。

でも、この2つのヘッダには利点も安定性もあります。

まず、Jフォン時代から発売されたネット対応携帯電話は全て x-jphone-msname を送信します。User-Agent 文字列がバラバラになった Vodafone 3G 端末にも -モトローラ製端末にすら- x-jphone-msname に名前を割り当てられています。

また、ボーダフォンとソフトバンクに買収されてもヘッダの名前が変わりませんでした。ソフトバンクなら変えかねないという声もあるでしょうが、いい兆候があります。ソフトバンクはヘッダを1つ追加して x-s-... という名前を導入しましたが、それでも x-jphone-... の名前は変わりませんでした。

おそらく、これは賭けていいです。ソフトバンクの機種判別は x-jphone-msname を参照するのだと。

x-jphone-uid が全機種で取得できるものか確認していませんが、User-Agent にシリアル番号が入らない古い機種でも対応できる利点がありそうです。

ボーダフォンに買収された頃から User-Agent がころころ変わるのでウェブサイトを開発しづらいと言われてきましたが、x-jphone-msname を参照するローカルルールがあると思えば腑に落ちます。

text/html -> application/vnd.wap.wmlc

Vodafone 804SH のブラウザの、ある奇妙な動作の理由がようやくわかった気がします。

サイズが 999 バイト以下の HTML を読み込ませてから、ページ情報を表示させるとおかしなことに気付きます。

• HTML のサイズが小さくなっています。999 バイト以下だと1の桁まで正確に表示しますが、サーバから配信したサイズより小さくなっています
• MIME タイプが application/vnd.wap.wmlc と表示されます。

おそらくプロキシサーバで Binary XML に変換しているのです。application/vnd.wap.wmlc は Open Mobile Alliance (旧 WAP Forum)が規定している Binary XML です。圧縮して回線速度・帯域をかせいでいるのでしょう。804SH より古いシャープ端末はいずれも同じかもしれませんが、確認していません。

気になることが一つあります。Tag Soup HTML(タグがごった煮にされた、valid には程遠い HTML)のエラーハンドリングです。何しろフォーマット変換を通しているのですから。

エラーコードが違うんです

mobilehacker グループ御中

私の Blog のエントリを紹介してくださったことに、私は喜んでいます。

ただ、よく見るとエラーコードが違うんです。

mobilehacker グループ様が情報をまとめてくださったエラーコードは WJ46065E で、私が作ったサイトで出したバグでは WJ46053E なのです。WJ46053E の方は、現在はググっても私の Blog のエントリしか情報がありません。

おそらくエラーコードにはソフトバンク(旧ボーダフォン、旧 Jフォン)内部で意味が割り当てられており、WJ46065E に当たるエラーが出ることは多くて、WJ46053E のように HTTP ステータスコードを出し忘れるサイトは滅多にないのだと思うのです。

S!アプリからの POST で Transfer-Encoding:chunked

8/10 に SoftBank Developers Support Site にて「S!アプリ開発ガイド [端末情報 MIDP 2.0 対応端末編]」が更新されました。

一部端末に、HTTP の POST リクエストでデータを送信する場合のエンコーディングの特徴が制限事項として記載されました。

902T, 903T, 803T, 904T, 705T, 910T, 810T, 811T, 813T, 812T, 911T, 814T, 815T, 912T の場合

• POST データが 2016Bytes 以上の場合は、自動的にヘッダフィールドオプションを「Transfer-Encoding:chunked」にして送信する
• POST データが 2016Bytes 以下の場合は、Content-Length を付与して送信する。ただし、flash() をコールした場合はデータサイズによらず chunked 形式で送信する

705P, 706P の場合

• POST データが 2560Bytes を超える場合、chunked 形式で送信する場合がある。アプリからの flash() のコールの有無には依存しない

これは、S!アプリから Web サーバにデータを送るとき、Web サーバ側のアプリ(CGI 等)が対応しないと送信したデータにゴミが入ってしまいます。

これを欠陥と呼ぶのは自分に Web アプリプログラマとして知識と技術がないと公言しているようなものなので、呼びたくありません。ソフトバンクは受信も chunked 形式に対応しているので、お互い様です。

しかし、手間がかかるのは避けられず、うんざりします。