Uniform Resource Identifier

出典: フリー百科事典『ウィキペディア(Wikipedia)』
ナビゲーションに移動 検索に移動

Uniform Resource Identifier(ユニフォーム リソース アイデンティファイア、URI)または統一資源識別子[1](とういつしげんしきべつし)は、一定の書式によってリソース(資源)を指し示す識別子[2]1998年8月に RFC 2396 として規定され、2005年1月に RFC 3986 として改定された。URI はUniform Resource Locator (URL) の考え方を拡張したものである。URIによって示されるリソースは限定されておらず、インターネット上に存在しない対象や抽象的な概念を示す場合もある[3]

設計[編集]

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

2012年、WHATWGによってURL Standardの開発が開始された。URL Standardでは、目標の1つとしてRFC 3986 (URI)とRFC 3987 (IRI)を過去のものにすることを掲げている[5][6]。また、従来のURIやIRIを区別する必要が無いとして、すべてURLの語を用いている。さらに、W3Cでも、このURL Standardのスナップショットをワーキンググループノートとして公開している。

共通構文[編集]

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

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

URIの長さは RFC 3986 、URL Standard共に255文字までと定められているが、URL Standardでは「有効なIPv4アドレス」が付け加えられている。

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

URI syntax diagram.svg
scheme(スキーム)
URIはこの「スキーム」と呼ばれる識別子から始まり、省略できない。階層的識別子(Hierarchical Identifiers)である:コロン)はスキームの区切り文字でスキーム名の最後に挿入する。
スキーム名は文字で始まり、文字数字+プラス記号)、-ハイフン)、.終止符)で構成される文字列となる。大文字と小文字を区別しないが、一貫性を保つために小文字の使用を推奨している。
authority権限
権限は//(ダブルスラッシュ)の区切り文字から始まる。userinfo(ユーザー情報)やhostホスト)の扱いは各スキームよって異なる。
URIの考案者であるティム・バーナーズ=リー2009年10月12日(現地時間)、ニューヨーク・タイムズにて権限の区切り文字であるダブルスラッシュについて「必要では無い事が判明した」と述べている[7]
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スキームの構文を使った例[8]

スキーム 権限 パス
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()メソッドが実装されている[9]

フラグメントはクライアントのみ影響する。URIを決定する際、アプリケーションはフラグメントを除外してからサーバーにリクエストを送る[10]

公式登録のスキーム[編集]

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

