Movatterモバイル変換

[0]ホーム
URL:

コンテンツにスキップ
Wikipedia
検索

Uniform Resource Identifier

出典: フリー百科事典『ウィキペディア（Wikipedia）』
ウィキペディアウィキペディアにおけるURIについては、「Help:URL」をご覧ください。
この記事には複数の問題があります。改善やノートページでの議論にご協力ください。

Uniform Resource Identifier（ユニフォーム リソース アイデンティファイア、URI）とは、抽象的または物理的なリソースを識別するためのコンパクトな文字列のことである[1]。また、一定の書式によってリソース（資源）を指し示す識別子である[2]。統一資源識別子（とういつしげんしきべつし）とも[3]。

1998年8月にRFC 2396 として規定され、2005年1月にRFC 3986 として改定された。URI はUniform Resource Locator (URL) の考え方を拡張したものである。URIによって示されるリソースは限定されておらず、インターネット上に存在しない対象や抽象的な概念を示す場合もある[4]。

設計

[編集]

URL と URN

[編集]
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]内で、上記の考え方を古典的な見解とした。以降、従来のURLとURNとはすべて「URI」と呼ばれることになり、URLやURNといった語はW3Cによって非公式な表現とされた。

一方、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]。現在、唯一の標準には至っていないが、W3CのURL規格の公式ページでは、このURL Standardのスナップショットをワーキンググループノートとして公開している[8]。

共通構文

[編集]

以下のURI共通構文はすべてのスキーム構文で扱うスーパーセットの定義である。なおこの節（下位含む）では2005年1月に発表されたRFC 3986[9]を主に出典とする。

URI = scheme:[//authority]path[?query][#fragment]

構文図（英語版）と各コンポーネントの解説は次の通り。

scheme（スキーム）
URIはこの「スキーム」と呼ばれる識別子から始まり、省略できない。階層的識別子（Hierarchical Identifiers）である:（コロン）はスキームの区切り文字でスキーム名の最後に挿入する。
スキーム名は文字で始まり、文字、数字、+（プラス記号）、-（ハイフン）、.（終止符）で構成される文字列となる。大文字と小文字を区別しないが、一貫性を保つために小文字の使用を推奨している。
authority（権限）
権限は//（ダブルスラッシュ）の区切り文字から始まる。userinfo（ユーザー情報）やhost（ホスト）の扱いは各スキームよって異なる。
URIの考案者であるティム・バーナーズ＝リーは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スキームの構文例

[編集]

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]。

公式登録のスキーム

[編集]
[icon]
この節の加筆が望まれています。
主に: 「仕様書・出典」と照らし合わせて、各項目の補完（可能な限り）。 （2021年9月）

IANAに登録されているスキームで、利用が続いている一部を掲載する[14]。

→「en:List of URI schemes」も参照
公式登録されているスキームのリスト[14]
スキーム名称仕様書・出典構文用途・備考
aaaRFC 6733
aaasRFC 6733
aboutアバウトRFC 6694about://<token>[?query][#fragmen]主にウェブブラウザの情報表示なとで用いられる。RFC 6694が定めるトークンはblankひとつのみであるが、固有機能は各トークンを参照し、処理することが推奨されている。
acapRFC 2244
acctRFC 7565
capRFC 4324
cidコンテンツID（Content Identifier）RFC 2392cid:<content-id>HTML形式の電子メールやMHTMLではMIMEマルチパートのコンテンツで指定されたContent-IDが存在している場合、ドキュメントからcidスキームを使うことで参照できる。
例：<img src="cid:example">
coapRFC 7252
coap+tcpRFC 8323
coap+wsRFC 8323
coapsRFC 7252
coaps+tcpRFC 8323
coaps+wsRFC 8323
cridRFC 4078
dataデータURI（データURL）RFC 2397data:<mediatype(;parameter)>[;base64]<,data>メディアタイプで指定されたコンテンツをデータに添付することで、HTMLドキュメントなどから参照することができる。
コンテンツがプレーンテキスト以外ならBase64でエンコードする必要がある、
davウェブダブ（WebDAV）RFC 4918
dictRFC 2229
dnsDomain Name SystemRFC 4501
example例RFC 7595example:<foo>スキーム構文例のために登録されたスキーム。RFC 7595は新しいスキームを登録する手順やガイドラインである。
filefile URI scheme（英語版）RFC 8089file://[[userinfo@]<host>]</path>ホストのファイルパスを提示するスキーム。構文で示しているように、権限は認証情報が必要ない、かつローカルホストであれば省略できるため、file:///からパスが始まる。
ftpファイル・トランスファー・プロトコルRFC 1738#共通構文 参照
geoRFC 5870
goRFC 3368
gopherRFC 4266
h323H.323RFC 3508h323:[<user>@]<host[:port]>[;url-parameter]
http
https		ハイパーテキスト・トランスファー・プロトコルRFC 7230
2章7節1項
および
2章7節2項		#http/httpsスキームの構文例 参照
iaxRFC 5456
icapRFC 3507
imRFC 3860
imapRFC 5092
infoRFC 4452
ippRFC 3510
ippsRFC 7472
irisRFC 3981
iris.beepRFC 3983
iris.lwzRFC 4993
iris.xpcRFC 4992
iris.xpcsRFC 4992
ldapRFC 4516
leaptofrogansRFC 8589
mailtoRFC 6068
midRFC 2392
msrpRFC 4975
msrpsRFC 4975
RFC 8873
mtqpRFC 3887
mupdateRFC 3656
newsRFC 5538
nfsRFC 2224
niRFC 6920
nihRFC 6920
nntpRFC 5538
opaquelocktokenRFC 4918
pkcs11RFC 7512
popRFC 2384
presRFC 3859
reloadRFC 6940
rtsp
rtspu
rtsps		リアルタイム・ストリーミング・プロトコルRFC 2326
RFC 7826		rtsp://<host[:port]>/path通常rtspとrtspsの通信プロトコルはTCPであるが、rtspuはUDPとなる。
serviceRFC 2609
sessionRFC 6787
shttpRFC 2660
sieveRFC 5804
sipRFC 3261
sipsRFC 3261
smsショートメッセージサービスRFC 5724sms://<recipient[,recipient...]>[?fields]
recipient = [+global-number]<local-number>
snmpRFC 4088
soap.beepRFC 4227
soap.beepsRFC 4227
stunRFC 7064
stunsRFC 7064
tagRFC 4151
tel電話番号RFC 3966
RFC 5341		tel:[+global-number]<local-number>
telnetRFC 4248
tftpRFC 3617
thismessageRFC 2557
tipRFC 2371
tn3270RFC 6270
turnRFC 7065
turnsRFC 7065
tvRFC 2838
urnRFC 8141
vemmiRFC 2122
vncRFC 7869
ws
wss		WebSocketRFC 6455ws://<host>[:port]<path>[?query]ポート番号のデフォルトはhttp/httpsと同様。
xconRFC 6501
xcon-useridRFC 6501
xmlrpc.beepRFC 3529
xmlrpc.beepsRFC 3529
xmppRFC 5122
z39.50rRFC 2056
z39.50sRFC 2056

