Einheitliche Ressourcenkennung

"Uri" leitet hier weiter. Für andere Verwendungen siehe URI (Disambiguierung).
Nicht zu verwechseln mit URL.
Einheitliche Ressourcenkennung (URI)
Abkürzung Uri
Domain Weltweites Netz

A Einheitliche Ressourcenkennung (Uri) ist eine eindeutige Abfolge von Zeichen, die eine logische oder physische Ressource identifiziert, die von Web -Technologien verwendet wird. URIs können verwendet werden, um alles zu identifizieren, einschließlich der realen Objekte wie Personen und Orten, Konzepten oder Informationsressourcen wie Webseiten und Büchern. Einige URIs bieten die Möglichkeit, Informationsressourcen in einem Netzwerk zu finden und abzurufen (entweder im Internet oder in einem anderen privaten Netzwerk, z. B. einem Computer -Dateisystem oder einem Intranet); diese sind Uniforme Ressourcenlokatoren (URLs). Eine URL bietet den Standort der Ressource. Ein URI identifiziert die Ressource mit dem Namen am angegebenen Ort oder an der URL. Andere URIs liefern nur einen einzigartigen Namen, ohne dass die Ressource oder Informationen dazu aufgefunden oder abgerufen werden können. Einheitliche Ressourcennamen (Urnen). Die Webtechnologien, die URIs verwenden, sind nicht auf Webbrowser beschränkt. URIs werden verwendet, um alles zu identifizieren, was mit dem beschrieben wurde Ressourcenbeschreibung Framework (RDF) zum Beispiel Konzepte, die Teil eines sind Ontologie definiert mit dem Web -Ontologie -Sprache (Eule) und Menschen, die mit dem beschrieben werden Freund eines Freundes Vokabular hätte jeder eine individuelle Uri.

Geschichte

Konzeption

URIS und URLs haben eine gemeinsame Geschichte. In 1990, Tim Berners-LeeVorschläge für Hypertext stellte implizit die Idee einer URL als kurze Zeichenfolge ein, die eine Ressource darstellt, die das Ziel von a ist Hyperlink.[1] Zu dieser Zeit bezeichneten die Leute es als "Hypertextname"[2] oder "Dokumentname".

In den nächsten dreieinhalb Jahren, als die Kerntechnologien des World Wide Web von HTML, HTTP und Webbrowsern entwickelten, müssen eine Zeichenfolge unterschieden, die eine Adresse für eine Ressource aus einer Zeichenfolge lieferte, die lediglich eine Ressource genannt wurde. Obwohl noch nicht formell definiert, der Begriff Einheitlicher Ressourcen -Locator kam, um die ersteren zu repräsentieren, und die umstritteneren Einheitlicher Ressourcenname kam, um letzteres zu repräsentieren. Im Juli 1992 Berners-Lee's Bericht über die Ietf "UDI (Universal Dokumentkennungen) Bof"Erwähnt URLs (als einheitliche Ressourcenlokatoren), Urnen (ursprünglich als eindeutige Ressourcennummern) und die Notwendigkeit, eine neue Arbeitsgruppe zu chartern.[3] Im November 1992 die Ietf "Uri -Arbeitsgruppe" traf sich zum ersten Mal.[4]

Während der Debatte über die Definition von URLs und Urnen wurde deutlich, dass die Konzepte, die von den beiden Begriffen verkörpert wurden Identifikation. Im Juni 1994 die Ietf veröffentlichte Berners-Lees erste Anfrage für Kommentare Das erkannte die Existenz von URLs und Urnen an. Vor allem definierte es eine formale Syntax für Universelle Ressourcenidentifikatoren (d. H. URL-ähnliche Zeichenfolgen, deren präzise Syntaxe und Semantik von ihren Schemata abhing). zusätzlich RFC 1630 versuchte, die zu diesem Zeitpunkt verwendeten URL -Systeme zusammenzufassen. Es erkannte an - aber nicht standardisieren - Die Existenz von relativen URLs und Fragment-Identifikatoren.[5]