公式登録されているスキームのリスト[11]
スキーム 名称 仕様書・出典 構文 用途・備考
aaa RFC 6733
aaas RFC 6733
about アバウト RFC 6694 about://<token>[?query][#fragmen] 主にウェブブラウザの情報表示なとで用いられる。RFC 6694が定めるトークンはblankひとつのみであるが、固有機能は各トークンを参照し、処理することが推奨されている。
acap RFC 2244
acct RFC 7565
cap RFC 4324
cid コンテンツID(Content Identifier) RFC 2392 cid:<content-id> HTML形式の電子メールやMHTMLではMIMEマルチパートのコンテンツで指定されたContent-IDが存在してる場合、ドキュメントからcidスキームを使う事で参照できる。
例:<img src="cid:example">
coap RFC 7252
coap+tcp RFC 8323
coap+ws RFC 8323
coaps RFC 7252
coaps+tcp RFC 8323
coaps+ws RFC 8323
crid RFC 4078
data データURI(データURL) RFC 2397 data:<mediatype(;parameter)>[;base64]<,data> メディアタイプで指定されたコンテンツをデータに添付することで、HTMLドキュメントなどから参照することができる。
コンテンツがプレーンテキスト以外ならBase64でエンコードする必要がある、
dav ウェブダブ(WebDAV) RFC 4918
dict RFC 2229
dns Domain Name System RFC 4501
example RFC 7595 example:<foo> スキーム構文例のために登録されたスキーム。RFC 7595は新しいスキームを登録する手順やガイドラインである。
file file URI scheme英語版 RFC 8089 file://[[userinfo@]<host>]</path> ホストのファイルパスを提示するスキーム。構文で示してるように、権限は認証情報が必要ない、かつローカルホストであれば省略できる為、file:///からパスが始まる。
ftp ファイル・トランスファー・プロトコル RFC 1738 #共通構文 参照
geo RFC 5870
go RFC 3368
gopher RFC 4266
h323 H.323 RFC 3508 h323:[<user>@]<host[:port]>[;url-parameter]
http
https
ハイパーテキスト・トランスファー・プロトコル RFC 7230
2章7節1項
及び
2章7節2項
#http/httpsスキームの構文例 参照
iax RFC 5456
icap RFC 3507
im RFC 3860
imap RFC 5092
info RFC 4452
ipp RFC 3510
ipps RFC 7472
iris RFC 3981
iris.beep RFC 3983
iris.lwz RFC 4993
iris.xpc RFC 4992
iris.xpcs RFC 4992
ldap RFC 4516
leaptofrogans RFC 8589
mailto RFC 6068
mid RFC 2392
msrp RFC 4975
msrps RFC 4975
RFC 8873
mtqp RFC 3887
mupdate RFC 3656
news RFC 5538
nfs RFC 2224
ni RFC 6920
nih RFC 6920
nntp RFC 5538
opaquelocktoken RFC 4918
pkcs11 RFC 7512
pop RFC 2384
pres RFC 3859
reload RFC 6940
rtsp
rtspu
rtsps
リアルタイム・ストリーミング・プロトコル RFC 2326
RFC 7826
rtsp://<host[:port]>/path 通常rtspとrtspsの通信プロトコルはTCPであるが、rtspuはUDPとなる。
service RFC 2609
session RFC 6787
shttp RFC 2660
sieve RFC 5804
sip RFC 3261
sips RFC 3261
sms ショートメッセージサービス RFC 5724 sms://<recipient[,recipient...]>[?fields]
recipient = [+global-number]<local-number>
snmp RFC 4088
soap.beep RFC 4227
soap.beeps RFC 4227
stun RFC 7064
stuns RFC 7064
tag RFC 4151
tel 電話番号 RFC 3966
RFC 5341
tel:[+global-number]<local-number>
telnet RFC 4248
tftp RFC 3617
thismessage RFC 2557
tip RFC 2371
tn3270 RFC 6270
turn RFC 7065
turns RFC 7065
tv RFC 2838
urn RFC 8141
vemmi RFC 2122
vnc RFC 7869
ws
wss
WebSocket RFC 6455 ws://<host>[:port]<path>[?query] ポート番号のデフォルトはhttp/httpsと同様。
xcon RFC 6501
xcon-userid RFC 6501
xmlrpc.beep RFC 3529
xmlrpc.beeps RFC 3529
xmpp RFC 5122
z39.50r RFC 2056
z39.50s RFC 2056

一般的な非登録のスキーム[編集]

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

関連項目[編集]

参考資料[編集]

脚注[編集]

[脚注の使い方]
  1. ^ JIS X 4159:2005「拡張可能なマーク付け言語 (XML) 1.0」日本産業標準調査会経済産業省) 9頁
  2. ^ Uniform Resource Identifier (URI): Generic Syntax (英語). January 2005. doi:10.17487/RFC3986. RFC 3986
  3. ^ "Overview of URIs". Uniform Resource Identifier (URI): Generic Syntax (英語). sec. 1.1. doi:10.17487/RFC3986. RFC 3986
  4. ^ RFC 3305 - URIs, URLs, and URNs: Clarifications and Recommendations 1.0
  5. ^ 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.”
  6. ^ URL Standard (日本語訳) 目標” (2017年6月1日). 2017年6月23日閲覧。 “RFC 3986RFC 3987 を現今の実装に揃わせて、その過程の中でそれらを過去のものにする。”
  7. ^ “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日閲覧。 
  8. ^ ウェブ上のリソースの識別” (日本語). MDN Web Docs. Mozilla. 2021年9月5日閲覧。
  9. ^ URLSearchParams” (日本語). MDN Web Docs. Mozilla. 2021年8月31日閲覧。
  10. ^ RFC 7230 参照
  11. ^ a b Uniform Resource Identifier (URI) Schemes” (英語). IANA. 2021年9月1日閲覧。
  12. ^ draft-hoehrmann-javascript-scheme-03” (英語). Internet Engineering Task Force (2010年9月25日). 2021年9月8日閲覧。