Uniform Resource Identifier - Wikipedia

A Uniform Resource Identifier ( URI ) ist eine Zeichenfolge, die eine bestimmte Ressource eindeutig identifiziert. Um die Einheitlichkeit zu gewährleisten, folgen alle URIs einem vordefinierten Satz von Syntaxregeln, behalten jedoch auch die Erweiterbarkeit durch ein getrennt definiertes hierarchisches Namensschema (z. B. http: // ).

Eine solche Identifizierung ermöglicht die Interaktion mit Darstellungen der Ressource über ein Netzwerk, normalerweise das World Wide Web, unter Verwendung spezifischer Protokolle. Schemata, die eine konkrete Syntax angeben, und zugehörige Protokolle definieren jeden URI. Die gebräuchlichste Form der URI ist der Uniform Resource Locator (URL), der häufig informell als Webadresse bezeichnet wird. Seltener bei der Verwendung ist der Uniform Resource Name (URN), der URLs ergänzen soll, indem er einen Mechanismus zur Identifizierung von Ressourcen in bestimmten Namespaces bereitstellt.

URLs und URNs [ edit ]

Ein Uniform Resource Name (URN) ist ein URI, der eine Ressource anhand des Namens in einem bestimmten Namespace identifiziert. Ein URN kann verwendet werden, um über eine Ressource zu sprechen, ohne den Standort oder den Zugriff darauf zu bestimmen. Im International Standard Book Number (ISBN) -System identifiziert ISBN 0-486-27557-4 beispielsweise eine bestimmte Ausgabe von Shakespeares Stück Romeo und Julia . Die URN für diese Ausgabe wäre urne: isbn: 0-486-27557-4 . Es gibt jedoch keine Informationen darüber, wo Sie eine Kopie dieses Buches finden können.

Ein Uniform Resource Locator (URL) ist ein URI, der die Mittel angibt, um auf die Darstellung einer Ressource zu reagieren oder diese zu erhalten, d. H. Sowohl den primären Zugriffsmechanismus als auch den Netzwerkstandort anzugeben. Beispielsweise bezieht sich die URL http://example.org/wiki/Main_Page auf eine Ressource, die als / wiki / Main_Page bezeichnet wird und deren Darstellung in Form von HTML und zugehörigem Code ist über das Hypertext Transfer Protocol ( http: ) von einem Netzwerkhost erhältlich, dessen Domänenname example.org lautet.

Eine URN kann mit dem Namen einer Person verglichen werden, während eine URL mit ihrer Straßenadresse verglichen werden kann. Mit anderen Worten, eine URN identifiziert ein Element und eine URL bietet eine Methode, um es zu finden.

Technische Veröffentlichungen, insbesondere Standards, die von der IETF und vom W3C erstellt wurden, spiegeln normalerweise eine in einer W3C-Empfehlung von 2001 umrissene Ansicht wider, die den Vorrang des Begriffs URI anerkennt, anstatt eine formale Unterteilung in URL und URN zu unterstützen.

“

URL ist ein nützliches, aber informelles Konzept: Eine URL ist ein URI-Typ, der eine Ressource anhand einer Darstellung ihres primären Zugriffsmechanismus (z. B. ihres Netzwerk- "Standorts") identifiziert, und nicht anhand einiger anderer Attribute, über die sie verfügt.

”

Daher ist eine URL einfach ein URI, der auf eine Ressource über ein Netzwerk verweist. ^[a] In nichttechnischen Kontexten und in Software für das World Wide Web bleibt der Begriff "URL" jedoch weit verbreitet . Darüber hinaus kommt der Begriff "Webadresse" (der keine formale Definition hat) häufig in nicht-technischen Publikationen als Synonym für einen URI vor, der die http oder https https verwendet. Solche Annahmen können beispielsweise bei XML-Namespaces, die eine visuelle Ähnlichkeit mit auflösbaren URIs aufweisen, zu Verwirrung führen.

Von WHATWG erstellte Spezifikationen bevorzugen URL über URI und so verwenden neuere HTML5-APIs URL U . [4]

“

Standardisieren Sie den Begriff URL. URI und IRI [Internationalized Resource Identifier] sind nur verwirrend. In der Praxis wird für beide ein einzelner Algorithmus verwendet, sodass es für niemanden hilfreich ist, sie voneinander zu unterscheiden. URL gewinnt auch leicht den Beliebtheitswettbewerb für Suchergebnisse. [5]

"

Obwohl die meisten URI-Schemata ursprünglich für die Verwendung mit einem bestimmten Protokoll entwickelt wurden und häufig denselben Namen haben, unterscheiden sie sich semantisch von Protokollen. Beispielsweise wird das Schema http im Allgemeinen für die Interaktion mit Webressourcen unter Verwendung von HTTP verwendet, aber die Schema -Datei hat kein Protokoll.

Generische Syntax [ edit ]

Definition [ edit ]

Jeder URI beginnt mit einem Schemanamen, der auf eine Zuordnungsspezifikation verweist Identifikatoren innerhalb dieses Schemas. Somit ist die URI-Syntax ein eingebundenes und erweiterbares Benennungssystem, in dem die Spezifikation jedes Schemas die Syntax und Semantik von Bezeichnern, die dieses Schema verwenden, weiter einschränken kann. Die generische URI-Syntax ist eine Obermenge der Syntax aller URI-Schemata. Sie wurde erstmals in Request for Comments (RFC) 2396, veröffentlicht im August 1998, definiert und in RFC 3986 finalisiert, veröffentlicht im Januar 2005.

Die generische URI-Syntax besteht aus einer hierarchischen Folge von fünf Komponenten :

 URI = Schema: [//authority] Pfad [?query][#fragment] 

wo sich die Komponente der Behörde in drei Teilkomponenten teilt:

 Authority = [userinfo@] Host [:port] 

Dies wird in einem Syntaxdiagramm dargestellt als:

Der URI umfasst:

• Eine nicht leere Komponente gefolgt von einem Doppelpunkt (: ), bestehend aus einer Folge von Zeichen, die mit einem Buchstaben beginnen und gefolgt von einer beliebigen Kombination von Buchstaben, Ziffern und Ziffern ( + ), Zeitraum (. ) oder Bindestrich ( - ). Obwohl bei Schemas die Groß- und Kleinschreibung nicht berücksichtigt wird, ist die kanonische Form Kleinbuchstaben, und Dokumente, in denen Schemata angegeben sind, müssen dies mit Kleinbuchstaben tun. Beispiele für gängige Schemata sind http https ftp mailto datei daten . und irc . URI-Schemata sollten bei der Internet Assigned Numbers Authority (IANA) registriert werden, obwohl in der Praxis nicht registrierte Schemata verwendet werden. [b]
• Eine optionale -Agentur der zwei Schrägstriche vorangestellt sind ( // ]), bestehend aus:
  • Eine optionale userinfo -Unterkomponente, die aus einem Benutzernamen und einem optionalen Kennwort bestehen kann, dem ein Doppelpunkt vorangestellt ist (: ), gefolgt von einem at-Symbol ( @ [19459007)]). Die Verwendung des Formats Benutzername: Kennwort in der Userinfo-Unterkomponente wird aus Sicherheitsgründen nicht mehr unterstützt. Anwendungen sollten Daten, die nach dem ersten Doppelpunkt (: ) in einer Userinfo-Unterkomponente gefunden wurden, nicht als Klartext wiedergeben, es sei denn, die Daten hinter dem Doppelpunkt sind leere Zeichenfolgen (die kein Kennwort angeben).
  • Optional (19459003) ] host Unterkomponente, bestehend aus einem registrierten Namen (einschließlich, aber nicht beschränkt auf einen Hostnamen) oder einer IP-Adresse. IPv4-Adressen müssen in Punkt-Dezimal-Notation angegeben werden, und IPv6-Adressen müssen in Klammern stehen ([]). ^[c]
  • Eine optionale -Portkomponente der ein Doppelpunkt vorangestellt ist (19459006]: ).