Raffinesse

Im Dezember 1994, RFC 1738 Formal definiert relative und absolute URLs, verfeinerte die allgemeine URL -Syntax, definiert, wie relative URLs in absoluter Form auflösen und die URL -Schemata besser aufzählten.[6] Die vereinbarte Definition und Syntax von Urnen musste bis zur Veröffentlichung von IETF RFC 2141 warten[7] Im Mai 1997.

Die Veröffentlichung von IETF RFC 2396[8] Im August 1998 wurde die URI -Syntax zu einer separaten Spezifikation[9] und die meisten Teile von RFCs 1630 und 1738 in Bezug auf URIs und URLs im Allgemeinen wurden von der überarbeitet und erweitert Ietf. Der neue RFC änderte die Bedeutung von "u" in "Uri" in "Uniform" von "Universal".

Im Dezember 1999, RFC 2732[10] stellte ein kleines Update für RFC 2396 zur Verfügung, sodass URIs untergebracht werden kann IPv6 Adressen. Eine Reihe von Mängel, die in den beiden Spezifikationen entdeckt wurden Roy Fielding, das gipfelte in der Veröffentlichung von IETF RFC 3986[11] Im Januar 2005. Während des Vorgangs des vorherigen Standards machte es nicht die Einzelheiten der vorhandenen URL -Programme veraltet. RFC 1738 regiert weiterhin solche Programme, sofern nicht anders abgelöst. IETF RFC 2616[12] Zum Beispiel verfeinert die http planen. Gleichzeitig veröffentlichte das IETF den Inhalt von RFC 3986 als vollständige Standard STD 66, was die Einrichtung der URI -Generikumssyntax als offizielles Internetprotokoll widerspiegelt.

Im Jahr 2001 veröffentlichte die technische Architekturgruppe der W3C (Tag) einen Leitfaden zu empfohlene Vorgehensweise und kanonische URIs zur Veröffentlichung mehrerer Versionen einer bestimmten Ressource.[13] Beispielsweise kann der Inhalt nach Sprache oder Größe unterschiedlich sein, um die Kapazität oder Einstellungen des Geräts anzupassen, das zum Zugriff auf diesen Inhalt verwendet wird.

Im August 2002, IETF RFC 3305[14] wies darauf hin, dass der Begriff "URL" trotz der weit verbreiteten öffentlichen Nutzung in naher Veralterung verblasst war und nur als Erinnerung dient, dass einige URIs als Adressen dienen, indem sie Systeme implizieren, was unabhängig von einer solchen tatsächlichen Verwendung eine Zugänglichkeit im Netzwerk impliziert. Als URI-basierte Standards wie z. Ressourcenbeschreibung Framework Machen Sie offensichtlich, die Ressourcenidentifikation muss weder das Abrufen von Ressourcenrepräsentationen über das Internet vermuten lassen, noch müssen sie netzwerkbasierte Ressourcen implizieren.

Das Semantisches Web Verwendet das HTTP -URI -Schema, um sowohl Dokumente als auch Konzepte in der realen Welt zu identifizieren, eine Unterscheidung, die Verwirrung darüber verursacht hat, wie die beiden unterscheiden können. Das Tag veröffentlichte 2005 eine E-Mail über die Lösung des Problems, das als die bekannt wurde HTTPRANGE-14-Auflösung.[15] Der W3C veröffentlichte anschließend eine Interessengruppe mit dem Titel mit dem Titel " Coole URIs für das semantische Web, was die Verwendung von erklärte Inhaltsverhandlung und die HTTP 303 Antwortcode für Umleitungen ausführlicher.[16]

Entwurf

URLs und Urnen

