統一リソース識別子

URI （Uniform Resource Identifier）は、以前はUniversal Resource Identifierと呼ばれ、抽象的または物理的なリソース（^[1] Webページ上のリソース、メールアドレス、電話番号、^[2]書籍、人や場所などの現実世界のオブジェクト、概念）を識別する一意の文字列です。^{[3] URIは、}リソース記述フレームワーク（RDF）を使用して記述されたものを識別するために使用されます。たとえば、Webオントロジー言語（OWL）を使用して定義されたオントロジーの一部である概念や、 Friend of a Friend語彙を使用して記述された人にはそれぞれ個別のURIがあります。

ネットワーク上（インターネット上、またはコンピュータファイルシステムやイントラネットなどの他のプライベートネットワーク上）の情報リソースを検索および取得する手段を提供する URI は、 Uniform Resource Locator（URL）です。したがって、URL は URI のサブセットであり、つまりすべての URL は URI です（逆は必ずしも当てはまりません）。^[2]その他の URI は、リソースまたはその情報を検索または取得する手段がなく、一意の名前のみを提供します。これらはUniform Resource Name（URN）です。URI を使用する Web テクノロジは、Web ブラウザーに限定されません。

URIとURLには共通の歴史があります。1990年にティム・バーナーズ＝リーがハイパーテキストを提案した際に、ハイパーリンクの対象となるリソースを表す短い文字列としてURLという概念が暗黙的に導入されました。^[4]当時、人々はそれを「ハイパーテキスト名」^[5]または「ドキュメント名」と呼んでいました。

その後 3 年半にわたり、ワールド ワイド ウェブのコア技術であるHTML、HTTP、ウェブ ブラウザが開発されるにつれ、リソースのアドレスを提供する文字列と、リソースに名前を付けるだけの文字列を区別する必要性が生まれました。まだ正式に定義されていませんでしたが、Uniform Resource Locatorという用語が前者を表すようになり、より議論の多いUniform Resource Name が後者を表すようになりました。1992 年 7 月、インターネット技術タスク フォース(IETF) に関するバーナーズ リーのレポート「UDI (Universal Document Identifiers) BOF」では、URL (Uniform Resource Locator として)、URN (元々は Unique Resource Number として)、および新しいワーキング グループの設立の必要性について言及されています。^[6] 1992 年 11 月、IETF「URI ワーキング グループ」が初めて会合を開きました。^[7]

URL と URN の定義をめぐる議論の中で、この 2 つの用語に具体化された概念は、リソース識別という基本的かつ包括的な概念の一側面にすぎないことが明らかになりました。1994 年 6 月、IETF はバーナーズ リーの最初のRequest for Commentsを公開し、URL と URN の存在を認めました。最も重要なのは、Universal Resource Identifiers (URL のような文字列で、その正確な構文と意味はスキームによって決まる) の正式な構文を定義したことです。さらに、RFC  1630 は、当時使用されていた URL スキームの構文をまとめようとしました。相対 URL とフラグメント識別子の存在は認めましたが、標準化はしませんでした。^[8]

1994年12月、RFC  1738は相対URLと絶対URLを正式に定義し、一般的なURL構文を改良し、相対URLを絶対形式に解決する方法を定義し、当時使用されていたURLスキームをより適切に列挙しました。^{[9] URNの合意された定義と構文は、1997年5月のIETF} RFC  2141 ^[10] の発行まで待たなければなりませんでした。

1998年8月にIETF RFC  2396 ^[11]が発行され、URI構文が独立した仕様^{[11]となり、URIおよびURL全般に関するRFC 1630および1738の大部分がIETFによって改訂および拡張されました。新しいRFCでは、} URIのUの意味が「ユニバーサル」から「ユニフォーム」に変更されました。

1999年12月、RFC  2732 ^[12]はRFC 2396 のマイナーアップデートを提供し、URI がIPv6アドレスに対応できるようにしました。2つの仕様で発見された多くの欠点により、RFC 2396 の共著者Roy Fieldingが調整するコミュニティの努力が結実し、2005年1月に IETF RFC  3986 ^[13]が公開されました。この標準は以前の標準を廃止しましたが、既存の URL スキームの詳細が廃止されたわけではなく、特に置き換えられない限り、RFC 1738 が引き続きそのようなスキームを管理しています。たとえば、 IETF RFC  2616 ^[14]はスキームを改良しています。同時に、IETF は RFC 3986 の内容を完全な標準 STD 66 として公開し、URI 汎用構文が公式のインターネットプロトコルとして確立されたことを反映させました。 http

