ユニフォームリソース識別子

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ
ユニフォームリソース識別子(URI)
略語URI
ドメインワールドワイドウェブ

ユニフォームリソース識別子URI)は、Webテクノロジで使用される論理リソースまたは物理リソースを識別する一意の文字シーケンスですURIは、人や場所などの実世界のオブジェクト、概念、またはWebページや本などの情報リソースを含むあらゆるものを識別するために使用できます。一部のURIは、ネットワーク(インターネット上、またはコンピューターファイルシステムやイントラネットなどの別のプライベートネットワーク上)で情報リソースを検索および取得する手段を提供します。これらはUniformResourceLocatorです(URL)。URLは、リソースの場所を提供します。URIは、指定された場所またはURLにある名前でリソースを識別します。他のURIは一意の名前のみを提供し、リソースまたはその情報を検索または取得する手段はありません。これらはURI( Uniform Resource Names)です。URIを使用するWebテクノロジーは、Webブラウザーに限定されません。URIは、 Resource Description Framework (RDF)を使用して記述されたものを識別するために使用されます。たとえば、Webオントロジー言語(OWL)を使用して定義されたオントロジーの一部である概念や、 Friend of aFriendの語彙を使用して記述された人々はそれぞれ個別のURIを持っています。

歴史

構想

URIとURLには共有履歴があります。1990年、Tim Berners-Leeのハイパーテキストの提案では、ハイパーリンクのターゲットであるリソースを表す短い文字列としてURLの概念が暗黙的に導入されました[1]当時、人々はそれを「ハイパーテキスト名」[2]または「ドキュメント名」と呼んでいました。

次の3年半にわたって、ワールドワイドウェブのHTML、HTTP、およびWebブラウザのコアテクノロジが開発されるにつれて、リソースのアドレスを提供する文字列と、単にリソースに名前を付けるだけの文字列を区別する必要が生じました。まだ正式には定義されていませんが、Uniform Resource Locatorという用語は前者を表すようになり、より論争の多いUniform ResourceNameは後者を表すようになりました。1992年7月、IETF「UDI(Universal Document Identifiers)BOF」に関するBerners-Leeのレポートでは、URL(Uniform Resource Locatorとして)、URN(元々はUnique Resource Numbersとして)、および新しいワーキンググループをチャーターする必要性について言及しています。[3] 1992年11月にIETF「URIワーキンググループ」が初めて開催されました。[4]

URLとURNの定義に関する議論の中で、2つの用語によって具体化された概念は、リソース識別の基本的で包括的な概念の単なる側面であることが明らかになりました。1994年6月、IETFは、URLとURNの存在を認めたBerners-Leeの最初のコメント要求を公開しました。最も重要なことは、Universal Resource Identifiersの正式な構文(つまり、正確な構文とセマンティクスがスキームに依存するURLのような文字列)を定義したことです。さらに、RFC  1630は、その時点で使用されていたURLスキームの構文を要約しようとしました。それは認めました-しかし標準化しませんでした-相対URLとフラグメント識別子の存在。[5]

改良

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

1998年8月のIETFRFC 2396 [8]の公開により、URI構文が別個の仕様になり[9]、URIおよびURL全般に関連するRFC1630および1738のほとんどの部分がIETFによって改訂および拡張されました。新しいRFCは、「URI」の「U」の意味を「Universal」から「Uniform」に変更しました。

1999年12月、RFC 2732 [10]はRFC2396のマイナーアップデートを提供し、URIがIPv6アドレスに対応できるようにしました。 2つの仕様で発見された多くの欠点は、RFC2396の共著者であるRoyFieldingによって調整されたコミュニティの取り組みにつながり、2005年1月にIETF RFC 3986 [11]が公開されました。以前の標準は廃止されましたが、そうではありませんでした。既存のURLスキームの詳細を廃止します。 RFC 1738は、他の方法で置き換えられた場合を除いて、このようなスキームを引き続き管理します。たとえば、IETF RFC 2616 [12]は、 http図式。同時に、IETFは、公式のインターネットプロトコルとしてのURI汎用構文の確立を反映して、RFC3986のコンテンツを完全な標準STD66として公開しました。

