人々は _ url _ s、 _ uri _ s、および _ urn _ sについて、まるで別物のように話しますが、肉眼でも同じように見えます。
両者の違いは何ですか?
URIは、ロケーター、名前、またはその両方としてさらに分類できます。 「ユニフォームリソースロケータ」(URL)という用語は、リソースを識別することに加えて、その主要アクセスメカニズム(たとえば、そのネットワーク「ロケーション」)を記述することによってリソースを見つける手段を提供するURIのサブセットを指す。 "Uniform Resource Name"(URN)という用語は歴史的に "urn"スキーム [RFC2141] の下の両方のURIを指すために使われてきました。利用できなくなり、名前のプロパティを持つ他の任意のURIに送信されます。
つまり、すべてのURLはURIです(実際にはまったくありません - 下記参照)。すべてのURNはURIです - ただし、URNとURLは異なるため、すべてのURIがURLであるとは言えません。
編集:私は以前、すべてのURLが有効なURIであると考えていましたが、コメントによれば:
ない "すべてのURLはURIです"。それはRFCの解釈によります。例えばJavaでは、URIパーサーは
[
や]
が好きではありません、そしてそれは仕様が "してはいけない"そして "してはいけない"と言っているからです。
それで、残念なことに、それは水をさらに濁らせます。
Roger Pateの答え をまだ読んでいない場合は、そうすることをお勧めします。
URI s identityおよびURL s Locate;ただし、ロケーターは識別子でもあるため、すべてのURLもURIですが、URLではないURIもあります。
これは私の名前であり、識別子です。これはURIのようなものですが、URLにすることはできません。私の場所や連絡方法については何も伝えないからです。この場合、米国だけで少なくとも5人の他の人を識別することもあります。
これはロケーターであり、その物理的な場所の識別子です。これはURLとURIの両方に似ており(すべてのURLはURIであるため)、私も 間接的に を "resident of .."として識別します。この場合、それは私を一意に識別しますが、ルームメイトを取得すると変更されます。
これらの例は必要な構文に従っていないため、「いいね」と言います。
From Wikipedia :
コンピューティングにおいて、Uniform Resource Locator(URL)は、識別されたリソースが利用可能な場所とそれを取得するメカニズムを指定するUniform Resource Identifier(URI)のサブセットです。 一般的な使用法や多くの技術文書や口頭での議論では、URIの同義語として誤って使用されることがよくあります... [emphasis mine]
この一般的な混乱のために、多くの製品およびドキュメントでは、誤って他の用語を使用したり、独自の区別を割り当てたり、同義語として使用したりしています。
私の名前、ロジャー・パテは、 URN (Uniform Resource Name)のようなものです。ただし、それらは はるかに規制されている であり、全体で一意であることを意図していますbothスペースと時間。
現在、この名前を他の人と共有しているため、グローバルに一意ではなく、URNとしては適切ではありません。ただし、他の家族がこの名前を使用していなかったとしても、父方の祖父にちなんで名付けられているので、時間の経過とともに一意になることはありません。そして、thatがそうでなかったとしても、私の子孫に名前を付ける可能性があるため、これをURNとして不適切にします。
URNは、URIの構文を共有しているにもかかわらず、この厳格な一意性制約のURLとは異なります。
URIは、数字、文字、記号の短い文字列を使用してドキュメントを識別するための標準です。それらは RFC 3986-Uniform Resource Identifier(URI):Generic Syntax で定義されています。 URL、URN、およびURCはすべてURIのtypesです。
その場所からリソースを取得する方法に関する情報が含まれています。例えば:
http://example.com/mypage.html
ftp://example.com/download.Zip
mailto:[email protected]
file:///home/user/file.txt
tel:1-888-555-5555
http://example.com/resource?foo=bar#fragment
/other/link.html
(相対URL、別のURLのコンテキストでのみ有用)URLは常にプロトコル(http
)で始まり、通常、ネットワークホスト名(example.com
)などの情報と、多くの場合ドキュメントパス(/foo/mypage.html
)が含まれます。 URLには、クエリパラメータとフラグメント識別子が含まれる場合があります。
一意で永続的な名前でリソースを識別しますが、必ずしもインターネット上でリソースを見つける方法を示しているわけではありません。通常、接頭辞urn:
で始まります。次に例を示します。
urn:isbn:0451450523
。ISBN番号で本を識別します。urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66
グローバルに一意の識別子urn:publishing:book
-ドキュメントを書籍の種類として識別するXML名前空間。URNは、アイデアと概念を識別することができます。ドキュメントの識別に限定されません。 URNがドキュメントを表す場合、「リゾルバ」によってURLに変換できます。その後、ドキュメントをURLからダウンロードできます。
ドキュメント自体ではなく、ドキュメントに関するメタデータを指します。 URCの例は、次のようなページのHTMLソースコードを指すものです:view-source:http://example.com/
データをインターネット上に配置したり、名前を付けたりするのではなく、データをURIに直接配置できます。例はdata:,Hello%20World
です。
HTMLのW3仕様では、 href
アンカータグ にはURLだけでなくURIを含めることができるとされています。 <a href="urn:isbn:0451450523">
などのURNを入力できるはずです。ブラウザはそのURNをURLに解決し、本をダウンロードします。
私が知っていることではありませんが、最新のWebブラウザーはデータURIスキームを実装しています。
いいえ。相対URLと絶対URLはどちらもURL(およびURI)です。
いいえ。クエリパラメータのあるURLとないパラメータはどちらもURL(およびURI)です。
いいえ。フラグメント識別子のあるURLとないフラグメントURLは両方ともURL(およびURI)です。
いいえ。URLはURIの厳密なサブセットとして定義されています。パーサーがURLの文字を許可し、URIの文字を許可しない場合、パーサーにバグがあります。仕様では、URLおよびURIのどの部分でどの文字が許可されているかについて詳細に説明しています。一部の文字はURLの一部でのみ許可される場合がありますが、URLとURIの違いは文字だけではありません。
はい。 W3Cは、これについて多くの混乱があることを認識しました。彼らは RI明確化ドキュメント を発行しました。これは、URLとURIという用語を(URIを意味する)交換可能に使用することが今では問題ないことを示しています。 URIをURL、URN、URCなどの異なるタイプに厳密にセグメント化することはもはや有用ではありません。
URNの定義は、上記で説明したものよりも緩やかになりました。 RIに関する最新のRFC は、「名前のプロパティ」がある限り、URIが(urn:
で始まるかどうかに関係なく)URNになり得ることを示しています。つまり、リソースが存在しなくなった場合や使用できなくなった場合でも、グローバルに一意で永続的です。例:http://www.w3.org/TR/html4/strict.dtd
などのHTML Doctypeで使用されるURI。そのURIは、w3.org Webサイトのページが削除された場合でも、HTML4 Transitional Doctypeに名前を付け続けます。
要約すると、 URIで識別され、URLで識別され、検索されます。
Shakespeareの演劇Romeo and Julietの特定の版を考えてみてください。そのうち、あなたはあなたのホームネットワークにデジタルコピーを持っています。
あなたはそのテキストをurn:isbn:0-486-27557-4
として識別することができます。
これはURIになりますが、 というテキストの名前は になるため、より具体的には _ urn _ *になります。
テキストをfile://hostname/sharename/RomeoAndJuliet.pdf
として識別することもできます。
これはURIでも構いませんが、 はテキスト を検索するため、 _ url _ になります。
*統一リソース名
(私の例は Wikipedia )から変更されていることに注意してください
これらは非常によく書かれているが長い間答えがある。 CodeIgniterに関する限り、これは の差です。 :
_ url _ - http://example.com/some/page.html
_ uri _ - /some/page.html
簡単に言えば、URLはあらゆる場所のリソースを識別するための完全な方法であり、FTP、HTTP、SCPなどのような異なるプロトコルを持つことができます。
URIは現在のドメイン上のリソースなので、必要な情報が少なくて済みます。
CodeIgniterがWordのURLまたはURIを使用するすべての例で、これは彼らが話している違いですが、Webのグランドスキームでは、100%正しいというわけではありません。
まず第一に、混乱からあなたの心を取り、それを単純にすると理解するでしょう。
URI => Uniform Resource Identifier リソースの完全なアドレス(場所、名前、またはその両方)を識別します。
URL => Uniform Resource Locator リソースの場所を識別します。
URN => Uniform Resource Name リソースの名前を識別します。
例
https://www.google.com/folder/page.htmlここで、
URI(Uniform Resource Identifier)=> https://www.google.com/folder/page.html
URL(Uniform Resource Locator)=> https://www.google.com/ /
URN(Uniform Resource Name)=> /folder/page.html
URI =>(URL + URN)またはURLのみまたはURNのみ
すでに投稿された答えに少し追加して、これは理論を要約するためのベンの図です(Prateek Joshiの美しい 説明 から):
そしてその一例(Prateekのウェブサイトからも):
これは私がウェブ専門家として遭遇した最も混乱し、おそらく無関係なトピックの1つです。
私が理解しているように、URIは、受け入れられたフォーマットに従って、何かの記述であり、それは何かの固有の名前(識別)とその場所の両方またはどちらかを定義することができます。
2つの基本的なサブセットがあります - 場所を定義するURL(特にWebページを検索しようとしているブラウザに)とURNは何かの固有の名前を定義します。
URNはGUIDに似ていると考える傾向があります。それらは、物に固有の名前を付けるための標準化された方法です。会社の名前を使用する名前空間宣言のように - それはテキストのその行に対応するためにどこかにサーバーの上に座っているリソースがあるようではない - それは単に何かを一意に識別する。
私はまた、URIという用語を完全に避け、必要に応じてURLまたはURNに関してのみ議論する傾向があります。混乱を招くからです。私たちが本当に人々のために答えようとするべき質問はそれほどセマンティクスではありませんが、プログラミング状況へのアプローチを変えるそれらに実際的な違いがあるかどうかどうかという用語に遭遇したときに識別する方法。例えば、誰かが私を会話の中で訂正して、「ああ、それはURLではない、それはURIである」と言ったら、私は彼らがそれでいっぱいだと知っています。 「URNを使用してリソースを定義している」と誰かが言った場合、サーバー上ではなく、一意に名前を付けるだけであることを理解する可能性があります。
もし私が基地から出るのであれば - 教えてください。
識別子=名前+場所
すべてのURL(U niform RソースL ocator)はURI(U niform Resource I dentifier)、簡単に言えば、すべてのURIはURLではありません。 URIの別のサブカテゴリはURN(U niform RソースN ame)です。 mailto、newsのように、ISBNはURIです。 出典
URN:
urn:[namespace identifier]:[namespace specific string]
arn:partition:service:region:account-id:resource
URL:
[scheme]://[Domain][Port]/[path]?[queryString]#[fragmentId]
類推:
人に連絡するには:運転(他の人にはSMS、Eメール、電話)、住所(他のホスト名、他の電話番号、EメールID)および人の名前(相対パスを持つオブジェクト名)。
URI => http://en.wikipedia.org/wiki/Uniform_Resource_Identifier
URLはURIのサブセットです(これにはURNも含まれます)。
基本的に、URIは一般的な識別子です。URLは場所を指定し、URNは名前を指定します。
URIについて考えるときに私が使用したいもう一つの例は、XML文書のxmlns属性です。
<rootElement xmlns:myPrefix="com.mycompany.mynode">
<myPrefix:aNode>some text</myPrefix:aNode>
</rootElement>
この場合、com.mycompany.mynodeは、私のXML文書内でそれを使用するすべての要素の「myPrefix」名前空間を一意に識別するURIです。これはURLではありません。識別するためだけに使用され、それ自体で何かを見つけるために使用されるわけではありません。
私が覚えている限りでは、URIとURLを明確に区別することは困難であるため、W3CはもはやURIとURLの間で違いを生じさせません( http://www.w3.org/Addressing/ )。
同じことだ 。 URIはURLを一般化したものです。元々、URIはURL(アドレス)とURN(名前)に分割されることが計画されていましたが、URLとURIの間にはほとんど違いはなく、http URIは実際にはリソースを見つけませんでしたが.
URI、URL、URN
上の画像が示すように、ここには3つの異なる要素があります。このようなことについて議論するときには、たいていの場合ソースに行くのが最善です。ですから、ここにTim Berners-Leeらの抜粋があります。 al。 RFC 3986:URI(Uniform Resource Identifier):一般的な構文:
URI(Uniform Resource Identifier)は、抽象的または物理的なリソースを識別するコンパクトな文字シーケンスです。
URIは、ロケーター、名前、またはその両方としてさらに分類できます。 「ユニフォームリソースロケータ」(URL)という用語は、リソースを識別することに加えて、その主要アクセスメカニズム(たとえば、そのネットワーク「ロケーション」)を記述することによってリソースを見つける手段を提供するURIのサブセットを指す。
URIはURLとURNのスーパークラスの一種です。ウィキペディアには すばらしい記事があります それらについての正しいRFCのセットへのリンクがあります。
ウィキペディアはあなたがここで必要とするすべての情報を提供します。 http://en.wikipedia.org/wiki/URI からの引用
URLは、リソースを識別することに加えて、その主要なアクセスメカニズムまたはネットワークの「場所」を記述することによってリソースの表現に基づいて行動するかまたはその表現を取得する手段を提供するURIです。
_ url _
URLは、特定のリソースのネットワーク上の場所を定義するURIの特殊化です。 URNとは異なり、URLはリソースの取得方法を定義します。私たちは毎日http://example.com
などの形式でURLを使用します。しかし、URLはHTTP URLである必要はなく、ftp://example.com
などでもかまいません。
_ uri _
URIは、場所、名前、またはその両方によってリソースを識別します。多くの場合、多くの場合、リソースの場所を定義するURIを使用します。 URIが名前と場所の両方でリソースを識別できるという事実は、私の意見では多くの混乱を招いています。 URIには、URLとURNという2つの特殊化があります。
URLとURIの違い
URIはリソースの識別子ですが、URLはそのリソースを取得するための特定の情報を提供します。 URIはURLであり、あるコメンターが指摘したように、アプリケーションを記述するときにURLを使用するのは不正確と見なされています。一般に、URLにリソースの場所と名前の両方が記載されている場合、使用する用語はURIです。これは一般的に私たちのほとんどが日常的に遭遇するケースであるので、URIは正しい用語です。
URIは、場所、名前、またはその両方によってリソースを識別します。多くの場合、多くの場合、リソースの場所を定義するURIを使用します。 URIが名前と場所の両方でリソースを識別できるという事実は、私の意見では多くの混乱を招いています。 URIには、URLとURNという2つの特殊化があります。
URLは、特定のリソースのネットワーク上の場所を定義するURIの特殊化です。 URNとは異なり、URLはリソースの取得方法を定義します。私たちは毎日 http://stackoverflow.com などの形式でURLを使用しますが、URLは必ずしもHTTP URLである必要はなく、ftp://example.com
などでもかまいません。
URIおよびURLという用語は厳密に定義されていますが、多くの場合、これらの用語が定義されている以外の目的で使用されています。
たとえば、Apacheを見てみましょう。 Apacheサーバーから http://example.com/foo が要求された場合は、次の環境変数が設定されています。
REDIRECT_URL
:/foo
REQUEST_URI
:/foo
Mod_rewriteを有効にすると、これらの変数もあります。
REDIRECT_SCRIPT_URL
:/foo
REDIRECT_SCRIPT_URI
:http://example.com/foo
SCRIPT_URL
:/foo
SCRIPT_URI
:http://example.com/foo
これが混乱の一部の理由かもしれません。
このドキュメント を参照してください。具体的には、
uRLは、それが有する可能性のある他のいくつかの属性によるのではなく、その一次アクセス機構(例えば、そのネットワーク「場所」)の表現を介してリソースを識別するURIの一種である。
本当にそれほど明確な用語ではありません。
投稿を読んだ後、私はいくつかの非常に関連性のあるコメントを見つけました。要するに、URL定義とURI定義の混同は、ソフトウェア定義におけるWord URIのどれが非公式に使用されているかに依存する定義に部分的には基づいています。
定義上、URLはURIのサブセットです[RFC2396]。 URIはURNとURLを含みます。 URIとURLの両方とも、それぞれURIまたはURLのどちらかであることのステータスを付与する独自の構文を持っています。 URNはリソースを一意に識別するためのものであり、URLはリソースを見つけるためのものです。リソースは複数のURLを持つことができますが、単一のURNのみを持つことができます。[RFC2611]
Web開発者およびプログラマーとして、私たちはほぼ常にURL、したがってURIに関心を持つでしょう。現在、URLはすべての部分スキームを持つように明確に定義されています。例えば https://stackoverflow.com/questions のように、scheme-specific-partです。これはURLであり、URIでもあります。 ../index.htmlのようにページに埋め込まれた相対リンクを考えてみましょう。これは定義上URLではなくなりました。それはまだ「URI参照」[RFC2396]と呼ばれるものです。
Word URIが相対パスを参照するのに使用されるとき、「URI参照」が実際に考えられているものであると私は信じます。そのため、非公式には、ソフトウェアシステムはURIを使用して相対パスを参照し、URLを絶対アドレスに使用します。したがって、この意味では、相対パスはURLではなくURIでもあります。
これが私の単純化です。
URN:一意のリソース名、すなわち「何」(例えば、urn:isn:1234〜5678)。これはユニークであることを意味します。2つの異なるドキュメントが同じURLを持つことはできないからです。 "uuid"のようなもの
URL: "where"で検索できます(例: https://google.com/pub?issnid=1234-5678 ..または ftp://somesite.com/doc8.pdf )
URI:URNでもURLでもかまいません。このあいまいな定義は、W3CとIETFによって作成されたRFC 3986のおかげです。
URIの定義は何年にもわたって変化してきたので、ほとんどの人にとって混乱することは理にかなっています。しかし、 http://somesite.com/something をURLまたはURIのどちらかとして参照できるという点で、安心できます。どちらにしても(少なくとも時間は必要ありません)とにかく…)
私は同じことについて疑問に思っていました、そして私はこれを見つけました: http://docs.kohanaphp.com/helpers/url 。
url::current()
メソッドを使った明確な例を見ることができます。 _ url _ :http://example.com/kohana/index.php/welcome/home.html?query=string
がある場合、url:current()
を使用すると、 _ uri _ が得られます。ドキュメントによれば、次のとおりです。welcome/home
URIは、Web上のリソースを特定する必要から生まれましたおよびその他のインターネットリソース電子メールボックスなど、統一された一貫した方法で。そのため、新しいタイプのwidget:URIを導入してwidgetリソースまたはtel:URIを使用してWebリンクを呼び出すと、呼び出されたときに電話がかけられます。
一部のURIは、リソース(そのマシン上のDNSホスト名やパスなど)を見つけるための情報を提供しますが、一部のURIは純粋なリソース名として使用されます。 URLは、http://stackoverflow.comなどの 'http' URLを含むリソースロケーターの識別子用に予約されています、ホスト上の特定のパスにあるWebページを識別します。別の例は、指定されたアドレスのメールボックスを識別するmailto:[email protected]などの「mailto」URLです。
RNsは、ロケーターではなく純粋なリソース名として使用されるURIです。たとえば、URI:mid:[email protected]は、それを含む電子メールメッセージを識別するURNです「Message-Id」フィールド。 URIは、そのメッセージを他の電子メールメッセージと区別するのに役立ちます。しかし、それ自体はどのストアでもメッセージのアドレスを提供しません。
これに答えるために、私は 私が別の質問 に修正した答えに頼ります。 URIの良い例は、Amazon S3リソースの識別方法です。とりましょう:
s3://www-example-com/index.html
[図1]
これをキャッシュコピーとして作成しました。
http://www.example.com/index.html
[図2]
amazonでは S3-US-West-2 datacenter。
たとえStackOverflowが私にs3://
へのハイパーリンクを許すとしても プロトコル 方式では、{検索} _リソースではまったく役に立ちません。 識別 a リソースなので、 fig。 1 は有効なURIです。 Amazonはバケット(URIのauthority
部分の用語)がデータセンター間で一意であることをAmazonが要求しているため、これも有効なURNです。それを見つけるのは参考ですが、データセンターを示すものではありません。そのため、URLとしては機能しません。
では、この場合、URI、URL、およびURNはどう違うのでしょうか。
注: RFC 3986ではURIをscheme://authority/path?query#fragment
として定義しています
説明が簡単:
次のように仮定しよう
URIはあなたの名前です
URLはあなたと通信するためのあなたの名前とあなたの名前です。
私の名前はロヨラ
ロヨラはURIです
私の住所はTN、Chennai 600001です。
TN、Chennai 600 001、LoyolaはURLです
ご理解ください
正確な例を見てみましょう。
http://www.google.com/fistpage.html
上記では、 firstpage.html ( _ uri _ )というページと通信できます。http://www.google.com/fistpage.html( _ url _ )。
したがって、URIはURLのサブセットですが、その逆ではありません。
URI(Uniform Resource Identifier)は、インターネットリソースを識別する文字列です。
最も一般的なURIは、インターネットドメインアドレスを識別するURL(Uniform Resource Locator)です。それほど一般的ではないもう1つのタイプのURIは、ユニバーサルリソース名(URN)です。
私が見つけた:
URI(Uniform Resource Identifier)は全体像を表しています。分割可能なURI/URIは、ロケーター(uniform resource locators - URL)、名前(uniform resource name - URN)、またはその両方として分類できます。そのため、基本的に、URNは人の名前のように機能し、URLはその人の住所を表します。長い話を簡単に言えば、URNはアイテムのアイデンティティを定義し、URLの提供はそれを見つけるための方法を定義し、最後にこれら2つの概念をカプセル化するのがURIです。
答えはあいまいです。 Javaでは、このように頻繁に使用されます。
URL(Uniform Resource Locator)は、スキーム(http、https、ftp、ニュースなど)を含むインターネットリソースを識別するために使用される用語です。例えば、 URI、URL、URNの違いは何ですか?
Uniform Resource Identifier(URI)は、Webサーバー内の単一の文書を識別するために使用されます。例えば、/ questions/176264/uri-a-urlの違い
Javaサーブレットでは、URIはWebアプリケーションのコンテキストなしでドキュメントを参照することがよくあります。