-
Notifications
You must be signed in to change notification settings - Fork 8
/
Copy pathRFC3986-ja.html
2535 lines (2068 loc) · 165 KB
/
RFC3986-ja.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="utf-8" />
<title>Uniform Resource Identifier (URI): 一般的構文</title>
<!--
<link rel="Stylesheet" href="rfc_ja.css" type="text/css" />
<link rel="Contents" href="http://www.studyinghttp.net/rfc_ja/" />
-->
<style type="text/css">
/**
* rfc_ja.css/20100325
* for RFC-Translations
*/
h1 {
clear:both;
text-align:center;
}
h2 {
margin:0.5em 0.1em;
text-align:left;
}
address {
font-size:0.9em;
font-style:normal;
text-align:right;
}
address a {
font-family:"Georgia", "Times New Roman", "Times", serif;
font-size:1.1em;
font-weight:bold;
}
p {
line-height:1.3em;
margin:0.5em 0.5em 0.5em 3em;
text-indent:1em;
}
pre {
line-height:1.3em;
margin:1em 1em 1em 5em;
}
dfn {
font-size:1.1em;
font-style:normal;
font-weight:bold;
}
code {
font:normal normal 1.1em monospace;
}
samp {
font-family:monospace;
margin:0 0.1em;
}
cite:before, cite:after {
content:'"';
}
em {
font-style:normal;
font-weight:bold;
}
blockquote {
margin-left:5em;
margin-right:4em;
}
a:hover, a:focus {
background-color:#bafecd;
}
hr {
clear:both;
}
ol {
list-style-type:decimal;
line-height:1.5em;
margin:0.5em 1em 0.5em 4em;
}
ol.ABC {
list-style-type:upper-alpha;
}
ol.abc {
list-style-type:lower-alpha;
}
ul {
list-style:disc;
line-height:1.5em;
margin:0.5em 1em 0.5em 4em;
}
ol p, ul p {
margin-left:0.5em;
}
li ol, li ul {
margin:0 0 0 1%;
}
dl { /* Definition List */
line-height:1.5em;
margin:1.2em 1em 0 4em;
}
dt {
font-weight:bold;
}
dd {
margin:0.2em 1em 0.7em;
}
table {
margin:1em 1em 1em 5em;
}
td dl, td pre {
margin:0.5em 0em;
}
/* --- Original Class --- */
.note {
font-size:0.9em;
margin-left:4em;
}
.references dt:before {
content:"[";
}
.references dt:after {
content:"]";
}
#NUMBER {
border:none;
float:left;
margin:0.5em;
white-space:pre;
}
#AUTHOR {
border:none;
float:right;
margin:0.5em;
white-space:pre;
}
#CONTENTS dt {
margin:0.5em 0 0;
}
#CONTENTS dd {
margin:0 0 0 2em;
}
#CONTENTS dd dl, #CONTENTS dd dt {
margin:0;
font-weight: normal;
}
#NOTICE {
border:0.2em #999 solid;
margin:1em 5%;
padding:0.5em;
}
</style>
<style>
aside {
font-size: small;
border: double #BB3333 6px;
padding: 0.5em 1em;
margin-bottom: 1em;
}
aside > p,
aside > ul {
margin: 1em;
}
</style>
<script >
</script>
</head>
<body>
<aside class="trans-meta">
<h1>RFC3986 日本語訳の複製</h1>
<p>
<a href="https://triple-underscore.github.io/rfc-others/RFC3986-ja.html">このページ</a>
は、 IETF による
<cite><a href="https://www.rfc-editor.org/rfc/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a></cite>
（ RFC 3986 ）の，橋本英彦 氏による
<a href="http://www.studyinghttp.net/rfc_ja/rfc3986">日本語訳</a>
†を、内容に手を加えずに，転載したものです††。
</p>
<ul>
<li>†
2014 年 3 月 頃のもの。
現在はリンク切れ — リンク先サイト（ http://www.studyinghttp.net/ ）は 2014 年 5 月 頃から，アクセスできなくなっています。
</li>
<li>††
転載 公開日： <time>2014-10-03</time> — 明示的に許諾は得てはいません。
下記ヘッダのリンク先に（上述と同じ頃に）記載されていた 取り扱い規約に従い，改変を加えずに配布するものです。
ただし、一部マークアップを変更しています（ DOCTYPE など）。
また、要素 id の命名方式を RFC 原文と同じものに戻しています。
</li>
v</ul>
</aside>
<div id="TOP">
<a href="http://www.studyinghttp.net/">Studying HTTP</a> >
<a href="http://www.studyinghttp.net/rfc_ja/">RFC-Translations related HTTP</a>
<p id="NOTICE">
この文書は、
<cite>T. Berners-Lee, R. Fielding, L. Masinter: <a href="http://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a> (RFC 3986), January 2005.</cite>
を 橋本英彦 が日本語訳した物です。
この文書の取り扱いについては、<a href="http://www.studyinghttp.net/rfc_ja/#Notice">[Studying HTTP] の RFC 日本語訳を利用するにあたって</a>に従って下さい。
</p>
</div>
<pre id="NUMBER">Network Working Group
Request for Comments: 3986
STD: 66
Updates: 1738
Obsoletes: 2732, 2396, 1808
Category: Standards Track
</pre>
<pre id="AUTHOR"> T. Berners-Lee
W3C/MIT
R. Fielding
Day Software
L. Masinter
Adobe Systems
January 2005
</pre>
<h1>Uniform Resource Identifier (URI): 一般的構文</h1>
<h2>この文書の位置付け</h2>
<p>
この文書は、インターネットコミュニティにおけるインターネット標準化過程プロトコルを規定し、改良のために議論と提案を求めるものである。
このプロトコルの標準化状態と状況については、"Internet Official ProtocolStandards" (STD 1) の最新版を参照していただきたい。
この文書の配布に制限は無い。
</p>
<h2>著作権表示</h2>
<p>
Copyright © The Internet Society (2005). All Rights Reserved.
</p>
<h2>概要</h2>
<p>
Uniform Resource Identifier (URI) は、抽象的あるいは物理的なリソースを識別するための簡潔な文字列である。
この仕様書は、一般的な URI の構文と相対的形式である URI 参照を解決するための手順を定義し、更にインターネット上での URI の使用のついての指針やセキュリティについての考察を示す。
URI の構文では、全ての妥当な URI の上位集合{superset} である文法を定義し、実装が取り得る全ての識別子についてのスキーム特有な必要条件を知らなくても URI 参照の共通の構成要素{component} を解析する事を可能にする。
この仕様書では各 URI の生成文法は定義しない; それらの作業は各 URI スキームについてのそれぞれの仕様書によって行われる。
</p>
<h2>目次</h2>
<dl id="CONTENTS">
<dt>1. <a href="#section-1">導入</a></dt>
<dd><dl>
<dt>1.1. <a href="#section-1.1">URI の概観</a></dt>
<dd>1.1.1. <a href="#section-1.1.1">一般的構文</a></dd>
<dd>1.1.2. <a href="#section-1.1.2">例</a></dd>
<dd>1.1.3. <a href="#section-1.1.3">URI, URL, URN</a></dd>
</dl></dd>
<dd><dl>
<dt>1.2. <a href="#section-1.2">設計について</a></dt>
<dd>1.2.1. <a href="#section-1.2.1">転記性</a></dd>
<dd>1.2.2. <a href="#section-1.2.2">相互動作からの識別を分離する</a></dd>
<dd>1.2.3. <a href="#section-1.2.3">階層的識別子</a></dd>
</dl></dd>
<dd>1.3. <a href="#section-1.3">構文の表記法</a></dd>
<dt>2. <a href="#section-2">文字</a></dt>
<dd>2.1. <a href="#section-2.1">パーセントエンコーディング</a></dd>
<dd>2.2. <a href="#section-2.2">予約文字</a></dd>
<dd>2.3. <a href="#section-2.3">非予約文字</a></dd>
<dd>2.4. <a href="#section-2.4">エンコード/デコードする時は</a></dd>
<dd>2.5. <a href="#section-2.5">データを識別する</a></dd>
<dt>3. <a href="#section-3">構文の構成要素</a></dt>
<dd>3.1. <a href="#section-3.1">スキーム</a></dd>
<dd><dl>
<dt>3.2. <a href="#section-3.2">オーソリティ{Authority}</a></dt>
<dd>3.2.1. <a href="#section-3.2.1">ユーザ情報</a></dd>
<dd>3.2.2. <a href="#section-3.2.2">ホスト</a></dd>
<dd>3.2.3. <a href="#section-3.2.3">ポート</a></dd>
</dl></dd>
<dd>3.3. <a href="#section-3.3">パス</a></dd>
<dd>3.4. <a href="#section-3.4">クエリ</a></dd>
<dd>3.5. <a href="#section-3.5">フラグメント</a></dd>
<dt>4. <a href="#section-4">使用法</a></dt>
<dd>4.1. <a href="#section-4.1">URI 参照</a></dd>
<dd>4.2. <a href="#section-4.2">相対的参照</a></dd>
<dd>4.3. <a href="#section-4.3">絶対 URI</a></dd>
<dd>4.4. <a href="#section-4.4">同一文書の参照</a></dd>
<dd>4.5. <a href="#section-4.5">接尾辞参照</a></dd>
<dt>5. <a href="#section-5">参照の解決</a></dt>
<dd><dl>
<dt>5.1. <a href="#section-5.1">基底 URI の確立</a></dt>
<dd>5.1.1. <a href="#section-5.1.1">本文内に埋め込まれた基底 URI</a></dd>
<dd>5.1.2. <a href="#section-5.1.2">カプセル化しているエンティティからの基底 URI</a></dd>
<dd>5.1.3. <a href="#section-5.1.3">取得される URI からの基底 URI</a></dd>
<dd>5.1.4. <a href="#section-5.1.4">基底 URI の初期値</a></dd>
</dl></dd>
<dd><dl>
<dt>5.2. <a href="#section-5.2">相対性の解決</a></dt>
<dd>5.2.1. <a href="#section-5.2.1">基底 URI を解析する前に</a></dd>
<dd>5.2.2. <a href="#section-5.2.2">参照の変形</a></dd>
<dd>5.2.3. <a href="#section-5.2.3">パスの併合</a></dd>
<dd>5.2.4. <a href="#section-5.2.4">ドットセグメントの削除</a></dd>
</dl></dd>
<dd>5.3. <a href="#section-5.3">構成要素の再構成</a></dd>
<dd><dl>
<dt>5.4. <a href="#section-5.4">参照の解決の例</a></dt>
<dd>5.4.1. <a href="#section-5.4.1">通常の例</a></dd>
<dd>5.4.2. <a href="#section-5.4.2">特異な例</a></dd>
</dl></dd>
<dt>6. <a href="#section-6">正規化と比較</a></dt>
<dd>6.1. <a href="#section-6.1">等価</a></dd>
<dd><dl>
<dt>6.2. <a href="#section-6.2">比較の梯子</a></dt>
<dd>6.2.1. <a href="#section-6.2.1">単純な文字列の比較</a></dd>
<dd>6.2.2. <a href="#section-6.2.2">構文に基づく正規化</a></dd>
<dd>6.2.3. <a href="#section-6.2.3">スキームに基づく正規化</a></dd>
<dd>6.2.4. <a href="#section-6.2.4">プロトコルに基づく正規化</a></dd>
</dl></dd>
<dt>7. <a href="#section-7">セキュリティについての考察</a></dt>
<dd>7.1. <a href="#section-7.1">信頼性と整合性</a></dd>
<dd>7.2. <a href="#section-7.2">悪意のある構造</a></dd>
<dd>7.3. <a href="#section-7.3">後置のコード変換{Back-End Transcoding}</a></dd>
<dd>7.4. <a href="#section-7.4">珍しい IP アドレス形式</a></dd>
<dd>7.5. <a href="#section-7.5">機密性の高い情報</a></dd>
<dd>7.6. <a href="#section-7.6">意味論的{Semantic} 攻撃</a></dd>
<dt>8. <a href="#section-8">IANA について</a></dt>
<dt>9. <a href="#section-9">謝辞</a></dt>
<dt>10. <a href="#section-10">参照文献</a></dt>
<dd>10.1. <a href="#section-10.1">規約の一部としての参照</a></dd>
<dd>10.2. <a href="#section-10.2">情報提供としての参照</a></dd>
<dt>A. <a href="#SecA">URI のために収集された ABNF</a></dt>
<dt>B. <a href="#SecB">正規表現による URI 参照の解析</a></dt>
<dt>C. <a href="#SecC">状況内の URI の範囲設定</a></dt>
<dt>D. <a href="#SecD">RFC 2396. からの変更点</a></dt>
<dd>D.1. <a href="#SecD.1">追加点</a></dd>
<dd>D.2. <a href="#SecD.2">修正点</a></dd>
<dt>索引</dt>
<dt>筆者のアドレス</dt>
<dt>著作権表示全文</dt>
</dl>
<h2 id="section-1">1. 導入</h2>
<p>
Uniform Resource Identifiers (URI) は、リソースを識別するための単純かつ拡張性のある方法を提供する。
URI 構文とその意味論を扱うこの仕様書は、World-Wide Web グローバル情報利用の先進によって導入された概念に由来し、このような識別子の使用は 1990 年から始まり、これは "Universal Resource Identifiers in WWW" [<a href="#ref-RFC1630">RFC1630</a>] に記述されている。
URI の構文は、"Functional Recommendations for Internet Resource Locators" [<a href="#ref-RFC1736">RFC1736</a>] 及び "Functional Requirements for Uniform Resource Names" [<a href="#ref-RFC1737">RFC1737</a>] 内で明示される推奨を満足するように
設計されている。
</p>
<p>
この文書は、全ての URI について、単一で、一般的な構文を定義するための "Uniform Resource Locators" [<a href="#ref-RFC1738">RFC1738</a>] 及び "Relative Uniform Resource Locators" [<a href="#ref-RFC1808">RFC1808</a>] を取り込んだ、[<a href="#ref-RFC2396">RFC2396</a>] を廃案にするものである。
また、IPv6 アドレスについての構文を導入した、[<a href="#ref-RFC2732">RFC2732</a>] を廃案にするものである。
この文書は、RFC 1738 で個々の URL スキーム特有の構文について定義した部分を除外している;
これらの部分は、独立した文書として更新されるであろう。
新たな URI スキームの登録についての手順は、[<a href="#ref-BCP35">BCP35</a>] によって独立して定義される。
新たな URI スキームの設計者のための助言は、[<a href="#ref-RFC2718">RFC2718</a>] にて見つけられるだろう。
RFC 2396 からの全ての重要な変更点は、付録 <a href="#SecD">D</a> 内に注記されている。
</p>
<h3 id="section-1.1">1.1. URI の概観</h3>
<p>
URI は、以下のように特徴付けられる:
</p>
<dl>
<dt>統一書式 {Uniform}</dt>
<dd>
統一書式性にはいくつかの利点がある。
異なる型のリソース識別子を同じ状況の中で、例えそれらの資源にアクセスするためのメカニズムが異なっていても、使う事ができる。
異なる型のリソース識別子に共通した構文の慣習を、同一の意味論で解釈できる。
既に存在する識別子が使用する方法を妨げる事無く新たな型のリソース識別子を導入できる。
識別子をさまざま異なった状況で再利用でき、それゆえ新たなアプリケーションやプロトコルは既に存在する、巨大で広く用いられているリソース識別子の集合を活用できる。
</dd>
<dt>リソース {Resource}</dt>
<dd>
この仕様書では、リソースであるものの範囲を制限しない;
むしろ、"リソース" という用語は、URI によって識別される全てのものについて一般的な意味において使用される。
よく知られた例としては、電子文書、画像、一貫性のある目的をもつ情報源 (例えば、"本日のロサンゼルスの天気予報")、サービス (例えば、HTTP から SMS へのゲートウェイ)、またその他のリソースの集合等がある。
リソースは、インターネットを通じてアクセス可能である必要はない;
例えば、人間、企業、及び図書館にある装丁された書籍も、リソースとみなす事ができる。
同様に、数学の方程式の演算子やオペランド、関係の種類 (例えば、"親" や "会社員")、あるいは数値 (例えば、"0" や "1", "無限大") のような、抽象的な概念もリソースとなりうる。
</dd>
<dt>識別子 {Identifier}</dt>
<dd>
識別子は、識別の範囲内の他の全てのものから特定されている事を区別するために必要な情報を具体化する。
我々は、"識別" や "識別する" という用語を、あるリソースを他の全てのリソースから区別する目的のために用い、その目的がどのように (例えば、氏名、住所、あるいは状況によって) 達成されるかにかかわらない。
これらの用語は、識別子が、いくつかの識別子の場合ではそうでなくても、参照されるものの識別を定義する、あるいは具体化するという事の前提であると誤用されるべきではない。
また、URI を使用するシステムがリソースを識別してアクセスするという事を仮定すべきではない:
多くの場合、URI は、それらがアクセスされるといういかなる意図もなしにリソースを表すために使用される。
同様に、識別される "一つの" リソースは、本質的に唯一である必要はない (例えば、リソースとは、名付けられた一式のもの、あるいは時間経過と共に変化するものへの写像でありうる)。
</dd>
</dl>
<p>
URI は、Section <a href="#section-3">3</a> 内の <URI> と名付けられる構文則に一致する文字列から成る識別子である。
また、名付けられるスキーム (Section <a href="#section-3.1">3.1</a>) の独立して定義される拡張集合を通じてのリソースの統一書式の識別子も可能である。
その識別がどのように達成され、割り当てられ、あるいはそれを可能にするかは、それぞれのスキームの仕様書に委ねられる。
</p>
<p>
この仕様書は、アプリケーションが、リソースを識別するための URI を使用して、参照されるリソース、あるいはある種のシステムを探すかもしれないので、リソースの性質においていかなる制限も設けない。
この仕様書は、URI が時を経ても同じリソースを識別し続ける事を、それが全ての URI スキームの共通した目標ではあるけれども、要求はしない。
それにもかかわらず、この仕様書は、アプリケーションがそれ自身を特定のリソースの種類に制限する事や、そのアプリケーションで望まれる特性を保持する URI の部分集合に
制限する事を妨げない。
</p>
<p>
URI は、世界的規模の範囲を持っており、その解釈の結果はエンドユーザの状況と関連しているかもしれないが、状況にかかわらず一貫して解釈される。
例えば、"http://localhost/" は、その参照の全てのユーザが同じ解釈を持っているが、各エンドユーザにとって "localhost" に対応するネットワークインタフェースは異なる: すなわち、解釈はアクセスに依存しない。
しかし、その参照に基づいて行われた動作はエンドユーザの状況と関連して行われるであろう。
これは、全体において一意なものを参照する意図がある動作では、そのリソースを全ての他のものと区別するような URI を使用しなければならない事を意味する。
エンドユーザのローカルの状況と関連して識別するような URI は、オンラインヘルプマニュアルがエンドユーザのファイルシステム上のファイルを参照する (例えば、"file:///etc/hosts") 時のように、状況自体がリソースの定義している解釈である時のみ使用されるべきである。
</p>
<h4 id="section-1.1.1">1.1.1. 一般的構文</h4>
<p>
各 URI は Section <a href="#section-3.1">3.1</a> に定義されるように、そのスキームの中にある識別子を割り当てた仕様書を参照するような、スキーム名から始まる。
その場合、URI 構文は各スキームの仕様書がそのスキームを使用する識別子の構文と意味論を更に制限する事ができるような、連結された、拡張可能な命名システムである。
</p>
<p>
この仕様書は、全ての URI スキームが必要とする、あるいは多くの URI スキームに共通であるような URI 構文の要素を定義する。
従って、ここでは URI 参照のためにスキームに依存しない解析メカニズムを実装するのに必要な構文と意味論を定義し、スキーム依存な URI の扱いはスキーム依存な意味論が必要になるまで先延ばしする事ができる。
同様に、URI 参照を利用するプロトコルやデータ形式は、未だ定義されていないそれらのスキームを含む、全ての URI について認められた構文の範囲のための定義として、この仕様書を参照する事ができる。
これは、識別するスキームの発展と、URI を利用するプロトコル、データ形式、及び実装の発展とを切り離す。
</p>
<p>
一般的な URI 構文のパーサは、あらゆる URI 参照をその主な構成要素に解析する事ができる。
一度スキームが決定されれば、更にスキーム特有な解析が構成要素上で実行されるであろう。
言い換えれば、URI 一般構文は全ての URI スキームの構文の上位集合である。
</p>
<h4 id="section-1.1.2">1.1.2. 例</h4>
<p>
以下に例示する URI は、いくつかの URI スキームとそれらの一般的な構文構成要素においての変化を例証したものである。
</p>
<pre> ftp://ftp.is.co.za/rfc/rfc1808.txt
http://www.ietf.org/rfc/rfc2396.txt
ldap://[2001:db8::7]/c=GB?objectClass?one
mailto:[email protected]
news:comp.infosystems.www.servers.unix
tel:+1-816-555-1212
telnet://192.0.2.16:80/
urn:oasis:names:specification:docbook:dtd:xml:4.1.2
</pre>
<h4 id="section-1.1.3">1.1.3. URI, URL, URN</h4>
<p>
URI は、それが位置指定子か、名前か、あるいはその両方かという点において、更に分類できる。
"Uniform Resource Locator" (URL) という用語は、リソースを識別するのに加えて、その主なアクセスメカニズム (例えば、そのネットワーク上の "位置") を記述する事によってリソースの場所を見つける方法を提供するような、URI の部分集合を指す。
"Uniform Resource Name" (URN) という用語は、例えそのリソースが存在しなくなったり、あるいは利用不可能になっても全体において一意で永続的である事が要求される "urn" スキーム [<a href="#ref-RFC2141">RFC2141</a>] の下での両方の URI、また名前の特性を持つあらゆる他の URI を参照するために歴史的に使用されている。
</p>
<p>
個々のスキームは、"名前" あるいは "位置指定子" のどちらか一方に分類される必要はない。
あらゆる与えられたスキームからの URI の例でも、名前、位置指定子、あるいは両方の特性を持っているかもしれないし、これはしばしばスキームのどんな品質よりも、命名の権威{naming authority} による識別子の割り当てにおける永続性と配慮に依存する。
将来の仕様書や関連文書では、より制限された用語である "URL" や "URN" よりも一般的な用語である "URI" を使用すべきである [<a href="#ref-RFC3305">3305</a>]。
</p>
<h3 id="section-1.2">1.2. 設計について</h3>
<h4 id="section-1.2.1">1.2.1. 転記</h4>
<p>
URI 構文は、その主な考慮事項の一つとして世界的な転記性を持つように設計されている。
URI は、非常に限られた文字集合、すなわち基本的なラテンアルファベット、数字、そしていくつかの特殊文字から成る文字列である。
URI は、例えば、紙の上のインクや、画面上のピクセル、あるいはエンコードしているオクテット文字列中など、様々な方法で表現できる。
URI の解釈は、使用されている文字にのみ依存し、それらの文字がネットワークプロトコル中でどのように表現されているかには依存しない。
</p>
<p>
転記性の目的は、簡単な筋書きによって説明する事ができる。
ある国際会議で、2 人の参加者 Sam と Kim が、パブで席について、研究のアイデアをやりとりしている様子を想像して頂きたい。
Sam が Kim により詳細な情報を得るための場所を尋ねると、Kim は研究のサイトの URI をナプキンに書く。
家に帰った後、Sam がナプキンを取り出しコンピュータに URI を打ち込めば、Kim が示した情報を取得するであろう。
</p>
<p>
このシナリオによって、いくつかの設計上の考慮事項が明らかにされている:
</p>
<ul>
<li>
URI は、常にオクテット列として表現されるわけではないような文字列である。
</li>
<li>
URI はネットワークにはない情報源から転記されるかもしれないので、ほとんどのコンピュータで入力可能な文字から成るべきであるが、そこには各種の言語やロケールのキーボード (及び関連する入力デバイス) による制限を負う。
</li>
<li>
URI は、しばしば人間が記憶しなければならないが、その構成要素が意味を持つ、あるいは親しみやすものから成る場合は、人間にとってより覚えやすい。
</li>
</ul>
<p>
これらの設計についての考慮事項は、常に合致するわけではない。
例えば、ある URI 構成要素において最も意味を持つ名前があるシステムではタイプできないような文字を必要とするというような場合がしばしばある。
リソース識別子をあるメディアから別のメディアへ転記するための能力は、URI が最も意味を持つ構成要素から成る事よりも重要であると考えられている。
</p>
<p>
ローカルや局所的状況において、かつ技術的改良を持ってすれば、ユーザはより広範囲の文字を使用でき、恩恵をうけるかもしれない;
但し、そのような使用法はこの仕様書では定義されない。
Percent-encoded オクテット (Section <a href="#section-2.1">2.1</a>) は、その表現がその URI が参照するスキーム、あるいはプロトコル要素によって認められているのであれば、US-ASCII にてコード化された文字セットの範囲外の文字を表すために URI の中で使用する事ができる。
そのような定義は、percent-encode する前に、その文字をオクテットにマッピングするために使用される文字エンコーディングを明示すべきである。
</p>
<h4 id="section-1.2.2">1.2.2. 相互動作からの識別を分離する</h4>
<p>
URI のについて一般的な誤解は、それらがアクセス可能なリソースを示すためだけに使用されるとされている事である。
URI 自身は、識別を提供するだけである;
すなわち、URI の存在によってリソースへのアクセスが保証されてもいないし、意味されるという事でもない。
その代わり、URI 参照に関連するあらゆる操作は、それが表されるプロトコルの要素、データの形式属性、あるいは自然言語文書によって定義される。
</p>
<p>
URI が与えられた場合、システムは、"アクセス"、"更新"、"置き換え"、あるいは "属性の検索" 等の語によって特徴付けられるような、様々な操作をそのリソースへ行おうとするかもしれない。
そのような操作は、この仕様書によってではなく、URI を利用するプロトコルによって定義される。
しかし、我々は URI における共通の操作について記述するためのいくつかの一般的な用語を使用する。
URI "解決" は、URI を逆参照 {dereference} するために必要なアクセスメカニズムや適切なパラメータを決定するための手順である。
この解決は、数回の繰り返しが必要かもしれない。
URI 上にあるリソースへの動作を実行するためにそのアクセス機構を使用する事が、URI を "逆参照" するという事である。
</p>
<p>
URI が情報源を特定するために情報取得システムの中で使用される時に、最も一般的な URI 逆参照の形式は "取得{retrieval}" である:
すなわち、それに関連したリソースの表現を取得するために URI を利用する。
"表現" とは、表現が生成される時のリソースの状態に関する記録の構成要素であるオクテット列と、それらオクテットを説明するための外部データ表現である。
情報の取得は、ローカルにキャッシュされた表現についてチェックするためのキャッシュ鍵としての URI の使用、(存在する場合) 適切なアクセスメカニズムを決定するための URI の解決、そして取得操作を適用するための URI の逆参照を包括した過程によって成し遂げられる。
取得を実行するために使用されるプロトコルによっては、リソース (リソース外部データ) についてや、他のリソースとの関係についての追加情報が提供されるかもしれない。
</p>
<p>
情報取得システムにおける URI 参照は、遅延結合{late-binding} であるように設計される:
一般に、アクセスの結果はアクセスされる時に決定されるが、それは時間経過あるいは他の相互作用による状況により変化するかもしれない。
これらの参照は、将来に使用されるために生成されるものである:
そこで識別されているものは過去に得られたある特定の結果ではないが、将来の結果において真実であると予測される何らかの特性ではある。
そのような場合、URI によって参照されるリソースは、実際には時を経た後に観測された時には、もしかしたらリソース供給者によって追加コメントや主張による説明がなされているかもしれないが、同一の特性を持つ。
</p>
<p>
多くの URI スキームがプロトコルにちなんで名付けられているが、これはこれらの URI の使用が名付けられたプロトコルを通じてリソースへアクセスする結果になるという事を意味するものではない。
URI は、しばしば単純なる識別のために使用される。
URI がリソースの表現を取得するために使用される時でさえ、そのアクセスはスキーム名に関連するプロトコルに依存しないゲートウェイ、プロクシ、キャッシュ、及び名前解決サービスを通じてのものかもしれない。
いくつかの URI の解決では複数のプロトコルの使用を必要とするかもしれない
(例えば、表現がローカルキャッシュ内に見つけられない時には "http" URI のオリジンサーバへアクセスするために、通常 DNS と HTTP の両方が使用される)。
</p>
<h4 id="section-1.2.3">1.2.3. 階層的識別子</h4>
<p>
URI 構文は階層的に組織化されており、より重要度が減少していく順に左から右へ構成要素が列挙されている。
いくつかの URI スキームにおいては、可視的階層構造はスキーム自体に制限される:
この場合、スキーム要素区切り子 (":") の後の全ては、URI 処理から見られない{opaque} とみなされる。
その他の URI スキームでは、階層構造を一般的な構文解析アルゴリズムに明示かつ可視にする。
</p>
<p>
一般的構文では、一般的なパーサの識別子の階層的な解釈に重要である構成要素を区切るために、スラッシュ ("/")、疑問符 ("?")、及び番号記号 ("#") 文字を使用する。
命名スキームを超えたこの階層構造の統一的表現は、わかりやすい構文の一貫した使用を通じてそのような識別子の読み易さを助ける事に加えて、スキームに依存しない参照をその階層構造に相対させる事ができる。
</p>
<p>
文書のグループあるいは "木{tree}" が共通の目的に役立つように構成されており、それら文書の大量の URI 参照がその外よりも木の中のリソースを指すような場合がしばしばある。
同様に、特定のサイトに位置する文書は、リモートサイトにあるリソースよりもはるかに、そのサイトにある他のリソースを参照するであろう。
URI の相対的参照によって、文書木はそれらの位置やアクセススキームに部分的に独立させる事ができる。
例えば、単一のハイパーテキスト文書の集合が相対的参照によってが互いに参照するならば、"file", "http", "ftp" の各スキームでアクセス可能であり、また横断可能{traversable} であるようにする事もできる。
更に、そのような文書木は、相対的参照のいずれも変更せずに、全体で、移動する事ができる。
</p>
<p>
相対的参照 (Section <a href="#section-4.2">4.2</a>) は、参照状況と目標 URI の間の階層的名前空間における違いを記述する事によってリソースを参照する。
Section <a href="#section-5">5</a> に示される参照解決アルゴリズムは、そのような参照がどのように目標 URI に変形されるかを定義する。
相対的参照は階層的な URI の状況中でのみ使用されるので、新たな URI スキームの設計者は、そのスキーム中で相対的参照を禁じざるを得ない理由がないのであれば、一般的な構文の階層的構成要素に一致する構文を使用すべきである。
</p>
<p class="note">
注意: 以前の仕様書では、URI の相対的参照を示すために "部分的 UR" と "相対的 URI" という用語を使用した。
何人かの読者がそれらの用語の意味を相対的な URI とは URI を参照する方法ではなく、URI の部分集合であると誤解したので、この仕様書ではそれらを単に相対的参照と述べる。
</p>
<p>
全ての URI 参照は、一般的な構文パーサが使用された時に解析される。
しかし、
1 つ以上のドットセグメント (Section <a href="#section-3.3">3.3</a> にて説明されるような、"." や ".." を持つ完全パスセグメント) を含んでいなければ、階層的処理は参照内で使用される絶対 URI には影響を与えないので、URI スキームの仕様は、スラッシュ文字、疑問符文字、及び "scheme:." と "scheme:.." という URI の使用を禁じる事によって、隠された{opaque} 識別子を定義する事ができる。
</p>
<h3 id="section-1.3">1.3. 構文の表記法</h3>
<p>
この仕様書は、[<a href="#ref-RFC2234">RFC2234</a>] で定義される以下のコア ABNF 構文則を含む、Augmented Backus-Naur Form (ABNF) 表記法を使用する:
ALPHA (文字), CR (復帰), DIGIT (10 進数字), DQUOTE (二重引用符), HEXDIG (16 進数字), LF (改行), SP (スペース)。
完全なる URI 構文は、付録 <a href="#SecA">A</a> に纏められる。
</p>
<h2 id="section-2">2. 文字</h2>
<p>
URI 構文は、おそらくリソースを識別するために、データを文字列をしてエンコードする方法を提供する。
URI 文字は、順に、転送や表示のためにオクテットに頻繁にエンコードされる。
この仕様書では、それらの文字を保存したり、転送するために使用される URI 文字とオクテットの間のマッピングについていかなる特定の文字エンコーディングも強制しない。
URI がプロトコル要素内に現れる場合、文字エンコーディングはそのプロトコルによって定義される;
もしそのような定義がなければ、URI は周囲のテキストと同じ文字エンコーディングであると仮定される。
</p>
<p>
ABNF 表記法は、その端子の値を US-ASCII にてコード化された文字セット [<a href="#ref-ASCII">ASCII</a>] に基づく負でない整数 (codepoints) と定義する。
URI は文字列なので、URI 構文を理解するためにその関係を逆にしなければならない。
従って、ABNF にて使用される整数値は構文則を完成するために US-ASCII を通してその対応する文字へとマッピングし戻さなければならない。
</p>
<p>
URI は、数字、文字、及びいくつかの図形記号から成る文字の限定的な集合から構成される。
それらの文字のうちの予約されている部分集合は、区切り子としての役目を果たさない予約されていない集合とそれらの予約されている集合を含む、残りの文字が各構成要素の識別データを定義する間、URI 中の構文構成要素を区切るために使用される。
</p>
<h3 id="section-2.1">2.1. パーセントエンコーディング</h3>
<p>
パーセントエンコーディング{percent-encoding} メカニズムは、オクテットの対応する文字が認められた文字の範囲外にある、あるいは構成要素の中で区切り子として使用されている場合に使用される。
パーセントエンコードされたオクテットは、パーセント文字 "%" と、そのオクテットの数値を表している二桁の 16 進数字から成る三重語としてエンコードされる。
例えば、"%20" は 2 進オクテット "00100000" (ABNF: %x20) についてのパーセントエンコーディングであり、US-ASCII のスペース文字 (SP) に対応している。
Section <a href="#section-2.4">2.4</a> は、パーセントエンコーディングとデコーディングが適応される時について記述している。
</p>
<pre> pct-encoded = "%" HEXDIG HEXDIG</pre>
<p>
大文字の 16 進数字 'A' から 'F' は、小文字の 'a' から 'f' とそれぞれ等価である。
二つの URI のパーセントエンコードされたオクテット内で使用される 16 進数字の大文字・小文字のみが異なる場合、それらは等価である。
整合性を持たせるため、URI の生成を行うもの{producers} や正規化を行うもの{normalizers} は全てのパーセントエンコーディングについて大文字の 16 進数字を使用すべきである。
</p>
<h3 id="section-2.2">2.2. 予約文字</h3>
<p>
URI は、"予約されている" 集合内の文字によって区切られる構成要素及び副構成要素を含んでいる。
これらの文字は、URI の逆参照アルゴリズムにおける一般的な構文、各スキーム特有の構文、あるいは実装特有の構文によって区切り子として定義される (あるいはされない) ので、"予約されている" と呼ばれる。
URI 構成要素についてのデータがデリミタとして予約されている文字の目的と競合する場合、競合するデータは URI が形成される前にパーセントエンコーディングされなければならない。
</p>
<pre> reserved = gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
</pre>
<p>
予約されている文字の目的は、URI 中の他のデータから区別可能である区切り文字の集合を提供する事である。
予約文字を、対応するパーセントエンコードされたオクテットに置き換えている点が異なる URI は、等価ではない。
ほとんどのアプリケーションにおいて、予約文字をパーセントエンコーディングする、あるいは予約文字に対応するパーセントエンコードされたオクテットをデコードする事によって、URI がどう解釈されるかが変わるであろう。
従って、予約されている集合内の文字は正規化{normalization} から保護されており、それ故に、それらは URI 内のデータ副構成要素を区切るためにスキーム特有、あるいは生成を行うもの特有のアルゴリズムによって使用されても安全であるだろう。
</p>
<p>
予約されている文字の部分集合 (gen-delims) は、Section <a href="#section-3">3</a> にて記述されるように一般的な URI 構成要素の区切り子として使用される。
構成要素の ABNF 構文則は、reserved あるいは gen-delims 規則名を直接には使用しないだろう;
その代わり、各構文則は、その構成要素として認められる (すなわち、それを区切らない) 文字と、そして予約されている集合の中にも構成要素の中の副構成要素の区切り子としての使用のために "予約されている" 任意の文字を列挙する。
この仕様書では最も一般的な副構成要素のみを定義する;
他の副構成要素は、そのような副構成要素がその構成要素として認められる予約されている集合内によって区切られるのであれば、URI スキームの仕様書、あるいは URI 逆参照アルゴリズムの実装特有な構文にて定義されるであろう。
</p>
<p>
URI 生成アプリケーションは、もし予約されている集合内の文字がその構成要素内のデータを表すために URI スキームによって特に認められているのでなければ、それらの文字に対応するデータオクテットをパーセントエンコードすべきである。
予約されている文字が URI 構成要素内に見つかったが、その文字についての区切り規則がわからない場合は、US-ASCII 内のその文字エンコーディングに対応するデータオクテットを表すものとして解釈されなければならない。
</p>
<h3 id="section-2.3">2.3. 非予約文字</h3>
<p>
URI 内に含む事が認められており、予約目的のない文字は、予約されていない (unreserved) と呼ばれる。
これは、大文字と小文字のアルファベット、数字、ハイフン、ピリオド、アンダースコア、チルダが含まれる。
</p>
<pre> unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"</pre>
<p>
非予約文字を、対応するパーセントエンコードされた US-ASCII オクテットに置き換えている点が異なる URI は、等価である:
それらは同じリソースを識別する。
しかし、URI 比較を行う実装が常に比較の前に正規化を行うわけではない (Section <a href="#section-6">6</a> 参照)。
整合性を持たせるため、URI の生成を行うものは ALPHA (%41-%5A と %61-%7A), DIGIT (%30-%39), hyphen (%2D), period (%2E), underscore (%5F), tilde (%7E) の範囲におけるパーセントエンコードされたオクテットを生成すべきではないし、URI を発見した時に、URI 正規化によってそれらを対応する非予約文字にデコードすべきである。
</p>
<h3 id="section-2.4">2.4. エンコード/デコードする時は</h3>
<p>
通常の状況下では、URI 内のオクテットがパーセントエンコードされる時は、その構成部品から URI の生成処理の間のみである。
これは、実装が副構成要素の区切り子として予約文字のいずれを使用するか、そしてそれはデータとして安全に使用できるを決定する時である。
一度生成されれば、URI は常にパーセントエンコードされた形式である。
</p>
<p>
URI が逆参照される時、スキーム特有の逆参照処理 (存在する場合) に重要である構成要素と副構成要素は、そうしなければデータが構成要素の区切り子と間違えられるので、それらの構成要素に含まれるパーセントエンコードされたオクテットが安全にデコードされる前に解析され、分割されなければならない。
唯一の例外は、パーセントエンコードされたオクテットが非予約集合内の文字に対応する場合で、この時はいつでもデコードできる。
例えば、チルダ ("~") に対応するオクテットは、古い URI 処理実装によってしばしば "%7E" としてエンコードされる;
しかし、 "%7E" はその解釈を変える事無く "~" に置き換える事ができる。
</p>
<p>
パーセント ("%") 文字はパーセントエンコードコード化されたオクテットのための指示器{indicator} としての役割を持つので、そのオクテットを URI 内のデータとして使用するためには"%25" とパーセントエンコードされなければならない。
既にデコードされた文字列を更にデコーディングする事はパーセントデータオクテットをパーセントエンコーディングの始まりと誤解する事に繋がるし、逆にパーセントエンコーディングの場合も既にエンコードされた文字列を誤解する事に繋がるであろうから、実装は同じ文字列を複数回パーセントエンコードやパーセントデコードをしてはならない。
</p>
<h3 id="section-2.5">2.5. データを識別する</h3>
<p>
URI 文字は、各 URI 構成要素についてデータの識別を提供し、システム間の識別のための外部インタフェースとしての役目を持つ。
URI 生成インタフェースの存在と性質は URI を使用するクライアントから隠される (そしてそれ故この仕様書で定義される相互運用性要件の範囲を超える) が、これは URI 文字の解釈の問題における頻繁な混乱と誤りの原因である。
実装者は、URI の生成と送信において複数の文字エンコーディング、すなわち、ローカル名、データエンコーディング、パブリックインタフェースエンコーディング、URI 文字エンコーディング、データフォーマットエンコーディング、プロトコルエンコーディングがある事に気付いていなければならない。
</p>
<p>
ファイルシステム名のようなローカル名は、ローカルな文字エンコーディングを用いて保存される。
URI 生成アプリケーション (例えば、オリジンサーバ) は、通常意味のある名前を生成するために原則としてローカルなエンコーディングを使用するであろう。
URI 生成者は、ローカルのエンコーディングをパブリックインタフェースに適するものに変形し、URI 文字の制限される集合 (予約文字、非予約文字、パーセントエンコーディング) へとパブリックインタフェースエンコーディングを変形するであろう。
それらの文字はデータフォーマットに含まれる参照として使用されるオクテット (例えば、文書の文字セット) として、順にエンコードされ、そのようなデータフォーマットは、しばしば続いてインターネットプロトコルを通じた転送のためにエンコードされます。
</p>
<p>
ほとんどのシステムにおいて、URI 構成要素内に現れる非予約文字は、US-ASCII 内のその文字のエンコーディングに対応するデータオクテットを表すものとして解釈される。
URI の需要者{Consumer} は、文字 "X" はオクテット "01011000" に対応すると仮定するし、例えその仮定が正しくない時でさえ、それを行う事において差し支えない。
EBCDIC のように、内部的に異なる文字エンコーディングの形式にて識別を提供するシステムは、一般に内部インタフェースにおいて原文の識別子を UTF-8 [<a href="#ref-STD63">STD63</a>] (あるいはいくつかの US-ASCII 文字エンコーディングの上位集合) へと文字変換エンコーディングを実行し、それにより単に元のオクテットをパーセントエンコードしたものよりもより意味を持つ識別子を提供できるであろう。
</p>
<p>
例えば、内部的に EBCDIC ベースのファイルシステムを使用して保存し、HTTP サーバを通じてインターネット上のクライアントへデータを提供するような情報サービスを考える。
著者がそのファイルシステム上に "Laguna Beach" という名前のファイルを作成する時、そのリソースに対応する "http" URI は意味を持つ文字列 "Laguna%20Beach" を含むと思われる。
しかし、
そのサーバが極度に単純化した未加工オクテットマッピングを使用して URI を生成した場合、その結果は "%D3%81%87%A4%95%81@%C2%85%81%83%88" を含む URI となるであろう。
内部コード変換インタフェースは、URI を生成する前にそのローカル名を US-ASCII の上位集合にコード変換する事でこの問題を修正する。
当然、そのようなインタフェースにおいて入って来る URI の適切な解釈には、逆コード変換がローカル名を得るために適用される前にパーセントエンコードされたオクテットが (例えば、"%20" から SP へと) デコードされる必要がある。
</p>
<p>
いくつかの場合では、それを表すために作られている URI 構成要素と識別されるデータの間と内部インタフェースは文字エンコーディングの翻訳よりよっぽど遠回りなものとなる。
例えば、URI の一部では、非 ASCII データにおけるクエリや、地図における数値座標を反射するかもしれない。
同じく、URI スキームは、構成要素を形成し URI を生成する前に、追加的エンコーディング要求を持つ構成要素を定義するかもしれない。
</p>
<p>
新たな URI スキームが汎用文字セット [<a href="#ref-UCS">UCS</a>] の文字から成るテキストデータを表す構成要素を定義する時、そのデータは最初に [<a href="#ref-STD63">STD63</a>] エンコードする UTF-8 文字によってオクテットとしてエンコードされるべきである;
そして、非予約集合内の文字に対応していないオクテットのみをパーセントエンコーディングすべきである。
例えば、文字 A は "A" と、GRAVE (訳注: アクセント記号) を持つラテン語の大文字では "%C3%80" と、カタカナ文字のアは "%E3%82%A2" と、それぞれ表されるであろう。
</p>
<h2 id="section-3">3. 構文の構成要素</h2>
<p>
一般的な URI 構文では、scheme, authority, authority, path, query, fragment と呼ばれる構成要素の階層的なシーケンスから成る。
</p>
<pre>
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
hier-part = "//" authority path-abempty
/ path-absolute
/ path-rootless
/ path-empty
</pre>
<p>
構成要素として scheme と path は必要であるが、path は空 (文字がない) かもしれない。
authority がある場合、path は空であるか、あるいはスラッシュ ("/") 文字で始めなければならない。
authority がない場合、path は 2 つのスラッシュ文字 ("//") で始まる事はできない。
これらの制限は path (Section <a href="#section-3.3">3.3</a>) への五つの異なる ABNF 規則をもたらすが、与えられたいかなる URI 参照もその中の一つのみに一致するであろう。
</p>
<p>
以下は、二つの URI の例とそれらの構成要素部分である:
</p>
<pre>
foo://example.com:8042/over/there?name=ferret#nose
\_/ \______________/\_________/ \_________/ \__/
| | | | |
scheme authority path query fragment
| _____________________|__
/ \ / \
urn:example:animal:ferret:nose
</pre>
<h3 id="section-3.1">3.1. スキーム</h3>
<p>
各 URI は、そのスキームを含む識別子を割り当てるための仕様書を参照するスキーム名で始まる。
その場合、URI 構文は各スキームの仕様書がそのスキームを使用する識別子の構文と意味論を更に制限する事ができるような、連結された、拡張可能な命名システムである。
</p>
<p>
スキーム名は、文字で始まり、その後に文字、数字、プラス("+")、ピリオド ("."), ハイフン ("-") を繋げたものから成る。
scheme は大文字・小文字を区別しないが、標準形は小文字なので、scheme を規定する文書では小文字で記述しなければならない。
実装は、ロバスト性のために scheme において大文字を小文字と同等に受け入れる (例えば、"HTTP" を "http" と同様に認める) べきであるが、整合性を持たせるために小文字のスキーム名のみを生成するべきである。
</p>
<pre> scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )</pre>
<p>
個々のスキームはこの文書では規定されない。
新たな URI スキームの登録の手順は、[<a href="#ref-BCP35">BCP35</a>] によって別個に定義される。
スキームの登録では、スキーム名とそれらの仕様書間の対応を保存する。
新たな URI スキームの設計者への助言は、[<a href="#ref-RFC2718">RFC2718</a>] にて見つけられる。
URI スキームの仕様は、それらのスキーム特有の構文に合致する全ての文字列が、Section <a href="#section-4.3">4.3</a> にて記述されるように、<absolute-URI> の文法にも合致するように、それら自身の構文も定義しなければならない。
</p>
<p>
一つ以上のスキーム特有の制限に違反する URI がある場合、スキーム特有の解決処理は不使用の部分を無視するよりもエラーとしてその参照を知らせるべきである;
そうする事によって、同等な URI の数を減らし、一般的な構文の乱用を検出する助けとなる。
これはその URI がユーザを誤り導くために構成されている事を示すものかもしれない (Section <a href="#section-7.6">7.6</a>)。
</p>
<h3 id="section-3.2">3.2. オーソリティ</h3>
<p>
多くの URI スキームは命名オーソリティ{authority} についての階層的な要素に含んでいるので、URI の残りの部分によって定義される名前空間の管理はそのオーソリティへと委ねられる (それらは更に他へ委ねられるかもしれない)。
一般的な構文は、登録名あるいはサーバアドレス、そして任意のポートとユーザ情報に基づく、authority を区別するための一般的な方法を提供する。
</p>
<p>
authority 構成要素は、ダブルスラッシュ ("//") で始まり、次のスラッシュ ("/")、疑問符 ("?")、及び番号記号 ("#") のいずれかの文字、あるいは URI の終了によって終結する。
</p>
<pre> authority = [ userinfo "@" ] host [ ":" port ]</pre>
<p>
URI の生成を行うものや正規化を行うものは、port 要素が空の場合は、host と port とを分けるための ":" 区切り子を省略すべきである。
いくつかのスキームでは、userinfo や port 副構成要素を認めない。
</p>
<p>
URI が authority 要素を含む場合、path 要素は、空であるか、あるいはスラッシュ ("/") 文字で始めなければならない。
(単にその主構成要素から URI 参照を分離するような) 妥当性を確かめないパーサは、URI が逆参照される時まで、しばしば authority の副構成要素構造を無視し、ダブルスラッシュから最初の終端区切り子までを不明な{opaque} 文字列として扱うであろう。
</p>
<h4 id="section-3.2.1">3.2.1. ユーザ情報</h4>
<p>
userinfo 副構成要素は、ユーザ名と、任意でリソースにアクセスするための認証を得る方法についてのスキーム特有の情報を含むであろう。
ユーザ情報が存在する場合、ホストからそれを区切るための商業的アットサイン ("@") を従える。
</p>
<pre> userinfo = *( unreserved / pct-encoded / sub-delims / ":" )</pre>
<p>
userinfo において "user:password" 形式の使用は推奨されない。
アプリケーションは、コロンの後のデータが空文字列 (パスワードがない事を示す) でなければ、userinfo 副構成要素の中に見つけられる最初のコロン (":") 文字の後にいかなるデータも明文として表示すべきでない。
アプリケーションは、それを参照の一部として受け取る時、そのようなデータを無視するか、または拒絶するのを選ぶ事ができ、暗号化されていない形式においてはそのようなデータの保存を拒絶すべきである。
明文での認証情報の通過は、それが使用されているほとんどすべての場合においてセキュリティリスクがあるとわかっている。
</p>
<p>
グラフィカルなハイパーテキストのブラウジング等のような、ユーザフィードバックのために URI を表示するアプリケーションは、可能であれば、URI の残りの部分から区別される方法で userinfo を表示すべきである。
そのような表現は、 userinfo が誤解させるように扱われるドメイン名に似せて作られているような場合にユーザの助けとなるであろう (Section <a href="#section-7.6">7.6</a>)。
</p>
<h4 id="section-3.2.2">3.2.2. ホスト</h4>
<p>
authority の host 副構成要素は、角括弧によって括られる IP 文字列、ドット付数字形式の IPv4 アドレス、及び登録名のいずれかによって識別される。
host 副構成要素は大文字・小文字を区別しない。
URI 内に host 副構成要素がある事が、スキームはインターネット上の与えられるホストへのアクセスを要求する事を意味するものではない。
多くの場合、host 構文は DNS のために作成され、展開される既存の登録手続きの再利用のためだけに使用され、その結果、別の登録を展開するコスト無しに全体において一意な名前を得る。
しかし、そのような使用はそれ自身のコストを伴う:
ドメイン名所有権は時が経つと URI の生成を行うものによって予測されない理由によって変わるかもしれない。
そうでない場合、host 構成要素内のデータはインターネットホストとは関係ない登録名を特定する。
それがその唯一の目的ではなく、その最も一般的な目的であるので、我々は ABNF 規則のために "host" という名前を使用する。
</p>
<pre> host = IP-literal / IPv4address / reg-name</pre>
<p>
IPv4address と reg-name との間で完全に区別できないので、host のついての構文則はあいまいなものである。
この構文を区別するために、"first-match-wins" アルゴリズムを適用する:
すなわち、host が IPv4address の規則に一致する場合は、それを IPv4 アドレス文字列とみなすべきだし、そうでなければ reg-name とみなすべきである。
host は大文字・小文字を区別しないが、URI の生成を行うものや正規化を行うものは、パーセントエンコーディングのためだけ大文字を使用し、画一性のために登録名や 16 進数字のアドレスについて小文字を使用すべきである。
</p>
<p>
インターネットプロトコルの文字列アドレス、バージョン 6 [<a href="#ref-RFC3513">RFC3513</a>] 及びそれ以降によって識別される host は、角括弧 ("[" と "]") を伴う IP 文字列で括られる事によって区別される。
これは角括弧文字が URI 構文にて許される唯一の場所である。
将来のいまだ定義されていない IP 文字列アドレス形式での予想において、実装は発見的解決法{heuristic} の決定に従うよりも、そのような形式を明示的に示すために任意のバージョンフラグを使用するかもしれない。
</p>
<pre> IP-literal = "[" ( IPv6address / IPvFuture ) "]"
IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
</pre>
<p>
バージョンフラグは IP バージョンを示さない;
むしろ、将来の文字列形式のバージョンを示す。
その場合、実装は以下に記述される既存の IPv4 や IPv6 文字列アドレス形式においてバージョンフラグを提供してはならない。
"v" (大文字・小文字を区別しない) で始まる IP-literal を含む URI は、バージョンフラグが存在する事を示すが、そのバージョンフラグの意味を知らないアプリケーションによって逆参照されるが、アプリケーションは"アドレスメカニズムがサポートされていない" 事についての適切なエラーを返すべきである。
</p>
<p>
IPv6 文字列アドレスによって識別される host は、バージョンフラグが置かれる事なく角括弧内に表される。
ここで提供される ABNF は、[<a href="#ref-RFC3513">RFC3513</a>] 内で提供される IPv6 文字列アドレスのテキスト定義の変形である。
この構文は、IPv6 scoped addressing zone identifiers をサポートしない。
</p>
<p>
128 ビットの IPv6 アドレスは、八つの 16 ビットの要素に分割される。
各要素は、一文字から四文字の 16 進数字を使用して (先行する 0 は認められる)、大文字・小文字を区別しない 16 進数字にて数値的に表現される。
八つのエンコードされた要素は、上位ビットが先に与えられ、コロン文字によって分割される。
任意で、下位の二つの要素は、代わりに IPv4 アドレスのテキスト形式にて表す事ができる。
アドレスに含まれる一つ以上の連続した 0 の 16 ビット要素の文字列は、それらの全ての数字を省略する事ができ、その省略を示すためにその場所にちょうど二つの連続したコロンを置く。
</p>
<pre> IPv6address = 6( h16 ":" ) ls32
/ "::" 5( h16 ":" ) ls32
/ [ h16 ] "::" 4( h16 ":" ) ls32
/ [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
/ [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
/ [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32
/ [ *4( h16 ":" ) h16 ] "::" ls32
/ [ *5( h16 ":" ) h16 ] "::" h16
/ [ *6( h16 ":" ) h16 ] "::"
ls32 = ( h16 ":" h16 ) / IPv4address
; アドレスの下位 32 ビット
h16 = 1*4HEXDIG
; 16 進数字で表現される 16 ビットのアドレス
</pre>
<p>
IPv4 文字列アドレスによって識別される host は、[<a href="#ref-RFC0952">RFC0952</a>] を参照する [<a href="#ref-RFC1123">RFC1123</a>] にて記述されるように、ドット付数字表記法 ("." によって分けられる、四つの 0 から 255 までの数字の連なり) によって表される。
Section <a href="#section-7.4">7.4</a> にて示されるように、いくつかのプラットフォームでは他のドット付数字表記法の形式が解釈されるかもしれないが、この文法では四つのオクテットのドット付数字表記法のみが許される事に注意せよ。
</p>
<pre> IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
dec-octet = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
</pre>
<p>
登録名によって識別されるホストは、 URI のスキーム特有の意味論が特定の登録 (あるいは固定された名前テーブル) が代わりに使用される事を必要とするかもしれないが、通常ローカルで定義されるホストやサービス名登録の中のルックアップのための文字列である。
最も一般的な名前登録メカニズムは、ドメインネームシステム (DNS) である。
DNS 内のルックアップのための登録名は、
[<a href="#ref-RFC1034">RFC1034</a>] の Section 3.5 と [<a href="#ref-RFC1123">RFC1123</a>] の Section 2.1 にて定義される構文を使用する。
そのような名前は、"." によって分けられるドメインラベルの連なりから成り、各ドメインラベルの初めと最後はアルファベットか数字の文字であるが、その間では "-" を含む事もできる。
DNS における完全修飾ドメイン名{fully qualified domain name} の最も右のドメインラベルは単一の "." を付ける事ができ、完全なるドメイン名とあるローカルドメインとの間で区別する必要がある場合はそうすべきである。
</p>
<pre> reg-name = *( unreserved / pct-encoded / sub-delims )</pre>