A Einheitlicher Ressourcenname (URN) ist eine URI, die eine Ressource mit dem Namen in einem bestimmten Namespace identifiziert. Eine Urne kann verwendet werden, um über eine Ressource zu sprechen, ohne ihren Standort zu implizieren oder wie man darauf zugreift. Zum Beispiel in der Internationale Standardbuchnummer (ISBN) System, ISBN 0-486-27557-4 identifiziert eine bestimmte Ausgabe von Shakespeares Spiel Romeo und Julia. Die Urne für diese Ausgabe wäre URN: ISBN: 0-486-27557-4. Es gibt jedoch keine Informationen darüber, wo eine Kopie dieses Buches gefunden werden kann.

A Einheitlicher Ressourcen -Locator (URL) ist eine URI, die die Mittel zur Wirkung oder Erlangung der Darstellung einer Ressource angibt, d. H. Einen primären Zugangsmechanismus und Netzwerkstandort. Zum Beispiel die URL http://example.org/wiki/main_page bezieht sich auf eine Ressource, die als identifiziert wurde /wiki/main_page, deren Darstellung in Form von Html und verwandter Code ist über die erhältlich Hypertext Transfer Protocol (http:) von einem Netzwerkhost, dessen Domainname ist Beispiel.org.

Eine Urne ist analog zum Namen einer Person, während eine URL analog zu ihrer Straßenadresse ist. Mit anderen Worten, eine Urne identifiziert ein Element und eine URL bietet eine Methode, um sie zu finden.


Technische Veröffentlichungen, insbesondere Standards, die von der erstellt wurden Ietf und von der W3creflektieren normalerweise eine Ansicht, die in a umrissen wurde W3C -Empfehlung vom 30. Juli 2001, das den Vorrang des Begriffs URI anerkennt, anstatt eine formelle Unterteilung in URL und Urne zu unterstützen.

URL ist ein nützliches, aber informelles Konzept: Eine URL ist eine Art von URI, die eine Ressource über eine Darstellung ihres primären Zugriffsmechanismus (z. B. des Netzwerks "Ort") und nicht durch einige andere Attribute identifiziert.[17]

Als solches ist eine URL einfach eine URI, die zufällig auf eine Ressource über ein Netzwerk hinweist.[a][18] In nicht-technischen Kontexten und in Software für das World Wide Web bleibt der Begriff "URL" jedoch weit verbreitet. Darüber hinaus erfolgt der Begriff "Webadresse" (der keine formale Definition hat) in nichttechnischen Veröffentlichungen häufig als Synonym für eine URI, die das verwendet http oder https Pläne. Solche Annahmen können beispielsweise zu Verwirrung führen, beispielsweise bei XML -Namespaces, die a haben visuelle Ähnlichkeit mit auflösbaren URIs.

Spezifikationen, die durch die erzeugt werden Waswg vorziehen URL Über Uriund so neuer HTML5 -APIs verwenden URL Über Uri.[19]

Standardisieren Sie den Begriff URL. URI und IRI [Internationalisierte Ressourcenkennung] sind nur verwirrend. In der Praxis wird ein einzelner Algorithmus verwendet, um sie beides zu halten, so dass es niemandem hilft. URL gewinnt auch leicht den Popularitätswettbewerb für Suchergebnisse.[20]

Während die meisten URI -Programme ursprünglich so konzipiert waren, dass sie mit einem bestimmten verwendet werden Protokollund oft den gleichen Namen, sie unterscheiden sich semantisch von Protokollen. Zum Beispiel das Schema http wird im Allgemeinen für die Interaktion mit Webressourcen Verwenden von HTTP, aber das Schema Datei hat kein Protokoll.

Syntax

Siehe auch: Liste der URI -Programme

Jeder URI beginnt mit einem Schema -Namen, der sich auf eine Spezifikation für die Zuweisung von Kennungen innerhalb dieses Schemas bezieht. Daher ist die URI -Syntax ein föderiertes und erweiterbares Namenssystem, bei dem die Spezifikation jedes Schemas die Syntax und Semantik von Identifikatoren mit diesem Schema weiter einschränken kann. Die URI -generische Syntax ist ein Supersatz der Syntax aller URI -Schemata. Es wurde zuerst in definiert in RFC 2396, veröffentlicht im August 1998,,[9] und abgeschlossen in RFC3986, veröffentlicht im Januar 2005.[21]

