RYU's HOME P@GE

福島中年探検隊

この文書は 2002 年 7 月に書いた物です。

ブラウザ情報について View to Analysis

インターネットを利用するためにブラウザは缺かせません。 そのブラウザは自分が意識するしないに拘らず、特定の情報を全世界に向けて發信してゐます。

ユーザーエージェント( UA )は本來、利用者に代って何かをするアプリケーションを指します。 ウェブブラウザのやうにリソースをダウンロードして表示するもの( Viewer )を一般に UA と言ひますが、こゝではアクセス解析で使はれる userAgent などの情報について說明します。

UA 情報表示

JavaScript が有效になってゐる場合、navigator オブジェクトから讀み出して、以下に貴方の使ってゐるブラウザの情報を表示します。 項目や内容はブラウザによって違ひます。 JavaScript が OFF だと こゝには表示されませんがサーバ側では HTTP_USER_AGENT などの環境變數から取得可能です。

ユーザーエージェント

userAgent は PC の簡單な情報を記載してあります。 揭示板などで これを表示してゐるケースもあります。 ブラウザと OS の種類が分かるので、閱覽者の環境によって最適化したい場合に參照する部分です。

しかし userAgent を書き替へられないのは IE ぐらゐで、IE コンポーネンツを利用した他のブラウザや Mozilla、Netscape などは簡單に書き替へることができます。 優秀なプログラマは appVersion や その他の要素を同時に參照して環境を特定するやうにしますが、晉通はこんな面倒な事はしません。 UA 書き替へは閱覽者の自由です。 つまり制作者がいくら頑張っても閱覽者の環境などを完全には把握できないという事になります。 いや、それでいいんですが。

スクリプトによる振り分け

JavaScript は信用できないが、CGI や SSI なら大丈夫と思ふのは早計です。 單にプログラムが動くか何うかの確率の問題で、情報内容の正確さ は保證してゐません。 UA は「ユーザーのために」何かするアプリケーションですから、IE のやうに發信する情報をユーザーの任意で書き替へられないのは、ひょっとしたら設計の誤りかも知れません。(プロキシを使へと言はれさう) そもそも HTTP の通信手段ではブラウザの違ひとか OS の種類など端末の違ひは考慮してゐません。

SSI での環境變數取得 ( Perl や PHP で書いても同じ)
(2020-11-12) サーバが SSI に對應しなくなったので表示できません。 こちらをご覽下さい。
userAgent:
内容は JavaScript で取得する結果と同じです。 これがいつも正しいとは限りません。

制作者は無力といふ事ではなく、もともとブラウザは特定できないといふ事です。 テレビ番組でも御金をかけてハイビジョンで制作したところで白黒テレビで見る人はゐます。 割合を大雑把な傾向として相對的には掴めても、確實な數としては「不明」または「だいたい」と言ふしかありません。

CSS 振り分けは無駄なのか?

「自動的に」といふのは無駄です。 制作者がブラウザを振り分ける理由は、NN 4 など CSS の實裝不備なブラウザだとレンダリングされない、または激しく崩れるのを避けるためと聞きます。 しかし、そもそもサーバサイドでもクライアントサイドでも環境を特定することは難しい。 本來、閱覽者は自分の代理人(ユーザーエージェント)であるブラウザのことをよく知っている筈です。 ならば閱覽者に任せるのが望ましい。 よく知ることができない制作者が振り分けるよりは確實です。

といふ事ですが、實際にはブラウザをデフォルトで使ふ人が大半なので、制作者サイドで「自動的に」振り分ける事が通用してゐるやうです。 ブラウザを「受像機」ぐらゐの感覺で使ってゐる人が多いんだらうなあ。(ひとりごと)

ブラウザ判定スクリプト

參考までに JavaScript で書いた簡單な判定プログラムを載せておきます。 斯う云ふ物は完璧にはなりません。 年月と伴に、といふか新しいブラウザが どんどん出てきて世代交替すれば役に立ちません。 2002 年現在での判定例です。

動作状況
該當する場合は true、該當しない場合は false が變數に格納されてゐます。exBrows は檢出對象外のブラウザです。 例へば新しく出たブラウザで持ってゐる情報が舊バージョンと異なる場合も該當します。 HTML 文書で使用する場合は、文書内に以下のように書くと、その行以降で各變數が利用できます。 これはフリーです。 改變・再配布も自由です。 不具合はお知らせ下さい。
判定スクリプトの利用例
HTML 文書内記述例
<script type="text/javascript" src="JS 外部ファイル名"></script>
利用例
if ( isOpera6 ) { Opera 6 で行ないたい処理; }

スタイルシート適用などに使ふために、判定の追加希望がありましたら どうぞ。(期待に沿へない場合もあります) また CGI や SSI で HTTP_USER_AGENT を利用したスクリプトも内容は同じになります。 なお、NN 4.x では JavaScript が OFF だと CSS も無効になるので意味はありません。