2001年、W3CのTechnical Architecture Group(TAG)は、特定のリソースの複数のバージョンを公開するためのベストプラクティスと正規URIのガイドを公開しました。[13]たとえば、コンテンツは、そのコンテンツへのアクセスに使用されるデバイスの容量または設定を調整するために、言語またはサイズによって異なる場合があります。

2002年8月、IETF RFC 3305 [14]は、「URL」という用語は、広く一般に使用されているにもかかわらず、ほとんど時代遅れになり、一部のURIは、ネットワークのアクセシビリティを暗示するスキームを持つことにより、アドレスとして機能することを思い出させるものとしてのみ機能することを指摘しました。そのような実際の使用の。Resource Description FrameworkなどのURIベースの標準が明らかにしているように、リソースの識別は、インターネットを介したリソース表現の取得を示唆する必要はなく、ネットワークベースのリソースを暗示する必要もありません。  

セマンティックWebは、HTTP URIスキームを使用して、現実世界のドキュメントと概念の両方を識別します。この区別により、2つを区別する方法について混乱が生じています。TAGは、問題を解決する方法について2005年に電子メールを公開しました。これは、httpRange-14解像度として知られるようになりました。[15] W3Cはその後、セマンティックWebのクールURIというタイトルのインタレストグループノートを公開しました。これは、コンテンツネゴシエーションとリダイレクトのためのHTTP303応答コードの使用をより詳細に説明しています。[16]

デザイン

URLとURN

ユニフォームリソース名(URN)は、特定の名前空間内のリソースを名前で識別するURIですURNは、リソースの場所やアクセス方法を暗示することなく、リソースについて話すために使用できます。たとえば、国際標準図書番号(ISBN)システムでは、ISBN 0-486-27557-4は、シェイクスピアの演劇ロミオとジュリエットの特定の版を識別します。そのエディションのURNはurn:isbn:0-486-27557-4になります。ただし、その本のコピーがどこにあるかについての情報はありません。

URL (Uniform Resource Locator)は、リソースに作用したり、リソースの表現を取得したりする手段を指定するURIです。つまり、プライマリアクセスメカニズムとネットワークの場所の両方を指定します。たとえば、URLhttp://example.org/wiki/Main_Pageは、として識別されるリソースを参照します/wiki/Main_Page。その表現は、HTMLおよび関連コードの形式で、ドメイン名が。のネットワークホストからハイパーテキスト転送プロトコルhttp :)を介して取得できます。 example.org

URNは人の名前と比較される場合があり、URLはその人の住所と比較される場合があります。つまり、URNはアイテムを識別し、URLはアイテムを見つけるための方法を提供します。

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

URLは便利ですが、非公式な概念です。URLは、他の属性ではなく、プライマリアクセスメカニズム(ネットワークの「場所」など)の表現を介してリソースを識別するURIの一種です。[17]

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

WHATWG によって作成された仕様はURIよりもURL優先するため、新しいHTML5APIはURIよりもURLを使用します[19]

URLという用語で標準化します。URIとIRI [Internationalized ResourceIdentifier]は紛らわしいだけです。実際には、両方に単一のアルゴリズムが使用されるため、それらを区別しておくことは誰にも役立ちません。URLも検索結果人気コンテストに簡単に勝ちます。[20]

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

構文

各URIは、そのスキーム内で識別子を割り当てるための仕様を参照するスキーム名で始まります。そのため、URI構文は、統合された拡張可能なネーミングシステムであり、各スキ​​ームの仕様により、そのスキームを使用する識別子の構文とセマンティクスがさらに制限される場合があります。URIの一般的な構文は、すべてのURIスキームの構文のスーパーセットです。これは、1998年8月に公開されたRFC 2396 [9]で最初に定義され、2005年1月に公開されたRFC3986で最終 決定されました。 [21] 

URIの一般的な構文は、5つのコンポーネントの階層シーケンスで構成されています[22]

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

ここで、権限コンポーネントは3つのサブコンポーネントに分割されます

Authority = [userinfo "@"] host [":" port]

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