2001年、ワールドワイドウェブコンソーシアム（W3C）の技術アーキテクチャグループ（TAG）は、特定のリソースの複数のバージョンを公開するためのベストプラクティスと正規のURIに関するガイドを公開しました。 ^[15]たとえば、コンテンツは、そのコンテンツにアクセスするために使用されるデバイスの容量や設定に合わせて、言語やサイズによって異なる場合があります。

2002 年 8 月、IETF RFC  3305 ^[16]は、「URL」という用語は、広く一般に使用されているにもかかわらず、ほとんど使われなくなっており、実際の使用に関係なく、ネットワーク アクセスを暗示するスキームを持つ一部の URI がアドレスとして機能することを思い出させるだけの役割しか果たしていないと指摘しました。リソース記述フレームワークなどの URI ベースの標準が明らかにしているように、リソースの識別は、インターネット経由でのリソース表現の取得を示唆する必要はなく、ネットワーク ベースのリソースを暗示する必要もありません。

セマンティックウェブは、実用的な用途のために文書と概念の両方を識別するためにHTTP URIスキームを使用していますが、この区別が両者をどのように区別するかについて混乱を引き起こしています。TAGは2005年に問題の解決策を記載した電子メールを公開し、これはhttpRange-14解決として知られるようになりました。^[17] W3Cはその後、セマンティックウェブのためのクールなURIと題したInterest Group Noteを公開し、コンテンツネゴシエーションとリダイレクトのためのHTTP 303応答コードの使用について詳しく説明しました。^[18]

URN ( Uniform Resource Name ) は、特定の名前空間で名前によってリソースを識別する URI です。URN は、リソースの場所やアクセス方法を暗示することなく、リソースについて説明するために使用できます。たとえば、国際標準図書番号(ISBN) システムでは、ISBN 0-486-27557-4 は、ウィリアム シェイクスピアの戯曲『ロミオとジュリエット』の特定の版を識別します。その版の URN は、urn:isbn:0-486-27557-4になります。ただし、その本のコピーがどこにあるかについての情報は提供されません。

Uniform Resource Locator (URL) は、リソースの操作やリソースの表現の取得の手段を指定する URI です。つまり、リソースの主なアクセス メカニズムとネットワーク上の場所の両方を指定します。たとえば、URL はhttp://example.org/wiki/Main_Pageとして識別されるリソースを参照します。このリソースの表現は、ドメイン名が であるネットワーク ホストからハイパーテキスト転送プロトコル( http:/wiki/Main_Page )を介して取得できます。(この場合、HTTP は通常、リソースがHTMLおよび関連コードの形式であることを意味します。実際には、HTTP ではヘッダーに任意の形式を指定できるため、必ずしもそうであるとは限りません。) example.org

URN は人の名前に似ており、URL は住所に似ています。つまり、URN はアイテムを識別し、URL はアイテムを見つける方法を提供します。

技術出版物、特に IETF と W3C によって作成された標準は、通常、 2001 年 7 月 30 日のW3C 勧告で概説された見解を反映しており、URL と URN への正式な区分を承認するのではなく、URI という用語の優先性を認めています。

URLは便利だが非公式な概念である。URLは、リソースが持つ他の属性ではなく、リソースの主なアクセスメカニズム（ネットワークの「場所」など）の表現を介してリソースを識別するURIの一種である。^[19]

したがって、URL は、ネットワーク上のリソースを指す URI にすぎません。^{[a] [16]}ただし、非技術的なコンテキストや World Wide Web のソフトウェアでは、「URL」という用語は依然として広く使用されています。さらに、「Web アドレス」という用語 (正式な定義はありません) は、非技術的な出版物で、httpまたはhttpsスキームを使用する URI の同義語としてよく使用されます。このような想定は、たとえば、解決可能な URI と視覚的に類似している XML 名前空間の場合に混乱を招く可能性があります。

WHATWG によって作成された仕様ではURIよりもURLが優先されるため、新しいHTML5 APIではURIよりもURLが使用されています。^[20]

URLという用語を標準化しましょう。URIとIRI [国際化リソース識別子]は紛らわしいだけです。実際には、両方に単一のアルゴリズムが使用されているため、区別しても誰の役にも立ちません。また、URLは検索結果の人気度でも簡単に勝ちます。^[21]

ほとんどの URI スキームは、もともと特定のプロトコルで使用するために設計されており、多くの場合同じ名前を持っていますが、プロトコルとは意味が異なります。たとえば、スキームhttpは通常、HTTP を使用してWeb リソースと対話するために使用されますが、スキームファイルにはプロトコルがありません。

