WebSurfer's Home

トップ > Blog 1   |   Login
Filter by APML

ブラウザーモードとドキュメントモード

by WebSurfer 29. December 2014 14:56

Internet Explorer (IE) で F12 キーを押して開発者ツールを起動すると、下の画像のようにブラウザーモードとドキュメントモードというメニューが表示されます。これについていろいろ調べましたので、後日役に立ちそうなことを忘れないように書いておきます。

ブラウザーモードの設定

ブラウザーモード

F12 開発者ツールのみで設定が可能なオプションで、IE 自体の動きが選択されたバージョンになります。

例えば、実際に使っているブラウザが IE9 でも、ブラウザーモードで他のバージョンを選択するとそのバージョンの動きになります。

試しに IE9 で[Internet Explorer 8(8)]を選択してみると、サーバーに送信される User Agent は Mozilla/4.0 (compatible; MSIE 8.0; ... というように IE8 のものになりました。(サーバーに送られる User Agent は、IE の互換表示の設定によっても変わってきます。詳しくは下の「2016/3/1 追記」を見てください)

また、<!--[if IE 8]> のような条件付コメントも、ブラウザーモードの選択によって影響を受けるとのことです(未検証です)。

ドキュメントモード

これはレンダリングエンジンのみを変更します。ブラウザーモードの切り替えのように IE 自体の動きは変更しません。

F12 開発者ツールを使う以外にも、(1) meta タグ (X-UA-Compatible) で指定、(2) IE の[ツール(T)]⇒[互換表示設定(B)]、(3) IE のアドレスバー右横の互換表示ボタン (IE11 では無くなった) で設定可能です。

ただし、IE9 で試した限りですが、上記の (2) と (3) では[Internet Explorer 7 標準(7)]相当になり、IE8 や Quirks モードを選ぶというようなことはできませんでした。

Quirks モードというのは IE6 で導入された旧バージョン(ということは IE5 以前のはず)のブラウザーと同じようにページが表示されるモードです。CSS の IE 独自実装である expression 関数が使えるのが Quirks モードです。

その他

IE10 以降では条件付コメントはサポートされなくなったそうです。

Conditional comments are no longer supported (条件付きコメントがサポートされなくなった)

IE10 以降では Quirks モードの既定の動作が修正されているそうです。

Interoperable (HTML5) quirks mode (相互運用可能な (HTML5) Quirks モード)

IE11 以降ではエッジモードが使われており、ドキュメントモードは廃止される可能性があるとのことで、将来的には切り替えることができなくなる可能性があるようです。ただし、現時点では F12 開発者ツールや meta タグ (X-UA-Compatible) での設定は可能な様子です。

Compatibility changes in IE11 (IE11 の互換性の変更点)

Web制作者は注意! Internet Explorer 11で変更された「互換性」

meta タグ (X-UA-Compatible) で指定する content="IE=7" とか content="IE=EmulateIE7" の違いは、以下のページが参考になると思います。

Defining document compatibility (ドキュメント互換性の定義)

Specifying legacy document modes

上の後者の記事によると、以下のように edge を指定した場合、IE6 ~ IE11 では "the highest standards mode supported by Internet Explorer" になるとのことです。

<meta http-equiv="x-ua-compatible" content="IE=edge" />

ただし、この先 meta タグで X-UA-Compatible は無視されるという話もあります。

"living" Edge ドキュメント モード

一体何を信じたら良いのかって感じですが、とにかく X-UA-Compatible でドキュメントモードを古いものに指定するようなことをしなければ今後も問題が起こることはなさそうです。

------- 2016/3/1 追記 -------

サーバーに送られる User Agent は、ブラウザモードの設定だけでなく、IE が互換表示するサイトと認識すると旧バージョンのものになるようです。

IE9 で試してみましたが、[ツール(T)]⇒[互換表示設定(B)]で表示されるダイアログで、要求するページのサイトが[互換表示に追加した Web サイト(W):]に含まれている場合とか、[すべての Web サイトを互換表示で表示する(E)]にチェックを入れた場合は IE7 の UA が Web サーバーに送られます。

[イントラネット サイトを互換表示で表示する(I)]にはデフォルトでチェックマークが入っているので要注意ですね。

Tags:

その他

名前解決

by WebSurfer 23. May 2012 21:48

Windows ネットワークにおける「名前解決」について、いろいろ調べて分ったことを備忘録として書いておきます。

Windows ネットワークで利用されるプロトコルには、大きく分けて NetBIOS 系のプロトコルと、TCP/IP 系のプロトコルがあり、その目的に応じて使い分けられています。(はじめから通信プロトコルに TCP/IP を採用していた UNIX 系の OS では NetBIOS 名という考え方は存在しません)

もともとこれらのプロトコルはまったく別のものでしたが、NBT(NetBIOS over TCP/IP)などの技術によって両者は巧みに組み合わされ、ユーザーはその違いをほとんど意識することなく利用することができるようになっています。

従って、現在では、Windows ネットワークにおける名前解決とは NetBIOS 名またはホスト名を IP アドレスに正しくマップすることと定義してよさそうです。

Windows ネットワークにおける名前解決のための機能は複数あり、標準的に、以下の優先順位で名前解決のための各機能が利用されています。(以下の「WINS サービス」と「NetBIOS 名のブロードキャスト」の部分はノードタイプによって異なります。詳しくは @IT の記事 第19回 NetBIOS over TCP/IPプロトコル(その2) (4/4) を見てください)

NetBIOS 名前キャッシュ
    ↓
WINS サービス
    ↓
NetBIOS 名のブロードキャスト
    ↓
lmhosts ファイル
    ↓
hosts ファイル
    ↓
DNS サービス

以下に、各機能の説明を書きます。

(1) NetBIOS

NetBIOS は、ネットワークサービスを呼び出すための API インターフェイスです。IBM-PC 用のネットワークアダプタ上に実装されていた BIOS の API として 1980 年代前半に開発され、Windows 95/98 や Windows NT、LAN Manager などを始め、パソコン用のネットワークサービスの API として広く普及したそうです。

アプリケーションでは、NCB(Network Control Block)というデータ構造体に NetBIOS のコマンドとそのパラメータをセットし、NetBIOS インターフェイスを呼び出すことによって各種のネットワ��クサービスを受けることができます。

NetBIOSは、通信プロトコルの規格ではなく、API の呼び出しインターフェイスの仕様です。物理的なネットワーク媒体やその上でやり取りされるパケットの構造については決めていません。

下位ネットワークプロトコルとしては、NetBEUI (NetBIOS Extended User Interface) や TCP/IP などが利用されています。TCP/IP をベースとするものを特に NBT(NetBIOS over TCP/IP)といいます。

(2) NetBEUI

NetBIOS API を使う Windows 95 時代の通信プロトコルが NetBEUI です。ブロードキャストを多用すること、ルーティング機能が実装されていないことから、プロトコルとしては小規模な LAN 向けです。

基本的にはコンピュータが自分の NetBIOS 名を知っていて、それが(ブロードキャストで)呼ばれたら変事をするような仕組みになっています。

現在では NBTに移行されていて、NetBEUI が使われることはほとんどないそうなので、忘れてよさそうです。実際、Windows 7 から NetBEUI が廃止されています。

(3) NBT

時代の流れに乗って一気に TCP/IP に移行してしまうと、今まで使ってきた NetBEUI と NetBIOS による Windows のファイル共有やプリンタ共有ができなくなるので、Microsoft の戦略として、TCP/IP 上で NetBIOS API を使えるようにしたのが NBT(NetBIOS over TCP/IP)です。

NBT により、複数セグメントに分かれたネットワークでも、NetBIOSのアプリケーションそのままで対応可能になりました。

参考: NBTとは

(4) NetBIOS 名

NetBIOS のサービスを利用して通信する場合、各コンピュータには必ず NetBIOS 名が付けられている必要があります。通信相手を特定するのに、IP アドレスや MAC アドレスではなく、この NetBIOS 名が利用されるためです。(NetBIOS 名は 16 バイト固定で、最後の 1 バイトがサフィックスという点が、コンピュータ名とはちょっと違います)

NetBIOS名 は、システムの起動時に各マシンごとに動的に登録するようになっています。つまり、あらかじめコンピュータに割り当てられた NetBIOS 名を、システムの起動時にネットワークにブロードキャストしたり、WINS サーバに登録したりし、それが認められて初めて Windows ネットワークに参加することができます。

逆に言えば、認められなければ、サービスを提供するだけでなく、ほかのマシンのサービスを利用することもできません。この点が、IP アドレスさえ割り当てられれば動作する TCP/IP とは大きく異なります。

参考: NetBIOS名とは何か?

(5) NetBIOS 名前キャッシュ

名前解決の結果は一定時間(デフォルトで 600 秒)だけ NetBIOS 名前キャッシュに格納されます。次にまた通信を行う場合、キャッシュ中に該当するエントリがあれば、キャッシュから IP アドレスが取り出され、問い合わせパケットを送信することはありません。

NetBIOS 名キャッシュの内容は「nbtstat -c」コマンドを実行すれば確認できます。解決した NetBIOS 名とユニークかグループかの種別、IP アドレス、寿命(キャッシュの有効期限。単位は秒)の情報が表示されます。

(6) WINS サービス

WINS (Windows Internet Name Service) は、NetBIOS over TCP/IP を使うルーティングされるネットワークで、NetBIOS の名前解決から発生した問題を解決するよう設計されたものだそうです。

各コンピュータが NetBIOS 名と IP アドレスの対応付けを WINS サーバーに登録しておき、利用したい場合には WINS サーバーに相手コンピュータの NetBIOS 名で問い合わせることで、相手コンピュータの IP アドレスを取得することができます。

なお、WINS にはドメインという概念がないので、大きなネットワークでも 1 台のサーバーで管理しなくてはいけないという問題を抱えています。そのためか、Microsoft も WINS には見切りをつけていて、廃止の方向に向かっているそうです。

参考: WINS の定義

(7) NetBIOS 名のブロードキャスト

WINS サービスが利用可能だからといって、必ずしも WINS サービスを使うと言うわけではなく、NBT のノードタイプによってはWINSサーバを使わず、ブロードキャストを使う場合があります。

ノードタイプは、RFC 1001『Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Concepts and Methods』で定義されていて、以下の通り 4 種類あります。

  1. b ノード(ブロードキャスト)
  2. p ノード(ピアツーピア:WINS サーバー利用)
  3. m ノード(混合:ブロードキャスト ⇒ WINS サーバー利用)
  4. h ノード(ハイブリッド:WINS サーバー利用 ⇒ ブロードキャスト)

参考: NetBIOS 名の解決

(8) lmhosts ファイルと hosts ファイル

Windows ネットワークにおいて静的な名前解決を行う手段としては、hosts ファイルと lmhosts (LAN Manager Hosts) ファイルの 2 つがあります。

hosts ファイルは、もともとは TCP/IP プロトコルで使われてきた名前解決手段ですが、現在では NBT 系のサービスでも利用されている、一番基本的な名前解決手段です。

lmhosts ファイルは、もともとは NBT プロトコルで利用されてきた名前解決手段で、主に NetBIOS 名と IP アドレスの対応付けを管理しています。

いずれも systemroot\System32\Drivers\Etc フォルダに格納されています。

参考: hosts と lmhostsの違い

(9) DNS サービス

Microsoft は Windows2000 で Active Directory という Windows ネットワークを管理する新しい仕組みを導入し、その中で名前解決の仕組みに DNS を導入しました。Windows ネットワークでも、本格的に TCP/IP + DNS という仕組みを採用したわけです。

しかしながら、上に述べましたように、過去の資産を継承するために NetBIOS の仕組みも存続させています。NBT も搭載していますし、NetBIOS 名の名前解決の仕組みとして WINS も存続しています。

それゆえ、Windows ネットワークは NetBIOS 名とホスト名が混在するややこしい状態になっています。

参考: NetBIOS名の登録

Tags: , ,

その他

ブラウザによる URL のエンコーディング

by WebSurfer 7. November 2011 22:08

クエリ文字列に日本語を使用している場合、それをブラウザのアドレスバーから直接入力して要求をかけるのは問題がありそうです。

以下のような、日本語を含む URL をブラウザのアドレスバーに直接打ち込んで要求をかけると、ブラウザはどのような文字列をサーバーに送るでしょうか?

http://www.abc.com/日本語.aspx?data=日本語

下の画像は IE9 の場合で、Fiddler を使って HTTP-GET 要求をキャプチャし、HexView で表示したものです。サーバーに送信したバイト列を 16 進数で表したものと、その 16 進数に相当する ASCII コードの文字が表示されています。

Fiddler によるキャプチャ画面

ファイル名の "日本語" の方は UTF-8 が URL エンコード(ASCII 文字で %E6%97%A5 ... %AA%9E)されますが、クエリ文字列の方の "日本語" は Shift_JIS そのまま(反転表示したバイト列 93 FA 96 7B 8C EA)になっているのが見えるでしょうか。

IE9, Firefox 7, Chrome 15 で試してみましたが、ファイル名の方はいずれも UTF-8 の URL エンコードで同じ結果になりましたが、クエリ文字列の方はそれぞれ以下のように結果が異なりました。

ブラウザ クエリ文字列
IE9 Shift_JIS そのまま
Firefox 7 Shift_JIS を URL エンコード
Chrome 15 UTF-8 を URL エンコード

ということは、サーバーが受信した文字列を UTF-8 として解釈する場合(ASP.NET のデフォルト)、上記のブラウザのうち Chrome しかクエリ文字列を正しく送信できないということになるようです。

では、アドレスバー直打ちではなく、以下のようなハイパーリンクをクリックするとブラウザはどのような要求をサーバーに送るでしょうか?

<a href="default.aspx?data=日本語">リンク</a>

IE は文字コードのバイト列を生のまま送ります。例えば、"日本語" というクエリ文字列の場合、ハイパーリンクのあるページのエンコーディングが Shift_JIS なら 93 fa 96 7b 8c ea、UTF-8 なら e6 97 a5 e6 9c ac e8 aa 9e となります。

Firfox と Chrome は URL エンコードしてから送ります。ただし、Shift_JIS の場合、2 バイト目が ASCII の非予約文字のときは、その文字をそのまま使用します。"日本語" の場合、"本" の 2 バイト目 7b が ASCII 文字で '{' に該当するので、結果は "%93%FA%96{%8C%EA" になります。

特殊な例かもしれませんが、BlogEngine.NET の場合 '{' という文字が問題で、内部で URL の書き換えを行う際に例外がスローされてサーバーエラーになってしまうという問題がありました。

このような予期しない問題を避けるために、サーバー側できちんと UrlEncode メソッドを使って URL エンコーディングした文字列("本" は "%96%7b" になります)を使うのがよさそうです。(ただし、アドレスバー直打ちされた場合はどうしようもありませんが)

ちなみに、URL 本体('?' の左側の文字列)は、アドレスバーへの直打ち、ハイパーリンクへの設定、ページに使用されているエンコーディングの違い、ブラウザの違い(IE9, Firefox 7, Chrome 15 しか試してませんが)などに関係なく UTF-8 の URL エンコーディングになります。

なので、BlogEngine.NET 2.0 の Tag cloud の問題日本語の著者名の問題 で書きましたように、URL 本体の文字に URL エンコードしない日本語の文字列を使っていますが、今までのところ期待通りに動いています。運よく問題に遭遇していないだけという可能性は排除しきれませんが。(笑)

Tags: ,

その他

About this blog

2010年5月にこのブログを立ち上げました。その後 ブログ2 を追加し、ここは ASP.NET 関係のトピックス、ブログ2はそれ以外のトピックスに分けました。

Calendar

<<  September 2021  >>
MoTuWeThFrSaSu
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

View posts in large calendar