URI構文図

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

  • 空でないスキームコンポーネントの後にコロン(:)が続き、文字で始まり、文字、数字、プラス(+)、ピリオド(.)、またはハイフン(-)の任意の組み合わせが続く文字のシーケンスで構成されます。スキームでは大文字と小文字は区別されませんが、標準形は小文字であり、スキームを指定するドキュメントでは小文字を使用する必要があります。一般的例には、、、、、、、httpおよび含まます。URIスキームは、Internet Assigned Numbers Authority(IANA)に登録する必要がありますが、実際には未登録のスキームが使用されます。[b]httpsftpmailtofiledatairc
  • オプション2つのスラッシュ(//が前に付いた権限コンポーネント。
    • オプションuserinfoサブコンポーネント。ユーザー名とオプションのパスワードの前にコロン(:)が続き、その後にアット@ます。userinfoサブコンポーネントでの形式の使用は、username:passwordセキュリティ上の理由から非推奨です。:コロンの後のデータが空の文字列(パスワードがないことを示す)でない限り、アプリケーションは、userinfoサブコンポーネント内で見つかった最初のコロン()の後のデータをクリアテキストとしてレンダリングしないでください
    • A登録名(ホスト名を含むがこれに限定されない)またはIPアドレスのいずれかで構成されるホストサブコンポーネント。IPv4アドレスはドット付き10進表記である必要があり、IPv6アドレスは角かっこ()で囲む必要があります[][24] [c]
    • オプションコロン()が前に付いたポート:サブコンポーネント。
  • Aパス/コンポーネント。スラッシュ( )で区切られた一連のパスセグメントで構成され定義されたパスは空(長さがゼロ)の場合もありますが、パスは常にURIに対して定義されます。セグメントが空の場合もあり//、パスコンポーネントに2つの連続したスラッシュ()が含まれる場合があります。パスコンポーネントは、ファイルシステムパスに類似しているか、正確にマップされている場合がありが、必ずしもファイルシステムパス権限コンポーネントが存在する場合、パスコンポーネントは空であるか、スラッシュ(/)で始まる必要があります。//権限コンポーネントが存在しない場合、次の文字が権限コンポーネントとして解釈されるため、パスを空のセグメント、つまり2つのスラッシュ()で始めることはできません[26]
:慣例により、httpおよびhttps URIでは、パスの最後の部分に名前が付けられますpathinfoおよびそれはオプションです。これは、既存の物理リソース名(ファイル、内部モジュールプログラム、実行可能プログラムなど)を参照せず、論理部分(コマンド、修飾子部分など)を参照する0個以上のパスセグメントで構成されます。Webサーバーによって管理される実行可能モジュールまたはプログラムを識別するパスの最初の部分に個別に渡されこれは、動的コンテンツ(ドキュメントなど)を選択したり、要求に応じてコンテンツを調整したりするためによく使用されます(CGIやPATH_INFOなども参照)。
例:
URI:"http://www.example.com/questions/3456/my-document"
ここで、はパス"/questions"の最初の部分(実行可能モジュールまたはプログラム)であり、 pathinfoという名前のパスの2番目の部分であり、要求されたドキュメントを選択するために指定された実行可能モジュールまたはプログラムに渡されます。"/3456/my-document""/questions"
クエリ部分のないpathinfo部分を含むhttpまたはhttpsURIは、「クリーンURL 」と呼ばれることもあり、その最後の部分は「スラッグ」である可能性があります。
クエリ区切り文字
アンパサンド(& key1=value1&key2=value2
セミコロン(;[d] key1=value1;key2=value2
  • オプション非階層データクエリ文字列?を含む、疑問符()が前に付いたクエリコンポーネント。その構文は明確に定義されていませんが、慣例により、ほとんどの場合区切り文字れた属性と値のペア
  • オプションハッシュ )が前に付いたフラグメントコンポーネント#フラグメントには、URIの残りの部分で識別される記事のセクション見出しなど、セカンダリリソースへの方向を提供フラグメント識別子が含まれていプライマリリソースがHTMLドキュメントの場合、フラグメントは特定の要素のid属性であることが多く、Webブラウザはこの要素をスクロールして表示します。

URI内のデータオクテットの文字列は文字として表されます。URI内で許可される文字は、現代英語のアルファベットの小文字と大文字のASCII文字、アラビア数字ハイフンピリオドアンダースコア、およびチルダです。[28]他の文字で表されるオクテットは、パーセントエンコードする必要があります。

ASCII文字セットのうち、文字: / ? # [ ] @は汎用URIコンポーネントの区切り文字として使用するために予約されており、たとえば%3F疑問符の場合はパーセントエンコードする必要があります。[29]文字! $ & ' ( ) * + , ; =は、一般的なURI構文によって、ユーザー情報、ホスト、およびパスで区切り文字としてエンコードせずに使用することが許可されています。[24] [30]さらに、パス、クエリ、:および@フラグメント内でエンコードされていないように見える場合があります。クエリまたはフラグメント内のデータとしてエンコードされていないように見える場合があり?ます[30] [31]/

次の図は、URIの例とそのコンポーネントパーツを示しています。

          userinfo       ホスト      ポート
          ┌──┴───┐┌──────┴──────┐┌┴┐  _  _
  https://[email protected]:123 / forum / questions /?tag = networking&order = newest#top
  └─┬─┘└───────────┬──────────────┘└───────┬───────┘    _ _  └───────────┬─────────────┘└┬┘ スキーム権限パスクエリフラグメント_
                                                          

  ldap:// [2001:db8 :: 7] / c = GB?objectClass?one
  └┬─┘└─────┬─────┘└─┬─┘└──────┬──────┘
  スキーム権限パスクエリ

  mailto:[email protected]
  └─┬──┘└────┬─────────────┘
  スキームパス

  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
  └┬┘└──────────────────────┬──────────────────────┘
  スキームパス

URI参照

URI参照は、URI、またはスキームコンポーネントで始まり、その後にコロン( )が続く相対参照のいずれか:です。[32]コロン文字(たとえばfoo:bar)を含むパスセグメントは、そのパスコンポーネントがスラッシュ()で始まらない場合/、スキームコンポーネントと間違われるため、相対参照の最初のパスセグメントとして使用できません。このようなパスセグメントの前には、ドットパスセグメント(例./foo:bar)を付ける必要があります。[33]

Webドキュメントマークアップ言語は、外部ドキュメントや同じ論理ドキュメントの特定の部分など、他のリソースを指すためにURI参照を頻繁に使用します。[34]

  • 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
path / resource.txt
../resource.txt
./resource.txt
resource.txt
#断片

解像度

ベースURIに対してURI参照を解決すると、ターゲットURIになります。これは、ベースURIが存在し、絶対URI(フラグメントコンポーネントのないURI)であることを意味します。ベースURIは、優先順位の高い順に、 [35]から取得できます。

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

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

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

相対参照は、次のようにターゲットURIに解決されます。[36]

"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の変更は、コマンドをURLの最後、通常は「?」の後に追加する手法です。トークンこれは、 HTTPに機能を追加するメカニズムとしてWebDAVで一般的に使用されますたとえば、バージョニングシステムでは、「チェックアウト」コマンドをURLに追加するために、として記述されます。これには、 CGIパーサーにとって簡単であるだけでなく、この場合はHTTPと基盤となるリソースの間の仲介役としても機能するという利点があります。[37]http://editing.com/resource/file.php?command=checkout

XML名前空間との関係

XMLでは名前空間は、要素名と属性名のコレクションを割り当てることができる抽象ドメインです。名前空間名は、一般的なURI構文に準拠する必要がある文字列です。[38]ただし、 URI仕様は字句コンポーネントだけでなく、それらの使用目的にも基づいて決定されるため、名前は一般にURIとは見なされません[39] 。名前空間名は、必ずしもURIスキームのセマンティクスを意味するわけではありません。たとえば、http:で始まる名前空間名には、 HTTPの使用を意味しない場合があります

元々、名前空間名は空でないURI参照の構文と一致する可能性がありましたが、相対URI参照の使用はW3Cによって非推奨になりました。[40] XML 1.1の名前空間に関する個別のW3C仕様では、URI参照に加えて、 Internationalized Resource Identifier(IRI)参照を名前空間名の基礎として機能させることができます。[41]

も参照してください

メモ

  1. ^ 2002年にW3C / IETFの合同作業部会によって発行されたレポートは、さまざまな「UR *」用語と標準の関係についてIETFとW3C内で保持されている異なる見解を正規化することを目的としています。どちらの組織からも完全な標準として公開されていませんが、それは上記の一般的な理解の基礎となり、それ以来多くの標準に情報を提供してきました。
  2. ^ 新しいURIスキームを登録する手順は、1999年にRFC 2717によって最初に定義され、現在は2015年6月に公開されたRFC7595によって定義されています 。 [23] 
  3. ^ World Wide Web上のリソースに関連するURIの場合、一部のWebブラウザー.0では、ドット付き10進表記の一部を削除したり、生の整数IPアドレスを使用したりできます。[25]
  4. ^ 歴史的なRFC1866(RFC 2854で廃止、CGIの作成者が ';'をサポートすることを推奨しています。 に加えて '&'。[27] 

参考文献

  1. ^ パーマー、ショーン。「HTMLの初期の歴史」infomesh.net 2020年12月6日取得
  2. ^ 「W3命名スキーム」www.w3.org1992 2020年12月6日取得
  3. ^ 「第24インターネット技術特別調査委員会の議事録」(PDF)p。193 2021年7月27日取得
  4. ^ 「第25インターネット技術特別調査委員会の議事録」(PDF)p。501 2021年7月27日取得
  5. ^ Berners-Lee、Tim(1994年6月)。「WWWのUniversalResourceIdentifiers」ネットワークワーキンググループ2020年12月6日取得 {{cite journal}}引用ジャーナルには|journal=ヘルプ)が必要です
  6. ^ Berners-Lee、Tim(1994年12月)。"Request for Comments:1738:ユニフォームリソースロケーター(URL)"tools.ietf.org/html 2020年12月6日取得
  7. ^ Moats、R。(1997年5月)。"Request for Comments:2141:URN構文"tools.ietf.org 2020年12月6日取得
  8. ^ Berners-Lee、Tim(1998年8月)。「RFC2396:URI(Uniform Resource Identifiers):汎用構文」tools.ietf.org 2020年12月6日取得
  9. ^ a b RFC 2396(1998)
  10. ^ Hinden、R。(1999年12月)。「RFC2732:URLのリテラルIPv6アドレスのフォーマット」tools.ietf.org 2020年12月6日取得
  11. ^ Berners-Lee、Tim(2005年1月)。「RFC3986:URI(Uniform Resource Identifier):汎用構文」tools.ietf.org 2020年12月6日取得
  12. ^ フィールディング、R。(1999年6月)。「RFC2616:ハイパーテキスト転送プロトコル-HTTP /1.1」tools.ietf.org 2020年12月6日取得
  13. ^ ラマン、テレビ(2006-11-01)。「検出と公開を可能にするための代替表現のリンクについて」www.w3.org 2020年12月6日取得
  14. ^ Mealling、M。(2002年8月)。「RFC3305:URI(Uniform Resource Identifiers)、URL、およびUniform ResourceNames」tools.ietf.org 2020年12月6日取得
  15. ^ フィールディング、ロイ(2005-06-18)。「[httpRange-14]解決済み」lists.w3.org 2020年12月6日取得
  16. ^ Sauermann、レオ(2008年12月)。「セマンティックWebのクールなURI」www.w3.org 2020年12月6日取得
  17. ^ URI計画利益団体、W3C / IETF(2001年9月)。「URI、URL、およびURN:説明と推奨事項1.0」www.w3.orgW3C / IETF 2020年12月8日取得
  18. ^ 共同W3C / IETF URI計画利益団体(2002)
  19. ^ 「URL標準:6.3。他の場所のURLAPI」
  20. ^ 「URL標準:目標」
  21. ^ RFC 3986(2005)
  22. ^ RFC 3986、セクション3(2005)
  23. ^ IETF(2015)
  24. ^ a b RFC 3986(2005)、§3.2.2。
  25. ^ ローレンス(2014)
  26. ^ RFC 2396(1998)、§3.3。
  27. ^ RFC 1866(1995)、§8.2.1。
  28. ^ RFC 3986(2005)、§2。
  29. ^ RFC 3986(2005)、§2.2。
  30. ^ a b RFC 3986(2005)、§3.3。
  31. ^ RFC 3986(2005)、§3.4。
  32. ^ RFC 3986(2005)、§4.1。
  33. ^ RFC 3986(2005)、§4.2。
  34. ^ RFC 3986(2005)、§4.4。
  35. ^ RFC 3986(2005)、§5.1。
  36. ^ RFC 3986(2005)、§5.4。
  37. ^ Whitehead 1998、p。38。
  38. ^ モリソン(2006)
  39. ^ ハロルド(2004)
  40. ^ W3C(2009)
  41. ^ W3C(2006)

さらに読む

外部リンク