＠IT
アジャイル/DevOps
Insider.NET
URI：Dev Basics／Keyword

URI：Dev Basics／Keyword

URIはさまざまな種類のリソースを統一的に参照するための識別子。URIは、広く使われている「URL」という用語を包含する概念である。

» 2017年02月28日 05時00分公開

[かわさきしんじ，Insider.NET編集部]

　URI（Uniform Resource Identifier）はさまざまな種類のリソースを統一的に参照するための識別子（統一リソース識別子）。広く使われている用語「URL」（Uniform Resource Locator）は（概念的には）URIのサブセットであるが、W3Cによれば現在では「URI」が正しい表記となる。

URIの特徴

　URIは、さまざまな種類のリソースを識別するための統一的で、階層構造を持った文字列のこと。ここでいう「統一的」とは、実際の「リソース識別子がどのような構文で記述され、それらがどのように解釈されるか」は個々の「スキーム」（処理方法やプロトコル）に任せて、URI自体は「さまざまなリソースを統一的に識別する」ための総称構文（generic syntax）を定めているという意味。

　URIはあくまでも「抽象的／物理的なリソースを（他の何かから）識別するためのもの」であり、そのURIで示されるリソースが実際に存在するか、そのリソースが実際にアクセスされることがあるかどうか、アクセス可能かどうかとは関係がない。アクセス可能であるリソースへのアクセス手段は、個々のプロトコル／スキームによって定義される。

　今述べたように、URIには何かのリソースにアクセスするための「ロケーター」（位置指定子）として機能する側面がある一方で、何かを識別する「名前」として機能することもある（1つのURIがその両者の特性を持つこともある）。

　例えば、Webコンテンツを特定するための「http://www.atmarkit.co.jp/」などのURI（URL）は、リソースを識別するだけではなく、そのリソースにアクセスする手段としても機能する。また、urnスキームを利用して「urn:isbn:ISBN番号」形式で特定の書籍を識別できるが、これはURIが名前のようにも機能していることを表す例といえる。

　「http:～」と「urn:isbn:～」という2つのURIは構文が全く異なっているが、URIではそれぞれのスキーマ（ここでは「http」と「urn」）にその構文と処理や解釈の方法を任せるようになっていることから、このような違いが出てくる。そうした違いがあっても、さまざまなリソースを統一的な表記で識別できるのがURIの特徴だ。

URIの総称構文

　さまざまなリソースを統一的に識別するためのURIの総称構文（generic URI syntax）を以下に示す。総称構文はスキーム／オーソリティー／パス／クエリ／フラグメントの5つの要素で構成される。

URIの総称構文

　URIがどのような要素に分解されるかの例を示す。

URIの例

　このうち、実際にリソースを識別するために必須の要素はスキームとパスの2つだ（上のurnスキームの例を参照）。ただし、パスは「空」でもよい。5つの要素を簡単にまとめると次のようになる。

　「スキーム」とは「そのスキームを使用したURI（リソース識別子）がどのような意味や構文を持ち、どのように記述／解釈／解決／処理されるのか」、その仕様を指定するためのもの。代表的なスキームとしてはhttp、https、mailto、fileなどがある。

　「オーソリティー」を指定する場合には「スキーム」「:」に続けてダブルスラッシュ（//）を前置し、その後にオーソリティーを「ユーザー情報@ホスト:ポート」の形式で指定する（「ホスト」部分にはIPv6のIPリテラル形式／IPv4のドット記法／DNS名などを記述可能。また、ユーザー情報とポート番号の指定はオプション）。この場合には、スキームとオーソリティーの後に続く要素（パス／クエリ／フラグメント）で定義される名前空間の管理がそのオーソリティーに任される。つまり、リソースの管理をオーソリティーが行う。

　「パス」にはスラッシュ区切りで「指定されたスキーム／オーソリティーの下で、リソースを識別するための階層的なデータ」を記述していく。パスを指定する際には以下のようなルールがある。

オーソリティーを指定した場合、パスはスラッシュで始めるか、空のパスを指定する（＝何も記述しない）
オーソリティーがない場合、パスをダブルスラッシュで始めてはいけない
相対パスの形でURIを参照している場合は、パスをコロンで始めてはいけない

　パスには論理的な関連性を記述していく場合もあれば、（それがアクセス可能なリソースであれば）ファイルシステムへのリソースの配置方法とURIのパスの構成が相似の関係となることもある。

　「パス」とは対照的に、「クエリ」は「リソースを識別するための非階層的なデータ」を記述するためのもので、先頭に「?」を付加する。「フラグメント」は、それ以外の要素で識別されるリソースに含まれる部分リソースを参照するために使用するもので、先頭に「#」を付加する。これはWebサービスに対してクエリを行うことを考えると分かりやすい。つまり、階層をたどってリソースにたどり着くのではなく、何らかのクエリを投げかけた結果でリソースを識別／取得するということだ。

　URIの使い道はもちろん何らかのドキュメントで対応するリソースを参照するために使用することであり、これを「URI参照」と呼ぶ。ただし、URI参照はURIそのものを用いて行う場合と、何らかの「ベースURL」に対する「相対パス参照」の形で行う場合がある。

　例えば、HTMLページの<a>要素のhref属性に「href="https://atmarkit.itmedia.co.jp/ait/articles/1702/28/foo.html"」などと指定した場合、これはfoo.htmlファイルへの相対パス参照であり、（何らかの手段で生成した、あるいはデフォルトの）ベースURLと相対パス参照からターゲットURI（最終的なURI）が生成される。このときには、相対パス参照をしている側で指定しているスキーム／オーソリティー／パス／クエリ／フラグメントを用いて、ベースURIにおけるそれらの要素を変更しながらターゲットURIを生成する。

　URIはさまざまな種類のリソースを参照するための統一的な識別子であり、リソースを表すためのスキームごとに異なるさまざまな構文やそのリソースの処理方法などを、統一的に表現するために使われる。