URI には、そのスキーム内で識別子を割り当てるための仕様を参照するスキームがあります。そのため、URI 構文は、各スキームの仕様によって、そのスキームを使用する識別子の構文とセマンティクスがさらに制限される可能性がある、統合された拡張可能な命名システムです。URI 汎用構文は、すべての URI スキームの構文のスーパーセットです。これは、 1998 年 8 月に公開されたRFC  2396 で最初に定義され、^{[11] 2005 年 1 月に公開された}RFC  3986で最終決定されました。 ^[22]

URI は、予約文字 (一般区切り文字: 、、、、、、、および ; サブ区切り文字: 、、、、、、、、、、、、、および ) [23] 、非予約文字 (大文字と小文字、10 進数字、、、、、および ) [23] 、および文字 [24] で構成される許可されたASCII文字セットから構成されます^。構文コンポーネントとサブコンポーネントは、予約文字(^{コンポーネント}の一般予約文字のみ)との区切り文字で区切られ、非予約文字、コンポーネントとサブコンポーネントでそれぞれ区切り文字として機能しない予約文字、[13] : §2 、および対応する文字が許可されたセット外であるか、コンポーネントの区切り文字として使用されているか、コンポーネント内に存在する場合^{にパーセント エンコーディング}として表される識別データを定義します。識別データオクテットのパーセントエンコーディングは、文字とそのオクテットの数値を表す2つの16進数字で構成される3つの文字のシーケンスです。 ^{[13] ：§2.1}:/?#[]@!$&'()*+,;=-._~%%

URIの汎用構文は、左から右へ重要度の降順で階層的に構成された5つの構成要素から構成される。 ^{[13] : §3}

URI = スキーム ":" ["//" 権限] パス ["?" クエリ] ["#" フラグメント]

コンポーネントは、関連する区切り文字があり、その区切り文字がURIに現れない場合には未定義である。スキームとパスのコンポーネントは常に定義されている。 ^{[13] : §5.2.1}コンポーネントに文字がない場合、そのコンポーネントは空である。スキームのコンポーネントは常に空ではない。^{[13] : §3}

権限コンポーネントはサブコンポーネントで構成されています:

権限 = [ユーザー情報 "@"] ホスト [":" ポート]

これは構文図では次のように表されます。

URI は次の要素で構成されます。

• 空でないスキーム構成要素の後にコロン (:) が続き、文字で始まり、文字、数字、プラス (+)、ピリオド (.)、またはハイフン (-) の任意の組み合わせが続く文字列で構成されます。スキームは大文字と小文字を区別しませんが、標準形式は小文字であり、スキームを指定する文書では小文字を使用する必要があります。一般的なスキームの例にはhttp、、、、、、、などInternet Assigned Numbers Authority (IANA)に登録する必要がありますが、https実際ftp使用されています。^[b]mailtofiledatairc
• オプション2つのスラッシュ（//） で始まる権限コンポーネントは、次のもので構成されます。
  • オプションuserinfoサブコンポーネントの後にアットマーク (@) が続き、ユーザー名とオプションのパスワード(その前にコロン (:) が付く) で構成されます。userinfo サブコンポーネントでこの形式を使用することusername:password、セキュリティ上の理由から非推奨です。コロンの後のデータが空の文字列 (パスワードがないことを示す) でない限り、アプリケーションは、userinfo サブコンポーネント内にある最初のコロン (:) の後のデータをクリア テキストとしてレンダリングしないでください。
  • あホストサブコンポーネントは、登録名（ホスト名）またはIPアドレス。IPv4ドット10進表記でなければならず、IPv6アドレスは括弧（ ）で囲まなければならない。^{[13]：§3.2.2  [c]}[]
  • オプションコロン ( ) で始まるポート:サブコンポーネント。10 進数で構成されます。
• あパスコンポーネントは、スラッシュ (/) で区切られたパスセグメントのシーケンスで構成されます。URI に対してパスは常に定義されますが、定義されたパスは空 (長さ 0) になる場合があります。セグメントも空になる可能性があり、その//パスコンポーネントには 2 つの連続したスラッシュ ( ) が含まれます。パスコンポーネントは、ファイル システム パスが、必ずしもファイル システム パスとの関係を意味するわけではありません。権限コンポーネントが定義されている場合、パスコンポーネントは空であるか、スラッシュ ( ) で始まっている必要があります/。権限コンポーネントが定義されていない場合、パスは空のセグメント、つまり 2 つのスラッシュ (//) で始まることはできません。これは、次の文字が権限コンポーネントとして解釈されるためです。^{[11] : §3.3}

