URL
ページは半保護されています

URL
ユニフォームリソースロケータ
略語URL
状態出版
初版1994 （1994年）
最新バージョン生活水準2023
組織インターネット技術タスクフォース（IETF）
委員会Webハイパーテキストアプリケーション技術ワーキンググループ（WHATWG）
シリーズコメント要求（RFC）
編集者アンネ・ファン・ケステレン
著者ティム・バーナーズ＝リー
基本基準
  • RFC  3986 –「Uniform Resource Identifier (URI): 汎用構文」[ 1 ]インターネット標準66。
  • RFC  4248 – 「Telnet URIスキーム」[ 2 ]
  • RFC  4266 – 「ゴーファーURIスキーム」[ 3 ]
  • RFC  6068 – 「'mailto' URIスキーム」[ 4 ]
  • RFC  6270 – 「'tn3270' URIスキーム」[ 5 ]
関連規格URI、URN
ドメインワールドワイドウェブ
ライセンスCC BY 4.0
Webサイトurl .spec .whatwg .org

ユニフォームリソース ロケータ( URL ) は、口語的にはウェブ アドレス[ 6 ]と呼ばれ、ワールド ワイド ウェブ上のリソースへの参照です。URL は、コンピュータ ネットワーク上のリソースの場所と、そのリソースを取得するためのメカニズムを指定します。URL は、ユニフォーム リソース識別子(URI)の一種ですが[ 7 ] [ 1 ]、多くの人がこの 2 つの用語を同じ意味で使用しています。[ 8 ] [ a ] URL は、ウェブ ページ( HTTP / HTTPS ) を参照するために最もよく使用されますが、ファイル転送 ( FTP )、電子メール ( mailto )、データベース アクセス ( JDBC )、その他多くのアプリケーション にも使用されます。

ほとんどのウェブブラウザでは、ウェブページのURLがアドレスバーの上部に表示されます。ウェブページのURLの例として、https://www.example.com/index.htmlプロトコルhttps、ホスト名www.example.com、ファイル名が挙げられますindex.html。

歴史

ユニフォームリソースロケータは、1992年に開催されたIETFリビングドキュメント のバーズオブアフェザーセッションで始まった共同作業の成果として、ワールドワイドウェブの発明者であるティムバーナーズリーとインターネット技術タスクフォース（IETF）のURIワーキンググループによって1994年にRFC 1738 [ 10 ]で定義されました。 [ 11 ] [ 12 ]

このフォーマットは、既存のドメイン名システム（1985年に作成）とファイルパス構文を組み合わせたもので、スラッシュはディレクトリ名とファイル名を区切るために使用されます。サーバー名を二重スラッシュ（ ）で区切ることで、ファイルパスを完結させるという慣習は既に存在していました//。[ 13 ]

バーナーズ＝リーは後に、 URI内でドメイン名の各部分を区切るためにドットを使用したことを後悔し、全体的にスラッシュを使用すればよかったと述べた。[ 13 ]また、URIの最初の構成要素の後にコロンが続くことを考えると、ドメイン名の前の2つのスラッシュは不要だったとも述べた。[ 14 ]

バーナーズ＝リーを含む初期のWorldWideWeb協力者たちは、当初UDI（Universal Document Identifiers）の使用を提案しました。HTML仕様の初期（1993年）草案[ 15 ]では、「ユニバーサル」リソースロケータ（Universal Resource Locator）に言及されていましたが、1994年6月[ 16 ]から10月[ 17 ]の間に削除されました。バーナーズ＝リーは 著書『Weaving the Web』の中で、当初の拡張において「universal」という語を「uniform」ではなく「universal」に含めていたことを強調し、後に「uniform」に変更された経緯についても簡潔に説明しています。

構文

すべてのHTTP URLは、汎用URIの構文に準拠しています。汎用URI構文は、左から右へ重要度の降順で階層的に構成された5つの要素で構成されています。 [ 1 ]：§3 

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