NN 4.x では JSSS ( JavaScript Style Sheets )に對應するために JavaScript と CSS を連動させたのだらうと思ひます。 結局シェアの點からも JSSS は晉及することなく現在は CSS が主流です。 JavaScript は Netscape が晉及に努めたのですが、W3C の DOM によって從來のクロスプラットフォームの考へ方が變りつゝあるやうです。

UA という名の戰略

userAgent 情報には食品表示のやうな決まりがありません。 ユーザーが自由に書き替へられるといふ事は、ブラウザメーカー(ベンダー)も自己の利益のために自由に書いてゐます。 以下に最近話題の Opera 英語版の UA を載せておきます。

Win98 + Opera 6 の UA
項目 内容
1 appName Microsoft Internet Explorer
2 appVersion 4.0 (compatible; MSIE 5.0; Windows 98)
3 userAgent Mozilla/4.0 (compatible; MSIE 5.0; Windows 98) Opera 6.01 [en]

IE と同じです。 違ふのは最後の部分に Opera と書いてあるだけ。 これだと userAgent を見る限り Internet Explorer と間違へてしまひます。 おそらく、それが狙ひ。 つまり「成りすます」ことによって IE と同じ扱ひをして貰はうといふ訣です。 IE がシェアの大多數を占めてゐる現在、そこへ食ひ込まうとする後發メーカーとしては、獨占メーカーに對抗する已むを得ない戰略かも知れません。 ただし Opera の UA は自由に變更できます。

Opera Software はノルウェーのオスロに本社があります。

これは Opera に限ったことではなく、IE も當時獨占してゐた Netscape に對抗するために同じことをしました。 Mozilla/4.0 と書いて compatible (互換)と言ってゐます。 さすがに appName には自社商品名を書いてゐますが、その頃の Opera 4 は堂々と Netscape と書いてゐました。(ここまでセコイと、なんか許せないなあ) で、本家 Netscape も それ以前に主流だった Mosaic ( Mozilla )を吸収してゐます。 userAgent は遺伝子情報みたいですね。

UA を「詐称」する

Internet Expolorer ではないのに、それを稱することは詐稱であるとする意見もあるやうですが書き方が決まってゐる訣ではありません。 ただ 自分の商品に他所の會社の商品名を名乘らせることは道義的に釋然としません。 現在のところ IE も「 Mozilla 」と名乗ってゐるのだから良いだらう、といふことでせう。 尤も IE も Mozilla( NCSA Mosaic )から派生したので、あながち嘘ではありませんが。

推奬環境の目的

適切な UA 名にしておかないと適切なサービスを受けられない可能性はあるものの、たいした問題ではありません。 それを決めるのは閱覽者です。 逆に言ふと UA 名を根據に「重要な判斷」をするプログラムは危險が多いといふことになります。 閱覽環境によって重要な振り分けをしたい場合は、案内を書いておくのが親切かもしれません。 推奬環境を書くとしたら斯う云ふ目的があると思ひます。

參照元を「詐稱」する

參照元についてですが、どこから來たのか知りたい時には Referer を使ひます。 閱覽者が Yahoo! JAPAN の檢索エンジンを使ってゐるなら、さういったニーズに應へるコンテンツを整備するなどの最適化を行ふことができます。 ただ HTTP (通信のためのプロトコル)では、Referer の送信は必須ではありません。 ブラウザによっては送らないやうに設定することもできます。

print "$ENV{'HTTP_REFERER'}";

Perl で このやうに書いたとしても、環境變數の中身が正しいとは限りません。 そこで已むを得ずクライアントサイドの document.referrer を利用することになりますが致命的な缺點があります。 それは JavaScript が OFF だとサッパリ解からない、といふことです。

Cookie を利用する

閱覽者自身の情報は、閱覽者の PC に保存しておかうといふのが Cookie ファイルです。 これは閱覽者の判斷に強く依存します。 つまり閱覽者が嫌だと言えば、Cookie は保存できません。 Cookie の讀み出しができない場合にアクセスを拒否する(結果的にアクセスできない場合も含む)のは、特別の事情のある場合に限定した方が良いやうです。

Cookie を利用して「あなたは○○回目の訪問です」 なーんていふメッセージを出すのは お遊び なので構ひません。 いやまあ、これもやらない方が良いでせう。 それより Cookie を重要な判斷のために使ふ場合は、事前に閱覽者の合意を得られるやうにしておくべきでしょう。 例えば Cookie が OFF の時に、何度入力しても受け附けられずに元に戾るのは困ります。

スタイルシートの切り替へフォームを JavaScript で設置しているケースがありますが、こんなものは無くても全く構ひません あっても良いとはいへ、このために Cookie ファイルが閱覽者の PC にドンドン溜まっていきます。 期限の切れたものは削除してあげるぐらゐの作法は必要。

關聯ページ
アクセス解析について
ご意見ご感想など
メール(ブラウザ情報について)メールのヘルプ

2020/11/12 (©2020 MIYAKE_ryutaro)