Die Leute sprechen über URLs , URIs und URNs, als wären sie verschiedene Dinge, aber sie sehen mit bloßem Auge gleich aus.
Was sind die unterscheidbaren Unterschiede zwischen ihnen?
( URIs ( URLs ) )
Die Leute sprechen über URLs , URIs und URNs, als wären sie verschiedene Dinge, aber sie sehen mit bloßem Auge gleich aus.
Was sind die unterscheidbaren Unterschiede zwischen ihnen?
( URIs ( URLs ) )
Antworten:
Aus RFC 3986 :
Ein URI kann weiter als Locator, Name oder beides klassifiziert werden. Der Begriff "Uniform Resource Locator" (URL) bezieht sich auf die Teilmenge von URIs, die zusätzlich zur Identifizierung einer Ressource ein Mittel zum Lokalisieren der Ressource bereitstellen, indem ihr primärer Zugriffsmechanismus (z. B. ihr Netzwerk "Standort") beschrieben wird. Der Begriff "Uniform Resource Name" (URN) wurde in der Vergangenheit verwendet, um beide URIs im Rahmen des "Urnen" -Schemas [RFC2141] zu bezeichnen , die global eindeutig und dauerhaft bleiben müssen, selbst wenn die Ressource nicht mehr existiert oder nicht mehr verfügbar ist zu einem anderen URI mit den Eigenschaften eines Namens.
Alle URLs sind also URIs (eigentlich nicht ganz - siehe unten), und alle URNs sind URIs - aber URNs und URLs sind unterschiedlich, sodass Sie nicht sagen können, dass alle URIs URLs sind.
EDIT: Ich hatte vorher gedacht, dass alle URLs gültige URIs sind, aber gemäß den Kommentaren:
Nicht "alle URLs sind URIs". Dies hängt von der Interpretation des RFC ab. Zum Beispiel in Java mag der URI-Parser nicht
[
oder]
und das liegt daran, dass in der Spezifikation "sollte nicht" und nicht "soll nicht" steht.
Das trübt das Wasser leider weiter.
Wenn Sie die Antwort von Roger Pate noch nicht gelesen haben , würde ich Ihnen auch raten, dies zu tun.
[
oder ]
und das liegt daran, dass in der Spezifikation "sollte nicht" und nicht "soll nicht" steht.
java.net.URI
Dokument selbst sagt: "Jede URL ist abstrakt eine URI, aber nicht jede URI ist eine URL." Und java.net.URL
macht seltsame Dinge wie das Überprüfen der Gleichheit von URLs durch Auflösen von Hostnamen in IP-Adressen (was in erster Linie im Widerspruch zu RFC 3986 Sek 6 steht und virtuelle Hosts zerstört). Ich denke, dies bedeutet nur, dass die Java Standard Library ein inkonsistentes Klassenverhalten aufweist.
URIs identifizieren und URLs lokalisieren ; jedoch sind Locators auch Bezeichner , so dass jeder URL ist auch eine URI, aber es gibt URIsdie keine URLs sind.
Dies ist mein Name, der eine Kennung ist. Es ist wie eine URI, kann jedoch keine URL sein, da es Ihnen nichts über meinen Standort oder die Kontaktaufnahme mit mir sagt. In diesem Fall werden auch mindestens 5 andere Personen allein in den USA identifiziert.
Dies ist ein Locator, der eine Kennung für diesen physischen Standort darstellt. Es ist wie eine URL und eine URI (da alle URLs URIs sind) und identifiziert mich auch indirekt als "wohnhaft in ...". In diesem Fall identifiziert es mich eindeutig, aber das würde sich ändern, wenn ich einen Mitbewohner bekomme.
Ich sage "Gefällt mir", weil diese Beispiele nicht der erforderlichen Syntax folgen.
Aus Wikipedia :
Beim Rechnen ist eine URL (Uniform Resource Locator) eine Teilmenge der URI (Uniform Resource Identifier), die angibt, wo eine identifizierte Ressource verfügbar ist, und den Mechanismus zum Abrufen. In der allgemeinen Verwendung und in vielen technischen Dokumenten und mündlichen Diskussionen wird es oft fälschlicherweise als Synonym für URI verwendet , ... [Hervorhebung von mir]
Aufgrund dieser häufigen Verwirrung verwenden viele Produkte und Dokumentationen fälschlicherweise einen Begriff anstelle des anderen, weisen eine eigene Unterscheidung zu oder verwenden sie synonym.
Mein Name, Roger Pate, könnte wie ein URN (Uniform Resource Name) sein, außer dass diese viel stärker reguliert sind und sowohl räumlich als auch zeitlich einzigartig sein sollen .
Da ich diesen Namen derzeit mit anderen Personen teile, ist er nicht global eindeutig und als URN nicht geeignet. Selbst wenn keine andere Familie diesen Namen verwenden würde, bin ich nach meinem Großvater väterlicherseits benannt, sodass er im Laufe der Zeit immer noch nicht einzigartig wäre. Und selbst wenn das nicht der Fall war, die Möglichkeit , meine Nachkommen nach mir zu benennen macht dies als URN ungeeignet.
URNs unterscheiden sich von URLs in dieser starren Eindeutigkeitsbeschränkung, obwohl beide die Syntax von URIs gemeinsam haben.
URNs are different from URLs in this rigid uniqueness constraint
Bedeutet dies, dass URLs einen Ort nicht eindeutig identifizieren?
URIs sind ein Standard zum Identifizieren von Dokumenten mithilfe einer kurzen Folge von Zahlen, Buchstaben und Symbolen. Sie werden durch RFC 3986 - URI (Uniform Resource Identifier): Generic Syntax definiert . URLs, URNs und URCs sind alle Arten von URI.
Enthält Informationen zum Abrufen einer Ressource von ihrem Speicherort. Zum Beispiel:
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
(Eine relative URL, die nur im Kontext einer anderen URL nützlich ist.)URLs beginnen immer mit einem Protokoll ( http
) und enthalten normalerweise Informationen wie den Netzwerkhostnamen ( example.com
) und häufig einen Dokumentpfad ( /foo/mypage.html
). URLs können Abfrageparameter und Fragmentkennungen enthalten.
Identifiziert eine Ressource anhand eines eindeutigen und dauerhaften Namens, sagt Ihnen jedoch nicht unbedingt, wie Sie sie im Internet finden können. Es beginnt normalerweise mit dem Präfix. urn:
Zum Beispiel:
urn:isbn:0451450523
ein Buch anhand seiner ISBN-Nummer zu identifizieren.urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66
eine global eindeutige Kennungurn:publishing:book
- Ein XML-Namespace, der das Dokument als Buchart identifiziert.URNs können Ideen und Konzepte identifizieren. Sie sind nicht auf die Identifizierung von Dokumenten beschränkt. Wenn eine URN ein Dokument darstellt, kann sie von einem "Resolver" in eine URL übersetzt werden. Das Dokument kann dann von der URL heruntergeladen werden.
Verweist auf Metadaten zu einem Dokument und nicht auf das Dokument selbst. Ein Beispiel für einen URC verweist auf den HTML-Quellcode einer Seite wie:view-source:http://example.com/
Anstatt es im Internet zu finden oder zu benennen, können Daten direkt in eine URI gestellt werden. Ein Beispiel wäre data:,Hello%20World
.
Die W3-Spezifikation für HTML besagt, dass das href
eines Ankertags einen URI enthalten kann, nicht nur eine URL. Sie sollten in der Lage sein, eine URN wie z <a href="urn:isbn:0451450523">
. Ihr Browser würde diese URN dann in eine URL auflösen und das Buch für Sie herunterladen.
Nicht das ich wüsste, aber moderne Webbrowser implementieren das Daten-URI-Schema.
Nein. Sowohl relative als auch absolute URLs sind URLs (und URIs).
Nein. Beide URLs mit und ohne Abfrageparameter sind URLs (und URIs).
Nein. Beide URLs mit und ohne Fragment-IDs sind URLs (und URIs).
Nein. URLs werden als strikte Teilmenge von URIs definiert. Wenn ein Parser ein Zeichen in einer URL, aber nicht in einem URI zulässt, liegt ein Fehler im Parser vor. Die Spezifikationen enthalten detaillierte Informationen darüber, welche Zeichen in welchen Teilen von URLs und URIs zulässig sind. Einige Zeichen sind möglicherweise nur in einigen Teilen der URL zulässig, aber Zeichen allein sind kein Unterschied zwischen URLs und URIs.
Ja. Das W3C erkannte, dass dies eine Menge Verwirrung stiftet. Sie gaben ein URI-Klärungsdokument heraus, das besagt, dass es jetzt in Ordnung ist, die Begriffe URL und URI austauschbar zu verwenden (um URI zu bedeuten). Es ist nicht mehr sinnvoll, URIs streng in verschiedene Typen wie URL, URN und URC zu segmentieren.
Die Definition von URN ist jetzt lockerer als oben angegeben. Der neueste RFC für URIs besagt, dass jeder URI jetzt ein URN sein kann (unabhängig davon, ob er damit beginnt urn:
), solange er "die Eigenschaften eines Namens" hat. Das heißt: Es ist global einzigartig und dauerhaft, selbst wenn die Ressource nicht mehr existiert oder nicht mehr verfügbar ist. Ein Beispiel: Die in HTML-Doctypes verwendeten URIs wie http://www.w3.org/TR/html4/strict.dtd
. Diese URI würde den HTML4-Übergangsdoktyp auch dann benennen, wenn die Seite auf der Website w3.org gelöscht würde.
file://
Präfix darauf. Obwohl Browser im Allgemeinen nicht mit URL formatierte Dateipfade verarbeiten. Mozilla veröffentlicht ihre Testfälle für Datei-URLs .
mailto:user@example.com
als URL erwähnt, aber eine andere Antwort unten besagt, dass es sich um eine URN handelt? Welches ist richtig? Ist es sowohl URN als auch URL?
Zusammenfassend: Ein URI identifiziert, eine URL identifiziert und findet.
Betrachten Sie eine bestimmte Ausgabe von Shakespeares Stück Romeo und Julia , von der Sie eine digitale Kopie in Ihrem Heimnetzwerk haben.
Sie können den Text als identifizieren urn:isbn:0-486-27557-4
.
Das wäre eine URI, genauer gesagt eine URN *, weil sie den Text benennt .
Sie können den Text auch als identifizieren file://hostname/sharename/RomeoAndJuliet.pdf
.
Das wäre auch eine URI, genauer gesagt eine URL, da sie den Text findet .
* Einheitlicher Ressourcenname
(Beachten Sie, dass mein Beispiel aus Wikipedia übernommen wurde )
ISBN 0486275574
auch der Text benannt und somit als URN qualifiziert. Ich wähle ein Format, von dem ich glaubte, dass es den Lesern vertrauter ist.
Dies sind einige sehr gut geschriebene, aber langatmige Antworten. Hier ist der Unterschied in Bezug auf CodeIgniter :
URL - http://example.com/some/page.html
URI - /some/page.html
Einfach ausgedrückt ist URL der vollständige Weg, um eine Ressource überall zu identifizieren, und kann verschiedene Protokolle wie FTP, HTTP, SCP usw. haben.
URI ist eine Ressource in der aktuellen Domäne, sodass weniger Informationen gefunden werden müssen.
In jedem Fall, in dem CodeIgniter das Wort URL oder URI verwendet, ist dies der Unterschied, über den sie sprechen, obwohl es im großen Schema des Webs nicht 100% korrekt ist.
/some/page.html
aber keine URI. Es ist eine "relative Referenz", die eine Art "URI-Referenz" ist. In Kombination mit einem Basis-URI-Kontext kann er in einen URI aufgelöst werden, ist jedoch selbst kein URI. Siehe Abschnitt 4.1 von RFC 3986 . CodeIgniter verwendet wahrscheinlich die falschen Begriffe und das sollte aufgerufen werden. Das Q (wie derzeit bearbeitet) ist nicht als CodeIgniter-spezifisch gerahmt.
Lassen Sie Ihren Geist zunächst aus der Verwirrung geraten und nehmen Sie es einfach und Sie werden verstehen.
URI => Uniform Resource Identifier Identifiziert eine vollständige Adresse der Ressource, dh Standort, Name oder beides.
URL => Uniform Resource Locator Gibt den Speicherort der Ressource an.
URN => Uniform Resource Name Gibt den Namen der Ressource an
Beispiel
Wir haben die Adresse https://www.google.com/folder/page.html wo,
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) oder nur URL oder nur URN
Als kleine Ergänzung zu den bereits veröffentlichten Antworten ist hier ein Venn-Diagramm, um die Theorie zusammenzufassen (aus Prateek Joshis schöner Erklärung ):
Und ein Beispiel (auch von Prateeks Website):
#posts
könnte Fragment-
Dies ist eines der verwirrendsten und möglicherweise irrelevantesten Themen, denen ich als Webprofi begegnet bin.
Nach meinem Verständnis ist eine URI eine Beschreibung von etwas, die einem akzeptierten Format folgt und sowohl den eindeutigen Namen (die Identifikation) von etwas als auch dessen Position definieren kann.
Es gibt zwei grundlegende Untergruppen: URLs, die den Speicherort definieren (insbesondere für einen Browser, der versucht, eine Webseite aufzurufen), und URNs, die den eindeutigen Namen von etwas definieren.
Ich neige dazu, URNs als ähnlich wie GUIDs zu betrachten. Sie sind einfach eine standardisierte Methode zur Bereitstellung eindeutiger Namen für Dinge. Wie in der Namespace-Deklarative, die den Namen eines Unternehmens verwendet - es ist nicht so, dass sich irgendwo auf einem Server eine Ressource befindet, die dieser Textzeile entspricht -, identifiziert sie einfach etwas eindeutig.
Ich neige auch dazu, den Begriff URI vollständig zu vermeiden und die Dinge nur in Bezug auf URL oder URN zu diskutieren, da dies so viel Verwirrung stiftet. Die Frage, die wir wirklich versuchen sollten, für Menschen zu beantworten, ist nicht so sehr die Semantik, sondern wie man bei der Begegnung mit den Begriffen erkennt, ob es einen praktischen Unterschied gibt, der die Herangehensweise an eine Programmiersituation verändert oder nicht. Wenn mich zum Beispiel jemand im Gespräch korrigiert und sagt: "Oh, das ist keine URL, es ist eine URI", weiß ich, dass er voll davon ist. Wenn jemand sagt "Wir verwenden eine URN, um die Ressource zu definieren", verstehe ich eher, dass wir sie nur eindeutig benennen und nicht auf einem Server lokalisieren.
Wenn ich weit weg von der Basis bin - lass es mich wissen!
redirect_url
anstelle von verwendet redirect_uri
würde, würde es jemanden wirklich interessieren?
Identität = Name mit Standort
Jede URL ( U niversal R esource L ocator) eine URI ( U niversal R esource I dentifier), abstrakt gesprochen, aber jede URI ist kein URL. Es ist eine weitere Unterkategorie von URI ist URN ( U niversal R esource N ame), die eine benannte Ressource ist aber nicht angeben , wie sie zu finden, wie mailto, Nachrichten, ist ISBN URIs. Quelle
URNE:
urn:[namespace identifier]:[namespace specific string]
arn:partition:service:region:account-id:resource
URL:
[scheme]://[Domain][Port]/[path]?[queryString]#[fragmentId]
Analogie:
Um eine Person zu erreichen: Fahren (Protokoll andere SMS, E-Mail, Telefon), Adresse (Hostname andere Telefonnummer, E-Mail-ID) und Personenname (Objektname mit einem relativen Pfad).
URI => http://en.wikipedia.org/wiki/Uniform_Resource_Identifier
URLs sind eine Teilmenge von URIs (die auch URNs enthalten).
Grundsätzlich ist ein URI eine allgemeine Kennung, bei der eine URL einen Speicherort und eine URN einen Namen angibt.
[
und ]
nicht mit einer URI erstellen .
Ein weiteres Beispiel, das ich gerne verwende, wenn ich über URIs nachdenke, ist das xmlns-Attribut eines XML-Dokuments:
<rootElement xmlns:myPrefix="com.mycompany.mynode">
<myPrefix:aNode>some text</myPrefix:aNode>
</rootElement>
In diesem Fall wäre com.mycompany.mynode ein URI, der den Namespace "myPrefix" für alle Elemente, die ihn in meinem XML-Dokument verwenden, eindeutig identifiziert. Dies ist KEINE URL, da sie nur zum Identifizieren und nicht zum Auffinden von Objekten an sich verwendet wird.
Aufgrund der Schwierigkeiten, URI und URL klar zu unterscheiden, macht W3C meines Erachtens keinen Unterschied mehr zwischen URI und URL ( http://www.w3.org/Addressing/ ).
Sie sind das gleiche . Ein URI ist eine Verallgemeinerung einer URL. Ursprünglich war geplant, URIs in URLs (Adressen) und URNs (Namen) zu unterteilen, aber dann gab es kaum einen Unterschied zwischen einer URL und URI, und http-URIs wurden als Namespaces verwendet, obwohl sie tatsächlich keine Ressourcen fanden.
URI, URL, URN
Wie das obige Bild zeigt, spielen hier drei verschiedene Komponenten eine Rolle. Es ist normalerweise am besten, zur Quelle zu gehen, wenn Sie solche Themen besprechen. Hier ist ein Auszug aus Tim Berners-Lee et al. al. in RFC 3986: URI (Uniform Resource Identifier): Generische Syntax:
Ein Uniform Resource Identifier (URI) ist eine kompakte Folge von Zeichen, die eine abstrakte oder physische Ressource identifiziert.
Ein URI kann weiter als Locator, Name oder beides klassifiziert werden. Der Begriff "Uniform Resource Locator" (URL) bezieht sich auf die Teilmenge der URIs, die zusätzlich zur Identifizierung einer Ressource ein Mittel zum Auffinden der Ressource bieten, indem sie ihren primären Zugriffsmechanismus (z. B. ihren Netzwerk "Standort") beschreiben.
URI ist eine Art Superklasse von URLs und URNs. Wikipedia hat einen guten Artikel über sie mit Links zu den richtigen RFCs.
Wikipedia gibt Ihnen hier alle Informationen, die Sie benötigen. Zitat aus http://en.wikipedia.org/wiki/URI :
Eine URL ist eine URI, die neben der Identifizierung einer Ressource auch die Möglichkeit bietet, auf die Ressource zu reagieren oder eine Darstellung der Ressource zu erhalten, indem ihr primärer Zugriffsmechanismus oder der "Standort" des Netzwerks beschrieben werden.
URL
Eine URL ist eine Spezialisierung des URI, die den Netzwerkspeicherort einer bestimmten Ressource definiert. Im Gegensatz zu einer URN definiert die URL, wie die Ressource abgerufen werden kann. Wir verwenden jeden Tag URLs in Form von http://example.com
usw. Eine URL muss jedoch keine HTTP-URL sein, sie kann auch ftp://example.com
usw. sein.
URI
Ein URI identifiziert eine Ressource entweder nach Standort oder nach einem Namen oder nach beidem. Meistens verwenden die meisten von uns URIs, die einen Speicherort für eine Ressource definieren. Die Tatsache, dass eine URI Ressourcen sowohl anhand ihres Namens als auch anhand ihres Standorts identifizieren kann, hat meiner Meinung nach zu großer Verwirrung geführt. Ein URI hat zwei Spezialisierungen, die als URL und URN bezeichnet werden.
Unterschied zwischen URL und URI
Ein URI ist eine Kennung für eine Ressource, aber eine URL gibt Ihnen spezifische Informationen zum Abrufen dieser Ressource. Ein URI ist eine URL, und wie ein Kommentator hervorhob, wird es jetzt als falsch angesehen, bei der Beschreibung von Anwendungen eine URL zu verwenden. Wenn die URL sowohl den Speicherort als auch den Namen einer Ressource beschreibt, lautet der zu verwendende Begriff im Allgemeinen URI. Da dies im Allgemeinen der Fall ist, dem die meisten von uns täglich begegnen, ist URI der richtige Begriff.
Gemäß RFC 3986 werden URIs aus den folgenden Teilen bestehen:
scheme://authority/path?query
Der URI beschreibt das Protokoll für den Zugriff auf eine Ressource ( Pfad ) oder Anwendung ( Abfrage ) auf einem Server ( Autorität ).
Alle URLs sind URIs, und alle URNs sind URIs, aber alle URIs sind keine URLs.
Bitte beachten Sie für weitere Details:
Ein URI identifiziert eine Ressource entweder nach Standort oder nach einem Namen oder nach beidem. Meistens verwenden die meisten von uns URIs, die einen Speicherort für eine Ressource definieren. Die Tatsache, dass eine URI Ressourcen sowohl anhand ihres Namens als auch anhand ihres Standorts identifizieren kann, hat meiner Meinung nach zu großer Verwirrung geführt. Ein URI hat zwei Spezialisierungen, die als URL und URN bezeichnet werden.
Eine URL ist eine Spezialisierung des URI, die den Netzwerkspeicherort einer bestimmten Ressource definiert. Im Gegensatz zu einer URN definiert die URL, wie die Ressource abgerufen werden kann. Wir verwenden jeden Tag URLs in Form von http://stackoverflow.com usw. Eine URL muss jedoch keine HTTP-URL sein, kann es auch sein ftp://example.com
usw.
Obwohl die Begriffe URI und URL streng definiert sind, verwenden viele die Begriffe für andere Dinge als für sie definiert.
Nehmen wir zum Beispiel Apache. Wenn http://example.com/foo von einem Apache-Server angefordert wird, sind die folgenden Umgebungsvariablen festgelegt:
REDIRECT_URL
:: /foo
REQUEST_URI
:: /foo
Wenn mod_rewrite aktiviert ist, haben Sie auch folgende Variablen:
REDIRECT_SCRIPT_URL
:: /foo
REDIRECT_SCRIPT_URI
:: http://example.com/foo
SCRIPT_URL
:: /foo
SCRIPT_URI
:: http://example.com/foo
Dies könnte der Grund für einige Verwirrung sein.
Siehe dieses Dokument . Speziell,
Eine URL ist ein URI-Typ, der eine Ressource anhand einer Darstellung ihres primären Zugriffsmechanismus (z. B. ihres Netzwerk- "Speicherorts") und nicht anhand einiger anderer Attribute identifiziert.
Es ist wirklich kein extrem klarer Begriff.
Nachdem ich die Beiträge gelesen habe, finde ich einige sehr relevante Kommentare. Kurz gesagt, die Verwechslung zwischen den URL- und URI-Definitionen basiert teilweise darauf, welche Definition von welcher abhängt, und auch auf der informellen Verwendung des Wortes URI in der Softwareentwicklung.
Per Definition ist die URL eine Teilmenge des URI [RFC2396]. URI enthalten URN und URL. Sowohl URI als auch URL haben jeweils eine eigene Syntax, die ihnen den Status eines URI oder einer URL verleiht. URN dienen zur eindeutigen Identifizierung einer Ressource, während URL zum Auffinden einer Ressource dient. Beachten Sie, dass eine Ressource mehr als eine URL, aber nur eine einzige URN haben kann. [RFC2611]
Als Webentwickler und Programmierer werden wir uns fast immer mit URL und damit URI befassen. Jetzt ist eine URL speziell so definiert, dass sie alle Teile enthält: Schema-spezifisches Teil, wie zum Beispiel https://stackoverflow.com/questions . Dies ist eine URL und auch eine URI. Betrachten Sie nun einen in die Seite eingebetteten relativen Link wie ../index.html. Dies ist per Definition keine URL mehr. Es ist immer noch eine sogenannte "URI-Referenz" [RFC2396].
Ich glaube, wenn das Wort URI verwendet wird, um sich auf relative Pfade zu beziehen, ist "URI-Referenz" tatsächlich das, woran man denkt. Informell gesehen verwenden Softwaresysteme URI, um auf den relativen Pfad und die URL für die absolute Adresse zu verweisen. In diesem Sinne ist ein relativer Pfad keine URL mehr, sondern immer noch eine URI.
Hier ist meine Vereinfachung:
URN: eindeutiger Ressourcenname, dh "was" (z. B. Urne: issn: 1234-5678). Dies soll einzigartig sein. In keinem Fall können zwei verschiedene Dokumente dieselbe Urne haben. Ein bisschen wie "uuid"
URL: "wo", um es zu finden (z . B. https://google.com/pub?issnid=1234-5678 .. oder ftp://somesite.com/doc8.pdf )
URI: kann entweder eine URN oder eine URL sein. Diese Fuzzy-Definition ist RFC 3986 zu verdanken, das von W3C und IETF hergestellt wurde.
Die Definition von URI hat sich im Laufe der Jahre geändert, daher ist es für die meisten Menschen sinnvoll, verwirrt zu sein. Jetzt können Sie sich jedoch trösten, dass Sie http://somesite.com/something entweder als URL oder als URI bezeichnen können ... und Sie werden in beiden Fällen Recht haben (zumindest vorerst sowieso). .)
Ich habe mich über das Gleiche gewundert und Folgendes gefunden: http://docs.kohanaphp.com/helpers/url .
Mit der url::current()
Methode können Sie ein klares Beispiel sehen . Wenn Sie diese haben URL : http://example.com/kohana/index.php/welcome/home.html?query=string
dann verwenden url:current()
gibt Ihnen die URI des nach der Dokumentation, ist: Willkommen / home
URIs entstanden aus der Notwendigkeit, Ressourcen im Web und andere Internetressourcen wie elektronische Postfächer auf einheitliche und kohärente Weise zu identifizieren . Man kann also einen neuen Widget- Typ einführen : URIs zum Identifizieren von Widget- Ressourcen oder tel: URIs zum Weben von Weblinks, die beim Aufrufen zu Telefonanrufen führen.
Einige URIs enthalten Informationen zum Auffinden einer Ressource (z. B. einen DNS-Hostnamen und einen Pfad auf diesem Computer), während andere als reine Ressourcennamen verwendet werden. Die URL ist für Bezeichner reserviert, bei denen es sich um Ressourcen-Locators handelt , einschließlich 'http'-URLs wie http://stackoverflow.com , die die Webseite unter dem angegebenen Pfad auf dem Host identifizieren. Ein weiteres Beispiel sind Mailto-URLs wie mailto: fred@mail.org , die das Postfach unter der angegebenen Adresse identifizieren.
URNs sind URIs, die als reine Ressourcennamen und nicht als Locators verwendet werden. Der URI: mid: 0E4FC272-5C02-11D9-B115-000A95B55BC8@stackoverflow.com ist beispielsweise ein URN, der die E-Mail-Nachricht identifiziert, die ihn in seinem Feld "Nachrichten-ID" enthält. Der URI dient dazu, diese Nachricht von jeder anderen E-Mail-Nachricht zu unterscheiden. Die Adresse der Nachricht wird jedoch in keinem Geschäft selbst angegeben.
Um dies zu beantworten, werde ich mich auf eine Antwort stützen , die ich in eine andere Frage geändert habe . Ein gutes Beispiel für einen URI ist die Identifizierung einer Amazon S3-Ressource. Lass uns nehmen:
s3://www-example-com/index.html
[Feige. 1]
die ich als zwischengespeicherte Kopie von erstellt habe
http://www.example.com/index.html
[Feige. 2]
im Amazon S3-US-West-2- Rechenzentrum.
Selbst wenn StackOverflow es mir ermöglichen würde, einen Hyperlink zum s3://
Protokollschema zu erstellen, würde es Ihnen beim Auffinden der Ressource nichts nützen . Weil es eine Ressource identifiziert , Abb. 1 ist eine gültige URI. Es ist auch eine gültige URN, da Amazon verlangt, dass der Bucket (der Begriff für den Teil der URI) in allen Rechenzentren eindeutig ist. Es ist hilfreich beim Auffinden, zeigt jedoch nicht das Rechenzentrum an. Daher funktioniert es nicht als URL.authority
Wie unterscheiden sich URI, URL und URN in diesem Fall?
HINWEIS: RFC 3986 definiert URIs alsscheme://authority/path?query#fragment
Einfach zu erklären:
Nehmen wir Folgendes an
URI ist dein Name
URL ist Ihre Adresse mit Ihrem Namen, um mit Ihnen zu kommunizieren.
Ich heiße Loyola
Loyola ist URI
Meine Adresse ist TN, Chennai 600001.
TN, Chennai 600 001, Loyola ist URL
Ich hoffe du verstehst,
Sehen wir uns nun ein genaues Beispiel an
http://www.google.com/fistpage.html
Oben können Sie mit einer Seite namens firstpage.html ( URI ) über die folgende http://www.google.com/fistpage.html ( URL ) kommunizieren .
Daher ist URI eine Teilmenge der URL, aber nicht umgekehrt.
Ein Uniform Resource Identifier (URI) ist eine Zeichenfolge, die eine Internetressource identifiziert.
Die häufigste URI ist die URL (Uniform Resource Locator), die eine Internetdomänenadresse identifiziert. Ein anderer, nicht so häufiger URI-Typ ist der Universal Resource Name (URN).
Ich fand:
Ein URI (Uniform Resource Identifier) repräsentiert so etwas wie ein großes Bild. Sie können URIs aufteilen / URIs können als Locators (Uniform Resource Locators-URL) oder als Namen (Uniform Resource Name-URN) oder als beides klassifiziert werden. Grundsätzlich funktioniert eine URN wie der Name einer Person, und die URL gibt die Adresse dieser Person an. Kurz gesagt, eine URN definiert die Identität eines Elements, während die URL die Methode zum Auffinden des Elements definiert. Diese beiden Konzepte sind schließlich die URI
Die beste (technische) Zusammenfassung imo ist diese
IRI, URI, URL, URN und ihre Unterschiede zu Jan Martin Keil:
Jeder, der sich wiederholt mit dem Semantic Web befasst, stößt wiederholt auf die Begriffe IRI , URI , URL und URN . Trotzdem stelle ich häufig fest, dass es Verwirrung über ihre genaue Bedeutung gibt. Und das haben natürlich auch andere bemerkt (siehe zB RFC3305 oder Suche bei Google). Um ehrlich zu sein, war ich von Anfang an selbst verwirrt. Aber eigentlich ist das Problem nicht so komplex. Werfen wir einen Blick auf die Definitionen der genannten Begriffe, um die Unterschiede zu ermitteln:
Ein Uniform Resource Identifier ist eine kompakte Folge von Zeichen, die eine abstrakte oder physische Ressource identifiziert. Der Zeichensatz ist auf US-ASCII beschränkt, mit Ausnahme einiger reservierter Zeichen. Zeichen außerhalb des Satzes zulässiger Zeichen können mithilfe der Prozentcodierung dargestellt werden. Ein URI kann als Locator, Name oder beides verwendet werden. Wenn ein URI ein Locator ist, beschreibt er den primären Zugriffsmechanismus einer Ressource. Wenn ein URI ein Name ist, identifiziert er eine Ressource, indem er ihr einen eindeutigen Namen gibt. Die genauen Spezifikationen der Syntax und Semantik eines URI hängen vom verwendeten Schema ab, das durch die Zeichen vor dem ersten Doppelpunkt definiert wird. [RFC3986]
Ein einheitlicher Ressourcenname ist eine URI in der Schemaurne, die als persistente, standortunabhängige Ressourcenkennung dienen soll. In der Vergangenheit bezog sich der Begriff auch auf eine URI. [RFC3986] Ein URN besteht aus einem Namespace Identifier (NID) und einem Namespace Specific String (NSS): urn :: Die Syntax und Semantik des NSS ist für jede NID spezifisch. Neben den registrierten NIDs gibt es mehrere weitere NIDs, die den offiziellen Registrierungsprozess nicht durchlaufen haben. [RFC2141]
Ein Uniform Resource Locator ist ein URI, der neben der Identifizierung einer Ressource auch die Lokalisierung der Ressource durch Beschreibung ihres primären Zugriffsmechanismus ermöglicht [RFC3986]. Da es keine genaue Definition der URL anhand einer Reihe von Schemata gibt, bezieht sich "URL ist ein nützliches, aber informelles Konzept" und bezieht sich normalerweise auf eine Teilmenge von URIs, die keine URNs enthalten [RFC3305].
Ein Internationalized Resource Identifier wird ähnlich wie ein URI definiert, der Zeichensatz wird jedoch auf den Universal Coded Character Set erweitert. Daher kann es alle lateinischen und nicht lateinischen Zeichen außer den reservierten Zeichen enthalten. Anstatt die Definition von URI zu erweitern, wurde der Begriff IRI eingeführt, um eine klare Unterscheidung zu ermöglichen und Inkompatibilitäten zu vermeiden. IRIs sollen URIs bei der Identifizierung von Ressourcen in Situationen ersetzen, in denen der Universal Coded Character Set unterstützt wird. Per Definition ist jeder URI ein IRI. Darüber hinaus gibt es eine definierte surjektive Zuordnung von IRIs zu URIs: Jeder IRI kann genau einem URI zugeordnet werden, aber verschiedene IRIs können demselben URI zugeordnet werden. Daher führt die Rückkonvertierung von einem URI zu einem IRI möglicherweise nicht zum ursprünglichen IRI. [RFC3987]
IRI is a superset of URI (IRI ⊃ URI)
URI is a superset of URL (URI ⊃ URL)
URI is a superset of URN (URI ⊃ URN)
URL and URN are disjoint (URL ∩ URN = ∅)
RDF erlaubt ausdrücklich die Verwendung von IRIs zum Benennen von Entitäten [RFC3987]. Dies bedeutet, dass wir fast jedes Zeichen in Entitätsnamen verwenden können. Auf der anderen Seite müssen wir uns oft mit Software für den frühen Zustand befassen. Daher ist es nicht unwahrscheinlich, dass Probleme mit Nicht-ASCII-Zeichen auftreten. Daher empfehle ich, Nicht-URI-Namen für Entitäten zu vermeiden und http-URIs [LINKED-DATA] zu verwenden. Kurz gesagt: Verwenden Sie nur URLs, um Ihre Entitäten zu benennen. Natürlich können wir auf vorhandene Entitäten verweisen, die durch eine URN benannt sind. Wir sollten jedoch vermeiden, diese Art von Bezeichnern neu zu erstellen.