コンポーネントは、関連する区切り文字を持ち、その区切り文字がURIに現れない場合には未定義です。スキームコンポーネントとパスコンポーネントは常に定義されています。 [ 1 ]：§5.2.1 コンポーネントに文字がない場合、そのコンポーネントは空です。スキームコンポーネントは常に空ではありません。[ 1 ]：§3

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

権限 = [userinfo "@"] ホスト [":" ポート]

これを構文図で表すと次のようになります。

URI構文図

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

  • 空でないスキーム構成要素は:、文字で始まり、文字、数字、プラス記号 (+)、ピリオド (.)、またはハイフン (で-あり、スキームを指定する文書は小文字で記述する必要があります。一般的なスキームの例としてはhttp、、、、、、などがAssignedNumbers Authority (IANA)に登録する必要がありますが、実際には登録されていないスキームも使用されていますhttps。 [ 18 ]ftpmailtofiledatairc
  • オプション2つのスラッシュ（//） で始まる権限コンポーネントは、次のもので構成されます。
    • オプションuserinfoサブコンポーネントの後にアットマーク (@) が続く形式は、ユーザー名コロン ( ) に続くオプションのパスワード:。userinfo サブコンポーネント内でこの形式を使用することは、、userinfo サブコンポーネント内の最初のコロン ( ) 以降のデータを、コロン以降のデータが空文字列 (パスワードなしを示す) でない限り、username:password平文としてレンダリングしないでください:
    • あホストサブコンポーネントは、登録名（ホスト名）またはIPアドレス。IPv4はドット付き10進表記でなければならず、IPv6アドレスは角括弧（ ）で囲む必要があります[]。 [ 1 ] : §3.2.2 [ b ]
    • オプションコロン ( ) で始まるポート:サブコンポーネント。10進数字で構成されます。
  • あパスコンポーネントは、スラッシュ ( ) で区切られたパスセグメントのシーケンスで構成されます/。URI に対してパスは常に定義されますが、定義されたパスは空 (長さ 0) になる場合があります。セグメントも空になる可能性があり、その場合は//パスコンポーネントに 2 つの連続したスラッシュ ( ) が含まれます。パスコンポーネントはファイルシステムパスが、必ずしもファイルシステムパスとの関係を意味するわけではありません。権限コンポーネントが定義されている場合、パスコンポーネントは空であるか、スラッシュ (/) で始まっている必要があります。権限コンポーネントが定義されていない場合、パスは空のセグメント、つまり 2 つのスラッシュ (//) で始まることはできません。これは、後続の文字が権限コンポーネントとして解釈されるためです。 [ 20 ] : §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 」と呼ばれることもあり、その最後の部分は「スラッグ」である場合があります。
クエリ区切り文字 例
アンパサンド（&） key1=value1&key2=value2
セミコロン ( ;) [ c ]key1=value1;key2=value2
  • オプションクエリコンポーネントは、疑問符（?）で始まり、クエリ文字列、属性と値のペアを区切り文字で区切ったシーケンスで構成されることが多いです。
  • オプションハッシュ（で始まるフラグメント#構成要素。フラグメントには、URIの残りの部分で識別される記事内のセクション見出しなど、二次リソースへの方向を示すフラグメント識別子がHTMLドキュメントの場合、フラグメントはid属性で、ウェブブラウザはこの要素をスクロールして表示します。

Web ブラウザは通常、指定されたホスト (デフォルトではポート番号 80) へのHTTP要求を実行することによって URL を逆参照します。このスキームを使用する URL では、要求と応答がWeb サイトへの安全な接続を介して行われることが必要です。 https

国際化されたURL

インターネットユーザーは世界中に分散しており、多様な言語とアルファベットを使用しているため、それぞれの地域のアルファベットでURLを作成できることを期待しています。国際化リソース識別子（IRI）は、 Unicode文字を含むURLの形式です。すべての最新ブラウザはIRIをサポートしています。URLの中で、異なるアルファベットに対応するために特別な処理が必要な部分は、ドメイン名とパスです。[ 23 ] [ 24 ]

IRIで示されるドメイン名は、国際化ドメイン名（IDN）と呼ばれます。Webおよびインターネットソフトウェアは、ドメイン名をドメインネームシステムで使用可能なPunycodeに自動的に変換します。例えば、中国語のURLは になります。 は、その文字が元々ASCII文字ではなかったことを示します。[ 25 ]http://例子.卷筒纸http://xn--fsqu00a.xn--3lr804guic/xn--

URLパス名は、ユーザーがローカルの表記法で指定することもできます。まだエンコードされていない場合はUTF-8に変換され、URLの基本文字セットに含まれない文字はパーセントエンコーディングを使用して16進数としてエスケープされます。例えば、日本語のURLは になります。ターゲットコンピュータはアドレスをデコードし、ページを表示します。[ 23 ] http://example.com/引き割り.htmlhttp://example.com/%E5%BC%95%E3%81%8D%E5%89%B2%E3%82%8A.html

プロトコル相対URL

プロトコル相対リンク（PRL）は、プロトコル相対URL（PRURL）とも呼ばれ、プロトコルが指定されていないURLです。例えば、//example.com現在のページのプロトコル（通常はHTTPまたはHTTPS）が使用されます。[ 26 ] [ 27 ]

参照

注記

  1. ^ URLは指定されたリソースにアクセスするための手段を意味し、プロトコルまたはアクセスメカニズムによって示されますが、これはすべてのURIに当てはまるわけではありません。 [ 1 ] [ 8 ]したがって、http://www.example.comはURLですが、はそうではwww.example.comありません。 [ 9 ]
  2. ^ワールドワイドウェブ上のリソースに関連するURIについては、一部のウェブブラウザでは.0ドット付き10進表記の一部を削除したり、生の整数IPアドレスを使用したりできます。 [ 19 ]
  3. ^歴史的なRFC  1866（RFC  2854 [ 21 ]によって廃止）では、CGI作者に「&」に加えて「;」をサポートすることを推奨しています。 [ 22 ]：§8.2.1

引用

  1. ^ a b c d e f g T. Berners-Lee ; R. Fielding ; L. Masinter (2005年1月). Uniform Resource Identifier (URI): Generic Syntax . Network Working Group. doi : 10.17487/RFC3986 . STD 66. RFC 3986 .インターネット 標準66。RFC 2732、2396、1808を 廃止。RFC 6874、7320、8820 により更新。RFC 1738 を更新。​​​​
  2. ^ P. Hoffman (2005年10月). Telnet URIスキーム. ネットワークワーキンググループ. doi : 10.17487/RFC4248 . RFC 4248 .提案された標準。RFC 1738を  廃止します。
  3. ^ P. Hoffman (2005年11月). Gopher URIスキーム. ネットワークワーキンググループ. doi : 10.17487/RFC4266 . RFC 4266 .提案された標準。RFC 1738を  廃止します。
  4. ^ M. Duerst; L. Masinter ; J. Zawinski (2010年10月). 「mailto」URIスキーム. Internet Engineering Task Force . doi : 10.17487/RFC6068 . ISSN 2070-1721 . RFC 6068 . 提案された標準。RFC 2368を  廃止します。
  5. ^ M. Yevstifeyev (2011年6月). 「tn3270」URIスキーム.インターネット技術タスクフォース. doi : 10.17487/RFC6270 . ISSN 2070-1721 . RFC 6270 . 提案された標準。RFC 1041、1738  、および2355を更新し ます。
  6. ^ W3C (2009) .
  7. ^ 「URLのフォワードスラッシュとバックスラッシュ」zzz.buzz . 2018年9月4日時点のオリジナルよりアーカイブ。2018年9月19日閲覧。
  8. ^ a b Mealling, Michael H.; Denenberg, Ray (2002年8月). W3C/IETF URI計画共同インタレストグループからの報告書: Uniform Resource Identifiers (URI), URL, and Uniform Resource Names (URN): 明確化と推奨事項. ネットワークワーキンググループ. doi : 10.17487/RFC3305 . RFC 3305 .情報提供。
  9. ^ Miessler, Daniel. 「URLとURIの違い」 . 2017年3月17日時点のオリジナルよりアーカイブ。2017年3月16日閲覧。
  10. ^ T. Berners-Lee ; L. Masinter ; M. McCahill (1994年12月). Uniform Resource Locators (URL) . Network Working Group. doi : 10.17487/RFC1738 . RFC 1738 .廃止。RFC 4248 および4266により 廃止。RFC 1808、2368、2396、3986、6196、6270、8089 により更新。​​​​​​​​​​
  11. ^ a b W3C (1994) .
  12. ^ IETF (1992) .
  13. ^ a bバーナーズ＝リー (2015) .
  14. ^ BBCニュース (2009) .
  15. ^バーナーズ＝リー、ティム、ダニエル・コノリー（1993年3月）。ハイパーテキスト・マークアップ言語（RFCxxx草案）（技術報告書）。p. 28。2017年10月23日時点のオリジナルよりアーカイブ。 2017年10月23日閲覧。
  16. ^ Berners-Lee, Tim (1994年6月). 「WWWにおけるユニバーサルリソース識別子：ワールドワイドウェブで使用されるネットワーク上のオブジェクトの名前とアドレスを表現するための統一構文」 . ネットワークワーキンググループ. doi : 10.17487/RFC1630 . RFC 1630 .情報提供。
  17. ^ Berners-Lee, Tim ; Masinter, Larry ; McCahill, Mark Perry (1994年10月). Uniform Resource Locators (URL) (技術レポート).（このインターネットドラフトは、同年後半にRFC 1738として公開されました。）Ang, CS; Martin, DC (1995年1月). Constituent Component Interface++ (技術レポート). UCSF Library and Center for Knowledge Management. 2017年10月23日時点のオリジナルよりアーカイブ。 2017年10月23日閲覧。
  18. ^ Hansen, Tony; Hardie, Ted (2015年6月). Thaler, Dave (編). URIスキームのガイドラインと登録手順. Internet Engineering Task Force . doi : 10.17487/RFC7595 . ISSN 2070-1721 . BCP 35. RFC 7595 . 現在のベストプラクティス 35。RFC 8615  により更新。RFC 4395 は廃止。
  19. ^ローレンス (2014) .
  20. ^ T. Berners-Lee ; R. Fielding ; L. Masinter (1998年8月). Uniform Resource Identifiers (URI): Generic Syntax . Network Working Group. doi : 10.17487/RFC2396 . RFC 2396 .廃止。RFC 3986  により廃止。RFC 2732 により更新。RFC 1808 および1738を更新。
  21. ^ D. Connolly ; L. Masinter (2000年6月). 「text/html」メディアタイプ. ネットワークワーキンググループ. doi : 10.17487/RFC2854 . RFC 2854 .情報提供/ レガシー。RFC 1980、1867、1942、1866、2070は 廃止さ れます。IETF による承認は受けていません。
  22. ^ Berners-Lee, Tim ; Connolly, Daniel W. (1995年11月). Hypertext Markup Language - 2.0 . Network Working Group. doi : 10.17487/RFC1866 . RFC 1866 .歴史的。RFC 2854  により廃止されました。
  23. ^ a b W3C (2008) .
  24. ^ W3C (2014) .
  25. ^ IANA (2003) .
  26. ^ Glaser, JD (2014-03-10). 『モバイルアプリのセキュア開発：PHPとJavaScriptによるセキュアなモバイルアプリケーションの設計とコーディング方法』（第1版）CRC Press . p. 193. ISBN 978-1-48220903-7. 2015年10月12日閲覧。
  27. ^ Schafer, Steven M. (2011). HTML, XHTML, and CSS Bible (第1版). John Wiley & Sons . p. 124. ISBN 978-1-11808130-3. 2015年10月12日閲覧。

参考文献

「 https://en.wikipedia.org/w/index.php?title=URL&oldid=1321410336」から取得