-
Notifications
You must be signed in to change notification settings - Fork 4
/
186.txt
1358 lines (1075 loc) · 68.3 KB
/
186.txt
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
[60] [DFN[[[URL]]]] は、 [[Web]] において[[アドレス]]や[[識別子]]として用いられている[[文字列]]です。
* 仕様書
[63] [[URL]] は、 [[URL Standard]] により定義されています。
[REFS[
- [153] '''[CITE@en[URL Standard]] ([TIME[2016-05-25 22:00:23 +09:00]]) <https://url.spec.whatwg.org/>'''
-- [154] [CITE@en[URL Standard]] ([TIME[2016-05-25 22:00:23 +09:00]]) <https://url.spec.whatwg.org/#urls>
--- [156] [CITE@en[URL Standard]] ([TIME[2016-05-25 22:00:23 +09:00]]) <https://url.spec.whatwg.org/#url-syntax>
- [31] [CITE@en-GB-x-hixie[HTML Standard]] ([TIME[2015-12-03 22:48:19 +09:00]] 版) <https://html.spec.whatwg.org/#valid-url>
]REFS]
* URL の構成要素
[155] [[文字列]]表現を [DFN[[RUBYB[URL文字列]@en[URL string]]]] [SRC[>>156]]、
[[データ構造]]を [DFN[[RUBY[URL記録][URLレコード][URL record]]]] [SRC[>>154]]といい、
曖昧でなければどちらも共に [DFN[URL]] と呼びます。
;; [157] [[仕様書]]の定義上、 [[URL文字列]]は、 [[URL]] としての構文に[[適合]]する[[文字列]]をいいます。
その他に、 [[URL構文解析器]]を通すと [[URL記録]]が得られるが [[URL文字列]]ではない[[文字列]]や、
[[URL構文解析器]]が[[失敗]]する[[文字列]]もあります。
;; [158] すべての [[URL記録]]は、 [[URL直列化器]]により [[URL文字列]]に変換できます。
すべての [[URL文字列]は、適切な[[基底URL]]を選べば[[URL記録]]に変換できます。
([[基底URL]]によっては[[失敗]]となることがあります。)
[70] [[URL]] はいろいろな要素によって構成されています。
[FIG(list members)[
- [F[scheme][URL scheme]] - [[ASCII文字列]]。初期状態は[[空文字列]]。
- [[authority]]
-- [[userinfo]]
--- [F[利用者名][userinfo]] - [[ASCII文字列]]。初期状態は[[空文字列]]。
--- [F[合言葉][userinfo]] - [[ASCII文字列]]。初期状態は[[空文字列]]。
-- [CODE[location.host]]
--- [F[ホスト]] - [[ホスト]]または [[null]]。初期状態は [[null]]。
--- [F[port]] - [[16ビット符号無し整数]]または [[null]]。初期状態は [[null]]。
- [F[パス][URL path]] - 0個[[以上]]の[[ASCII文字列]]の[[リスト]]。初期状態は空。
-- [[param]]
- [F[query][URL query]] - [[ASCII文字列]]または [[null]]。初期状態は [[null]]。
- [F[素片][素片識別子]] - [[文字列]]または [[null]]。初期状態は [[null]]。
]FIG]
[26] [[URL記録]]は、次の状態を持ちます。
[FIG(list members)[
: [F[オブジェクト][blob]] :[CODE(URI)@en[[[blob:]]]] [[URL]] が関連付けられた
[CODE(DOMi)@en[[[Blob]]]] (あれば) です。初期状態は [[null]]。
: [F[cannot-be-a-base-URL flag]] : [[boolean]]。初期状態は[[偽]]。
: [F[cannot have a username/password/port]] :
: [F[起源][URLの起源]] :
: [F[credentialsを含む]] :
]FIG]
;; [159] [[URL記録]]は[F[オブジェクト]]を持つことができますが、
[[URL文字列]]はこれに相当するものを持ちません。
[F[オブジェクト]]は [[URL構文解析器]]によってその時点の [[blob URL store]]
の状態に基づき設定されます。
** URL scheme
[137] [[URI]] の構造は、大きく [CODE(ABNF)[[[scheme]]]]
(識別方式), [CODE(ABNF)[[[authority]]]] (命名権者),
[CODE(ABNF)[[[path]]]] (経路), [CODE(ABNF)[[[query]]]] (照会),
[CODE(ABNF)[[[fragment]]]] (素片識別子) の5つに分けられます。
このうち、 [CODE(ABNF)[scheme][URL scheme]] は
[CODE(ABNF)[[[authority]]]],
[CODE(ABNF)[path][URL path]], [CODE(ABNF)[query][URL query]]
の詳細な構文と意味を決定します。
URI では様々な scheme が定義・利用されています。
それぞれの [[URI scheme]] はその構文と、
誰が識別子を作ることができるのか、
その識別子がどんな意味を持つのか、
色々な[[プロトコル]]や[[書式]]でどんな風に使うことができるのかなどを規定しています。
[138] このように [[URI scheme]] はそれぞれ独立した識別子の空間を作っています。
この独立性により、新しい[[資源]]の識別方法を URI
に取り込むことが可能になっています。
;; [139] 詳しくは [[URI scheme]] の項をご覧下さい。
** 素片識別子
[140] URI の5大部品の一つが[[素片識別子]]
([CODE(ABNF)[[[fragment]]]]) です。素片識別子以外の URI
が識別した[[資源]]の一部分・一表現を、
素片識別子は更に細かく識別します。
素片識別子は URI の一部ではないなどと呼ばれていた時代もありましたが、
現在では URI の一部分と考えられています。
;; [141] 詳しくは[[素片識別子]]の項をご覧下さい。
* URL の分類
[61] [[URL]] には、単独で解釈できる[[絶対URL]]と、他の[[絶対URL]]を文脈として解釈される[[相対URL]]があります。
細かな構文要素が認められるか否かにより、更に細かく次のような分類が存在しています。
[FIG(short list)[
- [[絶対URL]]
- [[相対URL]]
- [[部分URL]]
- [[単純参照]]
- [[ASCII URL]]
- [[ASCII絶対URL]]
- [[ハッシュURL]]
- [[妥当なURL]]
- [[妥当な非空URL]]
- [[妥当な間隔に囲まれているかもしれないURL]]
- [[妥当な間隔に囲まれているかもしれない非空URL]]
- [F[is special]]
- [F[is local]]
- [F[includes credentials]]
]FIG]
[62] [[絶対URL]]には [[URL scheme]] が含まれており、その値によって [[[CODE(URI)@en[http:]] URL]]、
[[[CODE(URI)@en[mailto:]] URL]]、[[[CODE(URI)@en[ftp:]] URL]] などに分類されます。
;; [[URL scheme]] も参照。
[32] [DFN[[RUBYB[妥当なURL]@en[valid URL]]]]とは、
[[URL]] のうち、 [[URL Standard]] の[[著者]]への要件に[[適合]]するものをいいます [SRC[>>31]]。
** URL と URI、URN、IRI
[199] 1990年代中頃、それまでの[[アドレス]]としての [[URL]] に加えて、
[[名前]]である [[URN]] が提案され、両者の総称が [DFN[URI]] とされました。
[[URN]] は [F[scheme][URL scheme]] が [CODE(URI)@en[urn][urn:]] の [[URI]] で、
[[URL]] はそれ以外の [[URI]] と決められました。
[200] 2000年前後の頃、 [[URI]] には [[URL]] としての性質が強い場合と [[URN]]
としての性質が強い場合があり、一概にどちらであるとは言えないと考えられるようになりました。
例えば [CODE(URI)@en[http:]] [[URI]] は [[HTTP]] で[[アドレス]] ([[URL]]) としても使えるし、
[[XML名前空間]]で[[名前]] ([[URN]]) としても使えると解釈されました。
このため技術用語の [[URL]] は徐々に [[URI]] へと置き換えられていきました。
[202] 2000年代前半、 [[ASCII文字]]の [[URI]] に対して、 [[Unicode]] に拡張された [[IRI]]
が開発されました。 [[IRI]] は [[URI]] を拡張した事実上の新バージョンでしたが、
形式的には別の名前で別の[[仕様書]]で定義される別の技術とされました。
それまでの [[URI]] は [[IRI]] に置き換えられていきましたが、
[[URI]] を使い続けるものや、
[[URI]] という呼称で実態が [[IRI]] のものもありました。
[203] 2000年代半ば頃、 [[HTML5]] は一部の専門家コミュニティー内でしか通用しない
[[URI]] や [[IRI]] といった語を排除し、一般の開発者や市民に浸透した [[URL]]
という呼称を復活させました。 2010年代に入ると、呼称だけでなく技術的にも実態に合っていない
[[URI]] や [[IRI]] の[[仕様書]]にかわり、 [CITE[URL Standard]] が開発されました。
[204] こうした経緯から、 [[URL]] と [[URN]] の区別の議論や
[[URI]] と [[IRI]] (やその他のバリエーション) の違いの説明は、
今となっては意味をなさないものです。
(事情が複雑で「公式」見解がころころ変わるので、1990年代から2000年代にかけて書かれた解説記事などは当時としても不正確なことが多いです。)
;; [201] 詳しくは、歴史の章を参照。
* URL に関する演算
[71] [[URL]] には色々な概念や演算が関係しています。
[FIG(short list)[
- [[URLの解決]]
- [[基底URL]]
- [[パーセント符号化]]
- [[URLの比較]]
- [[URLパターン]]
- [[URL雛形]]
- [[同文書参照]]
- [[URLの起源]]
]FIG]
** 相対 URL と URL の解決
[142] URI ([[絶対URI参照]]) は [[URI scheme]]
の名前から始まり、一つの[[資源]]を識別するべく説明を加えていきます。
例えば [SAMP(URI)[http://www.example.com/foo/bar/baz]]
は特定の [SAMP[baz]] という[[資源]]を識別するために、
[SAMP(URI)[[[http]]:]] URI scheme を使うこと、
[[命名権者]]が [SAMP(URI)[www.example.com]] であること、
その中の [SAMP(URI)[foo]] の中の [SAMP(URI)[bar]]
の中の [SAMP(URI)[baz]] が識別したい資源であることを順次説明しています。
しかし、このような説明は冗長なことがあります。
[SAMP(URI)[http://www.example.com/foo/bar/hoge]]
が自分と同じ[Q[[[階層]]]]に存在する [SAMP[baz]]
を指すためにわざわざ [SAMP(URI)[http:]] からはじめるのは面倒ですし、
不便なことも色々あります。
そこで、 URI の[DFN[[RUBYB[[[相対参照]]] [relative references]]]]という表現が規定されています。
例えば [SAMP(URI)[baz]] が相対参照です。
ただし、 [SAMP(URI)[baz]] だけでは URI (絶対 URI 参照)
ではありません。
[SAMP(URI)[http://www.example.com/foo/bar/hoge]]
という[Q[文脈]]の情報 ([DFN[[RUBYB[[[基底URI]]] [base URI]]]]
と言います。) があって始めて
[SAMP(URI)[http://www.example.com/foo/bar/baz]]
という URI (絶対 URI 参照) に[DFN[[RUBYB[[[解決]]] [resolve]]]]されます。
;; 参考: もし同じ相対参照 [SAMP(URI)[baz]] でも基底 URI が
[SAMP(URI)[http://example.net/foo]] なら、
[SAMP(URI)[http://example.net/baz]] に解決されます。
;; [143] 詳しくは[[相対参照]]の項をご覧下さい。
** URL の一部分の直列化
[160] 次の通り、 [[URL記録]]の一部を取り出して[[直列化]]する操作が必要になることがあります。
[FIG(list)[
- [161] [F[ホスト][URL host]]、[F[ポート][URL port]] (= [F[ホストとポート]])
-- [[ホストとポート]]参照
- [167] [F[パス][URL path]]、[F[クエリー][URL query]] (= [F[pathquery]])
-- [168] [[HTTP]] [[要求対象]]
- [174] [F[scheme][URL scheme]]、[F[ホスト][URL host]]、[F[ポート][URL port]]、
[F[パス][URL path]]、[F[クエリー][URL query]]
-- [166] [[HTTP]] [[要求対象]] ([[プロキシ]]利用の場合)
-- [175] [[Strip [VAR[url]] for use as a referrer]]
- [165] [F[scheme][URL scheme]]、[F[ホスト][URL host]]、[F[ポート][URL port]]、
[F[パス][URL path]]
-- [180] [[基底文字列URL]]
- [176] [F[scheme][URL scheme]]、[F[ホスト][URL host]]、[F[ポート][URL port]]
-- [177] [[Strip [VAR[url]] for use as a referrer]]
- [169] [[URL分解属性]]
]FIG]
** URL の一部分の書き換え
[170] 次の通り、 [[URL記録]]の一部を書き換える操作が必要になることがあります。
[FIG(list)[
- [171] [F[クエリー][URL query]]に関する操作
- [172] [[ハイパーリンクをたどる]]操作における[[ハイパーリンク接尾辞]]
- [173] [[URL分解属性]]
- [183] [[URL scheme]] の書き換え
-- [184] [CODE(URI)@en[https:]] → [CODE(URI)@en[http:]], [CODE(URI)@en[http:]] → [CODE(URI)@en[ws:]]
--- [CODE(JS)@en[new WebSocket]]
]FIG]
** URL の一部分の取り出し
[181] [[URL記録]]の一部から情報を取り出す、次のような操作が使われることがあります。
[FIG(list)[
- [[path segment]] の[[リスト]]
-- [[Webアプリケーション]]の[[ルーティング]]
- [[URL query]] の [CODE(MIME)@en[application/x-www-form-urlencoded]] としての[[復号]]
-- [[直列化]]された[[フォームデータ集合]]へのアクセス
]FIG]
** URL の組み立て
[182] [[URL]] を組み立てるための次のような操作が使われることがあります。
[FIG(list)[
- [[URL scheme]]、[[authority]] と、追加の [[path segment]] のリスト → [[URL]]
- [[URL]] の接頭辞 ([[URL scheme]]、[[authority]]、[[パス]]) と、
追加の [[path segment]] のリスト → [[URL]]
- [[ハイパーリンク接尾辞]]の追加
-- [[サーバー側画像写像]]
]FIG]
* 文脈
[12] [[URL]] はありとあらゆる文脈で使われています。
** URL に含められる文字を区切り文字として使う文脈
[13] [[HTTPヘッダー]]である [CODE(HTTP)@en[[[OPES-System:]]]] や
[CODE(HTTP)@en[[[OPES-Via:]]]] では、区切り文字として [CODE(HTTP)[[[,]]]]
や [CODE(HTTP)[[[;]]]] を使っています。 [CODE(HTTP)@en[[[OPES-Bypass:]]]]
では区切り文字として [CODE(HTTP)[[[,]]]] を使っています。
いずれも構文解析方法は決められていません。
[14] [[HTML]] の [CODE(HTMLa)@en[[[srcset]]]] [[属性]]では [CODE(HTTP)[[[,]]]]
が[[区切り文字]]として使われています。構文解析方法も明確に規定されています。
* API
[24] [[DOM]] には次の [[API]] があります。
[FIG(short list)[
- [CODE(JS)@en[[[window.URL]]]]
- [CODE(DOMi)@en[[[URLUtils]]]]
- [CODE(DOMi)@en[[[Location]]]]
- [CODE(DOMi)@en[[[document.URL]]]]
]FIG]
[25] [[URL]] で指定された[[資源]]を取得する [[API]] は、 [[fetch]] を参照。
* 応用
[18] [[URL]] は様々な場面で使われています。
[FIG(short list)[
- [[HTTPにおけるURL]]
- [[HTMLにおけるURL]]
- [CODE[[[uniformResourceIdentifier]]]]
- [[fetch]]
- [[navigate]]
- [[モジュール指定子]]
- [[データベースのURL]]
- [[VCSのURL]]
- [[附属文書系URL]]
]FIG]
** RSS における URL の利用
[5] [[RSS 2.0]] は [CODE(XMLe)@en[[[url]]]] [[要素]]、
[CODE(XMLe)@en[[[link]]]] [[要素]]、[CODE(XMLa)@en[[[url]]]] [[属性]]、
[CODE(XMLe)@en[[[docs]]]] [[要素]]、[CDE(XMLe)@en[[[comments]]]] [[要素]]、
[CODE(XMLe)@en[[[guid]]]] [[要素]]で [[URL]]
を値として使っています。ただし、「[[URL]]」の定義は明記されておらず、
どの仕様も引用されていません。
;; [[RSS Best Practices Profile]] は [[IRI]] を禁じるにあたって [[RFC 3987]]
を引用しているので、それを類推すれば [[RFC 3986]] に従うのかもしれませんが、
[[RFC 3986]] なら [[URL]] ではなく [[URI]] のはずです。
[6] このうち、なぜか [CODE(XMLe)@en[[[url]]]] ''[[要素]]''と
[CODE(XMLe)@en[[[link]]]] [[要素]]については [[URL scheme]] に関する制限があります。
仕様書:
-[CITE@en[RSS 2.0 Specification (version 2.0.10)]] ([TIME[2008-11-21 18:10:17 +09:00]] 版) <http://www.rssboard.org/rss-specification#comments>
-[CITE@en[RSS Best Practices Profile]] ([TIME[2008-11-21 15:11:45 +09:00]] 版) <http://www.rssboard.org/rss-profile#data-types-url>
*** 妥当性
[10] [CODE(XMLe)@en[[[url]]]] ''[[要素]]''と
[CODE(XMLe)@en[[[link]]]] [[要素]]の[[内容]]は妥当な [[URL]]
でなければ[['''なりません''']] [SRC@en[[[RSS Best Practices Profile]]]]。
;; [[IRI]] は使えません [SRC@en[[[RSS Best Practices Profile]]]]。
[7] [[RSS 2.0]] 仕様書や [[RSS Best Practices Profile]]
は、「最初の非[[空白]][[文字]]には制限があります」といっています。
つまり、明記されていませんが、 [[URL]] の前に[[空白]]を挿入してもかまわないようです。
[8] [CODE(XMLe)@en[[[url]]]] ''[[要素]]''と
[CODE(XMLe)@en[[[link]]]] [[要素]]の [[URL]] の
[[URL scheme]] は、 [[IANA]] 登録簿に登録されているものでなければ[['''なりません''']]
[SRC@en[[[RSS 2.0]], [[RSS Best Practices Profile]]]]。
[9] [CODE(XMLe)@en[[[url]]]] ''[[要素]]''と
[CODE(XMLe)@en[[[link]]]] [[要素]]の [[URL]]
は[[相対URL]] であっては[['''なりません''']] [SRC@en[[[RSS Best Practices Profile]]]]。
** 識別子としての利用
[16] 次の場面では [[URL]] が[[アドレス]]としてではなく、[[識別子]]として使われています。
[FIG(short list)[
- [[DSig]]
- [[名前空間名]]
- [[拡張宣言]]
- [CODE(XPointerScheme)@en[[[xmlns()]]]]
- [CODE(HTTP)@en[DAV:]] [[ヘッダー][HTTPヘッダー]]
- [CODE(HTMLa)@en[itemtype]] [[属性][内容属性]]
- [[RDF]] [[資源]]
- [[WebDAV特性]]
- [[状態トークン]]
- [[リンク関係型]]
- [[HTMLメタ情報プロファイル]]
- [[[CODE[profile]] (MIME)]]
- [CODE[rel=type]]
- [[XML署名]]
- [[XML暗号化]]
- [CODE(HTTP)@en[SOAPAction:]] [[ヘッダー][HTTPヘッダー]]
- [[アクセストークン型]]
- [[承諾型]]
- [[BEEPプロファイル]]
- [[SPDX Document URI]]
- [[OAuth scope]] ([[サーバー][OAuthサーバー]]によっては。)
]FIG]
[17] 次の場面では [[URL]] が[[アドレス]]としての側面と識別子としての側面の両方を持っています。
[FIG(short list)[
- [[OpenID]]
- [CODE[guid]]
]FIG]
[216] 元来[[プロトコル]]と結びつかない [[URL]] (例えば [CODE[urn:]] [[URL scheme]]
の [[URN]]) がこうした場面で使われることもありますが、
そうでない [[URL]] (例えば [CODE[http:]] [[URL]])
もよく使われています。
後者が用いられる場合は、
[[URL]] の本来の意味 (例えば [CODE[http:]] の場合 [[HTTP]] でアクセスできる[[資源]]という意味)
が失われている場合が多いです。
[EG[
[215] [[RDF]] では [CODE[http:]] [[URL]] であっても任意のもの、
例えば現実の[[人]]なども表せるということになっています。
]EG]
[20] [[Semantic Web]] 界では [CODE(URI)@en[[[http:]]]] [[URL]] を[[識別子]]として使っているため、
[[HTTP]] から [[HTTPS]] への移行が難しいという人もいます [SRC[>>19]]。
[[マイクロデータ]]界では実際に [[HTTPS]] 化時に[[識別子]]である [[URL]]
を [CODE(URI)@en[[[https:]]]] [[URL]] に書き換えようとした例 [SRC[>>21]]
もあり、 [[URL]] を[[識別子]]として用いることの問題が浮き彫りになっています。
-*-*-
[214] これらの場面のほとんどでは、[[URLの単純文字列比較]]が用いられています。
[FIG(quote)[
[FIGCAPTION[
[27] [CITE@en[Webmention]]
([TIME[2017-01-11 04:06:01 +09:00]])
<https://webmention.net/draft/#h-uris-for-form-encoded-properties>
]FIGCAPTION]
> If your implementation wants to treat the source and target parameters as URIs, you can prefix the terms with http://www.w3.org/ns/webmention#.
]FIG]
[28] >>27 の [CODE[source]] と [CODE[target]] は [CODE[application/x-www-form-urlencoded]]
のキーなんだけど、この[[URL]]は何の役に立つんですかね・・・?
[REFS[
- [11] [CITE@EN[The Self-Describing Web]] ([TIME[2009-01-16 04:14:18 +09:00]] 版) <http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html>
- [19] [CITE@en[Re: '''['''MIX''']''' Require HTTPS scripts to be able to anything HTTP scripts can do.]] ([[Tim Berners-Lee]] 著, [TIME[2015-02-26 01:03:52 +09:00]] 版) <https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0414.html>
- [21] [CITE@en[Bug 27388 – Use https://schema.org/ in examples if feasible]] ([TIME[2015-02-26 11:44:03 +09:00]] 版) <https://www.w3.org/Bugs/Public/show_bug.cgi?id=27388>
]REFS]
** URL とプログラミング言語
[118] [[プログラム言語]][[E]]では[[URI]]が言語の構文に組み込まれている。
[CITE[URI Expressions]]
<http://www.erights.org/elang/io/uri-exprs.html>
[119] 他に[[URI]]を積極的に[[言語]]そのものに取り入れた[[プログラム言語]]といえば[[WMLScript]]がある。
* URL 設計
[191] [[URL]] は、 [[URL scheme]] によって残りの部分の構文と意味が決まります。
残りの部分を誰がどのように決めるかも、 [[URL scheme]] に依存します。
ただし、[[相対URL]]を使う [[URL scheme]] は、ある程度の共通制約があります。
;; 具体的には[[相対URL]]、[[絶対URL]]、各 [[URL scheme]] の項を参照。
[193] [[x-callback-url]] のような複数の [[URL scheme]] の共通仕様もあります。
[192] [[URL]] の[F[素片識別子]]は、原則として [[URL scheme]] や [[URL]]
のその他の部分と独立しており、 [[URL]]
を使った取得操作の結果得られるデータの形式に依存して構文と意味が決まります。
(一部の [[URL scheme]] では、 [[URL scheme]] が[[素片識別子]]にも干渉しています。)
;; [[素片識別子]]参照。
[102] [[URL]] 一般の設計論については、[[URLの決め方]]を参照。
-*-*-
[164] 特定目的で [[URL]] に別名を与えようとする試みとして、
[[URN]]、
[[PURL]]、
[[短縮URL]]
といったものがありました。いずれも一時的に一定の賛同を得たものの、
それぞれの課題があって成功とはいえない状況です。
* URL の表示
[185] [[URLのレンダリング]]、[[アドレスバー]]を参照。
* URL の利用者親和性
[FIG(quote)[ [162] [TIME[2005-11-10 08:39:02 +00:00]]
>
[TALK[ [[Martin]] <mid:6.0.0.20.2.20051107184759.06dd4750@localhost>
URI は元々人間が見るものじゃなかったんすよ。
]TALK]
[TALK[ [[RoyF]] <mid:2f1b97034b715561e35a2b370ec13d19@gbiv.com>
んな阿呆な。
]TALK]
[TALK[ [[Martin]] <mid:6.0.0.20.2.20051108185959.06a21ec0@localhost>
いやね、 [[TimBL]] の旦那がそう言っとりましたよ。
1990年とかそこらの話だと思いやすけど。
]TALK]
]FIG]
[163] 確かにそんなこと Tim が言ってたのを [[www-talk]] かどこかで見た記憶がある。
* 自由文内の URL の抽出
[29] [[URLの自動リンク]]参照。
* セキュリティー
[209] [[URL]] が表示されることが[[セキュリティー]]上重要とされる場合があります。
;; [[アドレスバー]]参照。
[210] ある程度の専門的知識を有する人は、 [[URL]]
からその内容を推測し安全かどうかの判断基準として使うことがあります。
確実ではありませんが、ないよりは有用程度のヒントにはなります。
[EG[
[211] 例えば[[ハイパーリンク]]の[[リンク先]]の [[URL]]
の[[ドメイン]]が既知の[[Webサイト]]かどうかで、その[[リンク]]が安全かどうかを推測したりできます。
そのような判断をする人にとっては、[[Webブラウザー]]に[[リンク先]]の [[URL]]
の表示機能が備わっていることは重要です。
]EG]
** URL 内の秘密情報
[146] [[URL]] には、漏洩するべきでない情報が含まれることがあります。
そのような[[URLの決め方]]は好ましくありませんが、
現に存在しますし、避けられないこともあります。
[EG[
[147] [[クッキー]]に対応していない古い[[Webブラウザー]]のために、
[[セッションID]]を [[URL]] に付けていた時代もありました。
そのような [[URL]] の漏洩は深刻な[[セキュリティー]]問題でした。
]EG]
[EG[
[149] [[ブログ]]の記事の題名から自動的に [[URL]] が決められる場合、
その[[ブログ]]が非公開で閲覧に[[認証]]が必要であっても、
[[URL]] が漏れると題名が流出してしまうことになりますから、
取り扱いに注意が必要です。
]EG]
[EG[
[150] 特定の[[利用者]]にのみ発行される [[URL]] があり、
その[[文書]]に他の [[Webサイト]]への[[リンク]]が含まれる場合で、
[[URL]] が[[リファラー]]としてその [[Webサイト]]に送信されてしまう場合、
誰がアクセスしてきたかを他の [[Webサイト]]の側が特定できてしまうかもしれません。
場合によっては[[プライバシー]]保護の観点から問題となるかもしれません。
]EG]
[112] [[認証鍵付きURL]]や [[capability URL]] などと称して、
[[bearer]] を [[URL]] に付加することがよくあります。
簡易的な[[認証]]機能としたり、[[利用者]]の確認のために[[電子メール]]で [[URL]]
を送信する際に用いたりします。
[EG[
[148] [[無作為]]に決められた十分長い秘密の [[URL]] によって[[認証]]を行ったり、
特定[[利用者]]向けの情報を公開したりすることがあります。
]EG]
[151] [[URL]] の [[userinfo]] 部分は、元々[[利用者名]]と[[合言葉]]を記述する欄として用意されました。
現在では好ましくないと考えられています。しかし利便性が高いため、
しばしば用いられます。
[EG[
[113] [[プロキシを指定する環境変数]]では、[[プロキシ]]の [[URL]]
を指定しますが、 [[userinfo]] に[[プロキシ認証]]のための情報を含めることがあります。
]EG]
[EG[
[114] [[Webアプリケーション]]から [[Webアプリケーション]]への [[Web Hooks]]
の設定画面では、 [[URL]] を指定する欄が1つだけ用意されていて、
そこに記述する [CODE(URI)@en[https:]] [[URL]] の [[userinfo]]
に[[基本認証]]の[[利用者名]]と[[合言葉]]も含められることがあります。
]EG]
** 構成する文字に関わる問題
[117] '''似た形の文字''':
[[Unicode]] には[[図形記号]]が似た[[文字]](列)が極めて多く含まれています。
紛らわしくて困るというだけなら [WEAK[(それだけでも大問題ですが)]]
まだしも、[[なりすまし]]などの安全上の問題にもなります。
[186] かつての [[RFC 3987]] の仕様ではできるだけ [[NFC]] や [[NFKC]]
を使うことを勧めていましたが、従来の[[文字符号化方式]]との関係
[WEAK[(RFC 3987 は従来の文字符号化方式で IRI が記述されていたら [[NFC]] に変換することを求めていますが、 RFC 3987 の対象外の世界で従来の文字符号化方式から [[UTF-8]] などに変換済みなら NFC でないかもしれません。 IRI を[Q[作る]]側も、[[ファイル名]]など NFC でない因子を持っているかもしれません。)]]
や悪意のある者が必ずしもそれに従うとは限りません。
[187] '''見えない文字''':
[[Unicode]] には[[図形記号]]を持たない[[文字]]が多く含まれています。
例えば [CODE(char)[[[U+3000]]]]
([CODE(charname)[[[IDEOGRAPHIC SPACE]]]]) も IRI
で使えます。 IRI のような文字列があった時にどこで終わるのかわからないので不便ですし、
[CODE(char)[[[IDSP]]]] と [CODE(char)[[[EMSP]]]] と
[CODE(char)[[[ENSP]]]] が2つ並んでいるものは区別できなかったりします
(>>117 の問題)。
[188] 単に見えないだけではなく、何らかの意味を持った[[文字]]もあります。
[CODE(charname)[[[PARAGRAPH SEPARATOR]]]] は段落境界を意味します。
IRI の途中で改段落などされると甚だ迷惑ではあるのですが、
仕様上は認められているようです。
悪意のある人は悪いことに使うかもしれません。
[189] '''双方向性''':
かつての [[RFC 3987]] には [[bidi]] に関する規定がありました。
要約すると、 Unicode の bidi 算法をそのまま使うというものです。
最近の色々な規格 [WEAK[(例えば [[CSS]])]]
は全面的に Unicode の bidi 算法を採用しているので IRI
の部分だけ他の算法を採用するというのは非現実的ではありますが、
Unicode の bidi 算法は普通の文章を主に想定しているので、
記号を普通の文章とは違う特別な意味で使っている IRI
では予期せぬことが起こります ([[RFC 3987//6]]
にわずかながら例があります)。
[190] 1つの[[アドレス]]の途中で直感とは異なる形で表示上の場所が入れ替わるのは実用上も大きな問題ですが、
[[なりすまし]]などの[[保安]]上の問題もかかえています。
* 知的財産権
** 著作権
[103] あまり意識されることはありませんが、 URI
である文字列に対して[[著作権]]が主張される可能性があります。
単に[[資源]]の位置を表すに過ぎない [[URL]]
的な URI の類が[[著作物]]足る要件を満たすとは考えにくいですが、
ほとんどあらゆる種類のものが URI として表現し得ます。
特に、
[FIG(list)[
- [CODE(URI)[[[data]]:]] URI scheme を使った任意のデータを含む URI
- [CODE(URI)[[[javascript]]:]] URI scheme を使った任意の
[[JavaScript]] 符号を含む URI
- [CODE(HTMLa)[[[method]]]] が [CODE(HTML)[get]] な [[HTML]]
の[[フォーム]]を[[提出]]した結果得られる URI
]FIG]
... のようなものは、著作物が URI の一部として入り込む可能性が高いといえます。
任意のデータが [CODE(URI)[data:]] URI
にした途端著作権が消滅するのはおかしいですから、
著作物たる [CODE(URI)[data:]] URI が存在することは間違いありません。
また、 [[Bookmarklet]] などは創作性が高いと考えられますから、
簡単なものを除いて著作物だとの主張が認められる可能性が高いと思われます。
;; [104] もちろん、[[百分率符号化]]などの仔細な表現上の違いは著作権が存在するかどうかの議論とは無関係です。
[105] URI が著作物足り得るかどうかの議論は、
[[ハイパーテキストにおけるリンクの自由性]]にも関わってきます。
[106] URI に著作権は及ばないという主張の例:
[FIG(list)[
- [108] [CITE[壇弁護士の事務室: ちょっと、変更]] <http://danblog.cocolog-nifty.com/index/2004/12/post_4.html>
- [109] [CITE[@はんのう]] <http://www.hanno.jp/html/menseki.html>
- [127] [CITE[yoosee.net : copyright & disclaimer]] <http://yoosee.net/info/copyright_disclaimer.html>
- [128] [CITE[リンクと著作権のメモ]] <http://www1.neweb.ne.jp/wb/uramichi/column_11.html>
- [129] [CITE[著作権および免責事項]] <http://www.ansi.co.jp/copyright_disclaimer.html>
- [130] [CITE[無題ドキュメント]] <http://www.htokai.ac.jp/DM/policy.html>
- [134] [CITE[Webページの作法]] <http://www.daito.ac.jp/~mizutani/lecture/html/web-manner.html>
- [135] [CITE[」」」 Kiss The Moon 」」」]] <http://kissmoon.org/#NOTICE>
]FIG]
[107] URI に著作権が及ぶという主張の例:
[FIG(list)[
- [132] [CITE[Copyright and So on.]]
<http://www.cise.co.jp/~florian/warning.php>
-- この文書の著者が命名権者らしい [CODE(URI)[[[http]]:]] URI
の著作権を主張しています。
]FIG]
[110] [CITE[葉っぱ日記 - ぼくはまちちゃん!(Hatena) - urlのポエム化]] ([CODE[2007-01-17 09:25:44 +09:00]] 版) <http://d.hatena.ne.jp/hasegawayosuke/20070117/p1>
([[名無しさん]] [WEAK[2007-01-17 00:28:09 +00:00]])
** 商標権
[111] [[URI]] として使用する文字列の一部が[[商標]]としてみなされることがあります。
特に URI に一部としてよく使われる[[ドメイン名]]は頻繁に商標に関する係争が発生しています。
ドメイン名に限らず、商標を根拠に商標権者が URI
の使用者に使用しないように主張する可能性があります。
* テストデータ
[120] [CITE[UriTesting - ESW Wiki]] <http://esw.w3.org/topic/UriTesting>
[2004] [CITE[UriTesting - W3C Wiki]]
( ([TIME[2011-01-28 18:05:41 +09:00]] 版))
<http://www.w3.org/wiki/UriTesting>
[121] [CITE[Index of /uri]] ([CODE[2007-01-05 15:38:16 +09:00]] 版) <http://skew.org/uri/>
([[名無しさん]] [WEAK[2007-01-05 06:39:54 +00:00]])
* 歴史
[64] [[URL]] ははじめ [[TimBL]] によって [[World Wide Web]] を構成する技術の一つとして提案されました。
この当時の仕様書は [[W3O]] の [[Webサイト]]や [[www-talk]] [[メーリングリスト]]などで配布されていました。
[65] その後は [[IETF]] によって標準化が行われました。
[66] [[URL]] 本体仕様として、次のものが発行されています。
[FIG(list)[
- [[RFC 1630]]
- [[RFC 1738]]
- [[RFC 1808]] ([[相対URL]])
- [[RFC 2396]]
- [[RFC 2732]] ([[IPv6アドレス]])
- [[RFC 3986]]
- [[RFC 3987]] ([[IRI]])
- [[RFC 6874]] ([[ゾーン識別子]])
]FIG]
[212] しかしこれら「正式」な仕様書ではカバーしきれていない現実の問題が多く存在しており、
[[W3C]] は [[IRI]] の様々なバリエーションを規定しましたし、
[[Webブラウザー]]はそのいずれとも違うものを実装していました。
;; [67] この期間の歴史は本項の他に [[URN]]、[[IRI]] の項も参照してください。
[68] 00年代に [[WHATWG]] で改めて [[URL]] を定義する動きがあり、紆余曲折を経て2012年、
[[Anne van Kesteren]] により [[URL Standard]] が作られました。
;; [69] この期間の歴史は、 [CITE[URL Standard]] の歴史の項も参照してください。
** 呼称
[15] [[URL]] の一部または全部を指して、歴史的に様々な呼称が用いられてきました。
[FIG(short list)[
- [[URL]]
- [[URI]]
- [[IRI]]
- [[Web addresses]]
- [[HRef]]
- [[LEIRI]]
- [[XMLRI]]
- [[HRRI]]
- [[URN]]
- [[UDI]]
- [[URI参照]]
- [[IRI参照]]
- [[RDF URI参照]]
- [[DOM URI]]
- [[完全URI]]
- [[絶対URI]]
- [[絶対IRI]]
- [[絶対URI参照]]
- [CODE(ABNF)@en[[[generic-RL]]]]
- [[部分URI]]
- [[相対参照]]
- [[相対IRI参照]]
]FIG]
[88] [[IETF]] は [[RFC]] を改版する度に用語やその定義を少しずつ変えていました。
更に、実際に普及した用語や [[DOM]] 等の [[API]] で使われている用語とも一致していませんでした。
そのため、色々な[[仕様書]]や実装で似たような異なるような概念が交錯し、
大混乱していました。
[89] 加えて [[W3C]] は、 [[XML]] 関連仕様を新たに出版する度に、
新しい「URI のようなもの」を定義していました。その定義も少しずつ異なるものでした。
;; 詳細は [[IRI]] も参照。
[42] URI 関係の古い定義:
- [[逃避]], [[escape]], [[URI符号化]] → [[百分率符号化]]
- [[素片識別子]]は [[URI]] の一部ではない →
[[素片識別子]]も [[URI]] の一部分
- [CODE(ABNF)[[[scheme]]]] の後が [CODE(URI)[//]]
の URI でしか[[相対URI]] は使えない
→ どんな URI でも[[相対参照]]は使える
[82] [CITE[fragment identifiers from Roy T. Fielding on 2002-07-23 (www-tag@w3.org from July 2002)]] <http://lists.w3.org/Archives/Public/www-tag/2002Jul/0253.html>
[83] URI の標準化はかなりいい加減で混乱気味の上に W3C/Martin Durest は [[IRI]] を進めていて、それも [[SP]] を認めるとか [CODE[#]] もどうとか無茶苦茶なこと言ってたし、混乱は当分収まりそうにない。
[84] RFC 2396 は、絶対 URI だけを URI としており、相対 URI や素片識別子がついた URI も含めた名称を URI 参照としています。 (旧版の RFC 1808 も含めて) 旧来の仕様や慣習では絶対 URI と相対 URI の両方を URI と言っていましたし、素片識別子も仕様書には URI の一部ではないと書いてあるけど実際には曖昧に使われていた [WEAK[(古い URI 仕様書まで遡るとこちらも曖昧だった)]] という歴史的経緯がありまして、単に URI とだけ言われると厳密には何を指しているのだかわかったものではありません。[WEAK[たまに論争の火種になります(w]]
[85] XML 関連仕様書は URI という名前で IRI を指していたり、「URI と解釈されるもの」というわけのわからんのがでてきたりしますから混迷極まり ([CODE(WikiPage)[[[XML//URI]]]] 参照)。
[86] あと目立たないけど注意しておきたいのは、空文字列。 RFC 2396 的には URI 参照の一種ですが URI じゃないですし、相対 URI でもないかもしれません。 RFC 1808 から意味が変更されたものですから解釈は実装依存になってしまう。その上使えるかどうかは採用する規格に依存。 (URI 参照を使うと書かれている規格でも、よく見ると字数制限1文字以上で使えなかったりする。)
[87] 2396bis ではまた変わるみたいです。。。
** 拡張
[205] 歴史的にいくつも [[URL]] の拡張が提案されていますが、広く採用されたものはありません。
[FIG(short list)[ [206] [[URL]] の拡張の提案
- [[XURL]]
- [[XRI]]
- [[IRI]]
- [[LEIRI]]
]FIG]
** URI
[36] [[URI]] ([DFN[Uniform Resource Identifiers]],
[DFN[統一資源識別子]]) は、[[資源]]を[[識別]]するための統一的な仕組みとして提案されていました。
簡単に言えば、色々な[Q[もの]]に名前を付けるための仕組みでした。
あるいは、その仕組みによる識別子をも URI と呼んでいました。
また、文脈で意味が曖昧でない場合には、識別子によって参照される資源のことすらも
URI と呼ぶことがありました。
[37] 従来の情報システム・計算機システムは、
それぞれで資源を識別する仕組みや[[番地付け]]の仕組みを持っていました。
しかし、それらはあくまでそれぞれのシステムの範囲内でのみ有効な識別子システムでした。
ところが、1990年頃 [[TimBL]] が発明した [[WWW]]
では、番地付けのために URI を採用しました。
URI は [[URI scheme]] によって命名システムを識別し、
URI scheme ごとにその中で更に具体的な資源を識別するという構造を持っています。
そのため、従来の情報システムの識別子を URI scheme
として再定義することによってあらゆる資源を[Q[統一]]的に扱うことに成功したのです。
参考: そのような設計が採用された背景には、
当時様々な情報システムが提案されて割拠していたことがあります。
WWW は [[HTTP]] だけではなく、それら他のシステムも
URI によって[Q[取り込む]]ことで魅力的な情報システムになったのです。
[38] URI で識別される[Q[資源]]は、何も計算機で表現できるものに限りません。
[CODE(URI)[[[urn:isbn:]]]] [[URI]] を使えば [[ISBN]]
によって[[書籍]]を識別することができます。
物理的に存在するもの以外でも、
言葉や抽象概念などありとあらゆる[Q[資源]]を識別することが可能です。
[39] URI が元々 [[HTTP]] と [[HTML]] で[[番地付け]]のために使われてきたことから、
単にネットワーク資源の位置を表す[[住所]]のようなものと考えられることがよくあります。
しかし、 >>38 のように URI はネットワークで[Q[[[取出す]]]]ことができないものであっても[Q[識別]]できます。
[[Webブラウザ]]で画面に表示することはできないかもしれませんが、
それだけが URI の役割ではないのです。
*** URI の定義
[2000] 「[[URI]]」という言葉の定義は、[[URI]] を定義する仕様自体でも歴史的に変化していますし、
[[URI]] を参照する様々な仕様でも様々な意味に用いられています。
仕様内でもそうなのですから、それ以外の世界ではその意味は全く安定していないといっても過言ではありません。
[2001] 最も大きな定義上の混乱の1つは、 [[URI]] と [[URI参照]]の違いです。
最新の [[URI]] の定義である [[RFC 3986]] によると、[[相対参照]]は [[URI参照]]ですが、
[[URI]] ではありません。その前の [[RFC 2396]] の定義によると、[[素片識別子]]を含んだものは
[[URI参照]]ですが、[[URI]] ではありませんでした。
仕様書以外の場面 (や多くの関連仕様!) では、「[[URI]]」というと [[URI参照]]を指すことが多くあります。
これらについては [[URI参照]]や[[素片識別子]]の項をごらんください。
[2002] もう1つの最大の混乱は、利用可能な[[文字]]の種類に関するものです。
[[URI]] で本来認められない [[ASCII文字]]や、[[IRI]] では認められる[[非ASCII文字]]の扱いをめぐって、
多くの仕様がいろいろなものを「[[URI]]」と呼んでいます。
詳しくは [[IRI]] の項をご覧ください。
[2003] 前述の2つに比べれば細かい話ですが、 [[URI]] の構文や[[相対参照]]の[[解決]]の方法は新しい仕様書が発行される度に変化しています。
特に最新の [[RFC 3986]] とその1つ前の [[RFC 2732]] あるいは [[RFC 2396]] との関係は、
どちらがどちらの[[部分集合]]でも[[超集合]]でもありません。
[[URI]] を用いる色々な仕様がそれぞれ異なる版の [[URI]] を参照しており、
通常そのような仕様が多数組み合わせて用いられるので、
厳密に解釈すると [[URI]] の扱いは非常にややこしいことになります。
*** IETF における URI の標準化
- [78] ''IETF - Uniform Resource Identifiers (URI) Working Group'' (終了) <http://ftp.ics.uci.edu/pub/ietf/uri/>
- [79] ''IETF - Uniform Resource Identifiers (URI) Working Group'' <http://www.apache.org/~fielding/uri/>
- [80] ''Web Naming and Addressing Overview (URIs, URLs, ...)'' <http://www.w3.org/Addressing/>
[81] [CITE[URI.NET]] <http://uri.net/>
ちょっと古いしちゃんと管理されていないみたい。
([[名無しさん]] [WEAK[2005-03-11 03:40:22 +00:00]])
** 既存の識別子との関係
[125] [[URI]] は [[URI]] を意識せずに作られた[[識別子]]体系でもそのまま取り込んでしまうことができます
[WEAK[(もちろん相性のようなものはありますが)]]。
既に色々な[[識別子]]を [[URI]] として使う方法が定義されています。
[126] 色々な[[識別子]]の体系を [[URI]] 1つにまとめると、
何かしたいときに各[[識別子]]体系それぞれに対してその方法を考える必要がなくなります。
例えば引用文献を記述する時に、引用する文献が [[Web頁]]
([[URI]]) でも紙の書籍 ([[ISBN]]) でも両方 [[URI]]
として扱えると便利になることがあります。
あるいは連絡先が[[インターネット]]の[[電子メイル]]
([[電子メイル・アドレス]]) でも従来の[[電話]] ([[電話番号]])
でも統一して扱えたりもします。
[131] 既存の識別子と URI の対応
,既存の識別子体系 ,URI ,備考
,出版物 ,== ,==
,[[ISBN]] ,[CODE(URI)@en[[[urn:isbn]]:]]
,[[ISSN]] ,[CODE(URI)@en[[[urn:issn]]:]]
,[[公開識別子]] ,[CODE(URI)@en[[[urn:publicid]]:]]
,[[RFC]] ,[CODE(URI)@en[[[urn:ietf:rfc]]:]]
,ネットワーク番地 ,== ,==
,[[電話番号]] ,[CODE(URI)@en[[[tel]]:]]
,[[FTP]] ,[CODE(URI)@en[[[ftp]]:]]
,[[インターネット]]の[[電子メイル]] ,[CODE(URI)@en[[[mailto]]:]]
,[[ニュース組]] ,[CODE(URI)@en[[[news]]:]]
,[[チャット]]の[[チャンネル]] ,[CODE(URI)@en[[[irc]]:]]
,言語・文化 ,== ,==
,[[言語札]] ,[CODE(URI)@en[[[urn:x-suika-fam-cx:lang]]:]]
,その他 ,== ,==
,[[UUID]] ,[CODE(URI)@en[[[urn:uuid]]:]]
** RFC 1630 (第1世代)
[46]
- [[RFC1630]]
『Universal Resource Identifiers in WWW: A Unifying Syntax
for the Expression of Names and Addresses of Objects
on the Network as used in the World-Wide Web
(WWW における普遍資源識別子 :
World Wide Web で使われているネットワーク上の物体の
名前と番地の表現の統一構文)』,
-- T. Berners-Lee, 1994 年6月, Informational RFC。
-- この文書は、 WWW でインターネット上の物体の名前と番地を符号化するのに使われている構文を定義します。
Web は、既存のプロトコル, web 自体のために新しく開発されたプロトコル,
将来発明されるプロトコルを含めた拡張可能な数のプロトコルを使って接続可能な物体を含むと考えられます。
特定のプロトコルによる個々の物体への接続指示は、
番地文字列の形式に符号化されます。
他のプロトコルは種々の形式の物体名の使用を認めています。
一般物体の抽象的考えのために、 web は物体の普遍的集合の概念及び物体の名前及び番地の普遍的概念を必要としているのです。
[33]
- 『A Framework for Identifying, Locating, and Describing Networked
Information Resources
(ネットワーク情報資源の識別, 位置付け, 記述の枠組み)』
-- <http://www.apache.org/~fielding/uri/rfc/lynch93.txt>
-- Clifford Lynch, 1993年3月。
-- インターネット上のネットワーク情報資源の増加につれ、
この資源の体系的で標準的な識別・位置付け・記述手段が益々必要となっています。
そのような方式の開発の動機は様々ですが、
開発を進めるに当たって少なくても3つの大きな応用があります。
1つには、図書館界では伝統的な型録記述をネットワーク資源に拡張する必要があります。
本質的には、
(in the sense that libraries are shifting from
collections to access, and increasingly view their catalogs and
other databases as bibliographies of materials to which they are
prepared to provide, and perhaps subsidize, access)
書誌記述及び統一的に図書館蔵書と協調させるためのネットワーク情報資源の管理を可能とし、
これらへの接続を向上させる必要があります。
As networked information resources
become critical to scholarship and research, and come to
represent significant investments by institutions, it also becomes
essential to apply the practices of information management to
this new class of resources.
** RFC 1738 (第2世代)
[34]
- [[RFC1736]]
-- 『Functional Recommendations for Internet Resource Locators
(インターネット資源位置子の機能的要件)』
-- J. Kunze, 1995年2月。 Informational RFC。
-- この文書は、位置と資源の接続情報を伝達するインターネット資源位置子の要件の最小集合を規定します。
資源の典型的な例には、ネットワークで接続可能な文書,
WAIS データベース, FTP サーバー, Telnet 終点を含みます。
[35]
- [[RFC1737]]
-- 『Functional Requirements for Uniform Resource Names
(統一資源名の機能的要件)』
-- K. Sollins, L. Masinter, 1994年12月。 Informational RFC。
-- この文書は、統一資源名 (URN)
として知られるある種のインターネット資源識別子の要件の最小集合を規定します。
URN は、統一資源特性 (URC), 統一資源位置子 (URL)
を加えて構成される上位のインターネット情報体系内に
fit します。
URN は識別に使用され、 URC はめた情報を含めるのに使用され、
URL は資源の位置付けや探索に用いられます。
この文書は URN の規格を評価する基礎として提供します。
議論はメイリング・リスト <MAIL:uri@bunyip.com>
及び IETF の URI 作業部会の部で行われます。
[40]
- [[RFC1738]]
-- 『Uniform Resource Locators (URL)
(統一資源位置子 URL)』
-- T. Berners-Lee, L. Masinter, M. McCahill, 1994年12月。
提案標準。
-- RFC 1808, RFC 2368, RFC 2396 が更新。
-- この文書は、位置及びインターネットを介した資源への接続の形式化された情報の構文及び意味である統一資源位置子 (URL)
を規定します。
[92] RFC 1630 (URI) と RFC 1738 は、内容的に大体同じですが、文章としては全然違います。
** RFC 1808 (第2世代の相対URL)
[41]
- [[RFC1808]]
-- 『Relative Uniform Resource Locators
(相対統一資源位置子)』
-- R. Fielding, 1995年6月。提案標準。
-- RFC 1738 を更新。
-- RFC 2368, RFC 2396 が更新。
-- 統一資源位置子 (URL) は、インターネットを介して入手可能な資源の位置及び接続方法の短小な表現です。
URL を基底分書中に埋め込む時には、
絶対形式だと基底文書の取り出しの文脈で、
方式, ネットワーク位置, url-path の一部のように非常に多くの既知の情報を含んでいます。
基底 URL が良く定義されていて解析器 (人間又は機械)
がそれを知っている時には、その文脈を実現値毎に際して慰するのではなく、継承した
URL 参照を埋め込むことが出来ると便利です。
この文書ではこのような相対統一資源位置子の構文と意味を定義します。
- [1] [CODE(ABNF)[[DFN[URL]] = ( absoluteURL | relativeURL ) [ "#" fragment ] ]]
;; [[RFC 1808]]
** RFC 2396 (第3世代)
[43]
- [[RFC2396]]
-- 『Uniform Resource Identifiers (URI): Generic Syntax
(統一資源識別子 (URI): 一般的構文)』
-- T. Berners-Lee, R. Fielding, L. Masinter, 1998年8月。原案標準。
-- RFC 1808, RFC 1738 を更新。
-- 統一資源識別子 (URI)
は、抽象資源又は物理資源を識別する短小な文字の列です。
この文書は、絶対形及び相対形の双方を含む、 URI
の一般的構文とこれらの使用の指針を定義します。
この文書は RFC 1738 及び RFC 1808
の一般的定義を改訂・置換します。
-- この文書は全ての妥当な URI
の超集合である文法を定義します。従って、実装は方式規定の可能な識別型毎の要件を知ること無しに
URI 参照の共通の部品を解析することが出来ます。
この文書は URI の生成文法は定義しません。
その作業は各 URI 方式の個々の仕様書が行うことでしょう。
[91] RFC 1738 (URL) と RFC 2396 (URI) は、ほとんど別の文章です。扱う対象はほぼ同じであるにもかかわらず、 2396 は概念的にもかなり整理されていて、 [KBD[[[diff]]]] が役に立つ立たない以前の問題です。それ程違います。
[90] RFC 1808 (相対 URI) と RFC 2396 は、多くの部分が共通しています。節単位で [KBD[diff]] を取ったら違いは [CODE[URL]]→[CODE[URI]] ばっかり、みたいな。それでも、 2396 の包括的な定義に比較すると 1738 的古臭さ(謎)を感じる部分があって、その辺は 2396 にそのまま入ってはいません。
[93] >>92、>>91、>>90 というわけで、 URI の仕様書は毎回全然違う内容で出てくるのであって、同じ WWW でも [[HTTP]] の仕様書 ([[RFC1945]], [[RFC2068]], [[RFC2616]]) が追記的に成長していっているのに比べると、中々興味深いところであります。
[94] >>93 比較的早くまとまった (それでも随分かかってるけど。) HTTP の仕様に比べて、 URI は色々ありましたからねぇ。概念的に成熟するまでが長かったし、未だに不安定な部分も多々あるし・・・。
[95] >>94 HTTP みたいな転送プロトコルは前例が一杯あるからかも。 URI のような規模の番地付けってインターネットでは初めての試みだったと思うし。