43

すべてのURLがURIであると何度も説明されてきましたが、すべてのURIがURLであるとは限りません。誰かがURIであるがURLではない何かの例をあげることができますか？

4

7 に答える 7

29

ここから盗まれた例（違いの説明もあります）：

URL     http://www.pierobon.org/iis/review1.htm
URN     www.pierobon.org/iis/review1.htm#one
URI     http://www.pierobon.org/iis/review1.htm.html#one
于 2009-04-07T02:14:59.250 に答える
11

urn：isbn：0451450523

http://en.wikipedia.org/wiki/Uniform_Resource_Name

于 2009-04-07T02:10:37.903 に答える
5

ユニフォームリソース名（URN）は、特定の名前空間内のリソースを名前で識別するURIです。URNを使用すると、リソースの場所やアクセス方法を暗示することなく、リソースについて話すことができます。たとえば、URN urn：isbn：0-395-36341-1はURIです

差出人：ウィキペディア： http： //en.wikipedia.org/wiki/Uniform_Resource_Identifier

于 2009-04-07T02:07:02.717 に答える
4

XML スキーマは多くの場合、URI で識別されます。同様にフォーマットされている可能性がありますが、URL ではないため、そこに何かがあるという保証はありません。

XML ファイルを検証する必要がある場合は、正しい XML スキーマを識別する機能が必要です。検証の成功が​​有用なものになる前に、コンテンツとスキーマ作成者の間で識別手段を共有する必要があります。URI は、他の何よりもこのニーズを満たします。XML ファイルを使用するためにスキーマが必ずしも必要ではないことに注意してください。したがって、普遍的に配置可能または利用可能である必要はなく、単に識別可能である必要があります。URI のセマンティクスは、URL の場合のように、リソースが「ここ」に配置されている必要があるという意味を回避します。これには正当な理由があります。そのような詳細は、識別のタスクとは無関係です。

スキーマの発行者は、所有する URL に基づいて URI を作成することがよくあります。これには多くの理由があると想像できますが、その 1 つは、仲介者なしで名前の競合を回避するのに役立ちます。このような規則を使用する場合、URI が URL の場合に指す場所で定義をホストすることに抵抗するのは困難です。必要なことはわかっていますが、そうすることは評価された努力であり、優れた情報アーキテクチャの一例であると私は信じていますが、この事実は URI によって満たされるニーズとは無関係のままです。

于 2009-04-07T03:28:13.957 に答える
0

一般的なケースは、フォーマットのURIであるURNurn:namespace-id:resource-idです。ウィキペディアによる：

1997年にRFC2141で定義されたURNは、永続的で場所に依存しない識別子として機能することを目的としており、名前空間を単一のURN名前空間に簡単にマッピングできます。このようなURIの存在は、識別されたリソースの可用性を意味するものではありませんが、リソースが存在しなくなったり使用できなくなったりした場合でも、そのようなURIはグローバルに一意で永続的である必要があります。

両方のスタイルのリソース参照（URLとURN）は、後でURIの概念の下で結合されましたが、それらは別個の目的を果たすものとして認識されたままです（私の強調）：

ユニフォームリソース名（URN）は人の名前と比較でき、ユニフォームリソースロケーター（URL）はその人の番地と比較できます。つまり、URNはアイテムを識別し、URLはアイテムを見つけるための方法を提供します。

于 2009-04-07T02:08:57.923 に答える