• Ein Pfad -Komponente, bestehend aus einer Folge von durch einen Schrägstrich getrennten Pfadsegmenten ( / ). Ein Pfad ist immer für eine URI definiert, der definierte Pfad kann jedoch leer sein (Länge Null). Ein Segment kann auch leer sein, was zu zwei aufeinander folgenden Schrägstrichen ( // ) in der Pfadkomponente führt. Eine Pfadkomponente kann einem Dateisystempfad ähneln oder genau diesem entsprechen, impliziert jedoch nicht immer eine Beziehung zu einem Pfad. Wenn eine Berechtigungskomponente 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, das heißt mit zwei Schrägstrichen ( // ), da die folgenden Zeichen als Autoritätskomponente interpretiert werden. Der letzte Abschnitt des Pfads kann als "Slug" bezeichnet werden.

• Eine optionale -Query -Komponente, der ein Fragezeichen vorangestellt ist (? ). enthält eine Abfragezeichenfolge nicht hierarchischer Daten. Seine Syntax ist nicht klar definiert, aber meistens ist dies meist eine Folge von Attribut-Wert-Paaren, die durch ein Trennzeichen getrennt sind.
• Eine optionale -Fragment-Komponente der ein Hash vorangestellt ist ( # ). Das Fragment enthält eine Fragmentkennung, die die Richtung zu einer sekundären Ressource angibt, beispielsweise eine Abschnittsüberschrift in einem Artikel, die vom Rest des URI identifiziert wird. Wenn die primäre Ressource ein HTML-Dokument ist, ist das Fragment häufig ein id -Attribut eines bestimmten Elements, und Webbrowser rollen dieses Element in die Ansicht.

Zeichenketten von Datenoktetten innerhalb einer URI werden als dargestellt Zeichen. Zulässige Zeichen innerhalb einer URI sind die ASCII-Zeichen für die Klein- und Großbuchstaben des modernen englischen Alphabets, die arabischen Ziffern, Bindestrich, Punkt, Unterstrich und Tilde. Oktette, die von einem anderen Zeichen dargestellt werden, müssen in Prozent kodiert sein.

Vom ASCII-Zeichensatz sind die Zeichen : /? # [ ] @ sind für die Verwendung als Trennzeichen der generischen URI-Komponenten reserviert und müssen in Prozent codiert sein, z. B. % 3F für ein Fragezeichen. Die Zeichen ! $ & '() * +,; = sind durch die generische URI-Syntax zulässig, um unkodiert in den Benutzerinformationen, dem Host und dem Pfad als Trennzeichen verwendet zu werden. Außerdem können : und @ im Pfad, in der Abfrage und im Fragment unverschlüsselt erscheinen. und ? und / erscheinen möglicherweise als Daten in der Abfrage oder im Fragment unverschlüsselt.

Beispiele [ edit

Die folgende Abbildung wird angezeigt Beispiel-URIs und ihre Komponenten.

 Benutzerinfo-Host-Port           ┌─┴────┐ ┌────┴────────┐ ┌┴┐   https://john.doe@www.example.com: 123 / forum / questions /? tag = netzwerk & auftrag = neuestes # top   └─┬─┘ └───────┬────────────────────┘└─┬──────────── ─┘└──┬───────────────────────┘└┬─┘   Fragment der Schema-Berechtigungspfadabfrage    ldap: // [2001:db8::7] / c = GB "objectClass" eins   └─┬┘ └───────┬─────┘└─┬─┘ └──────┬──────┘  Schema Berechtigungspfadabfrage    mailto: John.Doe@example.com   └──┬─┘ └─────────┬────────┘   Schemapfad    news: comp.infosystems.www.servers.unix   └─┬┘ └───────────────┬───────────────┘  Schemapfad    Tel: + 1-816-555-1212   └┬┘ └──────┬──────┘ Schemapfad    telnet: //192.0.2.16: 80 /   └──┬─┘ └──────┬──────┘│   Schema Autoritätspfad    urn: oasis: namen: spezifikation: docbook: dtd: xml: 4.1.2   └┬┘ └──────────────────────┬──────────────────────┘ Schemapfad 

URI-Referenzen [ edit ]

Definition [ bearbeiten ]

A URI-Referenz ist entweder eine URI, oder eine relative Referenz von wenn sie nicht mit einer Schemakomponente beginnt, auf die ein Doppelpunkt folgt (: ). Ein Pfadsegment, das einen Doppelpunkt enthält (z. B. foo: bar ), kann nicht als erstes Pfadsegment einer relativen Referenz verwendet werden, wenn seine Pfadkomponente nicht mit einem Schrägstrich beginnt ( / [19459007)]), da es mit einer Schemakomponente verwechselt würde. Einem solchen Pfadsegment muss ein Punktpfadsegment vorangehen (z. B. ./foo: bar ).

Web-Dokument-Auszeichnungssprachen verwenden häufig URI-Verweise, um auf andere Ressourcen wie externe Dokumente oder zu verweisen bestimmte Teile desselben logischen Dokuments:

• in HTML, der Wert des Attributs src des Elements img liefert eine URI-Referenz, ebenso wie der Wert des . href -Attribut des Elements ein - oder -Link ;
• in XML ist die Systemkennung, die nach dem Schlüsselwort SYSTEM in einer DTD erscheint, fragmentlos URI-Referenz;
• in XSLT ist der Wert des href -Attributs des xsl: import -Elements / Befehls eine URI-Referenz; ebenso das erste Argument der document () -Funktion.

Beispiele [ edit ]

 https://example.com/path/resource.txt# Fragment //example.com/pfad/resource.txt /path/resource.txt Pfad / resource.txt /path/resource.txt ../resource.txt ./resource.txt resource.txt #Fragment 

URI-Auflösung [ edit ]

Definition [ edit ]

Eine absolute URI ist eine URI mit Nein Fragmentkomponente.

Das Auflösen einer URI-Referenz gegen einen Basis-URI führt zu einem Ziel-URI . Dies bedeutet, dass der Basis-URI existiert und ein absoluter URI ist. Die Basis-URI kann in der Reihenfolge ihrer Priorität erhalten werden aus:

• der Referenz-URI selbst, wenn es eine URI ist,
• der Inhalt der Repräsentation;
• die Entität, die die Repräsentation einkapselt;
• die URI wird für das tatsächliche Abrufen der Repräsentation verwendet;
• der Kontext der Anmeldung.

Beispiele [ edit ]

Innerhalb einer Repräsentation mit einer genau definierten Basis-URI von

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

Eine relative Referenz zu ihrem Ziel-URI wird wie folgt aufgelöst:

 "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? y # s" "; x" -> "http: // a / b / c /; x" "g; x" -> "http: // a / 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" 

Geschichte [ edit ]

Benennen, Adressieren und Identifizieren von Ressourcen [ edit ]

URIs und URLs haben eine gemeinsame Geschichte. Im Jahr 1994 führten Tim Berners-Lees Vorschläge für Hypertext implizit die Idee einer URL als kurzen String ein, der eine Ressource darstellt, die das Ziel eines Hyperlinks ist. Zu dieser Zeit bezeichnete man es als "Hypertextname" oder "Dokumentenname".

In den nächsten dreieinhalb Jahren, als sich die Kerntechnologien des World Wide Web (HTML, HTTP und Webbrowser) entwickelten, musste eine Zeichenfolge, die eine Adresse für eine Ressource lief, von einer Zeichenfolge unterschieden werden, die lediglich eine Ressource benannte aufgetaucht. Obwohl noch nicht formal definiert, repräsentierte der Begriff Uniform Resource Locator den ersten, und der umstrittenere Uniform Resource Name kam für letzteren.

Während der Debatte über die Definition von URLs und URNs wurde deutlich, dass die beiden Begriffe, die durch die Begriffe verkörpert wurden, lediglich Aspekte des grundlegenden, übergreifenden Ressourcenbegriffs waren . Im Juni 1994 veröffentlichte die IETF das RFC 1630 von Berners-Lee, das erste Request for Comments, das das Vorhandensein von URLs und URNs anerkannte, und, was noch wichtiger ist, eine formale Syntax für Universal Resource Identifiers definiert - URL-like Strings, deren genaue Syntax und Semantik von ihren Schemata abhängt. Darüber hinaus versuchte dieser RFC, die Syntax der zu dieser Zeit verwendeten URL-Schemata zusammenzufassen. Außerdem wurde das Vorhandensein relativer URLs und Fragmentkennungen bestätigt, jedoch nicht standardisiert.

Verfeinerung der Spezifikationen [ edit ]

Im Dezember 1994 definierte RFC 1738 die relativen und absoluten URLs formal, verfeinerte die allgemeine URL-Syntax und definierte, wie relative URLs in absolute Form aufgelöst werden. und die URL-Schemata dann besser aufgeschlüsselt als verwendet. Die vereinbarte Definition und Syntax der URNs musste bis zur Veröffentlichung von RFC 2141 im Mai 1997 warten.

Mit der Veröffentlichung von RFC 2396 im August 1998 wurde aus der URI-Syntax eine separate Spezifikation, und die meisten Teile der RFCs 1630 und 1738, die sich auf URIs und URLs im Allgemeinen beziehen, wurden von der IETF überarbeitet und erweitert. Der neue RFC hat die Bedeutung von "U" in "URI" in "Uniform" von "Universal" geändert.

Im Dezember 1999 stellte RFC 2732 eine geringfügige Aktualisierung von RFC 2396 bereit, sodass URIs IPv6-Adressen aufnehmen konnten. Eine Reihe von Mängeln, die bei den beiden Spezifikationen festgestellt wurden, führte zu einer Gemeinschaftsaktion, die von RF Field 2396, Mitautor Roy Fielding, koordiniert wurde, die im Januar 2005 mit der Veröffentlichung von RFC 3986 gipfelte. Obwohl der frühere Standard überholt wurde, wurden die Details nicht veröffentlicht bestehende URL-Schemas veraltet; RFC 1738 regelt solche Schemata weiterhin, sofern nichts anderes ersetzt wird. RFC 2616 verfeinert beispielsweise das Schema http . Gleichzeitig veröffentlichte die IETF den Inhalt von RFC 3986 als den vollständigen Standard-Standard-Standardentscheidungscode 66, was die Etablierung der generischen URI-Syntax als offizielles Internetprotokoll widerspiegelt.

Im Jahr 2001 veröffentlichte die Technical Architecture Group (TAG) des W3C einen Leitfaden zu bewährten Methoden und kanonischen URIs zum Veröffentlichen mehrerer Versionen einer bestimmten Ressource. Beispielsweise kann sich der Inhalt je nach Sprache oder Größe unterscheiden, um die Kapazität oder Einstellungen des Geräts anzupassen, das für den Zugriff auf diesen Inhalt verwendet wird.

Im August 2002 wies RFC 3305 darauf hin, dass der Begriff "URL" trotz weitverbreiteter öffentlicher Nutzung fast veraltet war und nur daran erinnert, dass einige URIs als Adressen fungieren, da sie Schemata haben, die auf die Netzwerkzugänglichkeit hinweisen eine solche tatsächliche Verwendung. Da URI-basierte Standards wie das Resource Description Framework deutlich machen, muss die Identifizierung von Ressourcen weder den Abruf von Ressourcendarstellungen über das Internet andeuten noch auf netzwerkbasierte Ressourcen schließen lassen.

Das Semantic Web verwendet das HTTP-URI-Schema, um sowohl Dokumente als auch Konzepte in der realen Welt zu identifizieren. Diese Unterscheidung hat zu Verwirrung bei der Unterscheidung der beiden geführt. Die TAG veröffentlichte 2005 eine E-Mail zur Lösung des Problems, die als httpRange-14-Auflösung bekannt wurde. Das W3C veröffentlichte daraufhin eine Interest Group Note mit dem Titel Cool URIs for Semantic Web in der die Verwendung von Inhaltsverhandlungen und der HTTP 303-Antwortcode für Umleitungen detaillierter erläutert wurden.

Beziehung zu XML-Namespaces [ edit ]

Ein Namespace ist in XML eine abstrakte Domäne, der eine Sammlung von Element- und Attributnamen zugeordnet werden kann. Der Namespace-Name ist eine Zeichenfolge, die der generischen URI-Syntax entsprechen muss. Der Name wird jedoch im Allgemeinen nicht als URI betrachtet, da die URI-Spezifikation die Entscheidung nicht nur auf lexikalischen Komponenten, sondern auch auf deren beabsichtigter Verwendung basiert. Ein Namespace-Name impliziert nicht notwendigerweise die Semantik von URI-Schemata. Beispielsweise kann ein Namespace-Name, der mit http: beginnt, keine Verbindung zur Verwendung von HTTP haben.

Ursprünglich konnte der Namespace-Name mit der Syntax einer nicht leeren URI-Referenz übereinstimmen. Die Verwendung relativer URI-Referenzen wurde jedoch vom W3C nicht mehr empfohlen. Eine separate W3C-Spezifikation für Namespaces in XML 1.1 ermöglicht, dass Internationalized Resource Identifier (IRI) -Referenzen als Basis für Namespace-Namen zusätzlich zu den URI-Referenzen dienen.

Siehe auch [

1. ] ^ Ein Bericht, der 2002 von einer gemeinsamen W3C / IETF-Arbeitsgruppe veröffentlicht wurde, zielte darauf ab, die unterschiedlichen Ansichten der IETF und des W3C hinsichtlich der Beziehung zwischen den verschiedenen "UR *" - Begriffen und -Standards zu normalisieren. Obwohl es von keiner Organisation als vollständiger Standard veröffentlicht wurde, ist es zur Grundlage für das oben genannte gemeinsame Verständnis geworden und hat seitdem viele Standards beeinflusst.
2. ^ Die Verfahren zur Registrierung neuer URI-Schemata wurden ursprünglich 1999 von RFC definiert 2717, und werden nun von RFC 7595 definiert, das im Juni 2015 veröffentlicht wurde.
3. ^ Für URIs, die sich auf Ressourcen im World Wide Web beziehen, gestatten einige Webbrowser .0 Teile von Punkt-Dezimalzahlen Notation, die fallen gelassen werden soll oder rohe, ganzzahlige IP-Adressen verwendet werden sollen.
4. ^ Historic RFC 1866 (veraltet durch RFC 2854) ermutigt CGI-Autoren zur Unterstützung von ';' zusätzlich zu "&".

Referenzen [ ]

[] []

] edit ]

