ネットワーク作業部会 T. Berners-Lee Request for Comments: 3986 W3C/MIT STD: 66 R. Fielding 更新: 1738 Day Software 廃止: 2732, 2396, 1808 L. Masinter 分類: 標準トラック Adobe Systems 2005年1月 統一資源識別子 (URI): 汎用構文 このメモの位置付け この文書は、インターネットコミュニティ向けの インターネット標準トラックプロトコルを規定し、 改善のための議論および提案を求める。このプロトコルの 標準化段階および状態については、最新版の「Internet Official Protocol Standards」(STD 1) を参照されたい。 このメモの配布に制限はない。 Copyright Notice Copyright (C) The Internet Society (2005). Berners-Lee, et al. 標準トラック [1ページ]
RFC 3986 URI 汎用構文 2005年1月 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. URI の概要 . . . . . . . . . . . . . . . . . . . . . . 4 1.1.1. 汎用構文 . . . . . . . . . . . . . . . . . . . . 6 1.1.2. 例 . . . . . . . . . . . . . . . . . . . . . . . 7 1.1.3. URI、URL、および URN . . . . . . . . . . . . . 7 1.2. 設計上の考慮事項 . . . . . . . . . . . . . . . . . . 8 1.2.1. 転記 . . . . . . . . . . . . . . . . . . . . . 8 1.2.2. 識別と相互作用の分離 . . . . . . . . . . . . . 9 1.2.3. 階層識別子 . . . . . . . . . . . . . . . . . . 10 1.3. 構文表記 . . . . . . . . . . . . . . . . . . . . . . 11 2. 文字 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1. パーセントエンコーディング . . . . . . . . . . . . . 12 2.2. 予約文字 . . . . . . . . . . . . . . . . . . . . . . 12 2.3. 非予約文字 . . . . . . . . . . . . . . . . . . . . . 13 2.4. エンコードまたはデコードする時点 . . . . . . . . . 14 2.5. 識別データ . . . . . . . . . . . . . . . . . . . . . 14 3. 構文コンポーネント . . . . . . . . . . . . . . . . . . . 16 3.1. スキーム . . . . . . . . . . . . . . . . . . . . . . 17 3.2. オーソリティ . . . . . . . . . . . . . . . . . . . . 17 3.2.1. ユーザー情報 . . . . . . . . . . . . . . . . . 18 3.2.2. ホスト . . . . . . . . . . . . . . . . . . . . 18 3.2.3. ポート . . . . . . . . . . . . . . . . . . . . 22 3.3. パス . . . . . . . . . . . . . . . . . . . . . . . . 22 3.4. クエリ . . . . . . . . . . . . . . . . . . . . . . . 23 3.5. フラグメント . . . . . . . . . . . . . . . . . . . . 24 4. 使用法 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.1. URI 参照 . . . . . . . . . . . . . . . . . . . . . . 25 4.2. 相対参照 . . . . . . . . . . . . . . . . . . . . . . 26 4.3. 絶対 URI . . . . . . . . . . . . . . . . . . . . . . 27 4.4. 同一文書参照 . . . . . . . . . . . . . . . . . . . . 27 4.5. サフィックス参照 . . . . . . . . . . . . . . . . . . 27 5. 参照解決 . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.1. 基底 URI の確立 . . . . . . . . . . . . . . . . . . 28 5.1.1. コンテンツに埋め込まれた基底 URI . . . . . . 29 5.1.2. カプセル化エンティティからの基底 URI . . . 29 5.1.3. 取得 URI からの基底 URI . . . . . . . . . . 30 5.1.4. 既定の基底 URI . . . . . . . . . . . . . . . . 30 5.2. 相対解決 . . . . . . . . . . . . . . . . . . . . . . 30 5.2.1. 基底 URI の事前解析 . . . . . . . . . . . . . 31 5.2.2. 参照の変換 . . . . . . . . . . . . . . . . . . 31 5.2.3. パスのマージ . . . . . . . . . . . . . . . . 32 5.2.4. ドットセグメントの除去 . . . . . . . . . . . 33 5.3. コンポーネントの再構成 . . . . . . . . . . . . . . 35 5.4. 参照解決の例 . . . . . . . . . . . . . . . . . . . . 35 5.4.1. 通常の例 . . . . . . . . . . . . . . . . . . . 36 5.4.2. 異常な例 . . . . . . . . . . . . . . . . . . . 36 Berners-Lee, et al. 標準トラック [2ページ]
RFC 3986 URI 汎用構文 2005年1月 6. 正規化と比較 . . . . . . . . . . . . . . . . . . . . . . . 38 6.1. 同値性 . . . . . . . . . . . . . . . . . . . . . . . 38 6.2. 比較の段階 . . . . . . . . . . . . . . . . . . . . . 39 6.2.1. 単純文字列比較 . . . . . . . . . . . . . . . . 39 6.2.2. 構文に基づく正規化 . . . . . . . . . . . . . . 40 6.2.3. スキームに基づく正規化 . . . . . . . . . . . . 41 6.2.4. プロトコルに基づく正規化 . . . . . . . . . . 42 7. セキュリティに関する考慮事項 . . . . . . . . . . . . . 43 7.1. 信頼性と一貫性 . . . . . . . . . . . . . . . . . . 43 7.2. 悪意のある構築 . . . . . . . . . . . . . . . . . . . 43 7.3. バックエンドトランスコーディング . . . . . . . . . 44 7.4. まれな IP アドレス形式 . . . . . . . . . . . . . . 45 7.5. 機密情報 . . . . . . . . . . . . . . . . . . . . . 45 7.6. 意味論的攻撃 . . . . . . . . . . . . . . . . . . . . 45 8. IANA に関する考慮事項 . . . . . . . . . . . . . . . . . 46 9. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 10. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . 46 10.1. 規範的参考文献 . . . . . . . . . . . . . . . . . . . . 46 10.2. 参考情報 . . . . . . . . . . . . . . . . . . . . . . . 47 A. URI の ABNF 集成 . . . . . . . . . . . . . . . . . . . . . 49 B. 正規表現による URI 参照の解析 . . . . . . . . . . . . . 50 C. 文脈内での URI の区切り . . . . . . . . . . . . . . . . 51 D. RFC 2396 からの変更 . . . . . . . . . . . . . . . . . . . . 53 D.1. 追加 . . . . . . . . . . . . . . . . . . . . . . . . 53 D.2. 変更 . . . . . . . . . . . . . . . . . . . . . . . . 53 索引 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 著者の住所 . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 完全な著作権声明 . . . . . . . . . . . . . . . . . . . . . . . . 61 Berners-Lee, et al. 標準トラック [3ページ]
RFC 3986 URI 汎用構文 2005年1月 1. はじめに 統一資源識別子 (URI) は、リソースを識別するための 単純かつ拡張可能な手段を提供する。この URI の構文および 意味論の仕様は、World Wide Web の世界的な情報 イニシアチブによって導入された概念に由来する。この識別子の使用は 1990 年にさかのぼり、"WWW における Universal Resource Identifiers" [RFC1630] に記述されている。この構文は、 "インターネットリソースロケーターの機能上の推奨事項" [RFC1736] および "統一資源名の機能要件" [RFC1737] に示された推奨事項を満たすよう設計されている。 この文書は [RFC2396] を廃止する。同文書は、すべての URI に対して 単一の汎用構文を定義するため、"Uniform Resource Locators" [RFC1738] と "Relative Uniform Resource Locators" [RFC1808] を統合したものである。 また、IPv6 アドレスの構文を導入した [RFC2732] も廃止する。 個々の URI スキームの具体的な構文を定義していた RFC 1738 の部分は除外され、それらの部分は別個の 文書として更新される。新しい URI スキームの登録プロセスは、 [BCP35] により別途定義される。新しい URI スキームの設計者向けの助言は [RFC2718] にある。RFC 2396 からの重要な変更はすべて 付録 D に記載されている。 この仕様では、"character" および "coded character set" という用語を [BCP19] で提供される定義に従って使用し、 [BCP19] が "charset" と呼ぶものの代わりに "character encoding" を使用する。 1.1. URI の概要 URI は次のように特徴付けられる: 統一性 統一性にはいくつかの利点がある。リソースへのアクセスに使用される 仕組みが異なる場合でも、異なる種類の リソース識別子を同じ文脈で使用できる。 異なる種類のリソース識別子間で共通する構文上の 規約を統一的に意味解釈できる。 既存の識別子の使用方法を妨げることなく、 新しい種類のリソース識別子を導入できる。 識別子をさまざまな文脈で再利用できるため、 新しいアプリケーションまたはプロトコルが、既存の 大規模かつ広く使用されているリソース識別子集合を活用できる。 Berners-Lee, et al. 標準トラック [4ページ]
RFC 3986 URI 汎用構文 2005年1月 リソース この仕様は、何がリソースとなり得るかの範囲を 制限しない。むしろ、"resource" という用語は、URI によって 識別され得るあらゆるものについて一般的な意味で使用される。 よく知られた例には、電子文書、画像、一貫した目的を持つ 情報源（例えば「ロサンゼルスの今日の天気予報」）、 サービス（例えば HTTP-to-SMS ゲートウェイ）、および その他のリソースの集合が含まれる。リソースは必ずしも インターネット経由でアクセス可能である必要はなく、例えば人間、企業、 図書館の製本された書籍もリソースになり得る。同様に、 数式の演算子と オペランド、関係の種類（例えば "parent" または "employee"）、 数値（例えば 0、1、無限大）などの抽象概念もリソースになり得る。 識別子 識別子は、その識別範囲内で、 識別対象を他のすべてのものから区別するために必要な情報を 具体化する。本仕様で "identify" および "identifying" という用語を 使用する場合、それがどのように達成されるか （例えば名前、アドレス、文脈）にかかわらず、 あるリソースを他のすべてのリソースから区別する目的を指す。 これらの用語を、識別子が参照対象の アイデンティティを定義または具体化するという前提と 誤解すべきではない。ただし一部の識別子ではそうである場合もある。 また、URI を使用するシステムが識別されたリソースへ アクセスするとも仮定すべきではない。多くの場合、 URI はアクセスを意図することなくリソースを示すために使用される。 同様に、識別される「1 つ」のリソースが本質的に 単一でない場合もある（例えば、リソースが名前付き集合や、 時間とともに変化するマッピングである場合）。 URI は、セクション 3 の <URI> という名前の構文規則に 一致する文字列から構成される識別子である。 別途定義された拡張可能な命名スキーム集合 (セクション 3.1) によって、リソースを統一的に識別できる。 その識別がどのように実現、割り当て、または可能にされるかは、 各スキーム仕様に委ねられる。 この仕様は、リソースの性質、 アプリケーションがリソースを参照しようとする理由、 またはリソース識別のために URI を使用するシステムの種類に いかなる制限も設けない。また、この仕様は、 URI が時間の経過後も同じリソースを識別し続けることを要求しないが、 これはすべての URI スキームに共通する目標である。それでも、この Berners-Lee, et al. 標準トラック [5ページ]
RFC 3986 URI 汎用構文 2005年1月 仕様は、アプリケーションが特定の種類の リソース、またはそのアプリケーションが望む特性を維持する URI の部分集合に自身を限定することを妨げない。 URI はグローバルなスコープを持ち、文脈にかかわらず 一貫して解釈される。ただし、その解釈結果は エンドユーザーの文脈に関連する場合がある。例えば、"http://localhost/" は、その参照を使用するすべてのユーザーに対して同じ解釈を持つが、 "localhost" に対応するネットワークインターフェイスは 各エンドユーザーで異なる場合がある。つまり、解釈はアクセスとは独立している。 ただし、その参照に基づいて行われる動作は、 エンドユーザーの文脈に関連して実行される。したがって、 グローバルに一意なものを参照することを意図する動作では、 そのリソースを他のすべてのものから区別する URI を 使用しなければならない。エンドユーザーのローカルな文脈との関係で 識別する URI は、その文脈自体がリソースを定義する側面である場合にのみ 使用すべきである。例えば、オンラインヘルプマニュアルがエンド ユーザーのファイルシステム上のファイルを参照する場合 （例えば "file:///etc/hosts"）である。 1.1.1. 汎用構文 各 URI は、セクション 3.1 で定義されるスキーム名で始まり、 そのスキーム内で識別子を割り当てるための仕様を 参照する。したがって、URI 構文は連合型かつ拡張可能な命名 システムであり、各スキームの仕様は、そのスキームを使用する 識別子の構文および意味論をさらに制限できる。 この仕様は、すべての URI スキームに必要な、 または多くの URI スキームに共通する URI 構文要素を定義する。 したがって、URI 参照に対するスキーム非依存の 解析機構を実装するために必要な構文および意味論を定義し、 URI のスキーム依存の処理を、スキーム依存の 意味論が必要となるまで遅延できる。同様に、 URI 参照を使用するプロトコルおよびデータ 形式は、まだ定義されていないスキームを含むすべての URI で 許可される構文範囲の定義として、この仕様を参照できる。 これにより、識別スキームの進化と、 URI を利用するプロトコル、データ形式、および実装の進化が 切り離される。 汎用 URI 構文のパーサーは、任意の URI 参照を 主要なコンポーネントへ解析できる。スキームが決定された後、 コンポーネントに対してさらにスキーム固有の解析を行える。 言い換えると、URI 汎用構文は、すべての URI スキームの構文の上位集合である。 Berners-Lee, et al. 標準トラック [6ページ]
RFC 3986 URI 汎用構文 2005年1月 1.1.2. 例 次の URI の例は、いくつかの URI スキームと、 それらに共通する構文コンポーネントのバリエーションを示す: ftp://ftp.is.co.za/rfc/rfc1808.txt http://www.ietf.org/rfc/rfc2396.txt ldap://[2001:db8::7]/c=GB?objectClass?one mailto:John.Doe@example.com news:comp.infosystems.www.servers.unix tel:+1-816-555-1212 telnet://192.0.2.16:80/ urn:oasis:names:specification:docbook:dtd:xml:4.1.2 1.1.3. URI、URL、および URN URI はさらに、ロケーター、名前、またはその両方として分類できる。 "Uniform Resource Locator" (URL) という用語は、 リソースを識別するだけでなく、その主要なアクセス機構 （例えばネットワーク上の「場所」）を記述することで リソースを特定する手段も提供する URI の部分集合を指す。 "Uniform Resource Name" (URN) という用語は歴史的に、 "urn" スキーム [RFC2141] の URI（リソースが存在しなくなったり 利用できなくなったりしても、グローバルに一意かつ永続的であることが 要求される）と、名前としての性質を持つその他すべての URI の 両方を指すために使用されてきた。 個々のスキームを、"name" または "locator" の どちらか一方だけに分類する必要はない。特定のスキームの URI の インスタンスは、スキーム自体の性質ではなく、 命名オーソリティによる識別子割り当ての 永続性や慎重さに応じて、名前、ロケーター、 またはその両方の特性を持つ場合が多い。 将来の仕様および関連文書では、より制限的な用語 "URL" および "URN" ではなく、一般的な用語 "URI" を使用すべきである [RFC3305]。 Berners-Lee, et al. 標準トラック [7ページ]
RFC 3986 URI 汎用構文 2005年1月 1.2. 設計上の考慮事項 1.2.1. 転記 URI 構文は、世界規模での転記を主要な考慮事項の 1 つとして 設計されている。URI は、非常に限定された集合の文字列である。 すなわち、基本ラテンアルファベットの文字、数字、 および少数の特殊文字である。URI はさまざまな 方法で表現できる。例えば、紙上のインク、画面上のピクセル、 または文字エンコーディングのオクテット列である。 URI の解釈は使用される文字だけに依存し、 それらの文字がネットワークプロトコル内で どのように表現されるかには依存しない。 転記という目標は、簡単なシナリオで説明できる。 国際会議のパブで、同僚の Sam と Kim が座って 研究アイデアを交換していると想像してほしい。Sam は Kim に 詳細情報を得る場所を尋ね、Kim は研究サイトの URI を ナプキンに書く。帰宅後、Sam はその ナプキンを取り出し、URI をコンピューターへ入力すると、 コンピューターは Kim が参照した情報を取得する。 このシナリオから、いくつかの設計上の考慮事項が明らかになる: o URI は文字列であり、必ずしも オクテット列として表現されるとは限らない。 o URI はネットワーク以外の情報源から転記される場合があり、 したがって、各言語および ロケールのキーボード（および関連する入力装置）による 制約の範囲内で、コンピューターへ入力できる可能性が 最も高い文字で構成されるべきである。 o URI は人が覚えなければならないことが多く、 意味のある、または馴染みのあるコンポーネントで構成される URI の方が、人にとって覚えやすい。 これらの設計上の考慮事項は、常に一致するとは限らない。 例えば、URI コンポーネントにとって最も意味のある名称には、 一部のシステムで入力できない文字が 必要になることがよくある。リソース識別子をある媒体から 別の媒体へ転記できることは、URI を 最も意味のあるコンポーネントで構成することよりも重要と考えられている。 ローカルまたは地域的な文脈において、技術の進歩に伴い、 より広い範囲の文字を使用できることがユーザーに有益な場合がある。 そのような使用はこの仕様では定義しない。パーセントエンコードされた オクテット (セクション 2.1) は、この Berners-Lee, et al. 標準トラック [8ページ]
RFC 3986 URI 汎用構文 2005年1月 表現が、URI が参照されるスキームまたはプロトコル要素によって 許可されている場合、US-ASCII 符号化文字集合の範囲外の文字を URI 内で表現するために使用できる。そのような定義では、 URI のためにパーセントエンコードする前に、それらの文字を オクテットへマッピングするために使用する文字エンコーディングを 指定すべきである。 1.2.2. 識別と相互作用の分離 URI に関する一般的な誤解の 1 つは、 アクセス可能なリソースを参照するためだけに使用されるというものである。 URI 自体が提供するのは識別だけであり、 URI が存在するからといってリソースへのアクセスが保証されるわけでも、 暗示されるわけでもない。代わりに、URI 参照に関連付けられた あらゆる操作は、その URI が現れるプロトコル要素、データ形式の 属性、または自然言語テキストによって定義される。 URI が与えられた場合、システムはリソースに対して "access"、"update"、"replace"、"find attributes" などの語で 特徴付けられるさまざまな操作を試みる場合がある。 このような操作は、この仕様ではなく、URI を使用する プロトコルによって定義される。ただし、本仕様では URI に対する 一般的な操作を説明するため、いくつかの一般用語を使用する。 URI の "resolution" は、URI を参照解決するために必要な アクセス機構と適切なパラメーターを決定するプロセスであり、 この解決には複数回の反復が必要な場合がある。 そのアクセス機構を使用して URI のリソースに対して 動作を実行することを、URI を "dereference" すると呼ぶ。 情報検索システム内で URI が情報源を識別するために使用される場合、 URI の参照解決の最も一般的な形態は "retrieval" である。これは、URI を使用して、 それに関連付けられたリソースの表現を取得することである。 "representation" は、オクテット列と、 それらのオクテットを記述する表現メタデータからなり、 表現が生成された時点でのリソースの状態を記録したものである。 取得は、URI をキャッシュキーとして使用して ローカルにキャッシュされた表現を確認すること、 URI を解決して適切なアクセス機構（存在する場合）を決定すること、 および取得操作を適用するために URI を参照解決することを 含み得るプロセスによって実現される。 取得に使用されるプロトコルによっては、 リソースに関する追加情報（リソースメタデータ）や、 他のリソースとの関係が提供される場合もある。 情報検索システム内の URI 参照は、 遅延バインディングとなるよう設計されている。 アクセス結果は通常、実際にアクセスした時点で決定され、 時間の経過または相互作用の他の側面によって変化する場合がある。 これらの参照は将来使用するために作成される。 識別されているものは、過去に取得された特定の結果ではなく、 将来の結果について成立すると期待される何らかの特性である。 このような場合、URI が参照するリソースは、実際には時間を通じて 観察される特性の同一性であり、 Berners-Lee, et al. 標準トラック [9ページ]
RFC 3986 URI 汎用構文 2005年1月 リソース提供者による追加のコメントまたは主張によって 明確化される場合がある。 多くの URI スキームはプロトコルにちなんで命名されているが、 その URI を使用すれば、名称となっているプロトコルによって リソースへアクセスすることになるとは限らない。 URI は単に識別のためだけに使用されることも多い。 URI がリソースの表現を取得するために使用される場合であっても、 そのアクセスは、スキーム名に関連付けられたプロトコルとは 独立したゲートウェイ、プロキシ、キャッシュ、および名前解決 サービスを経由する場合がある。一部の URI の解決には、 複数のプロトコルを使用する必要がある場合もある （例えば、ローカルキャッシュ内に表現が見つからない場合、 "http" URI のオリジンサーバーへのアクセスには通常 DNS と HTTP の両方が使用される）。 1.2.3. 階層識別子 URI 構文は階層的に構成され、コンポーネントは左から右へ 重要度が低下する順序で並ぶ。一部の URI スキームでは、見える階層はスキーム自体に限定される。 スキームコンポーネントの区切り文字 (":") より後のすべては、 URI 処理にとって不透明とみなされる。その他の URI スキームは、 階層を汎用解析アルゴリズムに対して 明示的かつ可視にする。 汎用構文は、スラッシュ ("/")、疑問符 ("?")、および 番号記号 ("#") を使用して、識別子に対する 汎用パーサーの階層的解釈に重要なコンポーネントを区切る。 馴染みのある構文を一貫して使用することで、 このような識別子の可読性を高めるだけでなく、 命名スキーム間で階層を統一的に表現することにより、 スキーム非依存の参照をその階層に対して相対的に行える。 共通の目的を果たすために文書のグループまたは「ツリー」が 構築され、その文書内の URI 参照の大部分が ツリーの外部ではなく内部のリソースを指すことはよくある。 同様に、特定のサイトに配置された文書は、遠隔サイトのリソースより 同じサイトの他のリソースを参照する可能性がはるかに高い。 URI の相対参照により、文書ツリーはその場所 およびアクセススキームから部分的に独立できる。例えば、 文書同士が相対参照を使用して参照し合う場合、単一の ハイパーテキスト文書集合を "file"、"http"、"ftp" の 各スキームから同時にアクセスし、たどることが可能である。 さらに、このような文書ツリーは、相対参照を一切変更せずに 全体として移動できる。 相対参照 (セクション 4.2) は、参照の文脈と 対象 URI の間にある階層名前空間内の差分を記述することで リソースを参照する。参照解決アルゴリズム、 Berners-Lee, et al. 標準トラック [10ページ]
RFC 3986 URI 汎用構文 2005年1月 セクション 5 で提示されるアルゴリズムは、そのような参照を 対象 URI へ変換する方法を定義する。相対参照は 階層 URI の文脈内でしか使用できないため、 新しい URI スキームの設計者は、そのスキーム内で 相対参照を禁止する説得力のある理由がない限り、 汎用構文の階層コンポーネントと整合する構文を使用すべきである。 注記: 以前の仕様では、URI への相対参照を示すために "partial URI" および "relative URI" という用語を使用していた。 一部の読者が、それらの用語を URI を参照する方法ではなく、 相対 URI が URI の部分集合であるという意味に誤解したため、 この仕様では単に相対参照と呼ぶ。 すべての URI 参照は、使用時に汎用構文パーサーによって解析される。 ただし、参照で使用される絶対 URI に 1 つ以上の ドットセグメント（セクション 3.3 で説明される "." または ".." からなる完全なパスセグメント）が 含まれない限り、階層処理は絶対 URI に影響しないため、 URI スキーム仕様は、スラッシュ文字、疑問符文字、 および URI "scheme:." と "scheme:.." の使用を禁止することで、 不透明な識別子を定義できる。 1.3. 構文表記 この仕様では [RFC2234] の Augmented Backus-Naur Form (ABNF) 記法を使用し、その仕様で定義される次のコア ABNF 構文規則を含む: ALPHA（文字）、CR（復帰）、 DIGIT（10 進数字）、DQUOTE（二重引用符）、HEXDIG（16 進 数字）、LF（改行）、SP（空白）。完全な URI 構文は 付録 A にまとめられている。 2. 文字 URI 構文は、おそらくリソースを識別するために、 データを文字列としてエンコードする方法を提供する。 URI の文字はさらに、伝送または表示のために オクテットとしてエンコードされることが多い。この仕様は、 URI の文字と、それらの文字を保存または伝送するために使用される オクテットとの間をマッピングする特定の文字エンコーディングを 義務付けない。URI がプロトコル要素内に現れる場合、 文字エンコーディングはそのプロトコルによって定義される。 そのような定義がない場合、URI は周囲のテキストと同じ 文字エンコーディングであるとみなされる。 ABNF 記法は、その終端値を US-ASCII 符号化文字集合 [ASCII] に基づく非負整数（コードポイント）として定義する。 URI は文字列であるため、URI 構文を理解するには その関係を逆にする必要がある。したがって、 Berners-Lee, et al. 標準トラック [11ページ]
RFC 3986 URI 汎用構文 2005年1月 ABNF が使用する整数値は、構文規則を完成させるために、 US-ASCII を介して対応する文字へ 再びマッピングしなければならない。 URI は、数字、文字、および少数の図形記号からなる 限定された文字集合から構成される。それらの文字の 予約された部分集合は URI 内の構文コンポーネントを区切るために 使用される場合があり、残りの文字、すなわち非予約集合と、 区切り文字として機能しない予約文字の両方が、 各コンポーネントの識別データを定義する。 2.1. パーセントエンコーディング パーセントエンコーディング機構は、あるオクテットに対応する文字が 許可された集合の外にある場合、またはコンポーネントの区切り文字、 あるいはコンポーネント内の区切り文字として使用される場合に、 そのデータオクテットをコンポーネント内で表現するために使用される。 パーセントエンコードされたオクテットは、 パーセント文字 "%" の後に、そのオクテットの数値を表す 2 桁の 16 進数字を続けた 3 文字としてエンコードされる。 例えば "%20" は、US-ASCII で空白文字 (SP) に対応する バイナリオクテット "00100000" (ABNF: %x20) の パーセントエンコーディングである。セクション 2.4 では、 パーセントエンコーディングおよびデコードが適用される時点を説明する。 pct-encoded = "%" HEXDIG HEXDIG 大文字の 16 進数字 'A' から 'F' は、それぞれ 小文字の 'a' から 'f' と同等である。2 つの URI が、 パーセントエンコードされたオクテットで使用される 16 進数字の 大文字小文字だけが異なる場合、それらは同等である。 一貫性のため、URI 生成者および正規化処理は、 すべてのパーセントエンコーディングで大文字の 16 進数字を使用すべきである。 2.2. 予約文字 URI には、"reserved" 集合の文字によって区切られる コンポーネントおよびサブコンポーネントが含まれる。 これらの文字が "reserved" と呼ばれるのは、 汎用構文、各スキーム固有の構文、または URI の参照解決アルゴリズムの実装固有構文によって、 区切り文字として定義される場合も、されない場合もあるためである。 URI コンポーネントのデータが予約文字の 区切り文字としての目的と競合する場合、その競合するデータは URI を形成する前にパーセントエンコードしなければならない。 Berners-Lee, et al. 標準トラック [12ページ]
RFC 3986 URI 汎用構文 2005年1月 reserved = gen-delims / sub-delims gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@" sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" 予約文字の目的は、URI 内の他のデータと区別できる 区切り文字の集合を提供することである。 予約文字を対応するパーセントエンコードされたオクテットに 置き換えた点だけが異なる URI は同等ではない。 予約文字をパーセントエンコードしたり、 予約文字に対応するパーセントエンコードされたオクテットを デコードしたりすると、大部分のアプリケーションによる URI の解釈が変化する。したがって、予約集合内の文字は 正規化から保護されており、URI 内のデータサブコンポーネントを 区切るため、スキーム固有および生成者固有のアルゴリズムで 安全に使用できる。 予約文字の部分集合 (gen-delims) は、セクション 3 で説明する 汎用 URI コンポーネントの区切り文字として使用される。 コンポーネントの ABNF 構文規則は、reserved または gen-delims の 規則名を直接使用しない。代わりに各構文規則は、 そのコンポーネント内で許可される文字 （すなわち、それを区切らない文字）を列挙し、 そのうち予約集合にも属する文字は、 コンポーネント内でサブコンポーネントの区切り文字として使用するために "reserved" となる。この仕様で定義するのは最も一般的な サブコンポーネントだけであり、その他のサブコンポーネントは、 URI スキームの仕様または URI の参照解決アルゴリズムの 実装固有構文によって定義してもよい。ただし、そのような サブコンポーネントは、そのコンポーネント内で許可される 予約集合の文字によって区切られなければならない。 URI 生成アプリケーションは、予約集合の文字に対応する データオクテットを、その URI スキームがそのコンポーネント内の データを表現するためにその文字を明示的に許可していない限り、 パーセントエンコードすべきである。URI コンポーネント内で 予約文字が見つかり、その文字に既知の区切り役割がない場合、 その文字の US-ASCII エンコーディングに対応する データオクテットを表すものとして解釈しなければならない。 2.3. 非予約文字 URI 内で許可されるが予約された目的を持たない文字は、 非予約文字と呼ばれる。これには大文字と小文字、 10 進数字、ハイフン、ピリオド、アンダースコア、チルダが含まれる。 unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" Berners-Lee, et al. 標準トラック [13ページ]
RFC 3986 URI 汎用構文 2005年1月 非予約文字を対応するパーセントエンコード済み US-ASCII オクテットに 置き換えた点だけが異なる URI は同等であり、 同じリソースを識別する。ただし、URI 比較の実装は、 比較前に常に正規化を行うとは限らない（セクション 6 を参照）。一貫性のため、ALPHA (%41-%5A および %61-%7A)、DIGIT (%30-%39)、ハイフン (%2D)、 ピリオド (%2E)、アンダースコア (%5F)、またはチルダ (%7E) の 範囲にあるパーセントエンコード済みオクテットを URI 生成者は生成すべきではなく、URI 内で見つかった場合、 URI 正規化処理は対応する非予約文字へデコードすべきである。 2.4. エンコードまたはデコードする時点 通常の状況では、URI 内のオクテットが パーセントエンコードされるのは、URI をそのコンポーネント部分から 生成する過程だけである。この時点で実装は、 どの予約文字をサブコンポーネントの区切り文字として使用し、 どれをデータとして安全に使用できるかを決定する。 一度生成された URI は、常にパーセントエンコードされた形式である。 URI を参照解決する場合、スキーム固有の参照解決プロセスに 重要なコンポーネントおよびサブコンポーネント（存在する場合）は、 それらのコンポーネント内のパーセントエンコードされたオクテットを 安全にデコードする前に、解析して分離しなければならない。 そうしなければ、データがコンポーネント区切り文字と誤認される可能性がある。 唯一の例外は、非予約集合内の文字に対応する パーセントエンコード済みオクテットであり、これはいつでもデコードできる。 例えば、チルダ ("~") に対応するオクテットは、 古い URI 処理実装では "%7E" としてエンコードされることが多いが、 "%7E" は解釈を変えずに "~" へ置き換えることができる。 パーセント ("%") 文字はパーセントエンコード済みオクテットの 指示子として機能するため、そのオクテットを URI 内のデータとして 使用するには "%25" としてパーセントエンコードしなければならない。 実装は同じ文字列を複数回パーセントエンコードまたは デコードしてはならない。すでにデコードされた文字列をデコードすると、 パーセントデータオクテットをパーセントエンコーディングの 開始と誤認する可能性があり、逆にすでにパーセントエンコードされた 文字列を再度パーセントエンコードした場合も同様である。 2.5. 識別データ URI 文字は、URI の各コンポーネントに識別データを提供し、 システム間での識別のための外部インターフェイスとして機能する。 URI 生成インターフェイスの存在と性質は、それによって生成された URI を 使用するクライアントからは隠されている （したがって、この仕様で定義する相互運用性要件の範囲外である）が、 URI の文字に関する問題を解釈する際の混乱および誤りの 頻繁な原因となる。実装者は、URI の Berners-Lee, et al. 標準トラック [14ページ]
RFC 3986 URI 汎用構文 2005年1月 生成および伝送には複数の文字エンコーディング、 すなわちローカル名およびデータのエンコーディング、 公開インターフェイスのエンコーディング、URI 文字エンコーディング、 データ形式エンコーディング、およびプロトコルエンコーディングが 関与することを認識する必要がある。 ファイルシステム名などのローカル名は、ローカルな 文字エンコーディングで保存される。URI 生成アプリケーション （例えばオリジンサーバー）は通常、意味のある名称を生成する基礎として ローカルエンコーディングを使用する。URI 生成者は ローカルエンコーディングを公開インターフェイスに適したものへ変換し、 次に公開インターフェイスのエンコーディングを、制限された URI 文字集合（予約文字、非予約文字、およびパーセントエンコーディング）へ 変換する。それらの文字はさらに、データ形式 （例えば文書の charset）内で参照として使用するために オクテットとしてエンコードされ、このようなデータ形式はその後、 インターネットプロトコルによる伝送のためにエンコードされることが多い。 大部分のシステムでは、URI コンポーネント内に現れる非予約文字は、 その文字の US-ASCII エンコーディングに対応するデータオクテットを 表すものとして解釈される。URI の利用者は、 文字 "X" がオクテット "01011000" に対応すると仮定し、 その仮定が誤っている場合でも、それによる害はない。 EBCDIC など、異なる文字エンコーディング形式で 識別子を内部的に提供するシステムは、通常、 内部インターフェイスでテキスト識別子を UTF-8 [STD63] （または US-ASCII 文字エンコーディングの別の上位集合）へ 文字変換し、元のオクテットを単純に パーセントエンコードした場合より意味のある識別子を提供する。 例えば、EBCDIC ベースのファイルシステムを使用して ローカルに保存されたデータを、HTTP サーバーを介して インターネット上のクライアントへ提供する情報サービスを考える。 著者がそのファイルシステム上に "Laguna Beach" という名前の ファイルを作成した場合、そのリソースに対応する "http" URI には 意味のある文字列 "Laguna%20Beach" が含まれることが期待される。 しかし、そのサーバーが過度に単純な生のオクテットマッピングを使用して URI を生成した場合、結果は "%D3%81%87%A4%95%81@%C2%85%81%83%88" を含む URI となる。 内部トランスコーディングインターフェイスは、URI を生成する前に ローカル名を US-ASCII の上位集合へトランスコードすることで この問題を解決する。当然ながら、このようなインターフェイスで 入力 URI を正しく解釈するには、ローカル名を得るための 逆トランスコーディングを適用する前に、 パーセントエンコード済みオクテットをデコード （例えば "%20" を SP へ）する必要がある。 場合によっては、URI コンポーネントと、それが表現するように 作られた識別データとの内部インターフェイスは、 文字エンコーディング変換ほど直接的ではない。 例えば、URI の一部が非 ASCII データに対するクエリや、数値の Berners-Lee, et al. 標準トラック [15ページ]
RFC 3986 URI 汎用構文 2005年1月 地図上の座標を反映する場合がある。同様に、URI スキームは、 コンポーネントを形成して URI を生成する前に適用される 追加のエンコーディング要件を持つコンポーネントを定義する場合がある。 新しい URI スキームが Universal Character Set [UCS] の 文字からなるテキストデータを表すコンポーネントを定義する場合、 そのデータはまず UTF-8 文字エンコーディング [STD63] に従って オクテットとしてエンコードし、その後、 非予約集合の文字に対応しないオクテットだけを パーセントエンコードすべきである。例えば、文字 A は "A"、 LATIN CAPITAL LETTER A WITH GRAVE は "%C3%80"、 KATAKANA LETTER A は "%E3%82%A2" として表現される。 3. 構文コンポーネント URI の汎用構文は、scheme、authority、path、query、 fragment と呼ばれるコンポーネントの階層的な並びから構成される。 URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] hier-part = "//" authority path-abempty / path-absolute / path-rootless / path-empty scheme と path コンポーネントは必須だが、 path は空（文字なし）でもよい。authority が存在する場合、 path は空であるか、スラッシュ ("/") 文字で始まらなければならない。 authority が存在しない場合、path は 2 つのスラッシュ ("//") で始めることはできない。これらの制限により、 path には 5 つの異なる ABNF 規則 (セクション 3.3) が存在し、 特定の URI 参照に一致するのはそのうち 1 つだけである。 次に、2 つの URI の例と、そのコンポーネント部分を示す: foo://example.com:8042/over/there?name=ferret#nose \_/ \______________/\_________/ \_________/ \__/ | | | | | scheme authority path query fragment | _____________________|__ / \ / \ urn:example:animal:ferret:nose Berners-Lee, et al. 標準トラック [16ページ]
RFC 3986 URI 汎用構文 2005年1月 3.1. スキーム 各 URI は、そのスキーム内で識別子を割り当てるための 仕様を参照するスキーム名で始まる。したがって、URI 構文は、 各スキームの仕様が、そのスキームを使用する識別子の 構文および意味論をさらに制限できる、 連合型かつ拡張可能な命名システムである。 スキーム名は、文字で始まり、その後に文字、数字、プラス ("+")、ピリオド (".")、またはハイフン ("-") の任意の組み合わせが続く 文字列から構成される。スキームでは大文字小文字を区別しないが、 正規形は小文字であり、スキームを規定する文書は 小文字で記述しなければならない。実装は堅牢性のため、 スキーム名で大文字を小文字と同等として受け入れるべきである （例えば "http" と同様に "HTTP" も許可する）が、 一貫性のため、生成するスキーム名は小文字だけにすべきである。 scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) 個々のスキームはこの文書では規定しない。 新しい URI スキームの登録プロセスは [BCP35] で別途定義される。 スキームレジストリは、スキーム名とその仕様との マッピングを維持する。新しい URI スキームの設計者向けの助言は [RFC2718] にある。URI スキーム仕様は、 そのスキーム固有の構文に一致するすべての文字列が、 セクション 4.3 で説明される <absolute-URI> 文法にも 一致するよう、独自の構文を定義しなければならない。 1 つ以上のスキーム固有の制限に違反する URI が提示された場合、 スキーム固有の解決プロセスは、使用されていない部分を無視するのではなく、 その参照をエラーとして示すべきである。そうすることで 同等な URI の数が減少し、URI がユーザーを誤認させるように 構築された可能性を示す汎用構文の悪用を 検出しやすくなる (セクション 7.6)。 3.2. オーソリティ 多くの URI スキームには、命名 オーソリティのための階層要素が含まれ、 URI の残りの部分によって定義される名前空間の管理を そのオーソリティに委任できる （さらに別の主体へ委任する場合もある）。 汎用構文は、登録名またはサーバーアドレスに基づく オーソリティを、任意のポートおよびユーザー情報とともに 区別する共通手段を提供する。 authority コンポーネントの前には二重スラッシュ ("//") があり、 次のスラッシュ ("/")、疑問符 ("?")、番号 記号 ("#")、または URI の末尾で終了する。 Berners-Lee, et al. 標準トラック [17ページ]
RFC 3986 URI 汎用構文 2005年1月 authority = [ userinfo "@" ] host [ ":" port ] URI 生成者および正規化処理は、port コンポーネントが空の場合、 host と port を分離する ":" 区切り文字を省略すべきである。 一部のスキームは userinfo および／または port サブコンポーネントを許可しない。 URI に authority コンポーネントが含まれる場合、 path コンポーネントは空であるか、 スラッシュ ("/") 文字で始まらなければならない。 非検証パーサー（URI 参照を主要コンポーネントへ分離するだけのもの）は、 URI が参照解決されるまで、authority のサブコンポーネント構造を 無視し、二重スラッシュから最初の終端区切り文字までを 不透明な文字列として扱うことが多い。 3.2.1. ユーザー情報 userinfo サブコンポーネントは、ユーザー名と、任意で リソースへのアクセス認可を得る方法に関する スキーム固有情報から構成される場合がある。 ユーザー情報が存在する場合、その後には host から区切る アットマーク ("@") が続く。 userinfo = *( unreserved / pct-encoded / sub-delims / ":" ) userinfo フィールドで "user:password" 形式を使用することは 非推奨である。アプリケーションは、userinfo サブコンポーネント内で見つかった最初のコロン (":") より後のデータを、 コロンより後のデータが空文字列 （パスワードがないことを示す）でない限り、 平文として表示すべきではない。 アプリケーションは、そのようなデータを参照の一部として受信した場合、 無視または拒否することを選択でき、 そのようなデータを暗号化されていない形式で保存することは 拒否すべきである。認証情報を平文で渡すことは、 使用されたほぼすべての場合でセキュリティリスクになることが 明らかになっている。 グラフィカルなハイパーテキスト閲覧など、 ユーザーへのフィードバックのため URI を表示するアプリケーションは、 可能であれば userinfo を URI の残りの部分と 区別できる方法で表示すべきである。このような表示は、 userinfo が信頼されたドメイン名のように見えるよう 誤解を招く形で作成されている場合にユーザーを支援する (セクション 7.6)。 3.2.2. ホスト authority の host サブコンポーネントは、 角括弧で囲まれた IP リテラル、 ドット付き 10 進形式の IPv4 アドレス、または登録名によって識別される。 host サブコンポーネントでは大文字小文字を区別しない。 URI 内に host サブコンポーネントが存在するからといって、 そのスキームがインターネット上の指定された host へのアクセスを 必要とすることを意味しない。多くの場合、host 構文は単に Berners-Lee, et al. 標準トラック [18ページ]
RFC 3986 URI 汎用構文 2005年1月 DNS のために作成され配備済みの既存の登録プロセスを 再利用するために使用され、それにより別のレジストリを 配備するコストなしにグローバルに一意な名前を得る。 ただし、そのような使用には固有のコストもある。 ドメイン名の所有権は、URI 生成者が予期しない理由によって 時間とともに変化する可能性がある。その他の場合、 host コンポーネント内のデータは、インターネットホストとは 無関係な登録名を識別する。ABNF 規則に "host" という名前を 使用するのは、それが唯一の目的だからではなく、 最も一般的な目的だからである。 host = IP-literal / IPv4address / reg-name host の構文規則は、IPv4address と reg-name を完全には 区別しないため曖昧である。構文の曖昧さを解消するため、 "first-match-wins" アルゴリズムを適用する。 host が IPv4address の規則に一致する場合、 reg-name ではなく IPv4 アドレスリテラルとみなすべきである。 host では大文字小文字を区別しないが、一貫性のため、 生成者および正規化処理は登録名および 16 進アドレスには 小文字を使用し、パーセントエンコーディングだけに 大文字を使用すべきである。 Internet Protocol のリテラルアドレス、バージョン 6 [RFC3513] 以降で識別される host は、 IP リテラルを角括弧 ("[" と "]") で囲むことで区別される。 URI 構文内で角括弧文字が許可されるのはここだけである。 将来の、まだ定義されていない IP リテラルアドレス形式を想定し、 実装はヒューリスティックな判定に依存する代わりに、 任意のバージョンフラグを使用してそのような 形式を明示的に示してもよい。 IP-literal = "[" ( IPv6address / IPvFuture ) "]" IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" ) バージョンフラグは IP バージョンを示すものではなく、 リテラル形式の将来のバージョンを示す。 したがって、実装は以下で説明する既存の IPv4 および IPv6 リテラルアドレス形式に バージョンフラグを付けてはならない。 "v"（大文字小文字を区別しない）で始まる IP-literal を含む URI、 すなわちバージョンフラグが存在することを示す URI が、 そのバージョンフラグの意味を知らないアプリケーションによって 参照解決された場合、アプリケーションは 「アドレス機構がサポートされていない」ことを示す適切な エラーを返すべきである。 IPv6 リテラルアドレスによって識別される host は、 先行するバージョンフラグなしで角括弧内に表現される。 ここで示す ABNF は、[RFC3513] で提供される IPv6 リテラルアドレスのテキスト定義を変換したものである。 この構文は IPv6 スコープ付きアドレスのゾーン識別子をサポートしない。 Berners-Lee, et al. 標準トラック [19ページ]
RFC 3986 URI 汎用構文 2005年1月 128 ビットの IPv6 アドレスは、8 つの 16 ビット部分に分割される。 各部分は、大文字小文字を区別しない 16 進数で、 1 桁から 4 桁の 16 進数字を使用して数値表現される （先頭のゼロは許可される）。 エンコードされた 8 つの部分は最上位から順に、 コロン文字で区切って記述される。任意で、最下位の 2 つの部分を IPv4 アドレスのテキスト形式で表現してもよい。 アドレス内の 1 つ以上連続する値 0 の 16 ビット部分は 省略でき、そのすべての数字を省略し、 省略箇所を示すためにちょうど 2 つの連続するコロンを残す。 IPv6address = 6( h16 ":" ) ls32 / "::" 5( h16 ":" ) ls32 / [ h16 ] "::" 4( h16 ":" ) ls32 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 / [ *4( h16 ":" ) h16 ] "::" ls32 / [ *5( h16 ":" ) h16 ] "::" h16 / [ *6( h16 ":" ) h16 ] "::" ls32 = ( h16 ":" h16 ) / IPv4address ; アドレスの最下位 32 ビット h16 = 1*4HEXDIG ; 16 進数で表現されたアドレスの 16 ビット IPv4 リテラルアドレスで識別される host は、 [RFC1123] から [RFC0952] を参照して説明されるように、 ドット付き 10 進表記（0 から 255 の範囲の 4 つの 10 進数を "." で区切った列）で表現される。 セクション 7.4 で説明するように、 一部のプラットフォームでは他のドット表記形式も解釈される場合があるが、 この文法で許可されるのは 4 オクテットの ドット付き 10 進形式だけである。 IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet dec-octet = DIGIT ; 0-9 / %x31-39 DIGIT ; 10-99 / "1" 2DIGIT ; 100-199 / "2" %x30-34 DIGIT ; 200-249 / "25" %x30-35 ; 250-255 登録名で識別される host は、 通常、ローカルに定義された host またはサービス名レジストリで 検索されることを意図した文字列であるが、 URI のスキーム固有の意味論では、特定のレジストリ （または固定された名前テーブル）の使用が必要な場合もある。 最も一般的な名前レジストリ機構は Domain Name System (DNS) である。 DNS で検索することを意図した登録名は、 Berners-Lee, et al. 標準トラック [20ページ]
RFC 3986 URI 汎用構文 2005年1月 [RFC1034] のセクション 3.5 および [RFC1123] のセクション 2.1 で 定義される構文を使用する。このような名前は "." で区切られた ドメインラベル列で構成され、各ドメインラベルは英数字で始まり 英数字で終わり、"-" 文字を含む場合もある。 DNS の完全修飾ドメイン名の最右端のドメイン ラベルの後には単一の "." を続けてもよく、 完全なドメイン名とローカルドメインを区別する必要がある場合には そうすべきである。 reg-name = *( unreserved / pct-encoded / sub-delims ) URI スキームが host の既定値を定義している場合、 host サブコンポーネントが未定義であるか、 登録名が空（長さ 0）の場合にその既定値が適用される。 例えば "file" URI スキームでは、authority がない場合、 host が空の場合、"localhost" のいずれもエンドユーザーの マシンを意味するよう定義されている一方、"http" スキームでは authority の欠如または空の host は無効とみなされる。 この仕様は特定の登録名検索技術を義務付けず、 したがって、相互運用性に必要な範囲を超えて reg-name の構文を制限しない。代わりに、 登録名の構文準拠の問題は、URI 解決を行う各アプリケーションの オペレーティングシステムに委ねられ、 そのオペレーティングシステムが host 識別のために何を 許可するかを決定する。URI 解決実装は、登録名を検索するために DNS、host テーブル、yellow pages、NetInfo、WINS、 またはその他のシステムを使用する場合がある。 ただし、グローバルスコープを持つことを意図する URI には、 DNS の完全修飾ドメイン名など、 グローバルスコープを持つ命名システムが必要である。 URI 生成者は、DNS の使用がすぐに明らかでない場合でも、 DNS 構文に準拠する名前を使用すべきであり、 その名前の長さを 255 文字以下に制限すべきである。 reg-name 構文では、基盤となる名前解決技術に依存せず、 非 ASCII 登録名を統一的に表現するために パーセントエンコード済みオクテットを許可する。 非 ASCII 文字は、まず UTF-8 [STD63] に従ってエンコードし、 次に対応する UTF-8 シーケンスの各オクテットを URI 文字として表現するためにパーセントエンコードしなければならない。 URI 生成アプリケーションは、UTF-8 文字列を表現する場合を除き、 host 内でパーセントエンコーディングを使用してはならない。 非 ASCII 登録名が DNS によって解決されることを意図した 国際化ドメイン名を表す場合、名前検索前に IDNA エンコーディング [RFC3490] へ変換しなければならない。 URI 生成者が旧来の URI リゾルバーとの相互運用性を 最大化したい場合、これらの登録名をパーセントエンコーディングではなく IDNA エンコーディングで提供すべきである。 Berners-Lee, et al. 標準トラック [21ページ]
RFC 3986 URI 汎用構文 2005年1月 3.2.3. ポート authority の port サブコンポーネントは、 host の後に続く任意の 10 進ポート番号で示され、 host とは単一のコロン (":") 文字で区切られる。 port = *DIGIT スキームは既定ポートを定義してもよい。例えば "http" スキームは、 予約済み TCP ポート番号に対応する既定ポート "80" を 定義している。ポート番号によって指定されるポートの種類 （例えば TCP、UDP、SCTP）は URI スキームによって定義される。 URI 生成者および正規化処理は、port が空である場合、 またはその値がスキームの既定値と同じ場合、 port コンポーネントと ":" 区切り文字を省略すべきである。 3.3. パス path コンポーネントには、通常は階層形式で構成されるデータが含まれ、 非階層的な query コンポーネント (セクション 3.4) のデータとともに、 URI のスキームおよび命名オーソリティ（存在する場合）の範囲内で リソースを識別するために使用される。path は、 最初の疑問符 ("?")、番号記号 ("#")、 または URI の末尾で終了する。 URI に authority コンポーネントが含まれる場合、 path コンポーネントは空であるか、 スラッシュ ("/") 文字で始まらなければならない。 URI に authority コンポーネントが含まれない場合、 path は 2 つのスラッシュ ("//") で始めることはできない。 さらに、URI 参照 (セクション 4.1) は相対パス参照の場合があり、 その場合、最初の path セグメントにはコロン (":") 文字を 含めることができない。ABNF はこれらのケースを曖昧さなく区別するために 5 つの別個の規則を必要とし、特定の URI 参照内の path 部分文字列に一致するのはそのうち 1 つだけである。 パーサーがこれらの規則の 1 つに一致させた URI 部分文字列を説明するため、 一般用語 "path component" を使用する。 path = path-abempty ; "/" で始まるか、空である / path-absolute ; "/" で始まるが "//" ではない / path-noscheme ; コロンを含まないセグメントで始まる / path-rootless ; セグメントで始まる / path-empty ; 文字数ゼロ path-abempty = *( "/" segment ) path-absolute = "/" [ segment-nz *( "/" segment ) ] path-noscheme = segment-nz-nc *( "/" segment ) path-rootless = segment-nz *( "/" segment ) path-empty = 0<pchar> Berners-Lee, et al. 標準トラック [22ページ]
RFC 3986 URI 汎用構文 2005年1月 segment = *pchar segment-nz = 1*pchar segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" ) ; コロン ":" を含まない長さがゼロでないセグメント pchar = unreserved / pct-encoded / sub-delims / ":" / "@" path は、スラッシュ ("/") 文字で区切られた path セグメントの列から構成される。URI には常に path が定義されるが、 定義された path は空（長さ 0）の場合もある。 階層を示すためにスラッシュ文字を使用することが必要なのは、 URI が相対参照の文脈として使用される場合だけである。 例えば、URI <mailto:fred@example.com> の path は "fred@example.com" である一方、 URI <foo://info.example.com?fred> の path は空である。 path セグメント "." および ".." はドットセグメントとも呼ばれ、 path 名の階層内での相対参照のために定義される。 これらは相対パス参照 (セクション 4.2) の先頭で使用し、 名前の階層ツリー内の相対位置を示すことを意図している。 これは、一部のオペレーティングシステムの ファイルディレクトリ構造において、それぞれ現在のディレクトリと 親ディレクトリを示す役割に似ている。 ただしファイルシステムとは異なり、これらのドットセグメントは URI path 階層内でのみ解釈され、解決プロセス (セクション 5.2) の一部として除去される。 階層 path 内のドットセグメントを除き、 path セグメントは汎用構文から不透明なものとみなされる。 URI 生成アプリケーションは、セグメント内で許可される予約文字を 使用して、スキーム固有または参照解決ハンドラー固有の サブコンポーネントを区切ることが多い。 例えば、セミコロン (";") と等号 ("=") の予約文字は、 そのセグメントに適用されるパラメーターおよびパラメーター値を 区切るためによく使用される。カンマ (",") の予約文字も 同様の目的でよく使用される。例えば、ある URI 生成者は "name" のバージョン 1.1 への参照を示すため "name;v=1.1" のようなセグメントを使用し、 別の生成者は同じことを示すために "name,1.1" のようなセグメントを使用する場合がある。 パラメーターの種類はスキーム固有の意味論によって定義される場合があるが、 多くの場合、パラメーターの構文は URI の参照解決アルゴリズムの 実装に固有である。 3.4. クエリ query コンポーネントには非階層的データが含まれ、 path コンポーネント (セクション 3.3) のデータとともに、 URI のスキームおよび命名オーソリティ（存在する場合）の範囲内で リソースを識別するために使用される。 query コンポーネントは最初の疑問符 ("?") 文字によって示され、 番号記号 ("#") 文字または URI の末尾で終了する。 Berners-Lee, et al. 標準トラック [23ページ]
RFC 3986 URI 汎用構文 2005年1月 query = *( pchar / "/" / "?" ) スラッシュ ("/") と疑問符 ("?") は、 query コンポーネント内でデータを表す場合がある。 一部の古く誤った実装では、このようなデータが 相対参照の基底 URI (セクション 5.1) として使用された場合、 正しく処理できない場合があることに注意されたい。 これは、階層区切り文字を探す際に query データと path データを 区別できないことが原因と考えられる。 ただし、query コンポーネントは "key=value" ペア形式の 識別情報を伝えるためによく使用され、頻繁に使用される値の 1 つが 別の URI への参照であるため、使いやすさの観点から これらの文字をパーセントエンコードしない方がよい場合がある。 3.5. フラグメント URI のフラグメント識別子コンポーネントにより、 一次リソースと追加の識別情報を参照することで 二次リソースを間接的に識別できる。 識別される二次リソースは、一次リソースの一部または部分集合、 一次リソースの表現に対する何らかのビュー、 またはそれらの表現によって定義または記述される別のリソースの場合がある。 フラグメント識別子コンポーネントは、番号記号 ("#") 文字の 存在によって示され、URI の末尾で終了する。 fragment = *( pchar / "/" / "?" ) フラグメント識別子の意味論は、 一次リソースに対する取得操作によって得られる可能性のある 表現集合によって定義される。したがって、フラグメントの形式および解決は、 取得される可能性のある表現のメディアタイプ [RFC2046] に依存する。 ただし、そのような取得が実際に行われるのは URI が参照解決される場合だけである。 そのような表現が存在しない場合、フラグメントの意味論は 不明とみなされ、実質的に制約されない。 フラグメント識別子の意味論は URI スキームから独立しているため、 スキーム仕様によって再定義することはできない。 個々のメディアタイプは、そのメディアタイプによって 二次リソースとして識別可能な異なる種類の部分集合、ビュー、 または外部参照を指定するために、 フラグメント識別子構文に独自の制限または構造を定義してもよい。 一次リソースに複数の表現がある場合、 これは取得要求の属性に基づいて表現が選択されるリソース （いわゆるコンテンツネゴシエーション）ではよくあるが、 フラグメントによって識別されるものは、 それらすべての表現で一貫しているべきである。 各表現は、どのように表現されるかにかかわらず 同じ二次リソースに対応するようフラグメントを定義するか、 またはフラグメントを未定義（すなわち見つからない）として 残すべきである。 Berners-Lee, et al. 標準トラック [24ページ]
RFC 3986 URI 汎用構文 2005年1月 他の URI と同様に、フラグメント識別子コンポーネントを使用しても、 取得操作が行われることを意味しない。 フラグメント識別子を持つ URI は、 一次リソースがアクセス可能である、または将来アクセスされるという 意味を伴わずに、二次リソースを参照するために使用できる。 フラグメント識別子は、情報検索システムにおいて、 クライアント側の間接参照の主要な形態として特別な役割を持ち、 著者が、リソース所有者からは間接的にしか提供されない 既存リソースの側面を具体的に識別できる。 そのため、フラグメント識別子は URI のスキーム固有処理には 使用されない。代わりに、フラグメント識別子は参照解決前に URI の残りの部分から分離されるため、 フラグメント自体の識別情報は URI スキームにかかわらず ユーザーエージェントだけによって参照解決される。 この分離処理は、特にリソースが時間とともに移動する場合の 参照の正確なリダイレクトにおいて、情報の損失と みなされることが多いが、同時に情報提供者が 参照の著者に対し、リソース内の情報を選択的に参照する権利を 拒否することを防ぐ役割も果たす。 間接参照はまた、新しい識別スキームよりも新しいメディアタイプの方が 定義および配備しやすいため、URI を使用するシステムに 追加の柔軟性と拡張性を提供する。 スラッシュ ("/") と疑問符 ("?") は、 フラグメント識別子内でデータを表すことが許可される。 一部の古く誤った実装では、このデータが 相対参照の基底 URI (セクション 5.1) として使用された場合、正しく処理できないことがあるので注意されたい。 4. 使用法 アプリケーションが URI を参照する場合、 "URI" 構文規則で定義される完全な参照形式を常に使用するとは限らない。 空間を節約し、階層的な局所性を利用するため、 多くのインターネットプロトコル要素およびメディアタイプ形式では URI の省略形を許可する一方、 その他は構文を特定の URI 形式に制限する。 最も一般的な参照構文形式は汎用構文の設計に影響し、 またそれに依存し、一貫した解釈には統一された解析アルゴリズムが 必要となるため、この仕様でそれらを定義する。 4.1. URI 参照 URI-reference は、リソース識別子の最も一般的な 使用法を示すために使用される。 URI-reference = URI / relative-ref Berners-Lee, et al. 標準トラック [25ページ]
RFC 3986 URI 汎用構文 2005年1月 URI-reference は URI または相対参照のいずれかである。 URI-reference のプレフィックスが、スキームの後に コロン区切り文字が続く構文と一致しない場合、 URI-reference は相対参照である。 URI-reference は通常、まず 5 つの URI コンポーネントへ解析され、 どのコンポーネントが存在するか、 および参照が相対的かどうかが判断される。 次に、各コンポーネントがその下位部分へ解析され、 それらが検証される。URI-reference の ABNF は、 "first-match-wins" の曖昧さ解消規則と合わせて、 汎用構文の検証パーサーを定義するのに十分である。 正規表現に詳しい読者は、任意の文字列から URI コンポーネントを抽出する非検証 URI-reference パーサーの 例について 付録 B を参照されたい。 4.2. 相対参照 相対参照は階層構文 (セクション 1.2.3) を利用して、 別の階層 URI の名前空間に対して相対的な URI 参照を表現する。 relative-ref = relative-part [ "?" query ] [ "#" fragment ] relative-part = "//" authority path-abempty / path-absolute / path-noscheme / path-empty 相対参照によって参照される URI は対象 URI とも呼ばれ、 セクション 5 の参照解決アルゴリズムを適用することで得られる。 2 つのスラッシュ文字で始まる相対参照を network-path 参照と呼ぶ。このような参照はまれにしか使用されない。 1 つのスラッシュ文字で始まる相対参照を absolute-path 参照と呼ぶ。スラッシュ文字で始まらない 相対参照を relative-path 参照と呼ぶ。 コロン文字を含む path セグメント（例えば "this:that"）は、 スキーム名と誤認されるため、 relative-path 参照の最初のセグメントとして使用できない。 このようなセグメントは、相対 path 参照にするため、 ドットセグメント（例えば "https://www.rfc-editor.org/rfc/this:that"）を 前置しなければならない。 Berners-Lee, et al. 標準トラック [26ページ]
RFC 3986 URI 汎用構文 2005年1月 4.3. 絶対 URI 一部のプロトコル要素では、フラグメント識別子を持たない URI の絶対形式だけを許可する。例えば、後で相対参照によって 使用する基底 URI を定義する場合、 フラグメントを許可しない absolute-URI 構文規則が必要になる。 absolute-URI = scheme ":" hier-part [ "?" query ] URI スキーム仕様は、スキーム固有の構文に一致する すべての文字列が <absolute-URI> 文法にも 一致するよう独自の構文を定義しなければならない。 フラグメント識別はスキーム定義と直交するため、 スキームによって識別可能なリソースへの適用可能性にかかわらず、 スキーム仕様はフラグメント識別子の構文または使用法を定義しない。 ただし、スキーム仕様には、 適切な場合にスキームの URI をフラグメント識別子とともに 使用する例を含め、広範な例を含めることが推奨される。 4.4. 同一文書参照 URI 参照が、そのフラグメントコンポーネント（存在する場合）を除き 基底 URI (セクション 5.1) と同一の URI を参照する場合、 その参照を "same-document" 参照と呼ぶ。 同一文書参照の最も一般的な例は、 空である相対参照、または番号記号 ("#") 区切り文字の後に フラグメント識別子だけが続く相対参照である。 同一文書参照が取得操作のために参照解決される場合、 その参照の対象は、その参照と同じエンティティ （表現、文書、またはメッセージ）内にあると定義される。 したがって、参照解決によって新しい取得操作が 発生すべきではない。 セクション 6.2.2 および 6.2.3 で説明するように、 比較前に基底 URI と対象 URI を正規化することは許可されるが、 実際にはめったに行われない。 正規化により同一文書参照の集合が増える可能性があり、 一部のキャッシュアプリケーションにとって有益な場合がある。 したがって、参照の著者は、わずかに異なるが同等な 参照 URI が、特定のアプリケーションによって 同一文書参照として解釈される（またはされない）と 仮定すべきではない。 4.5. サフィックス参照 URI 構文は、リソースへの曖昧さのない参照と、 URI スキームによる拡張性のために設計されている。 しかし、URI による識別および使用が一般化するにつれ、 従来型メディア（テレビ、ラジオ、新聞、看板など）は、 URI のサフィックスを参照として使用することが増えており、 Berners-Lee, et al. 標準トラック [27ページ]
RFC 3986 URI 汎用構文 2005年1月 これは URI の authority と path 部分だけから構成される。 例えば、 www.w3.org/Addressing/ または単独の DNS 登録名だけである。 このような参照は主として機械ではなく人間による解釈を 意図しており、文脈に基づくヒューリスティックで URI を 完成させるのに十分であると仮定されている （例えば、"www" で始まる登録名の大部分には "http://" という URI プレフィックスが付く可能性が高い）。 URI サフィックスの曖昧さを解消する標準的な ヒューリスティック集合は存在しないが、多くのクライアント実装では ユーザーがこれらを入力でき、ヒューリスティックに 解決できる。 このサフィックス参照を使用する慣行は一般的だが、 可能な限り避けるべきであり、長期的な参照が期待される 状況では決して使用すべきではない。 上記のヒューリスティックは、特に新しい URI スキームが 普及した場合に時間とともに変化し、 文脈外で使用すると誤ることが多い。 さらに、[RFC1535] で説明されるような セキュリティ問題につながる可能性がある。 URI サフィックスは relative-path 参照と同じ構文を持つため、 相対参照が期待される文脈では サフィックス参照を使用できない。その結果、 サフィックス参照は、ダイアログボックスや オフライン広告など、定義済みの基底 URI が存在しない 場所に限定される。 5. 参照解決 このセクションでは、相対参照を許可する文脈内で URI 参照を解決し、その結果が セクション 3 の <URI> 構文規則に一致する文字列となるようにする プロセスを定義する。 5.1. 基底 URI の確立 "relative" という用語は、相対参照を適用する対象となる "base URI" が存在することを意味する。 フラグメントだけの参照 (セクション 4.4) を除き、 相対参照は基底 URI が既知の場合にのみ使用できる。 相対的である可能性のある URI 参照を解析する前に、 パーサーは基底 URI を確立しなければならない。 基底 URI は <absolute-URI> 構文規則 (セクション 4.3) に準拠しなければならない。 基底 URI を URI 参照から取得する場合、 その参照を絶対形式へ変換し、フラグメントコンポーネントを すべて除去してから基底 URI として使用しなければならない。 Berners-Lee, et al. 標準トラック [28ページ]
RFC 3986 URI 汎用構文 2005年1月 参照の基底 URI は 4 つの方法のいずれかで確立できる。 以下では優先順位の順に説明する。 優先順位は層として考えることができ、 最も内側で定義された基底 URI が最も高い優先順位を持つ。 これは次のように図示できる: .----------------------------------------------------------. | .----------------------------------------------------. | | | .----------------------------------------------. | | | | | .----------------------------------------. | | | | | | | .----------------------------------. | | | | | | | | | <relative-reference> | | | | | | | | | `----------------------------------' | | | | | | | | (5.1.1) コンテンツに埋め込まれた基底 URI | | | | | | | `----------------------------------------' | | | | | | (5.1.2) カプセル化エンティティの基底 URI | | | | | | (メッセージ、表現、またはなし) | | | | | `----------------------------------------------' | | | | (5.1.3) エンティティの取得に使用した URI | | | `----------------------------------------------------' | | (5.1.4) 既定の基底 URI (アプリケーション依存) | `----------------------------------------------------------' 5.1.1. コンテンツに埋め込まれた基底 URI 特定のメディアタイプでは、相対参照用の基底 URI を コンテンツ自体の中に埋め込むことができ、 パーサーが容易に取得できる。 これは、目次などの記述的な文書を、 通常の取得文脈とは異なるプロトコル （例えば電子メールまたは USENET ニュース）によって 他者へ伝送する場合に有用である。 各メディアタイプについて基底 URI をどのように埋め込めるかを 規定することは、この仕様の範囲外である。 適切な構文が存在する場合、 各メディアタイプに関連付けられたデータ形式仕様で説明される。 5.1.2. カプセル化エンティティからの基底 URI 基底 URI が埋め込まれていない場合、 基底 URI は表現の取得文脈によって定義される。 メッセージやアーカイブなど、別のエンティティ内に 封入された文書では、そのエンティティが取得文脈となる。 したがって、表現の既定の基底 URI は、 その表現をカプセル化しているエンティティの 基底 URI となる。 Berners-Lee, et al. 標準トラック [29ページ]
RFC 3986 URI 汎用構文 2005年1月 MIME コンテナータイプ （例えば message および multipart タイプ）内に基底 URI を 埋め込む機構は MHTML [RFC2557] によって定義される。 MIME メッセージヘッダー構文を使用しないが、 何らかの形式のタグ付きメタデータをメッセージ内へ 含めることを許可するプロトコルは、 メッセージの一部として基底 URI を定義する独自の構文を 定義してもよい。 5.1.3. 取得 URI からの基底 URI 基底 URI が埋め込まれておらず、表現が別の エンティティ内にもカプセル化されていない場合、 URI を使用してその表現を取得したなら、 その URI を基底 URI とみなすものとする。 取得がリダイレクトされた要求の結果である場合、 最後に使用された URI（すなわち、表現を実際に 取得する結果となった URI）が基底 URI となることに注意されたい。 5.1.4. 既定の基底 URI 上記で説明した条件のいずれも当てはまらない場合、 基底 URI はアプリケーションの文脈によって定義される。 この定義は必然的にアプリケーション依存であるため、 その他の方法のいずれかを使用して基底 URI を定義しない場合、 同じコンテンツが異なる種類のアプリケーションによって 異なる方法で解釈される可能性がある。 相対参照を含む表現の送信者は、 それらの参照に対する基底 URI を確立できることを 保証する責任を負う。フラグメントだけの参照を除き、 相対参照は基底 URI が明確に定義されている状況でのみ 確実に使用できる。 5.2. 相対解決 このセクションでは、指定された基底 URI に対して 相対的である可能性のある URI 参照を、 その参照の対象を表す解析済みコンポーネントへ変換する アルゴリズムについて説明する。その後、セクション 5.3 で 説明するようにコンポーネントを再構成し、 対象 URI を形成できる。このアルゴリズムは、 他の実装の出力をテストするために使用できる 確定的な結果を提供する。アプリケーションは、 結果がこのアルゴリズムによって得られるものと一致する限り、 別のアルゴリズムを使用して相対参照の解決を実装してもよい。 Berners-Lee, et al. 標準トラック [30ページ]
RFC 3986 URI 汎用構文 2005年1月 5.2.1. 基底 URI の事前解析 基底 URI (Base) は セクション 5.1 の手順に従って 確立され、セクション 3 で説明する 5 つの主要コンポーネントへ 解析される。基底 URI で存在することが必須なのは scheme コンポーネントだけであることに注意されたい。 その他のコンポーネントは空または未定義の場合がある。 関連する区切り文字が URI 参照内に現れない場合、 コンポーネントは未定義である。path コンポーネントは 空の場合はあるが、未定義になることはない。 セクション 6.2.2 および 6.2.3 で説明される基底 URI の正規化は任意である。 URI 参照は、正規化する前に対象 URI へ変換しなければならない。 5.2.2. 参照の変換 各 URI 参照 (R) について、次の擬似コードは R をその対象 URI (T) へ変換するアルゴリズムを説明する: -- URI 参照を 5 つの URI コンポーネントへ解析する -- (R.scheme, R.authority, R.path, R.query, R.fragment) = parse(R); -- 非厳格パーサーは、参照内の scheme が -- 基底 URI の scheme と同一の場合、それを無視してもよい。 -- if ((not strict) and (R.scheme == Base.scheme)) then undefine(R.scheme); endif; Berners-Lee, et al. 標準トラック [31ページ]
RFC 3986 URI 汎用構文 2005年1月 if defined(R.scheme) then T.scheme = R.scheme; T.authority = R.authority; T.path = remove_dot_segments(R.path); T.query = R.query; else if defined(R.authority) then T.authority = R.authority; T.path = remove_dot_segments(R.path); T.query = R.query; else if (R.path == "") then T.path = Base.path; if defined(R.query) then T.query = R.query; else T.query = Base.query; endif; else if (R.path starts-with "/") then T.path = remove_dot_segments(R.path); else T.path = merge(Base.path, R.path); T.path = remove_dot_segments(T.path); endif; T.query = R.query; endif; T.authority = Base.authority; endif; T.scheme = Base.scheme; endif; T.fragment = R.fragment; 5.2.3. パスのマージ 上記の擬似コードでは、relative-path 参照と 基底 URI の path をマージする "merge" ルーチンを参照している。 これは次のように実行する: o 基底 URI に定義済みの authority コンポーネントと空の path がある場合、"/" と参照の path を連結した 文字列を返す。それ以外の場合、 Berners-Lee, et al. 標準トラック [32ページ]
RFC 3986 URI 汎用構文 2005年1月 o 基底 URI の path の最後のセグメントを除くすべてに、 参照の path コンポーネントを追加した文字列を返す （すなわち、基底 URI の path 内の最も右側の "/" より後の すべての文字を除外する。または、基底 URI の path に "/" 文字が含まれない場合は、その path 全体を除外する）。 5.2.4. ドットセグメントの除去 擬似コードでは、参照された path から特殊な完全 path セグメント "." および ".." を解釈し除去する "remove_dot_segments" ルーチンも参照している。 これは、path が相対的であるかどうかにかかわらず、 参照から path を抽出した後に行われ、 対象 URI を形成する前に、無効または余分な ドットセグメントを除去する。この除去プロセスを実現する方法は 多数あるが、ここでは 2 つの文字列バッファーを使用する 単純な方法を説明する。 1. 入力バッファーを、ここまで連結された path コンポーネントで初期化し、出力バッファーを空 文字列で初期化する。 2. 入力バッファーが空でない間、次を繰り返す: A. 入力バッファーが "../" または "https://www.rfc-editor.org/rfc/" というプレフィックスで始まる場合、 そのプレフィックスを入力バッファーから除去する。それ以外の場合、 B. 入力バッファーが "/./" または "/." というプレフィックスで始まり、 "." が完全な path セグメントである場合、 そのプレフィックスを入力バッファー内の "/" で置き換える。それ以外の場合、 C. 入力バッファーが "/../" または "/.." というプレフィックスで始まり、 ".." が完全な path セグメントである場合、 そのプレフィックスを入力バッファー内の "/" で置き換え、 出力バッファーから最後のセグメントと、 その前の "/"（存在する場合）を除去する。それ以外の場合、 D. 入力バッファーが "." または ".." だけで構成されている場合、 それを入力バッファーから除去する。それ以外の場合、 E. 入力バッファーの最初の path セグメントを 出力バッファーの末尾へ移動する。これには、 最初の "/" 文字（存在する場合）と、その後の、 次の "/" 文字または入力バッファーの末尾までの 文字（ただし次の "/" 自体は含まない）を含める。 3. 最後に、出力バッファーを remove_dot_segments の結果として返す。 Berners-Lee, et al. 標準トラック [33ページ]
RFC 3986 URI 汎用構文 2005年1月 ドットセグメントは、基底 URI 内の名前の階層に対して 相対的な識別子を表現するために URI 参照で 使用することを意図している。 remove_dot_segments アルゴリズムは、余分なドットセグメントを エラーとして扱ったり、参照解決実装による誤解釈に 任せたりするのではなく除去することで、その階層を尊重する。 次に、マージ済み path の 2 つの例について、 上記の手順がどのように適用されるかを示し、 各手順後の 2 つのバッファーの状態を示す。 手順 出力バッファー 入力バッファー 1 : /a/b/c/./../../g 2E: /a /b/c/./../../g 2E: /a/b /c/./../../g 2E: /a/b/c /./../../g 2B: /a/b/c /../../g 2C: /a/b /../g 2C: /a /g 2E: /a/g 手順 出力バッファー 入力バッファー 1 : mid/content=5/../6 2E: mid /content=5/../6 2E: mid/content=5 /../6 2C: mid /6 2E: mid/6 一部のアプリケーションでは、文字列ではなく 2 つのセグメントスタックを使用して remove_dot_segments アルゴリズムを実装する方が効率的な場合がある。 注記: 一部の古く誤った実装では、 基底 path と参照 path をマージする前に 参照の query コンポーネントと path コンポーネントを 分離できないため、query コンポーネントに "/../" または "/./" が含まれる場合、相互運用性の 障害が発生することに注意されたい。 Berners-Lee, et al. 標準トラック [34ページ]
RFC 3986 URI 汎用構文 2005年1月 5.3. コンポーネントの再構成 解析済みの URI コンポーネントは、 対応する URI 参照文字列を得るために再構成できる。 擬似コードを使用すると、次のようになる: result = "" if defined(scheme) then append scheme to result; append ":" to result; endif; if defined(authority) then append "//" to result; append authority to result; endif; append path to result; if defined(query) then append "?" to result; append query to result; endif; if defined(fragment) then append "#" to result; append fragment to result; endif; return result; 区切り文字が参照内に存在しなかったことを意味する 未定義のコンポーネントと、 区切り文字が存在し、その直後に次のコンポーネント区切り文字または 参照の末尾が続いたことを意味する空のコンポーネントとの 区別を維持するよう注意していることに留意されたい。 5.4. 参照解決の例 明確に定義された基底 URI http://a/b/c/d;p?q を持つ表現内では、相対参照は次のように その対象 URI へ変換される。 Berners-Lee, et al. 標準トラック [35ページ]
RFC 3986 URI 汎用構文 2005年1月 5.4.1. 通常の例 "g:h" = "g:h" "g" = "http://a/b/c/g" "https://www.rfc-editor.org/rfc/g" = "http://a/b/c/g" "g/" = "http://a/b/c/g/" "/g" = "http://a/g" "//g" = "http://g" "?y" = "http://a/b/c/d;p?y" "g?y" = "http://a/b/c/g?y" "#s" = "http://a/b/c/d;p?q#s" "g#s" = "http://a/b/c/g#s" "g?y#s" = "http://a/b/c/g?y#s" ";x" = "http://a/b/c/;x" "g;x" = "http://a/b/c/g;x" "g;x?y#s" = "http://a/b/c/g;x?y#s" "" = "http://a/b/c/d;p?q" "." = "http://a/b/c/" "https://www.rfc-editor.org/rfc/" = "http://a/b/c/" ".." = "http://a/b/" "../" = "http://a/b/" "../g" = "http://a/b/g" "../.." = "http://a/" "../../" = "http://a/" "../../g" = "http://a/g" 5.4.2. 異常な例 次の異常な例が通常の実務で生じる可能性は低いが、 すべての URI パーサーは一貫してこれらを解決できるべきである。 各例では上記と同じ基底を使用する。 パーサーは、relative-path 参照内の ".." セグメント数が、基底 URI の path にある階層 レベル数より多い場合の処理に注意しなければならない。 ".." 構文を使用して URI の authority コンポーネントを 変更することはできないことに注意されたい。 "../../../g" = "http://a/g" "../../../../g" = "http://a/g" Berners-Lee, et al. 標準トラック [36ページ]
RFC 3986 URI 汎用構文 2005年1月 同様に、パーサーは "." および ".." が path の完全なコンポーネントである場合はドットセグメントを除去しなければならないが、 セグメントの一部にすぎない場合は除去してはならない。 "/./g" = "http://a/g" "/../g" = "http://a/g" "g." = "http://a/b/c/g." ".g" = "http://a/b/c/.g" "g.." = "http://a/b/c/g.." "..g" = "http://a/b/c/..g" 相対参照が "." および ".." という完全な path セグメントの 不要または意味をなさない形式を使用する場合は、さらに起こりにくい。 "https://www.rfc-editor.org/rfc/../g" = "http://a/b/g" "https://www.rfc-editor.org/rfc/g/." = "http://a/b/c/g/" "g/./h" = "http://a/b/c/g/h" "g/../h" = "http://a/b/c/h" "g;x=1/./y" = "http://a/b/c/g;x=1/y" "g;x=1/../y" = "http://a/b/c/y" 一部のアプリケーションは、参照の query および／または fragment コンポーネントを path コンポーネントから分離せずに、 基底 path とマージしてドットセグメントを除去する。 この誤りはめったに気付かれない。通常の fragment の使用では 階層 ("/") 文字が含まれることがなく、 query コンポーネントも通常、相対参照内では使用されないためである。 "g?y/./x" = "http://a/b/c/g?y/./x" "g?y/../x" = "http://a/b/c/g?y/../x" "g#s/./x" = "http://a/b/c/g#s/./x" "g#s/../x" = "http://a/b/c/g#s/../x" 一部のパーサーでは、参照内のスキーム名が 基底 URI のスキームと同じ場合、相対参照内に そのスキーム名が存在することを許可する。 これは、以前の partial URI 仕様 [RFC1630] の抜け穴とみなされる。 その使用は避けるべきだが、後方互換性のために許可される。 "http:g" = "http:g" ; 厳格なパーサーの場合 / "http://a/b/c/g" ; 後方互換性の場合 Berners-Lee, et al. 標準トラック [37ページ]
RFC 3986 URI 汎用構文 2005年1月 6. 正規化と比較 URI に対する最も一般的な操作の 1 つは単純比較である。 すなわち、URI を使用してそれぞれのリソースへ アクセスすることなく、2 つの URI が同等かどうかを判断する。 比較は、レスポンスキャッシュへアクセスするたび、 ブラウザーがリンクを色付けするために履歴を確認するたび、 または XML パーサーが名前空間内のタグを処理するたびに行われる。 URI を比較する前の広範な正規化は、 スパイダーや索引付けエンジンによって、 検索空間を削減したり、要求動作およびレスポンス保存の 重複を減らしたりするためによく使用される。 URI の比較は、何らかの特定の目的のために行われる。 異なる目的で URI を比較するプロトコルまたは実装は、 別名識別子を減らすためにどれだけの労力をかけるべきかに関して、 異なる設計上のトレードオフを受けることが多い。 このセクションでは、URI の比較に使用できる各種方法、 それらの間のトレードオフ、およびそれらを使用する可能性のある アプリケーションの種類について説明する。 6.1. 同値性 URI はリソースを識別するために存在するので、 同じリソースを識別する場合、それらは同等と みなされるべきだと考えられる。しかし、この同値性の定義は 実務上あまり有用ではない。実装が 2 つのリソースを 完全に把握または制御していない限り、 それらを比較する方法がないためである。 このため、URI の同値または相違の判断は、 URI スキーム定義によって提供される追加規則への参照を 加える場合もあるが、文字列比較に基づく。 このような比較の可能な結果を説明するために "different" および "equivalent" という用語を使用するが、 同値性にはアプリケーション依存の多くの形態が存在する。 2 つの URI が同等であることを判断できたとしても、 URI の比較だけでは、2 つの URI が異なるリソースを 識別するかどうかを判断するには不十分である。 例えば、2 つの異なるドメイン名の所有者が、 両方から同じリソースを提供することを決定すれば、 2 つの異なる URI が生じる。 したがって、比較方法は偽陰性を最小限に抑えつつ、 偽陽性を厳格に回避するよう設計される。 同値性をテストする際、アプリケーションは 相対参照を直接比較すべきではない。 比較前に各参照をそれぞれの対象 URI へ変換すべきである。 表現の取得などのネットワーク動作を選択 （または回避）するために URI を比較する場合、 fragment コンポーネント（存在する場合）は比較から除外すべきである。 Berners-Lee, et al. 標準トラック [38ページ]
RFC 3986 URI 汎用構文 2005年1月 6.2. 比較の段階 URI の同値性をテストするため、実際にはさまざまな方法が 使用される。これらの方法は、必要な処理量と、 偽陰性の可能性をどの程度低減するかによって区別される 一連の範囲に属する。前述のとおり、偽陰性を 完全に排除することはできない。実際にはその可能性を 低減できるが、そのためにはより多くの処理が必要となり、 すべてのアプリケーションにとって費用対効果が高いわけではない。 この比較方法の範囲を階段と考えるなら、 以下の議論では、処理コストは低いが偽陰性が生じる可能性が 比較的高い方法から始まり、 計算コストは高いが偽陰性のリスクが低い方法へと その階段を上っていく。 6.2.1. 単純文字列比較 2 つの URI を文字列として見たときに同一であれば、 それらが同等であると安全に結論付けることができる。 この種類の同値性テストは計算コストが非常に低く、 さまざまなアプリケーション、特に解析分野で 広く使用されている。 文字列の同値性をテストするには、いくつかの基本的な注意が必要である。 この手順は "bit-for-bit" または "byte-for-byte" 比較と呼ばれることが多いが、 これは誤解を招く可能性がある。文字列の等価性テストは通常、 文字列を構成する文字を最初からペアで比較し、 両方の文字列が尽きてすべての文字が等しいと判定されるまで、 文字のペアが等しくないと判定されるまで、 または一方の文字列が他方より先に尽きるまで進める方法に基づく。 この文字比較では、各文字のペアを比較可能な形式に する必要がある。例えば、一方の URI が EBCDIC エンコーディングのバイト配列として格納され、 もう一方が Java String オブジェクト (UTF-16) に格納されている場合、 単純にビット単位の比較を適用すると誤りが生じる。 byte-for-byte または bit-for-bit ではなく、 character-for-character の等価性と表現する方が適切である。 実務上、文字単位の比較は、共通の文字エンコーディングへ 変換した後、コードポイント単位で行うべきである。 偽陰性は URI の別名が生成および使用されることで生じる。 比較方法にかかわらず、すでに正規化された形式 （すなわち、以下で説明する正規化を適用した結果と 同一の形式）で URI 参照を一貫して提供することで、 不要な別名を減らすことができる。 Berners-Lee, et al. 標準トラック [39ページ]
RFC 3986 URI 汎用構文 2005年1月 プロトコルおよびデータ形式では、 人と実装が自身の利益のために URI 参照の提供について 一貫性を保つ、少なくとも追加の正規化によって得られる 効率上の利点を打ち消すほどには一貫しているという考えに基づき、 一部の URI 比較を単純な文字列比較に限定することが多い。 6.2.2. 構文に基づく正規化 実装は、この仕様で提供される定義に基づくロジックを使用し、 偽陰性の可能性を低減してもよい。 この処理のコストは文字単位の文字列比較より やや高い。例えば、この手法を使用するアプリケーションは、 次の 2 つの URI を合理的に同等とみなすことができる: example://a/b/c/%7Bfoo%7D eXAMPLE://a/./b/../b/%63/%7bfoo%7d ブラウザーなどの Web ユーザーエージェントは、 キャッシュ済みレスポンスが利用可能かどうかを判断する際、 通常この種類の URI 正規化を適用する。 構文に基づく正規化には、大文字小文字の正規化、 パーセントエンコーディングの正規化、 ドットセグメントの除去などの技法が含まれる。 6.2.2.1. 大文字小文字の正規化 すべての URI について、パーセントエンコーディングの 3 文字内にある 16 進数字（例えば "%3a" と "%3A"）は 大文字小文字を区別しないため、A-F の数字には 大文字を使用するよう正規化すべきである。 URI が汎用構文のコンポーネントを使用する場合、 コンポーネント構文の同値性規則は常に適用される。 すなわち、scheme および host は大文字小文字を区別しないため、 小文字へ正規化すべきである。例えば URI <HTTP://www.EXAMPLE.com/> は <http://www.example.com/> と同等である。 その他の汎用構文コンポーネントは、スキームによって 特に別途定義されていない限り、大文字小文字を区別するとみなされる (セクション 6.2.3 を参照)。 6.2.2.2. パーセントエンコーディングの正規化 パーセントエンコーディング機構 (セクション 2.1) は、 それ以外は同一の URI 間で相違が生じる頻繁な原因となる。 上述の大文字小文字正規化の問題に加え、 一部の URI 生成者はパーセントエンコードする必要のない オクテットをパーセントエンコードし、 エンコードされていない対応物と同等な URI を生成する。 このような URI は、セクション 2.3 で説明するように、 非予約文字に対応するパーセントエンコード済みオクテットを デコードして正規化すべきである。 Berners-Lee, et al. 標準トラック [40ページ]
RFC 3986 URI 汎用構文 2005年1月 6.2.2.3. パスセグメントの正規化 完全な path セグメント "." および ".." は、 相対参照 (セクション 4.1) 内でのみ使用することを意図し、 参照解決プロセス (セクション 5.2) の一部として除去される。 ただし、一部の配備済み実装は、 参照がすでに URI である場合には参照解決が必要ないと 誤って仮定し、非相対 path に現れるドットセグメントを 除去しない。URI 正規化処理は、 セクション 5.2.4 で説明するように、 path に remove_dot_segments アルゴリズムを適用して ドットセグメントを除去すべきである。 6.2.3. スキームに基づく正規化 URI の構文および意味論は、 各スキームを定義する仕様で説明されるように、 スキームごとに異なる。実装は追加の処理コストをかけて スキーム固有の規則を使用し、偽陰性の可能性を 低減してもよい。例えば "http" スキームは authority コンポーネントを使用し、既定ポート "80" を持ち、 空の path を "/" と同等と定義するため、 次の 4 つの URI は同等である: http://example.com http://example.com/ http://example.com:/ http://example.com:80/ 一般に、空の path を持つ authority の汎用構文を 使用する URI は、path "/" へ正規化すべきである。 同様に、明示的な ":port" について、 port が空またはスキームの既定値である場合、 port および ":" 区切り文字を省略したものと同等であるため、 スキームに基づく正規化によって除去すべきである。 例えば、上記の 2 番目の URI が "http" スキームの正規形である。 正規化がスキームによって異なる別のケースは、 空の authority コンポーネントまたは空の host サブコンポーネントの 処理である。多くのスキーム仕様では、空の authority または host は エラーとみなされるが、その他では "localhost" または エンドユーザーの host と同等とみなされる。 スキームが authority の既定値を定義しており、 その既定値への URI 参照が必要な場合、 統一性、簡潔性、国際化のため、 参照は空の authority へ正規化すべきである。 ただし、userinfo または port サブコンポーネントのいずれかが 空でない場合、host が既定値と一致していても 明示的に指定すべきである。 関連するコンポーネントが空である場合でも、 スキーム仕様によって許可されていない限り、 正規化によって区切り文字を除去すべきではない。 Berners-Lee, et al. 標準トラック [41ページ]
RFC 3986 URI 汎用構文 2005年1月 例えば URI "http://example.com/?" は、 上記のどの例とも同等であると仮定できない。 同様に、userinfo サブコンポーネント内の区切り文字の 有無は、通常その解釈にとって重要である。 fragment コンポーネントにはスキームに基づく正規化を 適用しない。したがって、サフィックス "#" だけが異なる 2 つの URI は、 スキームにかかわらず異なるものとみなされる。 一部のスキームでは、大文字小文字を区別しないデータからなる 追加のサブコンポーネントを定義し、 正規化処理がこのデータを共通の大文字小文字 （例えばすべて小文字）へ変換することを暗黙に許可する。 例えば、"mailto" URI スキームのように、 path のサブコンポーネントにインターネットホスト名を 含むと定義する URI スキームでは、 そのサブコンポーネントは大文字小文字を区別せず、 したがって大文字小文字の正規化対象になる （例えば、汎用構文では path コンポーネントを 大文字小文字区別とみなすにもかかわらず、 "mailto:Joe@Example.COM" は "mailto:Joe@example.com" と同等である）。 その他のスキーム固有の正規化も可能である。 6.2.4. プロトコルに基づく正規化 偽陰性の発生を減らすために相当な労力をかけることは、 Web スパイダーにとって費用対効果が高いことが多い。 したがって、それらは URI 比較においてさらに 積極的な技法を実装する。例えば、 http://example.com/data のような URI が、末尾のスラッシュだけが異なる URI http://example.com/data/ へリダイレクトされることを観察した場合、 将来これら 2 つを同等とみなす可能性が高い。 この種の技法は、リソースへのアクセス結果と、 そのスキームの参照解決アルゴリズムに共通する規約の両方によって 同値性が明確に示される場合にのみ適切である （この場合は、相対参照の問題を避けるために HTTP オリジンサーバーがリダイレクトを使用すること）。 Berners-Lee, et al. 標準トラック [42ページ]
RFC 3986 URI 汎用構文 2005年1月 7. セキュリティに関する考慮事項 URI 自体はセキュリティ上の脅威をもたらさない。 しかし、URI はネットワークリソースへアクセスするための コンパクトな命令集合を提供するために頻繁に使用されるので、 URI 内のデータを適切に解釈し、 そのデータが意図しないアクセスを引き起こすことを防ぎ、 平文で公開すべきでないデータを含めないよう 注意しなければならない。 7.1. 信頼性と一貫性 一度 URI を使用して情報を取得した後、 将来もその URI によって同じ情報を取得できる保証はない。 また、将来その URI によって取得できる情報が、 過去に取得した情報と観察上類似しているという保証もない。 URI 構文は、特定のスキームまたはオーソリティが その名前空間をどのように分配し、 時間の経過とともにどのように維持するかを制約しない。 このような保証は、その名前空間と対象リソースを 制御する人物からのみ得られる。 特定の URI スキームは、そのスキームのすべての命名オーソリティに 必要な場合、名前の永続性などの追加の意味論を 定義してもよい。 7.2. 悪意のある構築 表現の取得など、一見無害で冪等な操作を 実行しようとすると、実際には損害を与える可能性のある 遠隔操作が発生するよう URI を構築できる場合がある。 安全でない URI は通常、対象ネットワークプロトコル用に 予約されたものとは異なるポート番号を指定することで構築される。 クライアントは知らずに別のプロトコルサービスを実行するサイトへ 接続し、URI 内のデータには、その別のプロトコルに従って 解釈された場合に予期しない操作を引き起こす命令が含まれる。 このような悪用の一般的な例として、 port コンポーネントに "25" を指定したプロトコルベースの スキームを使用し、ユーザーエージェントソフトウェアを欺いて SMTP サーバー経由で意図しない、またはなりすましの メッセージを送信させるものがある。 アプリケーションは、URI の参照解決に使用するプロトコルが、 その well-known port で期待されるプロトコルと互換でない限り、 "well-known port" の範囲 (0 - 1023) の TCP ポート番号を指定する URI の参照解決を防ぐべきである。 IANA は well-known port のレジストリを維持しているが、 新しいサービスの配備を妨げないため、 アプリケーションはこのような制限をユーザーが設定可能にすべきである。 Berners-Lee, et al. 標準トラック [43ページ]
RFC 3986 URI 汎用構文 2005年1月 URI に、特定の解決または参照解決プロトコルの 区切り文字と一致するパーセントエンコード済みオクテット （例えば TELNET プロトコルの CR および LF 文字）が含まれる場合、 それらのパーセントエンコーディングを、 そのプロトコルによる伝送前にデコードしてはならない。 プロトコルに違反する可能性があるとしても、 パーセントエンコーディングを転送する方が、 デコード済みオクテットを追加の操作またはパラメーターとして 解釈させ、予期しない、場合によっては有害な遠隔操作を 引き起こすより害が少ない。 7.3. バックエンドトランスコーディング URI が参照解決されると、その中のデータはしばしば ユーザーエージェントと 1 つ以上のサーバーの両方によって解析される。 例えば HTTP では、一般的なユーザーエージェントは URI を 5 つの主要コンポーネントへ解析し、 authority のサーバーへアクセスして、 authority、path、query コンポーネント内のデータを送信する。 一般的なサーバーはその情報を受け取り、 path をセグメントへ、query をキー／値ペアへ解析し、 要求に応答するための実装固有ハンドラーを呼び出す。 その結果、URI 全体または個別コンポーネントに分割して 処理するサーバー実装に共通するセキュリティ上の懸念は、 その URI 内の文字およびパーセントエンコーディングによって 表されるオクテットデータを適切に解釈することである。 パーセントエンコード済みオクテットは、 参照解決プロセスのいずれかの時点でデコードしなければならない。 アプリケーションはオクテットをデコードする前に URI をコンポーネントおよびサブコンポーネントへ分割しなければならない。 そうしなければ、デコードされたオクテットが 区切り文字と誤認される可能性がある。 URI 内のデータに対するセキュリティチェックは、 オクテットをデコードした後に適用すべきである。 ただし、"%00" パーセントエンコーディング (NUL) は 特別な処理を必要とする場合があり、 アプリケーションがコンポーネント内で生データを受信することを 想定していない場合は拒否すべきである。 URI path の解釈プロセスがバックエンドファイルシステムまたは 関連するシステム関数を使用する場合、特に注意すべきである。 ファイルシステムは通常、"/"、"\"、":"、"["、"]" などの 特殊文字、および "."、".."、"..."、"aux"、 "lpt" などの特殊なデバイス名に操作上の意味を割り当てる。 場合によっては、そのような名前が存在するかどうかを テストするだけで、オペレーティングシステムが停止したり、 無関係なシステムコールを呼び出したりし、 サービス拒否および意図しないデータ転送に関する 重大なセキュリティ上の問題を引き起こす。 この仕様ですべての重要な文字およびデバイス名を 列挙することは不可能である。 実装者は、アプリケーションに接続される可能性のある ストレージデバイスの種類について予約済みの名称および文字を調査し、 URI コンポーネントから得られたデータの使用を それに応じて制限すべきである。 Berners-Lee, et al. 標準トラック [44ページ]
RFC 3986 URI 汎用構文 2005年1月 7.4. まれな IP アドレス形式 IPv4address の URI 構文は、 一般的な IPv4 アドレスリテラルのドット付き 10 進形式だけを 許可するが、URI を処理する多くの実装では、 文字列リテラルを実際の IP アドレスへ変換するため、 gethostbyname() や inet_aton() など、 プラットフォーム依存のシステムルーチンを使用する。 残念ながら、このようなシステムルーチンは セクション 3.2.2 で説明されるよりはるかに広い 形式集合を許可し、処理することが多い。 例えば、多くの実装では 3 つの数字からなるドット形式を許可し、 最後の部分を 16 ビット量として解釈して ネットワークアドレスの最右端 2 バイト （例えば Class B ネットワーク）へ配置する。 同様に、2 つの数字からなるドット形式では、 最後の部分を 24 ビット量として解釈して ネットワークアドレスの最右端 3 バイト (Class A) へ配置し、 単一の数字（ドットなし）は 32 ビット量として解釈して ネットワークアドレスへ直接格納する。 さらに混乱を増すことに、一部の実装では、 C 言語で規定されるように、各ドット部分を 10 進、8 進、または 16 進として解釈することを許可する （すなわち、先頭の 0x または 0X は 16 進、 先頭の 0 は 8 進、それ以外は 10 進として解釈される）。 これらの追加 IP アドレス形式は、 プラットフォーム実装間の差異があるため URI 構文では許可されない。 ただし、アプリケーションが文字列リテラル形式の IP アドレスに基づいて リソースへのアクセスをフィルタリングしようとする場合、 セキュリティ上の問題になる可能性がある。 このフィルタリングを行う場合、リテラルを数値形式へ変換し、 文字列形式のプレフィックスまたはサフィックスではなく、 数値に基づいてフィルタリングすべきである。 7.5. 機密情報 URI 生成者は、秘密にすることを意図したユーザー名または パスワードを含む URI を提供すべきではない。 URI はブラウザーに頻繁に表示され、 平文のブックマークに保存され、 ユーザーエージェントの履歴および中継アプリケーション （プロキシ）によって記録される。 userinfo コンポーネント内に現れるパスワードは非推奨であり、 'password' パラメーターを公開することが意図されている まれな場合を除き、エラーとみなす （または単に無視する）べきである。 7.6. 意味論的攻撃 userinfo サブコンポーネントはめったに使用されず、 authority コンポーネント内で host より前に現れるため、 ある（信頼された）命名オーソリティを識別しているように 人間のユーザーに見せかけながら、実際にはノイズの背後に隠された 別のオーソリティを識別する、ユーザーを誤認させることを意図した URI の構築に利用できる。例えば Berners-Lee, et al. 標準トラック [45ページ]
RFC 3986 URI 汎用構文 2005年1月 ftp://cnn.example.com&story=breaking_news@10.0.0.1/top_story.htm は、人間のユーザーに host が 'cnn.example.com' であると 思わせる可能性があるが、実際には '10.0.0.1' である。 誤解を招く userinfo サブコンポーネントは、 上記の例よりはるかに長くできることに注意されたい。 上記のような誤解を招く URI は、 ソフトウェア自体への攻撃ではなく、 URI の意味についてユーザーが持つ先入観への攻撃である。 ユーザーエージェントは、URI を表示する際に その各種コンポーネントを区別することで、 このような攻撃の影響を軽減できる場合がある。 例えば userinfo が存在する場合は異なる色または色調で 表示できるが、万能な対策は存在しない。 URI に基づく意味論的攻撃に関する詳細情報は [Siedzik] にある。 8. IANA に関する考慮事項 セクション 3.1 の <scheme> で定義される URI スキーム名は、 [BCP35] で定義される手順に従って IANA が管理する登録済み名前空間を形成する。 この文書によって必要となる IANA の措置はない。 9. 謝辞 この仕様は RFC 2396 [RFC2396]、 RFC 1808 [RFC1808]、 および RFC 1738 [RFC1738] に由来し、 これらの文書の謝辞も引き続き適用される。 また、[RFC2732] で Robert M. Hinden、Brian E. Carpenter、および Larry Masinter が 定義した、host 構文における IPv6 リテラルの更新 （修正を含む）も取り込んでいる。 さらに、Gisle Aas、Reese Anschultz、 Daniel Barclay、Tim Bray、Mike Brown、Rob Cameron、Jeremy Carroll、 Dan Connolly、Adam M. Costello、John Cowan、Jason Diamond、Martin Duerst、Stefan Eissing、Clive D.W. Feather、Al Gilman、Tony Hammond、 Elliotte Harold、Pat Hayes、Henry Holtzman、Ian B. Jacobs、Michael Kay、John C. Klensin、Graham Klyne、Dan Kohn、Bruce Lilly、Andrew Main、Dave McAlpin、Ira McDonald、Michael Mealling、Ray Merkert、 Stephen Pollei、Julian Reschke、Tomas Rokicki、Miles Sabin、Kai Schaetzl、Mark Thomson、Ronald Tschalaer、Norm Walsh、Marc Warne、 Stuart Williams、および Henry Zongaro の貢献に感謝する。 10. 参考文献 10.1. 規範的参考文献 [ASCII] American National Standards Institute, "符号化文字 集合 -- 情報交換用 7 ビット米国標準コード", ANSI X3.4, 1986. Berners-Lee, et al. 標準トラック [46ページ]
RFC 3986 URI 汎用構文 2005年1月 [RFC2234] Crocker, D. and P. Overell, "構文 仕様のための拡張 BNF: ABNF", RFC 2234, 1997年11月. [STD63] Yergeau, F., "UTF-8、ISO 10646 の 変換形式", STD 63, RFC 3629, 2003年11月. [UCS] International Organization for Standardization, "情報技術 - 国際多オクテット符号化 文字集合 (UCS)", ISO/IEC 10646:2003, 2003年12月. 10.2. 参考情報 [BCP19] Freed, N. and J. Postel, "IANA 文字集合登録 手順", BCP 19, RFC 2978, 2000年10月. [BCP35] Petke, R. and I. King, "URL スキーム名の登録手順", BCP 35, RFC 2717, 1999年11月. [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD インターネット ホストテーブル仕様", RFC 952, 1985年10月. [RFC1034] Mockapetris, P., "ドメイン名 - 概念と機能", STD 13, RFC 1034, 1987年11月. [RFC1123] Braden, R., "インターネットホストの要件 - アプリケーション およびサポート", STD 3, RFC 1123, 1989年10月. [RFC1535] Gavron, E., "広く配備された DNS ソフトウェアにおける セキュリティ問題と修正案", RFC 1535, 1993年10月. [RFC1630] Berners-Lee, T., "WWW における Universal Resource Identifiers: World-Wide Web で使用されるネットワーク上のオブジェクトの 名前とアドレスを表現するための統一構文", RFC 1630, 1994年6月. [RFC1736] Kunze, J., "インターネット リソースロケーターの機能上の推奨事項", RFC 1736, 1995年2月. [RFC1737] Sollins, K. and L. Masinter, "Uniform Resource Names の 機能要件", RFC 1737, 1994年12月. [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, 1994年12月. [RFC1808] Fielding, R., "相対 Uniform Resource Locators", RFC 1808, 1995年6月. Berners-Lee, et al. 標準トラック [47ページ]
RFC 3986 URI 汎用構文 2005年1月 [RFC2046] Freed, N. and N. Borenstein, "多目的インターネットメール 拡張 (MIME) 第2部: メディアタイプ", RFC 2046, 1996年11月. [RFC2141] Moats, R., "URN 構文", RFC 2141, 1997年5月. [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "統一 資源識別子 (URI): 汎用構文", RFC 2396, 1998年8月. [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, "分散オーサリングのための HTTP 拡張 -- WEBDAV", RFC 2518, 1999年2月. [RFC2557] Palme, J., Hopmann, A., and N. Shelness, "HTML (MHTML) などの複合文書の MIME カプセル化", RFC 2557, 1999年3月. [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, "新しい URL スキームのための指針", RFC 2718, 1999年11月. [RFC2732] Hinden, R., Carpenter, B., and L. Masinter, "URL における リテラル IPv6 アドレスの形式", RFC 2732, 1999年12月. [RFC3305] Mealling, M. and R. Denenberg, "W3C/IETF URI Planning Interest Group 合同報告書: Uniform Resource Identifiers (URI)、URL、および Uniform Resource Names (URN): 明確化と推奨事項", RFC 3305, 2002年8月. [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "アプリケーションにおけるドメイン名の国際化 (IDNA)", RFC 3490, 2003年3月. [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) アドレッシングアーキテクチャ", RFC 3513, 2003年4月. [Siedzik] Siedzik, R., "意味論的攻撃: URL の中には何があるか?", 2001年4月, <http://www.giac.org/practical/gsec/ Richard_Siedzik_GSEC.pdf>. Berners-Lee, et al. 標準トラック [48ページ]
RFC 3986 URI 汎用構文 2005年1月 付録 A. URI の ABNF 集成 URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] hier-part = "//" authority path-abempty / path-absolute / path-rootless / path-empty URI-reference = URI / relative-ref absolute-URI = scheme ":" hier-part [ "?" query ] relative-ref = relative-part [ "?" query ] [ "#" fragment ] relative-part = "//" authority path-abempty / path-absolute / path-noscheme / path-empty scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) authority = [ userinfo "@" ] host [ ":" port ] userinfo = *( unreserved / pct-encoded / sub-delims / ":" ) host = IP-literal / IPv4address / reg-name port = *DIGIT IP-literal = "[" ( IPv6address / IPvFuture ) "]" IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" ) IPv6address = 6( h16 ":" ) ls32 / "::" 5( h16 ":" ) ls32 / [ h16 ] "::" 4( h16 ":" ) ls32 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 / [ *4( h16 ":" ) h16 ] "::" ls32 / [ *5( h16 ":" ) h16 ] "::" h16 / [ *6( h16 ":" ) h16 ] "::" h16 = 1*4HEXDIG ls32 = ( h16 ":" h16 ) / IPv4address IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet Berners-Lee, et al. 標準トラック [49ページ]
RFC 3986 URI 汎用構文 2005年1月 dec-octet = DIGIT ; 0-9 / %x31-39 DIGIT ; 10-99 / "1" 2DIGIT ; 100-199 / "2" %x30-34 DIGIT ; 200-249 / "25" %x30-35 ; 250-255 reg-name = *( unreserved / pct-encoded / sub-delims ) path = path-abempty ; "/" で始まるか、空である / path-absolute ; "/" で始まるが "//" ではない / path-noscheme ; コロンを含まないセグメントで始まる / path-rootless ; セグメントで始まる / path-empty ; 文字数ゼロ path-abempty = *( "/" segment ) path-absolute = "/" [ segment-nz *( "/" segment ) ] path-noscheme = segment-nz-nc *( "/" segment ) path-rootless = segment-nz *( "/" segment ) path-empty = 0<pchar> segment = *pchar segment-nz = 1*pchar segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" ) ; コロン ":" を含まない長さがゼロでないセグメント pchar = unreserved / pct-encoded / sub-delims / ":" / "@" query = *( pchar / "/" / "?" ) fragment = *( pchar / "/" / "?" ) pct-encoded = "%" HEXDIG HEXDIG unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" reserved = gen-delims / sub-delims gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@" sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" 付録 B. 正規表現による URI 参照の解析 "first-match-wins" アルゴリズムは、 POSIX 正規表現で使用される "greedy" な 曖昧さ解消方法と同一であるため、 URI 参照の 5 つの可能なコンポーネントを解析するために 正規表現を使用することは自然であり一般的である。 次の行は、整形式の URI 参照を そのコンポーネントへ分解するための正規表現である。 Berners-Lee, et al. 標準トラック [50ページ]
RFC 3986 URI 汎用構文 2005年1月 ^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))? 12 3 4 5 6 7 8 9 上の 2 行目の数字は可読性を補助するためだけのものであり、 各部分式（すなわち括弧の各ペア）の 参照点を示す。部分式 <n> に一致した値を $<n> と呼ぶ。例えば、上記の式を http://www.ics.uci.edu/pub/ietf/uri/#Related に一致させると、次の部分式の一致結果が得られる: $1 = http: $2 = http $3 = //www.ics.uci.edu $4 = www.ics.uci.edu $5 = /pub/ietf/uri/ $6 = <undefined> $7 = <undefined> $8 = #Related $9 = Related ここで <undefined> は、そのコンポーネントが存在しないことを示す。 上記の例では query コンポーネントがこれに該当する。 したがって、5 つのコンポーネントの値を次のように 決定できる: scheme = $2 authority = $4 path = $5 query = $7 fragment = $9 逆方向では、セクション 5.3 のアルゴリズムを使用して、 コンポーネントから URI 参照を再作成できる。 付録 C. 文脈内での URI の区切り URI は、その解釈の明確な文脈を提供しない 形式を通じて伝送されることが多い。 例えば、URI がプレーンテキストに含まれる機会は多く、 電子メール、USENET ニュース、印刷された紙面で送られる テキストなどが例として挙げられる。 このような場合、URI を残りのテキスト、 特に URI の一部と誤認される可能性のある句読点から 区切ることができることが重要である。 実際には URI はさまざまな方法で区切られるが、 通常は二重引用符 "http://example.com/"、山括弧 <http://example.com/>、または単に空白を使用する: Berners-Lee, et al. 標準トラック [51ページ]
RFC 3986 URI 汎用構文 2005年1月 http://example.com/ これらの囲みは URI の一部ではない。 場合によっては、長い URI を複数行に分割するため、 追加の空白（スペース、改行、タブなど）を 挿入する必要がある場合がある。URI を抽出するときは、 その空白を無視すべきである。 ハイフン ("-") 文字の後には空白を挿入すべきではない。 一部の組版システムおよびプリンターは、改行時に 行末へハイフンを（誤って）追加する場合があるため、 ハイフンの直後に改行を含む URI の解釈処理は、 改行の周囲にあるすべての空白を無視し、 そのハイフンが実際に URI の一部である場合と そうでない場合があることを認識すべきである。 各 URI を <> 山括弧で囲む方法は、 埋め込み空白を含む参照の区切り形式として特に推奨される。 プレフィックス "URL:"（末尾にスペースがあってもなくてもよい）は、 かつて URI とその他の括弧で囲まれた指示子を 区別するための方法として推奨されていたが、 実際には一般的に使用されておらず、現在は推奨されない。 堅牢性のため、ユーザーが入力した URI を受け付けるソフトウェアは、 区切り文字と埋め込み空白の両方を認識して 除去するよう試みるべきである。 例えば、次のテキスト はい、Jim、"http://www.w3.org/Addressing/" の下で見つけました。 ただし、おそらく <ftp://foo.example. com/rfc/> からも取得できます。<http://www.ics.uci.edu/pub/ ietf/uri/historical.html#WARNING> の警告に注意してください。 には、次の URI 参照が含まれる http://www.w3.org/Addressing/ ftp://foo.example.com/rfc/ http://www.ics.uci.edu/pub/ietf/uri/historical.html#WARNING Berners-Lee, et al. 標準トラック [52ページ]
RFC 3986 URI 汎用構文 2005年1月 付録 D. RFC 2396 からの変更 D.1. 追加 URI という用語の一般的な使用法の 1 つ、 すなわち任意のフラグメントを持つ絶対 URI に対応する URI の ABNF 規則が導入された。 authority コンポーネントの host 部分に使用可能な 識別子の一覧へ、[RFC2732] で説明される IPv6（およびそれ以降）のリテラルが追加され、 "[" と "]" が予約集合へ追加されるとともに、 将来の IP リテラルのバージョンを想定したバージョンフラグが 追加された。角括弧は現在 authority コンポーネント内で 予約済みと規定されており、host 内の IP リテラルを 区切る用途以外では許可されない。 path、query、fragment コンポーネントの技術的定義を 変更せずにこの変更を行うため、 それらの規則は許可される文字を直接指定するよう再定義された。 [RFC2732] は IPv6 リテラルアドレスの定義を [RFC3513] に委ねているが、残念ながら同文書には IPv6address の ABNF 記述がないため、 [RFC3513] のセクション 2.2 で定義されるテキスト表現に 一致する新しい IPv6address の ABNF 規則を作成した。 同様に、IPv4address の定義は、各 10 進オクテットを 0-255 の範囲へ制限するよう改善された。 URI の正規化と比較に関する セクション 6 は、 Tim Bray からの意見と W3C Technical Architecture Group 内での 議論を取り入れて、全面的に書き直され拡張された。 D.2. 変更 RFC 2396 のアドホックな BNF 構文は、 [RFC2234] の ABNF に置き換えられた。 この変更により、以前アンダースコア文字を含んでいた すべての規則名を、代わりにダッシュを使用する名前へ 変更する必要が生じた。さらに、 全体的な文法をより理解しやすくするため、 多数の構文規則が削除または簡略化された。 廃止された文法規則を参照する仕様は、 次の表に従ってそれらの規則を置き換えることで理解できる: Berners-Lee, et al. 標準トラック [53ページ]
RFC 3986 URI 汎用構文 2005年1月 +----------------+--------------------------------------------------+ | 廃止規則 | 変換 | +----------------+--------------------------------------------------+ | absoluteURI | absolute-URI | | relativeURI | relative-part [ "?" query ] | | hier_part | ( "//" authority path-abempty / | | | path-absolute ) [ "?" query ] | | | | | opaque_part | path-rootless [ "?" query ] | | net_path | "//" authority path-abempty | | abs_path | path-absolute | | rel_path | path-rootless | | rel_segment | segment-nz-nc | | reg_name | reg-name | | server | authority | | hostport | host [ ":" port ] | | hostname | reg-name | | path_segments | path-abempty | | param | *<pchar excluding ";"> | | | | | uric | unreserved / pct-encoded / ";" / "?" / ":" | | | / "@" / "&" / "=" / "+" / "$" / "," / "/" | | | | | uric_no_slash | unreserved / pct-encoded / ";" / "?" / ":" | | | / "@" / "&" / "=" / "+" / "$" / "," | | | | | mark | "-" / "_" / "." / "!" / "~" / "*" / "'" | | | / "(" / ")" | | | | | escaped | pct-encoded | | hex | HEXDIG | | alphanum | ALPHA / DIGIT | +----------------+--------------------------------------------------+ スキーム固有構文の定義に上記の廃止規則を使用することは 非推奨である。 文字に関する セクション 2 は、 どの文字が予約されるか、いつ予約されるか、 また汎用構文で区切り文字として使用されない場合でも なぜ予約されるのかを説明するために書き直された。 感嘆符 ("!")、アスタリスク ("*")、単一引用符 ("'")、開き括弧と閉じ括弧 ("(" および ")") を含む、 通常デコードすると安全でない mark 文字は、 予約文字と非予約文字の区別を明確にし、 スキーム設計者の最も一般的な疑問への回答となるよう、 予約集合へ移動された。同様に、 パーセントエンコードされた文字に関するセクションも書き直され、 URI 正規化処理は、任意のパーセントエンコード済みオクテットを デコードすることが許可されるようになった。 Berners-Lee, et al. 標準トラック [54ページ]
RFC 3986 URI 汎用構文 2005年1月 これは非予約文字に対応するものに限られる。一般に、 "escaped" および "unescaped" という用語は、 他の形式のエスケープ機構との混乱を減らすため、それぞれ "percent-encoded" および "decoded" に置き換えられた。 URI および URI-reference の ABNF は、 LALR パーサーにとってより扱いやすくし、複雑さを減らすため 再設計された。その結果、 構文記述のレイアウト形式は削除され、 uric、uric_no_slash、opaque_part、net_path、abs_path、rel_path、 path_segments、rel_segment、および mark 規則も削除された。 "opaque" URI へのすべての参照は、 path コンポーネントが階層に対してどのように不透明となり得るかについての より適切な説明へ置き換えられた。 relativeURI 規則は、それらが URI の部分集合かどうかに関する 不必要な混乱を避けるため relative-ref に置き換えられた。 最初のセグメントにコロンを含む URI-reference を URI または relative-ref のどちらとして解析するかという曖昧さは、 5 つの別個の path 一致規則を使用することで解消された。 フラグメント識別子は、汎用構文コンポーネントに関するセクションおよび URI と relative-ref 規則内へ戻されたが、 absolute-URI からは引き続き除外されている。 フラグメント構文を再統合した結果、 番号記号 ("#") 文字も予約集合へ戻された。 ABNF は path コンポーネントが空であることを許可するよう修正された。 これにより、実際に "dav:" 名前空間 [RFC2518] や、 多くの WWW ブラウザー実装で内部的に使用される "about:" スキームで 見られるように、absolute-URI が "scheme:" より後に 何も持たないことも許可される。 authority と path の境界に関する曖昧さは、 5 つの別個の path 一致規則を使用することで解消された。 汎用構文を使用するレジストリベースの命名オーソリティは、 現在 host 規則内で定義される。この変更により、 提供された任意の名前を単純にローカル名前解決機構へ渡す 現在の実装が、仕様と整合できるようになる。 また、ここで DNS 名形式を再規定する必要もなくなる。 さらに、host コンポーネントに パーセントエンコード済みオクテットを含めることが可能になる。 これは、国際化ドメイン名を URI で提供し、 URI 処理より上位のアプリケーション層では ネイティブの文字エンコーディングで処理し、 UTF-8 文字エンコーディングの登録名として IDNA ライブラリへ渡すことを可能にするために必要である。 server、hostport、hostname、domainlabel、toplabel、 および alphanum 規則は削除された。 [RFC2396] の相対参照解決アルゴリズムは、 明確性を向上し、次の問題を修正するため、 この改訂で擬似コードを使用して書き直された: Berners-Lee, et al. 標準トラック [55ページ]
RFC 3986 URI 汎用構文 2005年1月 o [RFC2396] セクション 5.2 のステップ 6a は、 path を持たない基底 URI を考慮していなかった。 o 参照に空の path と定義済みの query コンポーネントが 含まれる場合に、対象 URI が基底 URI の path コンポーネントを 継承するという [RFC1808] の動作を復元した。 o URI 参照が same-document 参照であるかどうかの判定を URI パーサーから分離し、配備済み URI 処理実装の 内部アーキテクチャと整合する形で、 アプリケーション内の URI 処理インターフェイスを簡略化した。 判定は現在、参照自体の形式ではなく、 参照を絶対形式へ変換した後の基底 URI との比較に基づく。 この変更により、特に正規化を使用して別名を減らす場合、 RFC 2396 の規則よりも多くの参照が この仕様の下で "same-document" とみなされる可能性がある。 ただし、既存の same-document 参照の状態は変更しない。 o path のマージルーチンを 2 つのルーチンに分離した。 merge は、基底 URI の path と relative-path 参照の組み合わせを記述し、 remove_dot_segments は、構成済み path から 特殊な "." および ".." セグメントを除去する方法を記述する。 remove_dot_segments アルゴリズムは現在、 一般的な実装と一致させ、実際の URI の正規化を改善するため、 すべての URI 参照 path に適用される。 この変更が影響するのは、基底 URI に非階層 path がある場合の 異常な参照および同一スキーム参照の解析だけである。 索引 A ABNF 11 absolute 27 absolute-path 26 absolute-URI 27 アクセス 9 authority 17, 18 B 基底 URI 28 C 文字エンコーディング 4 文字 4 文字 8, 11 符号化文字集合 4 Berners-Lee, et al. 標準トラック [56ページ]
RFC 3986 URI 汎用構文 2005年1月 D dec-octet 20 参照解決 9 ドットセグメント 23 F fragment 16, 24 G gen-delims 13 汎用構文 6 H h16 20 hier-part 16 階層的 10 host 18 I 識別子 5 IP-literal 19 IPv4 20 IPv4address 19, 20 IPv6 19 IPv6address 19, 20 IPvFuture 19 L ロケーター 7 ls32 20 M merge 32 N 名前 7 network-path 26 P path 16, 22, 26 path-abempty 22 path-absolute 22 path-empty 22 path-noscheme 22 path-rootless 22 path-abempty 16, 22, 26 path-absolute 16, 22, 26 path-empty 16, 22, 26 Berners-Lee, et al. 標準トラック [57ページ]
RFC 3986 URI 汎用構文 2005年1月 path-rootless 16, 22 pchar 23 pct-encoded 12 パーセントエンコーディング 12 port 22 Q query 16, 23 R reg-name 21 登録名 20 相対 10, 28 relative-path 26 relative-ref 26 remove_dot_segments 33 表現 9 予約済み 12 解決 9, 28 リソース 5 取得 9 S same-document 27 同一性 9 scheme 16, 17 segment 22, 23 segment-nz 23 segment-nz-nc 23 sub-delims 13 サフィックス 27 T 転記 8 U 統一 4 非予約 13 URI 文法 absolute-URI 27 ALPHA 11 authority 18 CR 11 dec-octet 20 DIGIT 11 DQUOTE 11 fragment 24 gen-delims 13 Berners-Lee, et al. 標準トラック [58ページ]
RFC 3986 URI 汎用構文 2005年1月 h16 20 HEXDIG 11 hier-part 16 host 19 IP-literal 19 IPv4address 20 IPv6address 20 IPvFuture 19 LF 11 ls32 20 OCTET 11 path 22 path-abempty 22 path-absolute 22 path-empty 22 path-noscheme 22 path-rootless 22 pchar 23 pct-encoded 12 port 22 query 24 reg-name 21 relative-ref 26 reserved 13 scheme 17 segment 23 segment-nz 23 segment-nz-nc 23 SP 11 sub-delims 13 unreserved 13 URI 16 URI-reference 25 userinfo 18 URI 16 URI-reference 25 URL 7 URN 7 userinfo 18 Berners-Lee, et al. 標準トラック [59ページ]
RFC 3986 URI 汎用構文 2005年1月 著者の住所 Tim Berners-Lee World Wide Web Consortium Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge, MA 02139 USA 電話: +1-617-253-5702 FAX: +1-617-258-5999 メール: timbl@w3.org URI: http://www.w3.org/People/Berners-Lee/ Roy T. Fielding Day Software 5251 California Ave., Suite 110 Irvine, CA 92617 USA 電話: +1-949-679-2960 FAX: +1-949-679-2972 メール: fielding@gbiv.com URI: http://roy.gbiv.com/ Larry Masinter Adobe Systems Incorporated 345 Park Ave San Jose, CA 95110 USA 電話: +1-408-536-3024 メール: LMM@acm.org URI: http://larry.masinter.net/ Berners-Lee, et al. 標準トラック [60ページ]
RFC 3986 URI 汎用構文 2005年1月 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 知的財産 IETF は、この文書に記載された技術の実装または使用に 関係すると主張され得る知的財産権またはその他の権利の 有効性または範囲について、またそのような権利に基づく ライセンスが利用可能であるか否か、その範囲について、 いかなる立場も取らない。また、そのような権利を特定するために 独自の調査を行ったことを表明するものでもない。IETF 文書における 権利に関する IETF の手順については、BCP 78 および BCP 79 を 参照されたい。 IETF 事務局に対して行われた IPR 開示の写し、および 利用可能とされるライセンスに関する保証、または この仕様の実装者または利用者がそのような 専有権を使用するための一般的なライセンスまたは許可を得ようと 試みた結果は、IETF のオンライン IPR リポジトリ http://www.ietf.org/ipr から入手できる。 IETF は、関係者に対し、この標準を実装するために 必要となる可能性のある技術を対象とする著作権、特許、 特許出願、またはその他の専有権について、 IETF に知らせるよう求めている。情報は IETF の ietf- ipr@ietf.org 宛てに送付されたい。 謝辞 RFC Editor 機能の資金は現在、 Internet Society によって提供されている。 Berners-Lee, et al. 標準トラック [61ページ]