Das URI Generische Syntax besteht aus einer hierarchischen Sequenz von fünf Komponenten:[22] 

Uri = Schema ":" ["//" Autorität] Pfad ["?" Abfrage] ["#" Fragment]

wo sich die Autoritätskomponente in drei unterteilt Unterkomponenten:

Authority = [UserInfo "@"] Host [":" Port]

Dies wird in a dargestellt Syntaxdiagramm wie:

URI syntax diagram

Der URI umfasst:

  • Ein nicht leeres planen Komponente gefolgt von einem Dickdarm (:), bestehend aus einer Folge von Zeichen, die mit einem Buchstaben beginnt und von einer beliebigen Kombination von Buchstaben, Ziffern plus (gefolgt von einer beliebigen Kombination von Buchstaben (), plus (+), Zeitraum (.) oder Bindestrich (-). Obwohl die Schemata in der Fall sind, sind die kanonischen Form in Kleinbuchstaben und Dokumente, die Schemata angeben, müssen dies mit Kleinbuchstaben ausführen. Beispiele für beliebte Programme sind http, https, ftp, Mailto, Datei, Daten und IRC. URI -Programme sollten bei der registriert werden Internet zugewiesene Zahlen Autorität (IANA), obwohl nicht registrierte Schemata in der Praxis verwendet werden.[b]
  • Ein optionales Behörde Komponente vor zwei Schrägstrichen (//), bestehend:
    • Ein optionales Benutzerinformation subkomponent, der aus a bestehen kann Nutzername und ein optionales Passwort Vorangegangen von einem Dickdarm (:), gefolgt von einem At -Symbol (@). Verwendung des Formats Benutzername Passwort In der UserInfo -Unterkomponente wird aus Sicherheitsgründen veraltet. Bewerbungen sollten nicht als klare Text nach dem ersten Dickdarm (:) In einem userInfo subcomponent gefunden, es sei denn, die Daten nach dem Dickdarm sind die leere Zeichenfolge (was kein Passwort anzeigt).
    • A Gastgeber subcomponent, bestehend aus einem registrierten Namen (einschließlich, aber nicht beschränkt auf a Hostname) oder an IP Adresse. IPv4 Adressen müssen in sein Dot-Decimal Notation, und IPv6 Adressen müssen in Klammern eingeschlossen sein ([]).[24][c]
    • Ein optionales Hafen Subcomponent vorausgeht von einem Dickdarm (:).
  • A Weg Komponente, bestehend aus einer Sequenz von Pfadsegmenten, die durch einen Schrägstrich getrennt sind (/). Ein Pfad ist immer für einen URI definiert, obwohl der definierte Pfad leer ist (Nulllänge). Ein Segment kann auch leer sein, was zu zwei aufeinanderfolgenden Schrägstrichen führt (//) in der Pfadkomponente. Eine Pfadkomponente kann genau an a ähneln oder zuordnen Dateisystempfad bedeutet aber nicht immer eine Beziehung zu einem. Wenn eine Autoritätskomponente vorhanden ist, muss die Pfadkomponente entweder leer sein oder mit einem Schrägstrich beginnen (/). Wenn eine Autoritätskomponente nicht vorhanden ist, kann der Pfad nicht mit einem leeren Segment beginnen - dh mit zwei Schrägstrichen (//) - Da die folgenden Zeichen als Autoritätskomponente interpretiert würden.[26]
Durch Konvention in http und https URIS, der letzte Teil von a Weg benannt Pathinfo Und es ist optional. Es besteht aus null oder mehr Pfadsegmenten, die sich nicht auf einen vorhandenen physischen Ressourcennamen beziehen (z. B. eine Datei, ein internes Modulprogramm oder ein ausführbares Programm), sondern auf einen logischen Teil (z. B. einen Befehl oder einen Qualifikationsteil), der dies muss getrennt an den ersten Teil des Pfades übergeben werden, der ein ausführbares Modul oder ein Programm identifiziert, das von a verwaltet wird Webserver; Dies wird häufig verwendet, um dynamische Inhalte (ein Dokument usw.) auszuwählen oder ihn wie angefordert zu maßnen (siehe auch: CGI und Path_info usw.).
Beispiel:
URI: "http://www.example.com/questions/3456/my-document"
wo: "/questions" ist der erste Teil der Weg (ein ausführbares Modul oder Programm) und "/3456/my-document" ist der zweite Teil der Weg genannt Pathinfo, das an das ausführbare Modul oder das benannte Programm übergeben wird "/questions" So wählen Sie das angeforderte Dokument aus.
Ein http oder https URI mit a Pathinfo Teil ohne a Anfrage Teil kann auch als 'bezeichnet werden'saubere URL"Wessen letzter Teil kann ein" sein "Schnecke'.
Abfrageteiler Beispiel
Et-Zeichen (&)) key1 = value1 & key2 = value2
Semikolon (;)[d] key1 = value1; key2 = value2
  • Ein optionales Anfrage Komponente vor einem Fragezeichen (?) mit a Abfragezeichenfolge von nicht-hierarchischen Daten. Seine Syntax ist nicht gut definiert, aber durch Konvent ist am häufigsten eine Abfolge von Attribut -Wert -Paare getrennt durch a Abgrenzer.
  • Ein optionales Fragment Komponente voraus a Hash (#). Das Fragment enthält a Fragment -Kennung Bereitstellung von Anweisungen zu einer sekundären Ressource, z. B. einem Abschnitt in einem Artikel, der vom Rest des URI identifiziert wurde. Wenn die primäre Ressource eine ist Html Dokument, das Fragment ist oft ein Ich würde Attribut Von einem bestimmten Element und Webbrowsern werden dieses Element in Sichtweise scrollen.

Datenzeichenfolgen Oktetten Innerhalb eines URI werden als Zeichen dargestellt. Erlaubte Charaktere innerhalb eines URI sind die ASCII Zeichen für die Kleinbuchstaben und Großbuchstaben der Moderne englisches Alphabet, das arabische Ziffern, Bindestrich, Zeitraum, unterstreichen, und Tilde.[28] Oktetten, die von einem anderen Charakter dargestellt werden, muss sein prozentualcodiert.

Des ASCII -Zeichensets, die Zeichen : /? # [] @ sind für die Verwendung als Abgrenzer der generischen URI-Komponenten reserviert und müssen prozentualcodiert sein-zum Beispiel, %3f für ein Fragezeichen.[29] Die Charaktere ! $ & '() * +,; = sind durch generische URI -Syntax zugelassen, um in den Benutzerinformationen, im Host und in den Pfad als Abgrenzer nichtcodiert zu werden.[24][30] Zusätzlich, : und @ kann innerhalb des Weges, der Abfrage und des Fragments uneingeschränkt erscheinen; und ? und / kann als Daten innerhalb der Abfrage oder des Fragments uneingeschränkt erscheinen.[30][31]

Beispiel uris

Die folgende Abbildung zeigt Beispiel -URIs und deren Komponententeile.

  Benutzerinformation  Gastgeber  Hafen  ┌──┴──┐ " ┌┴┐   https: //[email protected]: 123/Forum/Fragen/? Tag = networking & order = neuestes#Top └─┬─┘  "" " └┬┘  planen  Behörde  Weg  Anfrage  Fragment   ldap: // [2001: db8 :: 7]/c = gb? ─────┘ Scheme Authority Path Query mailto: [email protected] └─┬─┘ └──┬ ┬wort: └wort: └ └wort: └ └wort: └ └wort: └ └wort: └ └ └ ┬ ┬wort: └ └wort └wort: └ └ wortto └ └ └ └wort: └ └ └ └ wortto: └ └ └──┬───schung " comp.infosystems.www.servers.unix └┬─┘ └wort ─wort ─führ +1-816-555-1212 └┬┘ └wort └wort └wort └ └wort. ┬─── Rot Behörde Pfad Pfad Urne: Oase: Namen: Spezifikation: Docbook: DTD: XML: 4.1.2 └┬┘ └wort ───┬anz wortesersonenwort - ─────schung "

Dois (Digitale Objektkennung) passen in die System handhaben und passen in das URI -System, wie durch geeignete Syntax erleichtert.

URI -Referenzen

A URI -Referenz ist entweder ein URI oder ein Relative Referenz Wenn es nicht mit einer Schemekomponente beginnt, gefolgt von einem Dickdarm (:).[32] Ein Pfadsegment, das einen Dickdarmcharakter enthält (z. B.,, Foo: Bar) Kann nicht als erster Pfadsegment einer relativen Referenz verwendet werden, wenn seine Pfadkomponente nicht mit einem Schrägstrich beginnt (/), wie es mit einer Schema -Komponente verwechselt werden würde. Ein solches Pfadsegment muss ein DOT -Pfadsegment vorausgehen (z. B.,, ./foo:bar).[33]

Webdokument Markup -Sprachen Verwenden Sie häufig URI -Verweise, um auf andere Ressourcen wie externe Dokumente oder bestimmte Teile desselben logischen Dokuments zu verweisen:[34]

  • in Htmlder Wert der src Attribut der img Element liefert eine URI -Referenz, ebenso wie der Wert der href Attribut der a oder Verknüpfung Element;
  • in Xml, das Systemkennung erscheinen nach dem SYSTEM Schlüsselwort in a DTD ist eine fragmentlose URI -Referenz;
  • in Xsltder Wert der href Attribut der XSL: Import Element/Anweisung ist eine URI -Referenz; Ebenso das erste Argument an die dokumentieren() Funktion.
https://example.com/path/resource.txt#fragment //example.com/path/resource.txt /path/resource.txt path/ressourcen.txt ../resource.txt ./resource.txt Resource. txt #fragment

Auflösung

Lösung eine URI -Referenz gegen a Basis -Uri führt in a Ziel Uri. Dies impliziert, dass der Basis -URI existiert und ein ist Absolute Uri (Ein URI ohne Fragmentkomponente). Die Basis -URI kann in der Reihenfolge der Vorrang erhalten werden, aus:[35]

  • die Referenz URI selbst, wenn es sich um ein URI handelt;
  • der Inhalt der Darstellung;
  • die Entität, die die Darstellung einhört;
  • die URI, die für das tatsächliche Abrufen der Darstellung verwendet wird;
  • der Kontext der Anwendung.

Innerhalb einer Darstellung mit einem gut definierten Basis -URI von

http: // a/b/c/d; p? q

Eine relative Referenz wird wie folgt auf seine Ziel -URI gelöst:[36] 

"G: H" -> "G: H" "G" -> "http: // a/b/c/g" "./g" -> "http: // a/b/c/g" "g/" -> "http: // a/b/c/g/" "/g" -> "http: // a/g" "// g" -> "http: // g" " y " ->" http: // a/b/c/d; p? y "" g? y " ->" http: // a/b/c/g? y "" #S " -> "http: // a/b/c/d; p? q#s" "g#s" -> "http: // a/b/c/g#s" "g? y#S" -> "http: // a/b/c/g? /b/c/g; x "" g; x? y#s " ->" http: // a/b/c/g; x? y#s "" " ->" http: // a// b/c/d; p? q "". -> "http: // a/b/c/" "./" -> "http: // a/b/c/" ".." -> "http: // a/b/" ". ./ " ->" http: // a/b/"" ../g " ->" http: // a/b/g "" ../ .. " ->" http: // a// "" ../../ " ->" http: // a/"" ../../g " ->" http: // a/g "

URL MUNGING

URL -Munding ist eine Technik, mit der a Befehl ist an eine URL angehängt, normalerweise am Ende nach einem "?" Zeichen. Es wird üblicherweise in verwendet Webdav als Mechanismus, um Funktionalität zu hinzufügen Http. In einem Versionsversionssystem zum Beispiel, um einer URL einen "Checkout" -Fehl hinzuzufügen, ist es als geschrieben als http://editing.com/resource/file.php?command=checkout. Es hat den Vorteil, dass beide einfach sind für CGI -Parser und fungiert auch als Vermittler zwischen HTTP und zugrunde liegender Ressource in diesem Fall.[37]

Beziehung zu XML -Namespaces

Im Xml, a Namespace ist eine abstrakte Domäne, in die eine Sammlung von Element- und Attributnamen zugewiesen werden kann. Der Namespace -Name ist eine Zeichenzeichenfolge, die sich an die generische URI -Syntax halten muss.[38] Der Name wird jedoch im Allgemeinen nicht als URI angesehen,[39] Weil die URI -Spezifikation die Entscheidung nicht nur auf lexikalischen Komponenten, sondern auch auf der beabsichtigten Verwendung basiert. Ein Namespace -Name impliziert nicht unbedingt die Semantik von URI -Schemata; Zum Beispiel ein Namespace -Name, der mit beginnt mit http: kann keine Konnotation mit der Verwendung des Http.

Ursprünglich könnte der Namespace-Name mit der Syntax einer nicht leeren URI-Referenz übereinstimmen, aber die Verwendung relativer URI-Referenzen wurde durch das W3C veraltet.[40] Eine separate W3C -Spezifikation für Namespaces in XML 1.1 erlaubt Internationalisierte Ressourcenkennung (IRI) Verweise, um zusätzlich zu URI -Referenzen als Grundlage für Namespace -Namen zu dienen.[41]

Siehe auch

Anmerkungen

  1. ^ Ein im Jahr 2002 von einer gemeinsamer W3C/IETF -Arbeitsgruppe veröffentlichter Bericht zielte darauf ab, die unterschiedlichen Ansichten in der IETF und W3C über die Beziehung zwischen den verschiedenen 'Ur -Begriffen und -standards zu normalisieren. Obwohl dies nicht als vollständiger Standard von beiden Organisationen veröffentlicht wurde, ist es die Grundlage für das oben genannte gemeinsame Verständnis geworden und hat seitdem viele Standards informiert.
  2. ^ Die Verfahren zur Registrierung neuer URI -Programme wurden ursprünglich 1999 von definiert von RFC 2717, und sind jetzt definiert von RFC7595, veröffentlicht im Juni 2015.[23]
  3. ^ Für URIs, die sich auf Ressourcen im World Wide Web beziehen, erlauben einige Webbrowser .0 Teile der DOT-Dezimal-Notation, die fallen gelassen werden sollen, oder die zu verwendenden IP-Adressen von rohen Ganzzahl.[25]
  4. ^ Historisch RFC 1866 (veraltet von RFC2854) ermutigt CGI -Autoren, zu unterstützen ';' '; zusätzlich zu '&'.[27]

Verweise

  1. ^ Palmer, Sean. "Die frühe Geschichte von HTML". Infomesh.net. Abgerufen 2020-12-06.
  2. ^ "W3 -Namensschemata". www.w3.org. 1992. Abgerufen 2020-12-06.
  3. ^ "Verfahren der vierundzwanzigsten Internet Engineering Task Force" (PDF). p. 193. Abgerufen 2021-07-27.
  4. ^ "Verfahren der fünfundzwanzigsten Internet Engineering Task Force" (PDF). p. 501. Abgerufen 2021-07-27.
  5. ^ Berners-Lee, Tim (Juni 1994). "Universelle Ressourcenkennungen in www". Netzwerkarbeitsgruppe. Abgerufen 2020-12-06. {{}}: Journal zitieren erfordert |journal= (Hilfe)
  6. ^ Berners-Lee, Tim (Dezember 1994). "Anfrage für Kommentare: 1738: Uniform Resource Locators (URL)". Tools.ietf.org/html. Abgerufen 2020-12-06.
  7. ^ Moats, R. (Mai 1997). "Anfrage für Kommentare: 2141: Urnsyntax". Tools.ietf.org. Abgerufen 2020-12-06.
  8. ^ Berners-Lee, Tim (August 1998). "RFC 2396: Einheitliche Ressourcenidentifikatoren (URI): generische Syntax". Tools.ietf.org. Abgerufen 2020-12-06.
  9. ^ a b RFC 2396 (1998).
  10. ^ Hinden, R. (Dezember 1999). "RFC 2732: Format für buchstäbliche IPv6 -Adressen in URLs". Tools.ietf.org. Abgerufen 2020-12-06.
  11. ^ Berners-Lee, Tim (Januar 2005). "RFC 3986: Einheitliche Ressourcenkennung (URI): generische Syntax". Tools.ietf.org. Abgerufen 2020-12-06.
  12. ^ Fielding, R. (Juni 1999). "RFC 2616: Hypertext -Transferprotokoll - HTTP/1.1". Tools.ietf.org. Abgerufen 2020-12-06.
  13. ^ Raman, T.V. (2006-11-01). "Bei der Verknüpfung alternativer Darstellungen, um die Entdeckung und Veröffentlichung zu ermöglichen". www.w3.org. Abgerufen 2020-12-06.
  14. ^ Mahlzeiten, M. (August 2002). "RFC 3305: Einheitliche Ressourcenkennungen (URIs), URLs und einheitliche Ressourcennamen". Tools.ietf.org. Abgerufen 2020-12-06.
  15. ^ Fielding, Roy (2005-06-18). "[httprange-14] gelöst". lists.w3.org. Abgerufen 2020-12-06.
  16. ^ Sauermann, Leo (Dezember 2008). "Coole URIS für das semantische Web". www.w3.org. Abgerufen 2020-12-06.
  17. ^ URI Planning Interest Group, W3C/IETF (September 2001). "URIS, URLs und Urnen: Klarstellungen und Empfehlungen 1.0". www.w3.org. W3C/IETF. Abgerufen 2020-12-08.
  18. ^ Joint W3C/IETF URI -Planungs -Interessengruppe (2002).
  19. ^ "URL Standard: 6.3. URL -APIs an anderer Stelle".
  20. ^ "URL Standard: Ziele".
  21. ^ RFC 3986 (2005).
  22. ^ RFC 3986, Abschnitt 3 (2005).
  23. ^ IETF (2015).
  24. ^ a b RFC 3986 (2005), §3.2.2.
  25. ^ Lawrence (2014).
  26. ^ RFC 2396 (1998)§3.3.
  27. ^ RFC 1866 (1995)§8.2.1.
  28. ^ RFC 3986 (2005)§2.
  29. ^ RFC 3986 (2005)§2.2.
  30. ^ a b RFC 3986 (2005)§3.3.
  31. ^ RFC 3986 (2005)§3.4.
  32. ^ RFC 3986 (2005)§4.1.
  33. ^ RFC 3986 (2005)§4.2.
  34. ^ RFC 3986 (2005)§4.4.
  35. ^ RFC 3986 (2005)§5.1.
  36. ^ RFC 3986 (2005)§5.4.
  37. ^ Whitehead 1998, p. 38.
  38. ^ Morrison (2006).
  39. ^ Harold (2004).
  40. ^ W3C (2009).
  41. ^ W3C (2006).

Weitere Lektüre

Externe Links