• Fielding, Roy T. (18. Juni 2005). "[httpRange-14] gelöst" . 24. Juli 2009 .
• Harold, Elliotte Rusty (2004). XML 1.1 Bible (dritte Ausgabe). Wiley Publishing. p. 291. ISBN 978-0-7645-4986-1
• Gemeinsame W3C / IETF-URI-Planungsinteressengruppe (21. September 2001). "URIs, URLs und URNs: ​​Erläuterungen und Empfehlungen 1.0" . 2009-07-27 .
• Mealling, M .; Denenberg, R., Hrsg. (August 2002). "Bericht aus der gemeinsamen Interessengruppe der W3C / IETF-URI-Planung: URIs (Uniform Resource Identifiers), URLs und URNs (Uniform Resource Names): Erläuterungen und Empfehlungen". World Wide Web Consortium . 13. September 2015 .
• Hansen, T .; Hardie, T. (Juni 2015). Thaler, D., Hrsg. "Richtlinien und Registrierungsverfahren für URI - Schemata". Internettechnik-Arbeitsgruppe. ISSN 2070-1721.
• Morrison, Michael (2006). "Stunde 5: Verwendung von Namespaces ". Sams Teach Yourself XML . Sams Publishing. p. 91.
• Palmer, Sean B. (2001). "Die frühe Geschichte von HTML" . Abgerufen 2009-04-30 .
• URI-Planungsinteressengruppe, W3C / IETF (21. September 2001). "URIs, URLs und URNs: ​​Erläuterungen und Empfehlungen 1.0" . 2009-07-27 .
• "W3 Naming Schemes". World Wide Web Konsortium. 1992 . 2009-07-24 .
• "Über die Verknüpfung alternativer Darstellungen, um Entdeckung und Veröffentlichung zu ermöglichen". World Wide Web Konsortium. 2006 [2001]. 2012-04-03
• Bray, Tim; Hollander, Dave; Layman, Andrew; Tobin, Richard, Hrsg. (16. August 2006). Msgstr "Namespaces in XML 1.1 (Second Edition)". World Wide Web Konsortium. 2.2 Verwendung von URIs als Namespace-Namen . 31. August 2015 .
• Ayers, Danny; Völkel, Max (3. Dezember 2008). Sauermann, Leo; Cyganiak, Richard, Hrsg. "Coole URIs für das Semantic Web". World Wide Web Consortium . 2012-04-03 .
• Bray, Tim; Hollander, Dave; Layman, Andrew; Tobin, Richard; Thompson, Henry S., Hrsg. (8. Dezember 2009). Msgstr "Namensräume in XML 1.0 (Third Edition)". World Wide Web Konsortium. 2.2 Verwendung von URIs als Namespace-Namen . 31. August 2015 .
• ; Connolly, Dan (November 1995). "Hypertext Markup Language - 2.0". Internet Engineering Task Force . 13. September 2015 .
• Berners-Lee, Tim; Fielding, Roy; Masinter, Larry (August 1998). Uniform Resource Identifiers (URI): Generische Syntax . Internettechnik-Arbeitsgruppe. doi: 10.17487 / RFC2396. RFC 2396 . http://tools.ietf.org/html/rfc2396. Abgerufen am 31. August 2015 .
• Berners-Lee, Tim; Fielding, Roy; Masinter, Larry (Januar 2005). Uniform Resource Identifiers (URI): Generische Syntax . Internettechnik-Arbeitsgruppe. doi: 10.17487 / RFC3986. RFC 3986 . http://tools.ietf.org/html/rfc3986. Abgerufen am 31. August 2015 .
• Berners-Lee, Tim; Fielding, Roy; Masinter, Larry (Januar 2005). Uniform Resource Identifiers (URI): Generische Syntax, Abschnitt 3, Syntaxkomponenten . Internettechnik-Arbeitsgruppe. doi: 10.17487 / RFC3986. RFC 3986 . https://tools.ietf.org/html/rfc3986#section-3. Abgerufen am 31. August 2015 .
• Lawrence, Eric (6. März 2014). "Browser Arcana: IP Literals in URLs". IEInternals . Microsoft . 2016-04-25 .

Externe Links [ edit ]