慣例により、httpおよびhttps URIでは、パスの最後の部分は次のように命名されます。pathinfoはオプションです。これは、既存の物理リソース名 (ファイル、内部モジュール プログラム、実行可能プログラムなど) を参照するのではなく、Web サーバーによって管理される実行可能モジュールまたはプログラムを識別するパスの最初の部分に個別に渡す必要がある論理部分 (コマンドまたは修飾子部分など) を参照する 0 個以上のパス セグメントで構成されます。CGIおよび PATH_INFO などを参照

例：

URI:"http://www.example.com/questions/3456/my-document"

ここで、はパス"/questions"の最初の部分(実行可能モジュールまたはプログラム) であり、 はpathinfoという名前のパスの 2 番目の部分であり、要求されたドキュメントを選択するために、 という名前の実行可能モジュールまたはプログラムに渡されます。"/3456/my-document""/questions"

クエリ部分のないパス情報部分を含む http または https URI は、「クリーンURL 」とも呼ばれ、最後の部分は「スラッグ」である場合があります。

• オプションクエリコンポーネントは、疑問符 (?) で始まり、非階層データのクエリ文字列区切り文字で区切られた属性と値のペア。
• オプションフラグメントコンポーネントの前にハッシュ(#) が付きます。フラグメントには、URI の残りの部分で識別される記事のセクション見出しなど、セカンダリ リソースへの方向を示すフラグメント識別子HTMLドキュメントの場合、フラグメントはid属性、Web ブラウザーはこの要素をスクロールして表示します。

スキームまたは実装固有の予約文字は+、スキーム、ユーザー情報、ホスト、パス、クエリ、フラグメントで使用できます。また、スキームまたは実装固有の予約文字、 、 、 、 、 、 、 、 は、!ユーザー$情報&、'ホスト(、)パス*、,クエリ、フラグメントで使用できます。さらに、汎用予約文字は、ユーザー情報、パス、クエリ、フラグメントで使用できます。汎用予約文字 と は、パス、クエリ、フラグメントで使用できます。汎用予約文字 は、クエリとフラグメントで使用できます。^{[13] : §A};=:@/?

次の図は、URI とその構成要素の例を示しています。

          ユーザー情報       ホストポート┌──┴───┐ ┌──────┴──────┐ ┌┴─┐      
            
  https://john.doe@www.example.com:1234/forum/questions/?tag=networking&order=newest#top
  └─┬─┘    └─────────────┬──────────┘ └────────────┬────────┘ └────────────┬──────────┘ └┬┘スキーム 権限パスクエリフラグメントユーザー情報ホストポート┌──┴───┐ ┌──────┴──────┐ ┌┴─┐  
                                                           
                       
            
  https://john.doe@www.example.com:1234/forum/questions/?tag=networking&order=newest#:~:text=whatever
  └─┬─┘    └─────────────┬────────────┘ └────────────┬────────┘ └────────────┬────────┘ └──────────┬────────┘スキーム権限パスクエリフラグメント  
                                                                  

  ldap://[2001:db8::7]/c=GB?オブジェクトクラス?one
  └┬─┘    └─────┬─────┘ └─┬─┘ └──────┬──────┘スキーム権限パスクエリ​ 
              

  メール送信先:John.Doe@example.com
  └─┬──┘  └────┬──────────────┘スキームパス
       

  ニュース:comp.infosystems.www.servers.unix
  └┬─┘  └─────────────┬──────────────────┘スキームパス
              

  電話:+1-816-555-1212
  └┬┘  └──────┬──────┘スキームパス
      

  telnet://192.0.2.16:80/
  └─┬──┘    └─────┬──────┘ │スキーム権限パス
         

  urn:oasis:名前:仕様:docbook:dtd:xml:4.1.2
  └┬┘  └──────────────────────┬────────────────────┘スキームパス
                      

DOI (デジタル オブジェクト識別子)は、適切な構文によって実現されるため、ハンドル システムと URI システムに適合します。

URI参照は、スキームコンポーネントで始まっていない場合はURIまたは相対参照の:いずれかです（コロン（ ）が続きます）。^{[13] ：§4.1}コロン文字（例：foo:bar）を含むパスセグメントは、パスコンポーネントがスラッシュ（/）で始まっていない場合は、スキームコンポーネントと間違われるため、相対参照の最初のパスセグメントとして使用することはできません。このようなパスセグメントの前にはドットパスセグメント（例： ）がなければなりません./foo:bar。^{[13] ：§4.2}

ウェブ文書マークアップ言語では、外部文書や同じ論理文書の特定の部分など、他のリソースを指すためにURI参照が頻繁に使用される: ^{[13] : §4.4}

• HTMLでは、要素srcの属性の値は、または要素の属性imgの値と同様に URI 参照を提供します。hrefalink
• XMLでは、DTD内のキーワードの後に​​表示されるシステム識別子はフラグメントのない URI 参照です。SYSTEM
• XSLTでは、要素/命令hrefの属性の値はxsl:importURI 参照であり、document()関数の最初の引数も同様です。

https://example.com/path/resource.txt#fragment
//example.com/path/resource.txt
/path/resource.txt
パス/リソース.txt
../リソース.txt
./リソース.txt
リソース.txt
＃断片

URI参照をベースURIに対して解決すると、ターゲットURIが得られる。これは、ベースURIが存在し、絶対URI （フラグメント要素のないURI）であることを意味する。ベースURIは、優先順位に従って、以下から取得できる。^{[13] ：§5.1}

• URI の場合は参照 URI 自体。
• 表現の内容。
• 表現をカプセル化するエンティティ。
• 表現の実際の取得に使用される URI。
• アプリケーションのコンテキスト。

明確に定義されたベースURIを持つ表現内では、

http://a/b/c/d;p?q

相対参照は次のようにしてそのターゲットURIに解決される: ^{[13] : §5.4}

「g:h」->「g:h」
「g」->「http://a/b/c/g」
「./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/」
「./」 -> 「http://a/b/c/」
「..」 -> 「http://a/b/」
「../」 -> 「http://a/b/」
「../g」->「http://a/b/g」
「../..」 -> 「http://a/」
「../../」 -> 「http://a/」
「../../g」→「http://a/g」

URL マンギングとは、URL の末尾に、通常は「?」トークンの後にコマンドを追加する手法です。これは、 HTTPに機能を追加するメカニズムとしてWebDAVでよく使用されます。たとえば、バージョン管理システムで URL に「チェックアウト」コマンドを追加するには、 と記述します。この手法には、 CGI パーサーにとって簡単であるという利点があり、また、この場合は HTTP と基礎となるリソースの間の仲介役としても機能します。^[28]http://editing.com/resource/file.php?command=checkout

XMLでは、名前空間は要素名と属性名の集合を割り当てることができる抽象的なドメインです。名前空間名は、汎用 URI 構文に従う必要がある文字列です。^[29]しかし、名前は一般に URI とは見なされません。^[30] URI 仕様は、語彙要素だけでなく、その使用目的にも基づいて決定するためです。名前空間名は、必ずしも URI スキームのセマンティクスを意味するわけではありません。たとえば、http:で始まる名前空間名は、 HTTPの使用を暗示しない場合があります。

もともと、名前空間名は空でないURI参照の構文と一致することができましたが、相対URI参照の使用はW3Cによって非推奨になりました。^[31] XML 1.1の名前空間に関する別のW3C仕様では、 URI参照に加えて、国際化リソース識別子（IRI）参照が名前空間名の基礎として機能することを許可しています。^[32]

• キュリー
• リンクされたデータ
• 拡張リソース識別子
• 国際化リソース識別子(IRI)
• インターネット リソース ロケーター
• 永続的なユニフォーム リソース ロケータ
• 統一命名規則
• リソースディレクトリ記述言語
• ユニバーサルユニーク識別子
• URI スキームのリスト

• Berners-Lee, Tim ; Fielding, Roy T. ; Masinter, Larry (2005 年 1 月). RFC 3986 Uniform Resource Identifier (URI): Generic Syntax. Internet Engineering Task Force. doi : 10.17487/RFC3986 . RFC 3986 . 2024 年 2 月 16 日に取得。{{citation}}: CS1 maint: multiple names: authors list (link)

• Whitehead, EJ (1998). 「WebDAV: Web 上での共同オーサリングのための IEFT 標準」. IEEE インターネットコンピューティング. 2 (5): 34–40. doi :10.1109/4236.722228. ISSN  1941-0131 . 2021-10-12に取得。

• URI スキーム – IANAが管理する URI スキームのレジストリ
• W3C wiki の URI スキーム
• ワールド ワイド ウェブのアーキテクチャ、第 1 巻、§2: 識別 – W3C による
• W3C URI の明確化