人々はURL、URI、およびURNについて、あたかも別のものであるかのように話しますが、肉眼では同じように見えます。
それらの間の区別可能な違いは何ですか?
URIは識別し、 URLは検索します。ただし、ロケーターは識別子でもあるため、すべての URL も URI ですが、URL ではない URI があります。
これは識別子である私の名前です。これは URI に似ていますが、URL にすることはできません。私の場所や連絡方法については何も教えてくれないからです。この場合、米国だけでも少なくとも 5 人の人物を特定することができます。
これは、その物理的な場所の識別子であるロケーターです。これは URL と URI の両方に似ており (すべての URL は URI であるため)、間接的に私を「~の居住者」として識別します。この場合、それは私を一意に識別しますが、ルームメイトができればそれは変わります.
これらの例が必要な構文に従っていないため、「好き」と言います。
ウィキペディアから:
コンピューティングでは、Uniform Resource Locator (URL) は Uniform Resource Identifier (URI) のサブセットであり、識別されたリソースが利用可能な場所とそれを取得するメカニズムを指定します。一般的な使用法や、多くの技術文書や口頭での議論では、URI の同義語として誤って使用されることがよくあります... [私の強調]
このよくある混乱のため、多くの製品やドキュメントでは、一方の用語を他方の代わりに誤って使用したり、独自の区別を割り当てたり、同義語として使用したりしています。
私の名前、Roger Pate はURN (Uniform Resource Name) のようなものかもしれませんが、それらははるかに規制されており、空間と時間の両方で一意であることを意図しています。
私は現在、この名前を他の人と共有しているため、グローバルに一意ではなく、URN として適切ではありません。ただし、他の家族がこの名前を使用していなくても、父方の祖父にちなんで名付けられているため、時間の経過とともに一意になることはありません. そうでなかったとしても、私の子孫に私の名前を付ける可能性があるため、これは URN として不適切です。
URN は、URI の構文を共有していますが、この厳格な一意性制約において URL とは異なります。
RFC 3986から:
URIは、ロケーター、名前、またはその両方としてさらに分類できます。「ユニフォームリソースロケーター」(URL)という用語は、リソースを識別することに加えて、そのプライマリアクセスメカニズム(たとえば、ネットワークの「場所」)を記述することによってリソースを見つける手段を提供するURIのサブセットを指します。「UniformResourceName」(URN)という用語は、歴史的に「urn」スキーム[RFC2141]の下で両方のURIを指すために使用されてきました。これらは、リソースが存在しなくなったり使用できなくなったりしても、グローバルに一意で永続的である必要があります。名前のプロパティを持つ他のURIに。
したがって、すべてのURLはURIであり、すべてのURNはURIですが、URNとURLは異なるため、すべてのURIがURLであるとは言えません。
Roger Pateの回答をまだ読んでいない場合は、それもお勧めします。
URI は、数字、文字、および記号の短い文字列を使用してドキュメントを識別するための標準です。これらはRFC 3986 - Uniform Resource Identifier (URI): Generic Syntaxで定義されています。URL、URN、および URC はすべてURIのタイプです。
リソースをその場所から取得する方法に関する情報が含まれています。例えば:
http://example.com/mypage.html
ftp://example.com/download.zip
mailto:user@example.com
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 を含めることができると規定されています。などのURNを入れることができるはずです<a href="urn:isbn:0451450523">
。ブラウザはその URN を URL に解決し、書籍をダウンロードします。
私が知っていることではありませんが、最新の Web ブラウザーはデータ URI スキームを実装しています。
いいえ。相対 URL と絶対 URL はどちらも URL (および URI) です。
いいえ。クエリ パラメータを含む URL と含まない URL はどちらも URL (および URI) です。
いいえ。フラグメント識別子を含む URL と含まない URL はどちらも URL (および URI) です。
いいえ。URL は URI の厳密なサブセットとして定義されています。パーサーが URL では文字を許可するが URI では許可しない場合、パーサーにバグがあります。仕様では、URL と URI のどの部分でどの文字が許可されているかについて詳しく説明されています。一部の文字は URL の一部でのみ許可される場合がありますが、文字だけでは URL と URI の違いにはなりません。
はい。W3C は、これについて多くの混乱があることに気付きました。彼らは、現在では URL と URI という用語を同じ意味で (URI を意味するように) 使用しても問題ないと述べているURI 明確化文書を発行しました。URI を URL、URN、URC などのさまざまなタイプに厳密にセグメント化することは、もはや役に立ちません。
URN の定義は、上で述べたものよりも緩くなりました。URIに関する最新の RFC にurn:
よると、「名前のプロパティ」を持っている限り、任意の URI が (で始まるかどうかに関係なく) URN になることができるようになりました。つまり、リソースが存在しなくなったり利用できなくなったりしても、グローバルに一意で永続的です。例: などの HTML doctype で使用される URI http://www.w3.org/TR/html4/strict.dtd
。w3.org Web サイトのページが削除されたとしても、その URI は引き続き HTML4 移行 doctype を指定します。
要約すると、URI は識別し、URL は識別して位置を特定します。
シェイクスピアの戯曲ロミオとジュリエットの特定の版について考えてみます。この版のデジタル コピーはホーム ネットワーク上にあります。
としてテキストを識別することができますurn:isbn:0-486-27557-4
。
これは URI になりますが、より具体的にはURN * になります。テキストに名前が付けられているためです。
テキストを として識別することもできますfile://hostname/sharename/RomeoAndJuliet.pdf
。
これも URI ですが、より具体的にはURLです。
*統一資源名
(私の例はウィキペディアから改作されていることに注意してください)
これらは、非常によく書かれていますが、長々とした回答です。CodeIgniter に関する限り、違いは次のとおりです。
URL - http://example.com/some/page.html
URI - /some/page.html
簡単に言えば、URL はあらゆる場所のリソースを識別するための完全な方法であり、FTP、HTTP、SCP などのさまざまなプロトコルを使用できます。
URI は現在のドメインのリソースであるため、検索に必要な情報は少なくなります。
CodeIgniter が URL または URI という単語を使用するすべての場合、これは彼らが話している違いですが、Web の壮大な計画では、それは 100% 正しいわけではありません。
すでに投稿された回答への小さな追加、ここに理論を要約するためのベン図があります(Prateek Joshiの美しい説明から):
そして例(これもPrateekのウェブサイトから):
ID = 場所を含む名前
抽象的に言えば、すべての URL (Uniform Resource Locator) は URI (Uniform Resource I dentifier )ですが、すべてのURIはURLではありません。URI の別のサブカテゴリとして URN (Uniform Resource Name )があります。これは名前付きのリソースですが、mailto、news、ISBN のように検索方法を指定していません 。URIです。ソース
骨壷:
urn:[namespace identifier]:[namespace specific string]
arn:partition:service:region:account-id:resource
URL:
[scheme]://[Domain][Port]/[path]?[queryString]#[fragmentId]
類推:
人に到達するには: 運転 (プロトコル、その他の SMS、電子メール、電話)、住所 (ホスト名、その他の電話番号、電子メール ID)、および個人の名前 (相対パスを持つオブジェクト名)。
これは、私が Web 専門家として遭遇した中で最も混乱を招き、おそらく無関係なトピックの 1 つです。
私が理解しているように、URI は何かの一意の名前 (ID) またはその場所の両方またはいずれかを定義できる、受け入れられている形式に従う何かの記述です。
2 つの基本的なサブセットがあります。
URN は GUID に似ていると考える傾向があります。それらは、物事に一意の名前を付けるための標準化された方法にすぎません。会社名を使用する名前空間宣言のように、そのテキスト行に対応するリソースがサーバーのどこかにあるわけではありません。単に何かを一意に識別します。
また、URI という用語を完全に避けて、必要に応じて URL または URN の観点からのみ説明する傾向があります。これは、非常に混乱を招くためです。私たちが実際に人々のために答えようとするべき問題は、セマンティクスではなく、プログラミング状況へのアプローチを変更する実際的な違いがあるかどうかを用語に遭遇したときにどのように識別するかです。たとえば、誰かが会話で私を訂正して、「ああ、それは URL ではなく URI です」と言った場合、私は彼らがそれでいっぱいであることを知っています。「URN を使用してリソースを定義している」と誰かが言った場合、サーバー上に配置するのではなく、一意に名前を付けているだけだと理解する可能性が高くなります。
私がベースから外れている場合は、お知らせください!
URI => http://en.wikipedia.org/wiki/Uniform_Resource_Identifier
URLはURIのサブセットです(URNも含まれています)。
基本的に、URIは一般的な識別子であり、URLは場所を指定し、URNは名前を指定します。
URI について考えるときに私が好んで使用するもう 1 つの例は、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のスーパークラスの一種です。ウィキペディアには、RFCの適切なセットへのリンクを含むそれらに関するすばらしい記事があります。
ウィキペディアはあなたがここで必要とするすべての情報を提供します。http://en.wikipedia.org/wiki/URIからの引用:
URLは、リソースを識別することに加えて、そのプライマリアクセスメカニズムまたはネットワークの「場所」を記述することによって、リソースに作用したり、リソースの表現を取得したりする手段を提供するURIです。
URL
URL は、特定のリソースのネットワーク上の場所を定義する URI の特殊化です。URN とは異なり、URL はリソースを取得する方法を定義します。私たちは毎日、http://example.com
etc の形式で URL を使用しています。しかし、URL は HTTP URL である必要はなく、etc でもかまいません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 を例にとってみましょう。http://example.com/fooが Apache サーバーから要求された場合、次の環境変数が設定されます。
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 の定義の混同は、どの定義がどの定義に依存しているか、およびソフトウェア開発における URI という言葉の非公式な使用にも一部基づいています。
定義により、URL は URI [RFC2396] のサブセットです。URI には URN と URL が含まれます。URI と URL の両方には、URI または URL のいずれかのステータスを与える独自の特定の構文があります。URN はリソースを一意に識別するためのものであり、URL はリソースを見つけるためのものです。リソースは複数の URL を持つことができますが、URN は 1 つだけであることに注意してください。[RFC2611]
Web 開発者およびプログラマーとして、私たちはほとんどの場合、URL、したがって URI に関心を持っています。これで、URL は、たとえばhttps://stackoverflow.com/questionsのように、すべての部分が scheme:scheme-specific-part になるように明確に定義されます。これは URL であり、URI でもあります。ここで、../index.html などのページに埋め込まれた相対リンクを考えてみましょう。これはもはや定義上 URL ではありません。それはまだ「URI参照」[RFC2396]と呼ばれるものです。
相対パスを参照するために URI という単語が使用される場合、実際には「URI 参照」が考えられていると思います。したがって、非公式に言えば、ソフトウェア システムは URI を使用して相対パスを参照し、URL を絶対アドレスとして使用します。この意味で、相対パスは URL ではなく URI のままです。
このドキュメントを参照してください。具体的には、
URL は、他の属性ではなく、プライマリ アクセス メカニズム (ネットワークの「場所」など) の表現によってリソースを識別する URI の一種です。
それは非常に明確な用語ではありません。
URIは、Web上のリソース、および電子メールボックスなどの他のインターネットリソースを統一された一貫した方法で識別する必要性から生まれました。したがって、新しいタイプのウィジェットを導入できます。URIを使用してウィジェットリソースを識別したり、 tel: URIを使用してWebリンクを設定したりすると、呼び出されたときに電話がかけられます。
一部のURIは、リソースを見つけるための情報(DNSホスト名やそのマシン上のパスなど)を提供しますが、一部は純粋なリソース名として使用されます。URLは、ホスト上の特定のパスにあるWebページを識別するhttp://stackoverflow.comなどの「http」URLを含む、リソースロケーターである識別子用に予約されています。もう1つの例は、 mailto:fred@mail.orgなどの「mailto」URLです。これは、指定されたアドレスのメールボックスを識別します。
URNは、ロケーターではなく純粋なリソース名として使用されるURIです。たとえば、URI:mid:0E4FC272-5C02-11D9-B115-000A95B55BC8@stackoverflow.comは、「Message-Id」フィールドにそれを含む電子メールメッセージを識別するURNです。URIは、そのメッセージを他の電子メールメッセージと区別するのに役立ちます。ただし、それ自体はどのストアでもメッセージのアドレスを提供しません。
ここに私の単純化があります:
URN: 一意のリソース名、つまり「何」 (例: urn:issn:1234-5678 )。これは一意であることを意味します.. 2 つの異なるドキュメントが同じ urn を持つことはできないためです。「uuid」に少し似ています
URL: 「場所」で検索できます (例: 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 として参照できるという事実に慰めを得ることができます... どちらの方法でも正しいでしょう (少なくとも当面は.. .)
これに答えるために、別の質問に変更した回答に頼ります。URI の良い例は、Amazon S3 リソースを識別する方法です。取りましょう:
s3://www-example-com/index.html
[図。1]
キャッシュされたコピーとして作成したもの
http://www.example.com/index.html
[図。2]
Amazon のS3-US-West-2データセンターにあります。
StackOverflow でs3://
プロトコルスキームへのハイパーリンクが許可されたとしても、リソースを見つけるのには何の役にも立たないでしょう。これはResourceを識別するためです。1は有効な URI です。これは有効な URN でもあります。Amazon ではバケット ( URI の一部を表す用語) がデータセンター全体で一意である必要があるためです。場所を特定するのに役立ちますが、データセンターを示すものではありません。したがって、URL としては機能しません。authority
では、この場合、URI、URL、および URN はどのように異なるのでしょうか?
注: RFC 3986 では、URI を次のように定義しています。scheme://authority/path?query#fragment
私は同じことについて疑問に思っていましたが、これを見つけました: http://docs.kohanaphp.com/helpers/url .
url::current()
メソッドを使用した明確な例を見ることができます。このURLがある場合:http://example.com/kohana/index.php/welcome/home.html?query=string
を使用すると、ドキュメントによると、welcome/homeであるURIurl:current()
が得られます。
簡単に説明します:
次のことを仮定しましょう
URIはあなたの名前です
URL は、あなたと通信するためのあなたの名前とあなたのアドレスです。
私の名前はロヨラです
ロヨラはURI
私の住所はテネシー州チェンナイ 600001 です。
TN, Chennai 600 001, Loyola は URL
ご理解いただければ幸いです。
正確な例を見てみましょう
http://www.google.com/fistpage.html
上記では、次のhttp://www.google.com/fistpage.html ( URL ) を使用してfirstpage.html ( URI )というページと通信できます。
したがって、URI は URL のサブセットですが、その逆ではありません。
答えはあいまいです。Javaでは、次のように頻繁に使用されます。
ユニフォームリソースロケーター(URL)は、スキーム(http、https、ftp、ニュースなど)を含むインターネットリソースを識別するために使用される用語です。たとえば、URI、URL、URNの違いは何ですか?
ユニフォームリソース識別子(URI)は、Webサーバー内の単一のドキュメントを識別するために使用されます。たとえば、/ questions / 176264 / whats-the-difference-between-a-uri-and-a-url
Javaサーブレットでは、URIはWebアプリケーションコンテキストなしでドキュメントを参照することがよくあります。