この記事には
複数の問題があります 。
改善 やノートページ での議論にご協力ください。
Uniform Resource Identifier （ユニフォーム リソース アイデンティファイア、URI ）とは、抽象的または物理的なリソースを識別するためのコンパクトな文字列のことである[ 1] リソース （資源）を指し示す識別子 である[ 2] 統一資源識別子 （とういつしげんしきべつし）とも[ 3]
1998年 8月に RFC 2396 として規定され、2005年 1月に RFC 3986 として改定された。URI はUniform Resource Locator (URL) の考え方を拡張したものである。URIによって示されるリソースは限定されておらず、インターネット 上に存在しない対象や抽象的な概念を示す場合もある[ 4]
URI, URL, URN の集合図 URI には、以下の2つのサブセットがある。
Uniform Resource Locator (URL)リソースの「場所」を識別する。ネットワーク内の位置を示してリソースを同定する。
Uniform Resource Name (URN)リソースの「名前」を識別する。もしネットワーク上にリソースがなくなっても、一意で永続的な識別を行えるようにする。例えば urn:ietf:rfc:2648 というURNは、RFC 2648への参照を示す。 2001年、W3C はRFC 3305 [ 5]
一方、2012年、WHATWG によって開始されたURL Standard （URLを標準化を目指す規格書）では、URIの概念を表す語に「URL」を用いている。規格書では、語「URL」を標準化した理由を二つ挙げている。一つ、URIとIRI は混同されやすく、いずれも同じアルゴリズムを用いている。そのため、それらを区別する利点がない。二つ、Google Trends （2025年時点）で「URI」と「URL」の二つの語を比較すると、「URL」の方が優位である。つまり、インターネット上では、「URL」という言葉を使用しているユーザーの方が多い[ 6]
URL Standardでは、目標の1つとしてRFC 3986 (URI) とRFC 3987 (IRI) に代わる標準になることを掲げている[ 7] [ 6] [ 8]
以下のURI共通構文はすべてのスキーム構文で扱うスーパーセット の定義である。なおこの節（下位含む）では2005年 1月に発表された RFC 3986 [ 9]
URI = scheme:[//authority]path[?query][#fragment]
構文図 （英語版 ）
scheme（スキーム）URIはこの「スキーム」と呼ばれる識別子 から始まり、省略できない。階層的識別子（Hierarchical Identifiers）である:（コロン ）はスキームの区切り文字でスキーム名の最後に挿入する。文字で始まり、文字、数字 +（プラス記号 ）、-（ハイフン ）、.（終止符 ）で構成される文字列となる。大文字と小文字を区別しないが、一貫性を保つために小文字の使用を推奨している。
authority（権限 ）権限は//（ダブルスラッシュ）の区切り文字から始まる。userinfo（ユーザー情報）やhost（ホスト ）の扱いは各スキーム よって異なる。ティム・バーナーズ＝リー は2009年 10月12日 （現地時間）、ニューヨーク・タイムズ にて権限の区切り文字であるダブルスラッシュについて「必要ではないことが判明した」と述べている[ 10]
path（パス）URIに権限 が含まれている場合、パス に文字がなくても/（スラッシュ ）で始める必要があり、このことからパス を省略することはできない。権限 が含まれていない場合は//で始めることはできない。さらに相対パスである場合は:から始めることはできない。パス に?（疑問符 ）、#（番号記号 ）を含む、あるいは末尾の場合、パス の終わりを示す。階層的（hierarchical）に構成されたデータが含まれ、階層は/で区切る。
query（クエリ）クエリ は?の区切り文字から始まり、#また末尾で終える。パス と違い、階層的なデータを含まない。RFC 3986、第3章4節において明確な構文は示されていない。fragment（フラグメント、素片）フラグメント は#の区切り文字から始まる。任意な扱いで、プライマリ（一次）リソースを参照し、セカンダリ（二次）リソースへ提供するフラグメント識別子を含む。クエリ と同様に明確な構文は示されていない。HTML ドキュメントの場合、要素のid属性に何かしらの値を指定し、フラグメントにも同様の値を指定することで、ウェブブラウザ は表示の際にその要素の位置までスクロールする。ウィキペディア では「アンカー 」と呼ばれる機能が該当する。
予約文字（RFC 3986 第2章2節）
gen-delims
:
/
?
#
[
]
@
N/A
sub-delims
!
$
&
'
(
)
*
+
,
;
=
上記で列挙した文字は、URI共通構文で区切りとして予約された文字（Reserved Characters）であるため、コンポーネント内で直接使用することはできない。なお[と]（角括弧 ）はIPv6 の区切り文字である。sub-delimsはURIスキームの仕様によって定義されることがある。
パーセントエンコーディング （Percent-Encoding）は上記で列挙した予約文字などをURIで使えるよう、別の形式に変換する。名前のとおり、パーセント記号%とオクテット を16進数 で表現した文字を組み合わせた形式で表す。例えばスペース （空白）文字 をパーセントエンコーディングすると%20に変換される。
予約されていない文字 （Unreserved Characters）は、制約がなく、コンポーネント内で自由に使える文字。予約されていない文字は次の通り（RFC 3986 第2章3節）。
なおチルダ~は古いURIの仕様によってしばしば%7eに変換されることがある。しかしチルダ含め、予約されていない文字の変換は本来必要ない。
http/httpsスキームの構文を使った例[ 11]
スキーム
権限
パス
https:
//
user:password@
www.example.com:123
/forum/questions/
?tag=networking&order=newest
#top
ユーザー情報
ホスト:ポート
クエリ
フラグメント
#共通構文 と同じコンポーネントの解説は除く。
userinfo（ユーザー情報、認証情報）はホスト:ポートよりも先に記載する必要がある。開始の区切り文字はなく、@（アットマーク ）で区切ることでユーザー情報の終わりを示す。ユーザー情報の形式はuser:passwordである。URIにユーザー情報が付加され、かつその情報が正しければウェブブラウザは認証ダイアログを表示せずプライベートページを表示させることができる。認証情報を平文で示すため、パスワードを含んだ認証情報は非推奨である 。これはURL Standardでも同様である。
host（ホスト）はhttp/httpsスキームにおいて必要な権限であり、省略することはできない。port（ポート）はスキームのデフォルトポートであれば省略できる。
クエリはパスに対しての引数 であるがその構文は明確に示されていない。一般的な利用法は、「名前」と「値」の組み合わせ（名前-値ペア （英語版 ） key=valueとなり、「名前」と「値」の間は=（イコール ）で結ぶ。このペアが複数存在する場合、上記構文例のように&（アンパサンド ）で繋げる。クエリはWebサーバー およびクライアント 側で処理できる。URL StandardではJavaScript 上でクエリ文字列を簡単に扱えるようURLSearchParams()メソッド が実装されている[ 12]
フラグメントはクライアントのみ影響する。URIを決定する際、アプリケーション はフラグメントを除外してからサーバーにリクエストを送る[ 13]
この節の
加筆 が望まれています。
（2021年9月 ）
IANAに登録されているスキームで、利用が続いている一部を掲載する[ 14]
javascriptウェブブラウザやHTMLドキュメントでJavaScriptを実行する手段として用いられている。ドラフト状態であったが2011年 3月29日 に期限切れを迎えた[ 15]
いくつかのプログラミング言語 や環境では、ネットワーク通信などでURIを扱う際に便利なクラスライブラリなどが標準的に用意されている。Java ではjava.net.URI .NET ではSystem.Uri[ 16] Android ではandroid.net.Uriクラスが用意されている[ 17] ファイルシステム 上におけるリソースを統一的に指し示す目的でも使用される。
^ Stallings, William (2016). Foundations of modern networking : SDN, NFV, QoE, IoT, and Cloud ISBN 978-0-13-417547-8 . OCLC 927715441 . https://www.worldcat.org/oclc/927715441 ^ Uniform Resource Identifier (URI): Generic Syntax doi :10.17487/RFC3986 RFC 3986 .^ JIS X 4159 日本産業標準調査会 、経済産業省 ） 9頁^ “Overview of URIs” . Uniform Resource Identifier (URI): Generic Syntax doi :10.17487/RFC3986 RFC 3986 .^ RFC 3305 - URIs, URLs, and URNs: Clarifications and Recommendations 1.0 ^ a b “URL Standard （日本語訳） 目標 ” (jp) (2017年6月1日). 2025年6月23日閲覧。
^ “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: W3C Working Group Note 06 December 2016 ”. W3C (2017年3月7日). 2025年7月31日閲覧。 ^ Berners-Lee, Tim; Fielding, Roy T.; Masinter, Larry M. (2005-01). Uniform Resource Identifier (URI): Generic Syntax . https://datatracker.ietf.org/doc/rfc3986/ . ^ “The Web’s Inventor Regrets One Small Thing” (英語). ニューヨーク・タイムズ . 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
![[icon]](%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:Wiki_letter_w_cropped.svg){kind=small}
