Uniform Resource Identifier

Uniform Resource Identifier（ユニフォーム リソース アイデンティファイア、URI）または統一資源識別子（とういつしげんしきべつし）とは、抽象的または物理的なリソースを識別するためのコンパクトな文字列のことである。また、一定の書式によってリソース（資源）を指し示す識別子である。1998年8月に RFC 2396 として規定され、2005年1月に RFC 3986 として改定された。URI はUniform Resource Locator (URL) の考え方を拡張したものである。URIによって示されるリソースは限定されておらず、インターネット上に存在しない対象や抽象的な概念を示す場合もある。 URI には、以下の2つのサブセットがある。 Uniform Resource Locator (URL) リソースの「場所」を識別する。ネットワーク内の位置を示してリソースを同定する。 Uniform Resource Name (URN) リソースの「名前」を識別する。もしネットワーク上にリソースがなくなっても、一意で永続的な識別を行えるようにする。例えば urn:ietf:rfc:2648 というURNは、RFC 2648への参照を示す。 2001年、W3CはRFC 3305内で、上記の考え方を古典的な見解とした。ここで示されたW3Cの新たな考え方により、従来のURLとURNとはすべてURIと呼ばれることになった。URLやURNといった語はW3Cによって非公式な表現とされた。 2012年、WHATWGによってURL Standardの開発が開始された。URL Standardでは、目標の1つとしてRFC 3986 (URI) とRFC 3987 (IRI) を過去のものにすることを掲げている。また、従来のURIやIRIを区別する必要がないとして、すべてURLの語を用いている。さらに、W3Cでも、このURL Standardのスナップショットをワーキンググループノートとして公開している。 以下のURI共通構文はすべてのスキーム構文で扱うスーパーセットの定義である。なおこの節（下位含む）では2005年1月に発表された RFC 3986 を主に出典とする。 URI = scheme:[//authority]path[?query][#fragment] 構文図（英語版）と各コンポーネントの解説は次の通り。 scheme（スキーム） URIはこの「スキーム」と呼ばれる識別子から始まり、省略できない。階層的識別子（Hierarchical Identifiers）である:（コロン）はスキームの区切り文字でスキーム名の最後に挿入する。 スキーム名は文字で始まり、文字、数字、+（プラス記号）、-（ハイフン）、.（終止符）で構成される文字列となる。大文字と小文字を区別しないが、一貫性を保つために小文字の使用を推奨している。 authority（権限） 権限は//（ダブルスラッシュ）の区切り文字から始まる。userinfo（ユーザー情報）やhost（ホスト）の扱いは各スキームよって異なる。 URIの考案者であるティム・バーナーズ＝リーは2009年10月12日（現地時間）、ニューヨーク・タイムズにて権限の区切り文字であるダブルスラッシュについて「必要ではないことが判明した」と述べている。 path（パス） URIに権限が含まれている場合、パスに文字がなくても/（スラッシュ）で始める必要があり、このことからパスを省略することはできない。権限が含まれていない場合は//で始めることはできない。さらに相対パスである場合は:から始めることはできない。パスに?（疑問符）、#（番号記号）を含む、あるいは末尾の場合、パスの終わりを示す。階層的（hierarchical）に構成されたデータが含まれ、階層は/で区切る。 query（クエリ） クエリは?の区切り文字から始まり、#また末尾で終える。パスと違い、階層的なデータを含まない。RFC 3986、第3章4節において明確な構文は示されていない。 fragment（フラグメント、素片） フラグメントは#の区切り文字から始まる。任意な扱いで、プライマリ（一次）リソースを参照し、セカンダリ（二次）リソースへ提供するフラグメント識別子を含む。クエリと同様に明確な構文は示されていない。 一例としてプライマリリソースがHTMLドキュメントの場合、要素のid属性に何かしらの値を指定し、フラグメントにも同様の値を指定することで、ウェブブラウザは表示の際にその要素の位置までスクロールする。ウィキペディアでは「アンカー」と呼ばれる機能が該当する。 電話番号、電子メールアドレスは RFC 3191 および RFC 3192 で定義されている構文を利用する。 上記で列挙した文字は、URI共通構文で区切りとして予約された文字（Reserved Characters）であるため、コンポーネント内で直接使用することはできない。なお[と]（角括弧）はIPv6の区切り文字である。sub-delimsはURIスキームの仕様によって定義されることがある。 パーセントエンコーディング（Percent-Encoding）は上記で列挙した予約文字などをURIで使えるよう、別の形式に変換する。名前のとおり、パーセント記号%とオクテットを16進数で表現した文字を組み合わせた形式で表す。例えばスペース（空白）文字 をパーセントエンコーディングすると%20に変換される。 予約されていない文字（Unreserved Characters）は、制約がなく、コンポーネント内で自由に使える文字。予約されていない文字は次の通り（RFC 3986 第2章3節）。 英字 ： AからZ、そしてaからz 数字 ： 0から9 一部の記号 ： -、.、_（アンダースコア）、~（チルダ） なおチルダ~は古いURIの仕様によってしばしば%7eに変換されることがある。しかしチルダ含め、予約されていない文字の変換は本来必要ない。 http/httpsスキームの構文を使った例： #共通構文と同じコンポーネントの解説は除く。 userinfo（ユーザー情報、認証情報）はホスト:ポートよりも先に記載する必要がある。開始の区切り文字はなく、@（アットマーク）で区切ることでユーザー情報の終わりを示す。ユーザー情報の形式はuser:passwordである。URIにユーザー情報が付加され、かつその情報が正しければウェブブラウザは認証ダイアログを表示せずプライベートページを表示させることができる。認証情報を平文で示すため、パスワードを含んだ認証情報は非推奨である。これはURL Standardでも同様である。 host（ホスト）はhttp/httpsスキームにおいて必要な権限であり、省略することはできない。port（ポート）はスキームのデフォルトポートであれば省略できる。 クエリはパスに対しての引数であるがその構文は明確に示されていない。一般的な利用法は、「名前」と「値」の組み合わせ（名前-値ペア（英語版）、またはキーペアなど）で扱われ、構文にするとkey=valueとなり、「名前」と「値」の間は=（イコール）で結ぶ。このペアが複数存在する場合、上記構文例のように&（アンパサンド）で繋げる。クエリはWebサーバーおよびクライアント側で処理できる。URL StandardではJavaScript上でクエリ文字列を簡単に扱えるようURLSearchParams()メソッドが実装されている。 フラグメントはクライアントのみ影響する。URIを決定する際、アプリケーションはフラグメントを除外してからサーバーにリクエストを送る。 IANAに登録されているスキームで、利用が続いている一部を掲載する。 javascript ウェブブラウザやHTMLドキュメントでJavaScriptを実行する手段として用いられている。ドラフト状態であったが2011年3月29日に期限切れを迎えた。 いくつかのプログラミング言語や環境では、ネットワーク通信などでURIを扱う際に便利なクラスライブラリなどが標準的に用意されている。Javaではjava.net.URIが、.NETではSystem.Uriが用意されている。Androidではandroid.net.Uriクラスが用意されている。通例、ネットワークリソースだけでなく、ローカルのファイルシステム上におけるリソースを統一的に指し示す目的でも使用される。 Extensible Resource Identifier (XRI) Internationalized Resource Identifier (IRI) 短縮URI (CURIE) Uniform Resource Locator (URL) Uniform Resource Name (URN) 名前空間 パーセントエンコーディング [脚注の使い方] ^ JIS X 4159:2005「拡張可能なマーク付け言語 (XML) 1.0」（日本産業標準調査会、経済産業省） 9頁 ^ Stallings, William (2016). Foundations of modern networking : SDN, NFV, QoE, IoT, and Cloud. Florence Agboma, Sofiene Jelassi. Indianapolis, Indiana. ISBN 978-0-13-417547-8. OCLC 927715441. https://www.worldcat.org/oclc/927715441  ^ Uniform Resource Identifier (URI): Generic Syntax (英語). January 2005. doi:10.17487/RFC3986. RFC 3986。 ^ "Overview of URIs". Uniform Resource Identifier (URI): Generic Syntax (英語). sec. 1.1. doi:10.17487/RFC3986. RFC 3986。 ^ RFC 3305 - URIs, URLs, and URNs: Clarifications and Recommendations 1.0 ^ “URL Standard Goals” (英語). WHATWG (2017年6月23日). 2017年6月23日閲覧。 “Align RFC 3986 and RFC 3987 with contemporary implementations and obsolete them in the process.” ^ “URL Standard （日本語訳） 目標” (2017年6月1日). 2017年6月23日閲覧。 “RFC 3986 と RFC 3987 を現今の実装に揃わせて、その過程の中でそれらを過去のものにする。” ^ “The Web’s Inventor Regrets One Small Thing” (英語). ニューヨーク・タイムズ. (2009年10月12日). https://bits.blogs.nytimes.com/2009/10/12/the-webs-inventor-regrets-one-small-thing/ 2021年8月31日閲覧。  ^ “ウェブ上のリソースの識別”. MDN Web Docs. Mozilla. 2021年9月5日閲覧。 ^ “URLSearchParams”. MDN Web Docs. Mozilla. 2021年8月31日閲覧。 ^ RFC 7230 参照 ^ a b “Uniform Resource Identifier (URI) Schemes” (英語). IANA. 2021年9月1日閲覧。 ^ “draft-hoehrmann-javascript-scheme-03” (英語). Internet Engineering Task Force (2010年9月25日). 2021年9月8日閲覧。 ^ Uri Class (System) | Microsoft Learn ^ Uri  |  Android Developers RFC 2396 - Uniform Resource Identifiers (URI): Generic Syntax (旧) TS X 0097:2004 - 統一資源識別子(URI) 共通構文 標準仕様書(TS) RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax RFC 8820 - URI Design and Ownership URL Standard URL Standard 日本語訳 URL W3C Working Group Note URI Schemes - IANAのURIスキーム登録簿 表示 編集