→ カグア！ Google Analytics 携帯版Hack 全キャリア機種名対応
現在のGoogleAnalytics携帯版では、auやソフトバンクのガラケーおよびスマートフォンからのアクセスが機種判定できません。
上記ブログで公開されている修正を適用することで、これらが可能になるとのことです。
いずれGoogle側で修正が加えられ、公式にこれらの情報が取得できるようになるとは思いますが、ひとまずの対処としてこの修正を適用するのはアリだと思います。
つまりドコモ全体の46.32%がクッキー対応端末で、非対応端末は53.68%です。
ドコモのシェアは55.5%ですので、全体の割合を計算すると、
53.68 * 0.555 = 29.79%
つまり、全キャリアでは約70%がクッキー対応端末、約30%が非対応端末ということです。
3ヶ月前の調査では60%が対応端末でしたので、10%向上したということになります。
クッキー非対応端末のシェアは着実に減ってはいるものの、簡単ログインの撤廃など、クッキーだけに依存するサービスに完全移行するのはまだ検討が必要かもしれません。
モバイルユーザー傾向DATABOXの2010年12月版が公開されたので、クッキー対応端末のシェアを再計算してみました | ke-tai.org
良エントリーを見かけましたのでご紹介します。
携帯コンテンツ変換エンジンのroundaboutなどでおなじみのシンメトリックさんのブログに、2011年2月に行われるYahoo!ケータイのSSL大幅仕様変更への対応方法のまとめ記事がありました。
→ 株式会社シンメトリック公式ブログ SoftBank SSL仕様変更への対処まとめ [symple.jp]
2011年に行われるという仕様変更がどういうものかということについては、以前こちらの記事でご紹介しました。
→ ke-tai.org 2011年2月にソフトバンク（Yahoo! ケータイ）のSSLに大幅な仕様変更があるようです [ke-tai.org]
今回の仕様変更がどんなものでどうして行われるのかという点から、対応のポイントまで簡潔にまとめられている良エントリーだと思います。
- GW中継時のURLが使用できない
- SoftBank拡張ヘッダが取得できない
- POSTデータが文字化けする
- 絵文字が文字化けする
- 著作権保護が機能しない
という5点について、それぞれの対処法が書かれています。
ソフトバンク向けのSSLを利用しているサイトは必ず対応が必要になりますので、ギリギリになる前に今のうちからチェックしてみてはいかがでしょうか。
2011年2月に行われるYahoo!ケータイのSSL仕様変更への対処法がまとめられた記事「SoftBank SSL仕様変更への対処まとめ」 | ke-tai.org
入力された文字が絵文字かどうかってどうやって判定すればいいんだろう 740 ：nobodyさん ：2010/10/21(木) 22:30:49 ID:??? SoftbankならEE8081<x<EE94BEだったら。（入力フォーム：UTF8）
AUならF340<x<F9FCだったら。（入力フォーム：SJIS）
DOCOMOならF89F<x<F9FCだったら。（入力フォーム：SJIS）
てのを愚直に１バイトずつ切って2バイトもしくは3バイト単位で調べてる感じ。
って実装してて今のところ問題は起こってないな
DoCoMo/2.0の端末はほぼ、XHTMLのフォーマットが使えるらしい。
ただしDoCoMo/2.0にも関わらず、D2101V、P2101V、SH2101V、T2101V、N2001、N2002、P2002の端末がXHTMLはだめらしい。と、ここでふつうにやりたくなるのは、パターンでDoCoMo/2.0の端末はすべてXHTMLでフォーマット。
D210V、・・・・は、個別に例外で除外。つまり、ほかのフォーマットを適用。ということをしようとすれば、何らかのパターン表現のフォーマット＋個別指定のフォーマットというのが理解しやすいいうことになる。
さて、ユーティリティの設定がされたところで、各設定を見てみる。
・プロトコル制限なし(従来通り)
APN: emb.ne.jp
接続番号: *99***1#
ユーザー名/パスワード: em
・プロトコル制限あり(B)
APN: emb2.ne.jp
接続番号: *99***1#
ユーザー名/パスワード: em
・My EMOBILE
APN: myemobile
接続番号: *99***1#
ユーザー名/パスワード: em
・EMチャージ
APN: rtc.data
接続番号: *99***1#
ユーザー名/パスワード: em
って事で、APNを見てどのプランで接続するかを判別しているようだ。課金の問題もあるので、同時に電話番号などでの判断もしているのだろう。
んで、検証結果だけど、プロトコル制限なしのユーザーがプロトコル制限あり(B)のAPNを使うことはできるようだ。まぁ、そんなことをするのは非常に無駄ではあるが。使ってみた感じでは、
1. プロトコル制限あり(B)では、10.0.0.0/8でLSN＋プロトコル制限をかけているようだ。ざっと思いつくポートの接続確認をしてみたら、
port 25(SMTP: NG)、port 110(POP3: OK)、port 143(IMAP: OK)、port 465(SMTPS: OK)、port 587(SUBMISSION: OK)、 port 993(IMAP4S: OK)、port 995(POP3S: OK) と、メールは問題ないようだ。
当然、port 80(HTTP: OK)、port 443(HTTPS: OK)と、こちらも問題ない。
port 22(SSH: NG)なのは、業務用途に使う場合はちときついか？
port 6667(IRC: NG)なのも、ちと痛い。まぁ、一般ユーザーでIRCをやるか？ と言われると、微妙な気はするが。
port 1935(RTMP: NG)なのは、仕方ないか。でも、Ustreamのライブ視聴はできても動画配信はダメっぽい。Ustって、視聴は別なプロトコルだったっけ？
また、某ラジオ視聴もフィルタされているようだ。この辺りは、状況によって変わる可能性は十分ありそうだ。
2. My EMOBILEは、プロトコル制限あり(B)と同じネットワーク網(10.0.0.0/8)を使い、80番以外の外部へのアクセスは全フィルタ、80番へ のアクセスは、My EMOBILE簡単ログインサイトにproxyされているようだ。裏を返せば、LSN装置の基本機能の中にリダイレクトの機能も持っているっぽい。
ってところか。
ちなみに、UT-VPNを使って自宅にL2TPを張ったところ、IPv4でアドレスを拾えるけど、通信はできないっぽい。ところが、UT-VPNを使って MobileFree.jp にVPNを張ったら、なんとVPNが張れてしまった。MobileFree.jp は、2.0.0.0/8 のアドレスを使っているところがキモなのか？
まぁ、2.0.0.0/8 の割り当てが始まった時点で、MobileFree.jp の実験は終了するしかない、もしくはアドレス体系を変更しないといけないから、どこかで使えなくなるとは思うけど、とりあえず動くみたいだ…。
イーモバイル 新機能(データプランB/「My EMOBILE」かんたんログイン機能)を検証してみた カール・ミッチーのなんでも日記/ウェブリブログ
sshのポートを別のに変更すれば使えるという可能性もありますね。
プロトコルではなくポートだけ観ている可能性が濃厚ですので。
※注意
2011年2月以降、ソフトバンク携帯電話のSSL（Secure Sockets Layer）、TLS（Transport Layer Security）仕様が変わります。
このページでは2011年2月以降のSSL/TLS仕様を解説します。
2011年1月以前の仕様はこちら■ SSL/TLSとは SSL（Secure Sockets Layer）、TLS（Transport Layer Security）は、サーバに対してのなりすましや、盗聴、データの改竄の防止に利用されている暗号化プロトコルです。 SSL/TLSに対応しているソフトバンク携帯電話とWebサーバ間をより安全にデータ通信することができます。 ソフトバンク3G携帯電話では「端末⇔Webサーバ」のEnd-to-End通信区間でSSL/TLSのセッションを確立します。
SSL/TLSのご利用にあたり、ソフトバンクモバイル株式会社はSSL/TLSの安全性に関し保証を行うものではありませ ん。ソフトバンクモバイル株式会社では、データの盗聴や改竄、なりすまし等によるトラブルや損害に関して一切責任を負いません。お客様ご自身の判断と責任 においてご利用願います。 ※ SSLの利用に際しては、認証局（以降、CA）からサーバ証明書を取得し、Webサーバにインストールする必要があります。また、証明書のインストールには、Webサーバに関する知識が必要となります。 ■ 非SSL/TLS時との比較 End-to-EndのSSL/TLS利用時は、非SSL時と比較して以下の点が異なります。
・文字エンコーディング変換(*1)を行わない
・独自拡張ヘッダ(*2)を利用できない
・ISO-2022絵文字(*3)を利用できない*1: Request URI とエンティティボディの EUC-JP、ISO-2022-JP → Shift_JIS への変換 *2: x-jphone-color、x-jphone-display、x-jphone-msname、x-jphone-region、x-jphone-smaf、x-jphone-uid、x-s-bearer、x-jphone-copyright *3: 「
SoftBankは2048bitのSSLに対応しているとの事。
高い日本のVeriSignを使わずとも、米国のが動くという事。他のキャリアに関しては引き続き調査します。
以前にちょこっと書いたSoftBank携帯のブラウザに表示されるエラー。
わかった範囲でメモメモ。
エラーが発生しました。しばらくたってからもう一度操作してください。(WJ40012E)
①存在しないホスト名である。
②接続しようとしたサーバが落ちている。
③URLに誤りがある。
エラーが発生しました。レスポンスが不正です。(WJ40102E)
レスポンスのステータスコードに誤りがある。
エラーが発生しました。しばらくたってからもう一度操作してください。(WJ40103E)
①レスポンスにステータスコードが出力されていない。
②HTTPヘッダ部とBODY部に空行がない。
③BODY部がない場合、HTTPヘッダ部が空行で終わっていない。
④「Set-Cookie」ヘッダのCOOKIE値が長すぎる。
エラーが発生しました。しばらくたってからもう一度操作してください。(WJ40133E)
お客様の端末からはご利用になれません。(WJ46013E)
ポート80または443以外でHTTP通信またはSSL/TLS通信を行おうとした。
エラーが発生しました。レスポンスが不正です。(WJ40254E)
エラーが発生しました。(WJ46065E)
①コンテンツが取得可能サイズを超えている。
②「Content-Length」ヘッダに誤りがある。
③膨大なTABLEを含む、文字数が多すぎる、HRタグが多すぎる等、ページ出力に負荷がかかりすぎている。
その携帯が表示できる最大サイズによってエラー番号が変わるっぽい？
22K、48Kの携帯はWJ40254E、300Kの携帯はWJ46065E
エラーが発生しました。サーバ証明書が不正です。(WJ42018E)
SSL/TLS通信時、サーバ証明書が携帯に入っているルート証明書に対応していない。
お客様の端末からはご利用になれません。(WJ46042E)
エラーが発生しました。レスポンスが不正です。(WJ46098E)
①非対応データ。
②実際のデータと「Content-Type」ヘッダが一致していない。
エラーが発生しました。リクエストが不正です。(WJ46048E)
①レスポンスにContent-Typeヘッダが出力されていない。
②GETリクエストのURLに対して、スラッシュの直後にクエリを記述している。
例）http://hoge.com/dir/?q=ng
③サーバ側で「web.config」の「cookieless」を「true」に設定している。
エラーが発生しました。リクエストが不正です。(WJ46053E)
レスポンスのステータスコードのHTTPバージョンに誤りがある。
エラーが発生しました。(WJ46054E)
レスポンスのContent-Typeヘッダに「/」の入っていない値が指定されている。
例）○「text/html」 ×「texthtml」
エラーが発生しました。レスポンスが不正です。(WJ46094E)
①レスポンスにステータスコードが複数存在する。
②ヘッダ名とヘッダ値の間に「:」がない。
③HTTPヘッダ部とBODY部の間に空行がない。
④BODY部がない場合、HTTPヘッダ部が空行で終わっていない。
応答が得られませんでした。しばらくたってからもう一度操作してください。(WJ46133E)
応答が得られませんでした。しばらくたってからもう一度操作してください。(WJ46143E)
応答が得られませんでした。しばらくたってからもう一度操作してください。(WJ46150E)
TCPレベルでのエラー。Linux系サーバで「tcp_tw_recycle」の設定が有効に設定されているなど？
応答がえられませんでした。しばらくたってからもう一度操作してください。(WJ46147E)
①ネットワークが混雑している等の理由でサーバの応答が遅い。
②サーバサイドアプリケーションでBODY部出力までに時間がかかりすぎている。
③ネットワーク機器のMTU設定の値が大きすぎる。
お客様の端末からはご利用になれません。(WJ46202E)
Forward/LockのDRMがかかったコンテンツで、取得可能サイズを超えている。
お客様の端末からはご利用になれません。(WJ46203E)
エラーが発生しました。レスポンスが不正です。(WJ46207E)
Forward/LockのDRMがかかったコンテンツで、非対応データまたはコンテンツ内のMIMEブロックの「Content-Type」指定が実データと一致していない。
エラーが発生しました。レスポンスが不正です。(WJ46208E)
Forward/LockのDRMがかかったコンテンツで、コンテンツ内のMIMEブロックの「Content-Transfer-Encoding」の値に誤りがある。
エラーが発生しました。レスポンスが不正です。(WJ46209E)
Forward/LockのDRMがかかったコンテンツで、HTTPヘッダの「Content-Type」で指定されたバウンダリと、コンテンツ内の実際のバウンダリの文字列が異なる。
エラーが発生しました。レスポンスが不正です。(WJ46210E)
Forward/LockのDRMがかかったコンテンツで、HTTPヘッダの「Content-Type」にバウンダリ文字列が指定されていない。
エラーが発生しました。(WJ46221E)
Forward/LockのDRMがかかったコンテンツで、コンテンツ内のMIMEブロックの「Content-Type」の値に誤りがある。
エラーが発生しました。(WJ46283E)
表示しようとしたページ内に、a要素のhref属性に指定したURIが長すぎるアンカーが存在する。
（「mailto:」の「?body=」等のクエリ部分も含めて、SoftBankで有効なURIは1024バイトまで。）
ちなみにドコモはURLで2033バイトまで有効、mailto:などでのURIはスキームによって有効サイズが異なる。
エラーが発生しました。レスポンスが不正です。(WJ46289E)
OMAダウンロードで<objectURI>にURIの指定がない。
エラーが発生しました。レスポンスが不正です。(WJ46301E)
OMAダウンロードで<objectURI>のスキームがHTTPでない。(https://〜もエラーになる?)
エラーが発生しました。レスポンスが不正です。(WJ46402E)
①JISコードなどの自動判別し辛い文字コードのコンテンツで、文字コード指定をしていない。
②「Content-Type」ヘッダの文字コード指定に誤りがある。
②HTMLやXHTMLページで、METAタグによる文字コード指定に誤りがある。
エラーが発生しました。(WJ46405E)
Forward/LockのDRMがかかったコンテンツで、コンテンツ内のMIMEブロックに「Content-Type」の指定がない。
いったい何日記なのかわからなくなってきたよ :: オデンスタブ
エラーコード一覧です
ソフトバンクについてはWJ40103E等のエラーコードでの検索キーだった。
これはport 80番以外のアクセスの場合に出しているエラー。
なぜ今このコードで検索しているのか不明だが、何らかの報告が有ったのかもしれない。
ソフトバンクのエラーコードにしつこく触れているのはうちのサイトぐらいのようで
googleやyahooで検索するとかならずこのサイトが上位に来る。
やはり得体の知れないエラーコードに対する情報はほとんど無いのだろう。
このエラーコードに興味を示している私も実はよく分かっていない。
元のソフトバンクが何の情報も出さないので。
とりあえず過去記事に書いたものをもう一度張っておく。
WJ46013E http port80番以外へのアクセス
WJ46032E ネットワークエラーが発生（157でも内容不明）
WJ46900l アクセス制限中
WJ46065E HTMLファイルサイズ48K以上エラー
WJ46202E HTMLファイルサイズ48K以上エラー
WJ46150E ネットワークエラーが発生（157でも内容不明）
WJ40103E コンテンツサイトの不具合
WJ46042E MIMEタイプの不一致のエラー？
WJ40253E ブラウザ予約語エラー(uid.lid)
更にこの件に触れている記事をピックアップしておく。
ソフトバンクのブラウザが吐くエラー
http://suzunonejh.blog15.fc2.com/blog-entry-238.html
切迫する電波事情
http://suzunonejh.blog15.fc2.com/blog-entry-289.html
当サイトへのアクセス＆ソフトバンク携帯からのアクセス
http://suzunonejh.blog15.fc2.com/blog-entry-222.html
鈴の音情報局blog 総務省も探しているソフトバンクのエラーコード
URLが長いときのエラーもあったはず。
イトにアクセスがあったとき、ページを自動的に移動させる方法として3xx系のレスポンスを返す方法があります。
301 Moved Permanently 302 Found(Moved Temporary)301は、『サイトは永久に移動しましたよ』という意味です。
302は、『サイトは一時的に移動しましたよ』という意味です。
この場合、Docomo端末では301だと、『サイトが移動しました(301)』のメッセージが出ます。
メッセージを出さずに、自動的にリダイレクトさせるには302のレスポンスを使用します。
『サイトが移動しました』を出さない方法 - [Docomo [ｉモード]] ぺんたん info
PHPなら以下のコードで、どの携帯端末も気づかずにリダイレクトさせる事が出来ます。
header(“Location: 【遷移先URL】”); exit();
?>
「条件分岐編」、「デザイン編」の2回にわけて、Flash軽量化について解説されています。
条件分岐編では、if文の条件を見直して容量を削減するテクニックが述べられています。
「<=」は「<」より容量を食うので使わないなど、かなり涙ぐましい努力が見て取れます。デザイン編では、素材の画像の加工方法や、使用するフォントについて触れられています。
ベクターデータのフォントは角ばったフォントを使ったほうが容量が少ないとのことです。
原理を考えれば当たり前のことなのですが、これは気にしたことが無かったです。
また「2」と「5」を反転で使いまわせるというメリットもあるようです。ケータイ向けFlashと容量削減は切っても切れない関係なので、Flashの制作をされている方はチェックしてみてはいかがでしょうか。
Flash Liteの容量削減テクニックをまとめて記事「知らないと損をするよ！ 携帯Flash軽量化メモ」 | ke-tai.org
NTTドコモおよびソ フトバンクモバイルの端末がJavaScriptに 対応したことによ り、XSSのリ スクが高まっています。そのような状況で、両事業者は、典型的なXSS試験パターンを「一見動作しなくなる」という対応を しています。
しかし、これら「対策」は非常に表層的なもので、URLを少し変えるだけでXSS攻撃ができてしま います。すなわち、XSS対 策としての効果はほとんどなく、逆に副作用の方が大きいと思わ れます。オレ標準JavaScript勉強会でも、 「alert殺したらデバッグが大 変になるのでは?」という指摘がありましたが、私も同感です。
携帯電話事業者に学ぶ「XSS対策」 - ockeghem(徳丸浩)の日記
モバイルサイトもXSS対策が必要な時代となってきました。
Amazon: 携帯サイト年鑑2010: 津田 武
ですが、本書が今までと違う点は何といってもその「圧倒的な掲載量」です。
今までの書籍では、1冊あたり100サイト強だったのですが、この本ではなんと500を超えるサイトが紹介されています。
やはりこの豊富な選択肢の中から、デザインに参考できるサイトを選ぶことができるというのは嬉しいところですね。
掲載サイトはカテゴリ別に整理され、全サイトがカラーで紹介されており、デザイン上のポイントなどもコメントされています。
===
以上、ke-tai.orgより
入力フォームの操作性、機種による違いにご注意！ | 株式会社シンメトリック公式ブログ - 携帯開発から生まれる技術情報
実は先日、とあるサイトで「チェックボックスが選択できない」といったユーザーからの問い合わせがあった。調べてみるとそのページは今回サンプルとして説明したデザインとよく似ていて、かつ使用していた機種は上下左右キーでフォーカスを移動する機種！やはり通常は上下キーのみでフォーカスを移動しているからチェックボックスが選択できなかったようだ。
携帯では上下キーをスクロール操作にも使用するし、事実上、上下キーしか使用しない携帯ユーザーも多いことを考えれば、上下キーのみでフォーカス移動できるようなページ構成にしておくべきだ。
具体的にはHTMLに次のような工夫をしておく。
* チェックボックスやラジオボタンは横1列に並べない（性別のラジオボタンなど）
* チェックボックスやラジオボタンの右側にリンクを配置する場合、リンクは次の行に配置する（説明ページへのリンクなど）
もしチェックボックスやラジオボタンを横方向に並べたり、フォーム内にリンクを配置する場合は、上下左右キーでフォーカスを移動するタイプの機種を使い、ユーザーインタフェースを必ずチェックしておこう。
===
とのことです。
（1 / 3 ページ）