一般的な非登録のスキーム

[編集]
javascript
ウェブブラウザやHTMLドキュメントでJavaScriptを実行する手段として用いられている。ドラフト状態であったが2011年3月29日に期限切れを迎えた[15]。

プログラミング環境でのサポート

[編集]

いくつかのプログラミング言語や環境では、ネットワーク通信などでURIを扱う際に便利なクラスライブラリなどが標準的に用意されている。Javaではjava.net.URIが、.NETではSystem.Uri[16]が用意されている。Androidではandroid.net.Uriクラスが用意されている[17]。通例、ネットワークリソースだけでなく、ローカルのファイルシステム上におけるリソースを統一的に指し示す目的でも使用される。

関連項目

[編集]

脚注

[編集]
[脚注の使い方]
  1. ^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 
  2. ^Uniform Resource Identifier (URI): Generic Syntax (英語). January 2005.doi:10.17487/RFC3986.RFC3986.
  3. ^JIS X 4159:2005「拡張可能なマーク付け言語 (XML) 1.0」（日本産業標準調査会、経済産業省） 9頁
  4. ^“Overview of URIs”.Uniform Resource Identifier (URI): Generic Syntax (英語). sec. 1.1.doi:10.17487/RFC3986.RFC3986.
  5. ^RFC 3305 -URIs, URLs, and URNs: Clarifications and Recommendations 1.0
  6. ^ab“URL Standard （日本語訳） 目標” (jp) (2017年6月1日). 2025年6月23日閲覧。
  7. ^“URL Standard Goals” (英語). WHATWG (2017年6月23日). 2017年6月23日閲覧。 “AlignRFC 3986 andRFC 3987 with contemporary implementations and obsolete them in the process.”
  8. ^“URL: W3C Working Group Note 06 December 2016”. W3C (2017年3月7日). 2025年7月31日閲覧。
  9. ^Berners-Lee, Tim; Fielding, Roy T.; Masinter, Larry M. (2005-01). Uniform Resource Identifier (URI): Generic Syntax. https://datatracker.ietf.org/doc/rfc3986/. 
  10. ^“The Web’s Inventor Regrets One Small Thing” (英語). ニューヨーク・タイムズ. (2009年10月12日). https://archive.nytimes.com/bits.blogs.nytimes.com/2009/10/12/the-webs-inventor-regrets-one-small-thing/ 2021年8月31日閲覧。 
  11. ^“ウェブ上のリソースの識別”. MDN Web Docs. Mozilla. 2021年9月5日閲覧。
  12. ^“URLSearchParams”. MDN Web Docs. Mozilla. 2021年8月31日閲覧。
  13. ^RFC 7230 参照
  14. ^ab“Uniform Resource Identifier (URI) Schemes” (英語). IANA. 2021年9月1日閲覧。
  15. ^“draft-hoehrmann-javascript-scheme-03” (英語). Internet Engineering Task Force (2010年9月25日). 2021年9月8日閲覧。
  16. ^Uri Class (System) | Microsoft Learn
  17. ^Uri  |  Android Developers

参考資料

[編集]
スタブアイコン

この項目は、インターネットやウェブに関連した書きかけの項目です。この項目を加筆・訂正などしてくださる協力者を求めています（PJ:コンピュータ/P:コンピュータ）。

国立図書館
その他
「https://ja.wikipedia.org/w/index.php?title=Uniform_Resource_Identifier&oldid=107959394」から取得
カテゴリ:
隠しカテゴリ:
[8]ページ先頭
©2009-2026 Movatter.jp