1. Introduction (序論)
本章では、URIの基本概念、設計上の考慮事項、構文表記法を紹介します。
概要
統一資源識別子 (Uniform Resource Identifier, URI) は、リソースを識別するためのシンプルで拡張可能な手段を提供します。
歴史的背景:
- World Wide Webグローバル情報イニシアチブによって導入された概念に由来
- これらの識別子の使用は1990年にさかのぼる
- 本文書はRFC 2396を廃止し、URLと相対URL仕様を統合
本仕様:
- すべてのURIに対する単一の汎用構文を定義
- IPv6アドレス構文を導入
- 個別のURIスキームの特定構文を除外（別文書で更新）
1.1. Overview of URIs (URIの概要)
URIの特徴
URIの特徴は、Uniform（統一）、Resource（資源）、**Identifier（識別子）**という3つの言葉で要約できます。
Uniform (統一)
統一性の利点:
-
コンテキスト独立性: アクセスメカニズムが異なる場合でも、同じコンテキスト内で異なるタイプのリソース識別子を使用できます
-
意味的一貫性: 異なるタイプのリソース識別子間で共通の構文規則に対する統一的な意味解釈を可能にします
-
拡張性: 既存の識別子の使用方法を妨げることなく、新しいタイプのリソース識別子を導入できます
-
再利用性: 多くの異なるコンテキストで識別子を再利用でき、新しいアプリケーションやプロトコルが既存の大規模で広く使用されているリソース識別子セットを活用できます
例:
http://example.com/page
ftp://example.com/file
mailto:[email protected]
すべて同じ汎用構文構造を使用
Resource (資源)
リソースの範囲: 本仕様は、リソースが何であるかを制限しません。「リソース」という用語は、URIによって識別される可能性のあるものすべてを表す一般的な意味で使用されます。
身近な例:
- 📄 電子文書
- 🖼️ 画像
- 📊 一貫した目的を持つ情報源（例：「ロサンゼルスの今日の天気予報」）
- 🔧 サービス（例：HTTPからSMSへのゲートウェイ）
- 📚 他のリソースのコレクション
広義のリソース:
- 🧑 人間
- 🏢 企業
- 📖 図書館の製本された書籍
- 🔢 抽象概念（数学演算子、関係タイプ、数値）
重要なポイント: リソースは必ずしもインターネット経由でアクセス可能である必要はありません
Identifier (識別子)
定義: 識別子は、識別されるものをその識別範囲内の他のすべてのものと区別するために必要な情報を体現します。
「識別」の意味:
- あるリソースを他のすべてのリソースと区別する目的を指します
- その目的がどのように達成されるか（例えば、名前、アドレス、またはコンテキストによって）は考慮されません
- 識別子が参照される内容のアイデンティティを定義または体現していると誤解すべきではありません
- URIを使用するシステムが識別されたリソースにアクセスすると仮定すべきではありません
URIの定義: URIは、第3節で<URI>という名前の構文規則に一致する文字列で構成される識別子です。
URIのグローバル性
グローバルスコープ: URIはグローバルスコープを持ち、コンテキストに関係なく一貫して解釈されます
例:
http://localhost/
この参照を使用するすべてのユーザーに対して同じ解釈
「localhost」に対応するネットワークインターフェースは
各エンドユーザーで異なる可能性があるにもかかわらず
解釈はアクセスとは独立
コンテキスト相対性:
- 参照に基づいて実行されるアクションは、エンドユーザーのコンテキストに対して相対的に実行されます
- グローバルに一意なものを参照する意図のある操作は、リソースを他のすべてのものと区別するURIを使用する必要があります
ローカルコンテキストURI:
file:///etc/hosts
コンテキスト自体がリソース定義の側面である場合にのみ使用
例：エンドユーザーのファイルシステム上のファイルを参照するオンラインヘルプマニュアル
1.1.1. Generic Syntax (汎用構文)
スキーム名
各URIはスキーム名（第3.1節で定義）で始まり、そのスキーム内で識別子を割り当てる仕様を指します。
連邦命名システム: URI構文は連邦的かつ拡張可能な命名システムであり、各スキームの仕様は、そのスキームを使用する識別子の構文と意味をさらに制限できます。
汎用要素
本仕様は、URI構文の以下の要素を定義します：
- ✅ すべてのURIスキームに必要な要素
- ✅ 多くのURIスキームに共通する要素
利点:
- スキーム独立解析: スキーム独立のURI参照解析メカニズムを実装するために必要な構文と意味を定義
- 遅延処理: スキーム依存の意味が必要になるまで、URIのスキーム依存処理を延期できます
- プロトコル独立性: URI参照を使用するプロトコルとデータ形式は、すべてのURIに許可される構文範囲の定義として本仕様を参照できます
- 前方互換性: まだ定義されていないスキームを含みます
分離された進化: 識別スキームの進化を、URIを使用するプロトコル、データ形式、実装の進化から分離します。
汎用パーサー
解析能力: 汎用URI構文のパーサーは、任意のURI参照をその主要コンポーネントに解析できます
2段階解析:
- 汎用解析: スキームと主要コンポーネントを決定
- スキーム固有解析: コンポーネントに対してさらにスキーム固有の解析を実行
スーパーセット関係: 汎用URI構文は、すべてのURIスキーム構文のスーパーセットです
1.1.2. Examples (例)
URI例
以下のURI例は、いくつかのURIスキームとその共通構文コンポーネントのバリエーションを示しています：
ftp://ftp.is.co.za/rfc/rfc1808.txt
- スキーム:
ftp - オーソリティ:
ftp.is.co.za - パス:
/rfc/rfc1808.txt
http://www.ietf.org/rfc/rfc2396.txt
- スキーム:
http - オーソリティ:
www.ietf.org - パス:
/rfc/rfc2396.txt
ldap://[2001:db8::7]/c=GB?objectClass?one
- スキーム:
ldap - オーソリティ:
[2001:db8::7](IPv6アドレス) - パス:
/c=GB - クエリ:
objectClass?one
mailto:[email protected]
- スキーム:
mailto - パス:
[email protected]
news:comp.infosystems.www.servers.unix
- スキーム:
news - パス:
comp.infosystems.www.servers.unix
tel:+1-816-555-1212
- スキーム:
tel - パス:
+1-816-555-1212
telnet://192.0.2.16:80/
- スキーム:
telnet - オーソリティ:
192.0.2.16:80 - パス:
/
urn:oasis:names:specification:docbook:dtd:xml:4.1.2
- スキーム:
urn - パス:
oasis:names:specification:docbook:dtd:xml:4.1.2
1.1.3. URI, URL, and URN
概念的区別
URI分類: URIは、ロケータ、名前、またはその両方としてさらに分類できます
URL (Uniform Resource Locator, 統一資源位置指定子)
定義: リソースを識別することに加えて、その主要なアクセスメカニズム（例えば、そのネットワーク「位置」）を記述することによってリソースを配置する手段を提供するURIのサブセット
特徴:
- アクセス方法を提供
- ネットワーク位置を記述
- リソースが移動すると変更される可能性がある
例:
http://www.example.com/index.html
ftp://ftp.example.com/file.txt
URN (Uniform Resource Name, 統一資源名)
定義: 歴史的に、「urn」スキーム [RFC2141] の下のURIを指すために使用され、リソースが存在しなくなった場合や利用できなくなった場合でも、グローバルに一意で永続的であることが求められます
特徴:
- 永続的識別子
- 位置独立
- リソースが消失してもも有効
例:
urn:isbn:0-486-27557-4
urn:ietf:rfc:3986
関係図
URI (統一資源識別子)
/ \
URL URN
(リソースの見つけ方) (永続的な名前)
(位置依存) (位置独立)
現代的な使用法
用語の簡素化: 現在では、「URL」と「URN」という用語をURI空間内のニーモニックとして見るのが最善です
実用的なガイダンス:
- 「URL」や「URN」ではなく「URI」を使用
- すべてのURLはURI
- すべてのURNはURI
- しかし、すべてのURIがURLまたはURNであるとは限りません
1.2. Design Considerations (設計上の考慮事項)
URI設計は、複数の、時には相反する目標のバランスをとる必要があります。
1.2.1. Transcription (転写)
目標: URIは、さまざまな技術とメディアを使用して人間が転写できるべきです
制約:
- 簡潔であるべき
- 記憶しやすいべき
- 入力しやすいべき
他の目標との競合:
簡潔性 vs 可読性
http://x.co/a vs http://example.com/article
記憶性 vs グローバル一意性
http://blog vs http://username.blog.example.com
実用的な考慮事項:
- 限定された文字セット（ASCII）
- 大文字小文字を区別しないシステム
- 特殊文字の処理
転写エラー:
一般的な間違い:
- 0（ゼロ）とO（文字）の混同
- 1（イチ）とl（小文字のエル）の混同
- -（ハイフン）と_（アンダースコア）の混同
1.2.2. Separating Identification from Interaction (識別と相互作用の分離)
原則: URIは、そのリソースがどのようにアクセスされるかとは独立してリソースを識別します
利点:
- 識別の永続性: アクセス方法が変更されても識別子は変更されません
- プロトコル独立性: 同じリソースに複数の方法でアクセスできます
- 参照整合性: アクセス不可能なリソースを参照できます
例:
識別: urn:isbn:0-486-27557-4
アクセス1: http://amazon.com/dp/0486275574
アクセス2: http://barnesandnoble.com/...
アクセス3: 地元の図書館
非アクセス用途:
- 📝 文書参照
- 🏷️ メタデータタグ
- 🔗 リンク関係
- 📊 データ識別
1.2.3. Hierarchical Identifiers (階層的識別子)
階層構造: URI構文は階層的名前空間をサポートします
組織形式:
http://example.com/products/electronics/phones/model-x
└─オーソリティ─┘ └────────パス階層─────────┘
利点:
- 委任管理: 命名権限の委任を可能にします
- 相対参照: 相対URI参照をサポートします
- 論理的組織: リソースの論理的組織を反映します
階層の例:
/products/
/electronics/
/phones/
/model-x
/model-y
/laptops/
/clothing/
1.3. Syntax Notation (構文表記法)
本仕様では、URI構文規則を定義するために拡張バッカス・ナウア記法 (ABNF) [RFC2234]を使用します。
ABNF基本
規則形式:
rulename = elements
基本要素:
ALPHA = A-Z / a-z
DIGIT = 0-9
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
演算子:
/: 選択（または）*: 繰り返し（0回以上）[ ]: オプション( ): グループ化
例:
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
解釈:
- 文字で始まる
- その後に0回以上の（文字/数字/+/-/.）が続く
主要概念まとめ
URIの3つの特徴
- Uniform（統一）: 一貫した構文と意味
- Resource（資源）: 何でも識別可能
- Identifier（識別子）: 区別と識別の能力
URI vs URL vs URN
| 概念 | 焦点 | 永続性 | 例 |
|---|---|---|---|
| URI | 識別 | 保証なし | すべてのURI |
| URL | 位置 | 位置依存 | http://example.com/page |
| URN | 名前 | 永続的 | urn:isbn:0-486-27557-4 |
設計原則
- 転写可能性: 人間が簡単に入力して記憶できる
- 関心の分離: 識別はアクセスと独立
- 階層性: 委任と組織をサポート
次の章: 2. Characters (文字) - URIにおける文字処理とエンコーディング