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] 内で、上記の考え方を古典的な見解とした。ここで示されたW3Cの新たな考え方により、従来のURLとURNとはすべてURIと呼ばれることになった。URLやURNといった語はW3Cによって非公式な表現とされた。
2012年、WHATWG によってURL Standard の開発が開始された。URL Standardでは、目標の1つとしてRFC 3986 (URI) とRFC 3987 (IRI) を過去のものにすることを掲げている[ 6] [ 7] 。また、従来の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日 (現地時間)、ニューヨーク・タイムズ にて権限の区切り文字であるダブルスラッシュについて「必要ではないことが判明した」と述べている[ 8] 。
path
(パス)
URIに権限 が含まれている場合、パス に文字がなくても/
(スラッシュ )で始める必要があり、このことからパス を省略することはできない。権限 が含まれていない場合は//
で始めることはできない。さらに相対パスである場合は:
から始めることはできない。パス に?
(疑問符 )、#
(番号記号 )を含む、あるいは末尾の場合、パス の終わりを示す。階層的(hierarchical)に構成されたデータが含まれ、階層は/
で区切る。
query
(クエリ)
クエリ は?
の区切り文字から始まり、#
また末尾で終える。パス と違い、階層的なデータを含まない。RFC 3986、第3章4節において明確な構文は示されていない。
fragment
(フラグメント、素片)
フラグメント は#
の区切り文字から始まる。任意な扱いで、プライマリ(一次)リソースを参照し、セカンダリ(二次)リソースへ提供するフラグメント識別子を含む。クエリ と同様に明確な構文は示されていない。 一例としてプライマリリソースがHTML ドキュメントの場合、要素のid
属性に何かしらの値を指定し、フラグメントにも同様の値を指定することで、ウェブブラウザ は表示の際にその要素の位置までスクロールする。ウィキペディア では「アンカー 」と呼ばれる機能が該当する。
予約文字とパーセントエンコーディング
予約文字(RFC 3986 第2章2節)
gen-delims
:
/
?
#
[
]
@
—
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スキームの構文を使った例[ 9] :
スキーム
権限
パス
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()
メソッド が実装されている[ 10] 。
フラグメントはクライアントのみ影響する。URIを決定する際、アプリケーション はフラグメントを除外してからサーバーにリクエストを送る[ 11] 。
公式登録のスキーム
この節の
加筆 が望まれています。
主に: 「仕様書・出典」と照らし合わせて、各項目の補完(可能な限り)。 (2021年9月 )
IANAに登録されているスキームで、利用が続いている一部を掲載する[ 12] 。
一般的な非登録のスキーム
javascript
ウェブブラウザやHTMLドキュメントでJavaScriptを実行する手段として用いられている。ドラフト状態であったが2011年 3月29日 に期限切れを迎えた[ 13] 。
プログラミング環境でのサポート
いくつかのプログラミング言語 や環境では、ネットワーク通信などでURIを扱う際に便利なクラスライブラリなどが標準的に用意されている。Java ではjava.net.URI
が、.NET ではSystem.Uri
[ 14] が用意されている。Android ではandroid.net.Uri
クラスが用意されている[ 15] 。通例、ネットワークリソースだけでなく、ローカルのファイルシステム 上におけるリソースを統一的に指し示す目的でも使用される。
関連項目
脚注
参考資料