URI 正規化

URI 正規化は、URI を一貫した方法で変更および標準化するプロセスです。正規化プロセスの目的は、URI を正規化された URI に変換して、構文的に異なる 2 つの URI が同等であるかどうかを判断できるようにすることです。

検索エンジンは、複数の URI で見つかる可能性があるページを正しくランク付けし、重複するページのインデックス作成を減らすために、URI 正規化を採用しています。Webクローラーは、同じリソースを複数回クロールしないようにするために URI 正規化を実行します。Webブラウザーは、リンクがアクセスされたかどうか、またはページがキャッシュされたかどうかを判断するために正規化を実行する場合があります。Webサーバーも、さまざまな理由で正規化を実行する場合があります (つまり、クライアント要求によるセキュリティ リスクをより簡単に傍受できるようにするため、キャッシュに保存されているリソースごとに 1 つの絶対ファイル名のみを使用するため、ログ ファイルで名前が付けられているなど)。

実行できる正規化にはいくつかの種類があります。常に意味が保持されるものもあれば、そうでないものもあります。

^{RFC 3986 [1]}では、同等のURIを生成するための以下の正規化が説明されています。

• パーセントエンコードされたトリプレットを大文字に変換します。URIのパーセントエンコードされたトリプレット内の16進数字（例：%3a対%3A）は大文字と小文字を区別しないため、数字A〜Fに大文字を使用するように正規化する必要があります。^[2]例：

http://example.com/foo%2a→http://example.com/foo%2A

• スキームとホストを小文字に変換します。URIのスキームとホストのコンポーネントは大文字と小文字を区別しないため、小文字に正規化する必要があります。^[3]例:

HTTP://User@Example.COM/Foo→http://User@example.com/Foo

• パーセントエンコードされた非予約文字のトリプレットのデコード。ALPHA ( -と- )、DIGIT ( - )、ハイフン ( )、ピリオド ( ) 、アンダースコア ( )、またはチルダ ( )の範囲の URI のパーセントエンコードされたトリプレットは、パーセントエンコードを必要とせず、対応する非予約文字にデコードする必要があります。^[4]例:%41%5A%61%7A%30%39%2D%2E%5F%7E

http://example.com/%7Efoo→http://example.com/~foo

• ドットセグメントの削除。URIのパスコンポーネント内のドットセグメント.は、 RFC 3986 ^[6]で説明されているパスにremove_dot_segmentsアルゴリズム^[5]を適用して削除する必要があります。例:..

http://example.com/foo/./bar/baz/../qux→http://example.com/foo/bar/qux

• 空のパスを「/」パスに変換する。権限コンポーネントが存在する場合、空のパスコンポーネントは「/」のパスコンポーネントに正規化される必要があります。^[7]例:

http://example.com→http://example.com/

• デフォルトポートの削除。URIの空またはデフォルトポートコンポーネント（スキームの場合はポート80 http）とその「:」区切り文字は削除する必要があります。^[8]例:

http://example.com:80/→http://example.com/

http および https URI の場合、RFC 3986 に記載されている次の正規化により同等の URI が生成される可能性がありますが、標準では保証されていません。

• 空でないパスの末尾に「/」を追加します。ディレクトリ (フォルダ) は末尾のスラッシュで示され、URI に含める必要があります。例:

http://example.com/foo→http://example.com/foo/

ただし、URI パス コンポーネントがディレクトリを表しているかどうかを知る方法はありません。RFC 3986 では、前者の URI が後者の URI にリダイレクトされる場合、それらは同等であることを示すとされています。

次の正規化を適用すると、同じリソースを参照している場合でも、意味的に異なる URI が生成されます。

• ディレクトリ インデックスを削除します。デフォルトのディレクトリ インデックスは通常、URI では必要ありません。例:

http://example.com/a/index.html→http://example.com/a/

http://example.com/default.asp→http://example.com/

• フラグメントの削除。URIのフラグメントコンポーネントはサーバーからは見えないため、削除できる場合があります。例:

http://example.com/bar.html#section1→http://example.com/bar.html

ただし、AJAXアプリケーションではフラグメント内の値が頻繁に使用されます。

• IP をドメイン名に置き換えます。IPアドレスがドメイン名にマップされているかどうかを確認します。例:

http://208.77.188.166/→http://example.com/

仮想 Web サーバーのため、逆の置換はほとんど安全ではありません。

• プロトコルの制限。さまざまなアプリケーション層プロトコルを制限します。たとえば、「https」スキームを「http」に置き換えることができます。例:

https://example.com/→http://example.com/

• 重複したスラッシュを削除する 隣接する 2 つのスラッシュを含むパスは 1 つに変換できます。例:

http://example.com/foo//bar.html→http://example.com/foo/bar.html

• 最初のドメイン ラベルとして「www」を削除または追加します。一部の Web サイトは、2 つのインターネット ドメインで同じように動作します。1 つは最下位のラベルが「www」で、もう 1 つは最初のドメインの名前から最下位のラベルを省略した名前です。後者はネイキッド ドメインと呼ばれます。たとえば、http://www.example.com/と はhttp://example.com/同じ Web サイトにアクセスできます。多くの Web サイトは、ユーザーをwwwアドレスから非 www アドレスにリダイレクトするか、その逆を行います。正規化機能は、これらの URI の 1 つが他の URI にリダイレクトされるかどうかを判断し、すべての URI を適切に正規化します。例:

http://www.example.com/→http://example.com/

• クエリ パラメータの並べ替え。一部の Web ページでは、URI で複数のクエリ パラメータが使用されています。正規化ツールは、パラメータをアルファベット順 (値付き) に並べ替え、URI を再構成できます。例:

http://example.com/display?lang=en&article=fred→http://example.com/display?article=fred&lang=en

しかし、URI内のパラメータの順序は重要になる場合があり（これは標準では定義されていない）、Webサーバーは同じ変数が複数回出現することを許可する場合があります。^[9]

• 使用されていないクエリ変数を削除します。ページはクエリに特定のパラメータのみが表示されることを期待している場合があります。使用されていないパラメータは削除できます。例:

http://example.com/display?id=123&fakefoo=fakebar→http://example.com/display?id=123

値のないパラメータは必ずしも未使用のパラメータではないことに注意してください。

• デフォルトのクエリ パラメータを削除します。クエリ文字列内のデフォルト値は、存在するかどうかに関係なく、同じようにレンダリングされる場合があります。例:

http://example.com/display?id=&sort=ascending→http://example.com/display

• クエリが空の場合は「?」を削除します。クエリが空の場合は、「?」は必要ない場合もあります。例:

http://example.com/display?→http://example.com/display

以前のクロールやウェブサーバーのログから取得したURIリストを調べることで、特定のウェブサイト向けの正規化ルールが開発されることがあります。たとえば、URI

http://example.com/story?id=xyz

クロールログに複数回出現し、

http://example.com/story_xyz

2 つの URI は同等であり、いずれかの URI 形式に正規化できると想定できます。

Schonfeld ら (2006) は、URI リストに適用できる DUST (類似したテキストを持つ異なる URI) ルールを検出するための DustBuster と呼ばれるヒューリスティックを発表しました。彼らは、正しい DUST ルールが見つかり、正規化アルゴリズムを使用して適用すると、URI リスト内の冗長な URI を最大 68% 検出できることを示しました。

• URL (ユニフォーム リソース ロケータ)
• URIフラグメント
• ウェブクローラー

• RFC 3986 - 統一リソース識別子 (URI): 一般的な構文
• Sang Ho Lee、Sung Jin Kim、Seok Hoo Hong (2005)。URL の正規化について(PDF) 。国際計算科学とその応用に関する会議 (ICCSA 2005) の議事録。pp. 1076–1085。2006年 9 月 18 日のオリジナル(PDF)からアーカイブ。
• Uri Schonfeld、Ziv Bar-Yossef、Idit Keidar (2006)。「ほこりの中を這いずってはダメ: 類似したテキストを持つ異なる URL」。第 15 回World Wide Web国際会議の議事録。pp. 1015–1016。
• Uri Schonfeld、Ziv Bar-Yossef、Idit Keidar (2007)。「ほこりの中を這いずってはダメ: 似たようなテキストを持つ異なる URL」。第 16 回 World Wide Web 国際会議の議事録。pp. 111–120。