Uniform Resource Locator

Als Uniform Resource Locator (engl.; Abk. URL; dt. „einheitlicher Quellenanzeiger“) bezeichnet man eine Unterart von Uniform Resource Identifiern (URIs). URLs identifizieren und lokalisieren eine Ressource über die zu verwendende Zugriffsmethode (z. B. das verwendete Netzwerkprotokoll wie HTTP oder FTP) und den Ort (engl. location) der Ressource in Computernetzwerken. Im allgemeinen Sprachgebrauch werden sie auch als Internetadresse oder Webadresse bezeichnet,^[1] wobei damit (der umgangssprachlich häufigen Gleichsetzung von Internet und WWW^[2] folgend) meist speziell URLs von Webseiten gemeint sind.

Da URLs die erste und häufigste Art von URIs darstellen, werden die Begriffe häufig synonym verwendet. Der Unterschied besteht vereinfacht gesagt darin, dass URIs die für den konkreten Zugriff auf Ressourcen im Kontext des Internets gedachte URL-Syntax auf die bloße Benennung von beliebigen Ressourcen erweitern – also z. B. auch Telefonnummern (tel:[phone]).^[3][4]

Aufbau

Der grundsätzliche Aufbau einer URL besteht aus einer die Zugriffsmethode festlegenden Schema-Bezeichnung (engl. scheme) und einem Schema-spezifischen Teil (scheme-specific-part), die durch einen Doppelpunkt getrennt sind:

<scheme>:<scheme-specific-part>

wobei scheme oft, aber nicht zwingend gleich lautet wie das zugrundeliegende Netzwerkprotokoll (bei ftp oder http ist das z. B. der Fall, aber nicht bei mailto oder file).^[5]

Mögliche Elemente einer URL sind z. B. bei http:

     scheme-specific-part →                        →                       → |
     |
http://hans:[e-mail]:80/demo/example.cgi?land=de&stadt=aa#geschichte
|      |    |      |           | |                 |                |
|      |    |      host        | url-path          searchpart       fragment
|      |    password           port
|      user
scheme (hier gleich Netzwerkprotokoll)

bei mailto:

mailto:[e-mail]
|      |
|      E-Mail-Adresse gemäß RFC822)
scheme (hier kein Netzwerkprotokoll) 

bei news (in diesem Beispiel ist weder ein Netzwerkprotokoll noch eine Host-Adresse enthalten):

news:alt.hypertext
|    |
|    Name der Newsgroup
scheme 

oder bei file:

file:///C:/foo/bar.txt
|       |
|       Pfad zur Datei (lokal, d. h. im Dateisystem des Rechners, der die URL interpretiert)
scheme

Strenggenommen hat dieses Schema die Form file://<host>/<path>, wobei aber der Host-Teil praktisch nicht verwendet (und von modernen Browsern nicht resp. nur eingeschränkt unterstützt^[6]) wird, da das file-Schema mangels einer Möglichkeit, ein Netzwerkprotokoll für den Zugriff auf die Datei anzugeben, kaum sinnvoll über ein Netzwerk benutzt werden kann.^[7] File-URLs werden z. B. in der Programmiersprache Java verwendet, um auf lokale Dateien zuzugreifen.^[8]

scheme

Legt fest, mit welcher technischen Methode die Ressource angesprochen werden soll. Ist meistens, aber nicht zwingend gleichlautend mit dem verwendeten Netzwerkprotokoll, über das die Ressource lokalisiert werden kann. Beispiele sind HTTP, HTTPS oder FTP, aber auch mailto (zum Schreiben einer E-Mail) oder file (zum Zugriff auf lokale Dateien).

scheme-specific-part

Je nach scheme sind unterschiedliche spezifische Angaben erforderlich resp. möglich. Im Folgenden werden beispielhaft die für HTTP dargestellt.

user/password

Falls benötigt, kann ein Login aus Benutzername (user) und Passwort (password) übermittelt werden. Diese werden, voneinander durch Doppelpunkt getrennt, der Domain mit einem trennenden At-Zeichen (@) vorangestellt.

Auch wenn für dieses Beispiel das Protokoll HTTP gewählt wurde, ist die Angabe von Benutzername und Passwort als Teil der URL gerade nicht Teil der HTTP-Spezifikation!^[9] Aktuelle Browser akzeptieren diese URL-Syntax zwar, fragen aber beim Benutzer nach, ob er sich wirklich mit den angegebenen Daten anmelden möchte. Der Internet Explorer 6 (ab Windows XP SP2) und neuere Versionen fallen hier aus dem Rahmen, indem sie diese URL-Syntax rundweg als fehlerhaft ablehnen. Mit einem Registry-Eintrag kann man sie zum gleichen Verhalten zwingen, wie es die Vorgänger bis Version 5.5 zeigen: Diese übernehmen die Anmeldedaten ungefragt und übergeben sie direkt an den Server.

Bei einigen anderen Protokollen, etwa FTP, ist die Angabe der Benutzerdaten in der gezeigten Form dagegen völlig korrekt und durch die Standards abgedeckt.

host

Die Host-Komponente wird in Form einer IPv4-Adresse in dezimaler Schreibweise durch Punkte getrennt, in Form einer IPv6-Adresse in hexadezimaler Schreibweise durch Doppelpunkte getrennt und in eckige Klammern gesetzt oder in Form eines FQDN notiert.^[10]

port

Die Angabe des Ports erlaubt die Ansteuerung eines TCP/IP-Ports. Wird kein Port angegeben, so wird der Standard-Port des jeweiligen Protokolls verwendet – zum Beispiel bei HTTP 80, bei HTTPS 443 und bei FTP 21.

url-path

Der Pfad beschreibt eine bestimmte Ressource (diese kann sich beispielsweise mit der Verzeichnisstruktur des Zielsystems decken, also etwa eine Datei oder ein Verzeichnis) auf dem Server. Der Pfad kann auch leer sein. Ein leerer Pfad kann optional durch einen Slash ersetzt werden und ist zu diesem gleichbedeutend.^[5]

Die Interpretation (Datei oder Verzeichnis; Textdatei liefern oder Skript ausführen) bleibt dem Server überlassen. Ein typisches Beispiel für die Interpretationsfreiheit ist das Verhalten bei der Anforderung des Pfades / durch einen Client: Je nach Einstellung liefert der Server etwa den Inhalt einer namentlich ausgezeichneten Datei (wie /index.html, /README, /HEADER), ohne dass dies für den anfragenden Client ersichtlich ist. Genauso kann der Server allerdings – je nach Protokoll – auch explizit zu dieser Ressource weiterleiten oder eine Verzeichnisauflistung ausgeben.

searchpart

Im Fall des HTTP kann nach dem eigentlichen Ressourcenanzeiger – getrennt durch ein Fragezeichen – ein Query String folgen.^[11] Damit können zusätzliche Informationen übertragen werden, die server- oder clientseitig weiterverarbeitet werden können.

fragment

Nach einem Doppelkreuz kann ein Teil der Ressource referenziert werden (typischerweise ein Anker in einer HTML-Seite, zu dem dann automatisch heruntergescrollt wird: Die URL "http://example.com/dokument.html#absatz3" würde im fiktiven Dokument zum dritten Absatz springen.

Beispiele

• ftp://hans:[e-mail] FTP mit Benutzer und Password
• http://de.wikipedia.org Webseite ohne Pfad (Aufruf der „Startseite“)
• http://de.wikipedia.org/wiki/Uniform_Resource_Locator Webseite mit Pfad
• mailto:[e-mail] zum Schreiben einer E-Mail an die angegebene Mailadresse (öffnet den Standard-Mailclient mit einer neuen, leeren Mail, in der die TO-Adresse vorausgefüllt ist)
• news:alt.hypertext Anzeige einer Usenet-Newsgruppe (generisch, ohne Angabe des Netzwerkprotokolls NNTP)
• nntp:alt.hypertext Anzeige einer Usenet-Newsgruppe (mit Angabe des Netzwerkprotokolls NNTP)
• telnet:example.org Start einer Telnet-Session
• file:///C:/foo/bar.txt Zugriff auf eine lokale Datei

Sprachgebrauch

Die Abkürzung URL wird im deutschen Sprachgebrauch meist mit einem weiblichen Artikel, gelegentlich auch mit einem männlichen Artikel verwendet.^[12] Die Wahl des Genus hängt davon ab, ob es in Anlehnung an die deutsche Übersetzung „die Adresse“ (feminin) gebildet wird oder mittels der Regel, dass Wörter auf „-or“ (hier „Locator“) im Deutschen stets maskulin sind.^[13]

URLs in Texten

RFC 3986, Anhang C, empfiehlt, URIs (und damit auch URLs) in Texten

• eigenständig auf einer Zeile,
• mit doppelten Anführungsstrichen "http://example.com/" oder
• mit spitzen Klammern <http://example.com/>

gegen den Kontext und vor allem gegen die Interpunktion des Satzes abzugrenzen.

Relative URL

Neben den bisher dargestellten „absoluten“ oder „vollständigen“ URL gibt es auch relative URL.^[14] Sie sind nur innerhalb eines Kontextes gültig, von dem sie Eigenschaften „erben“. Ihnen fehlt die Ortsangabe im World Wide Web oder einem echten Intranet. Sie sind vor allem in der Gruppe http, https und ftp möglich, aber auch bei mailto. Das entspräche einer Telefonnummer ohne Vorwahl (des Landes, des Ortsnetzes).

Relative URL für http, https, ftp

Beginn	Bedeutung	Anmerkung	Beispiel
//	Gleiches Protokoll	sinnvoll, um http: oder https: der momentanen Umgebung zu verwenden	//example.com/pfad/zu/datei
/	Gleiche Domäne (host+port), „Wurzelverzeichnis“		/pfad/zu/datei
#	Gleiche Ressource	Wirkung über Nebenwirkung	#
#fragment	Gleiche Ressource, Sprungmarke		#knoten
nichts	Gleiche Ressource
../	ein Pfad-Segment aufwärts	Ein Server muss keine durch / gegliederte Pfad-Segmentierung unterstützen.	/pfad/zur/../zur/datei ./relativer/pfad
./ sonstige	gleiches Pfad-Segment

Relative URL werden oft eingesetzt, um eine Gruppe zusammengehörender Ressourcen wahlweise in einem lokalen Dateisystem oder an unterschiedlichen Orten in verschiedenen Netzwerk-Domänen unverändert abzulegen und aufeinander zu verlinken. Im Übrigen ist die Interpretation des Identifikators (Zeichenkette zwischen host+port und #) jedem Server freigestellt – zwar handhabt es die weitaus überwiegende Anzahl der Server und jede Standard-Software wie oben angegeben, jedoch können / genau wie ? % & nach eigenen Regeln ausgewertet werden.

Bei mailto: wäre eine relative URL mailto:Nachbar (ohne @) – sie gilt nur im lokalen Netzwerk.

Geschichte

Name und Standardisierung

In der Anfangszeit des WWW (ab Ende 1990) fand sich in der Dokumentation auf info.cern.ch zunächst keine dezidierte Bezeichnung für die Adressierung von Webseiten, das Thema wurde nur beschreibend als „W3 document address“, „W3 name“, „W3 address“ oder „Hypertext Name“ dokumentiert.^[15][16][17] Die damals spezifizierte (und in den ersten Webseiten verwendete) Gestalt der Adressierung entspricht aber schon der später als „URL“ standardisierten Form; im Standardisierungsprozess wurden zwar Änderungen erwogen, wegen der inzwischen schon fortgeschrittenen Verbreitung des WWW aber wieder verworfen.^[16][18]

Im Sommer 1992 versuchte Tim Berners-Lee beim IETF-Meeting in Boston eine Arbeitsgruppe ins Leben zu rufen, die den Zugriff auf Dokumente im Web standardisieren sollte. Er schlug als Namen Universal Document Identifier (UDI) vor, womit nach seiner Vorstellung ein allgemeiner Internet-Standard definiert werden sollte. Der Name wurde aber als zu „arrogant“ kritisiert, was vor allem am Wort „universal“ (dt.: allgemeingültig, umfassend) lag. Statt dessen wurde von der Gruppe der bescheidenere Begriff „uniform“ (dt.: einheitlich) vorgeschlagen. Weiters wurde „Document“ durch „Resource“ ersetzt, um zu unterstreichen, dass das Web mit anderen Informationssystemen integriert werden sollte. Die URI-Arbeitsgruppe kam schließlich zustande, wobei noch eine weitere Namensänderung für den zu definierenden Standard beschlossen wurde: „Identifier“ wurde durch „Locator“ ersetzt, um zu betonen, dass es sich bei Web-Adressen nicht um dauerhaft registrierte Adressen handelt.^[19]

Aufgrund der konfliktreichen Arbeitsweise der Gruppe wurde der erste – noch informelle – Standardisierungsentwurf RFC 1630 erst im Juni 1994 von Berners-Lee vorgelegt.^[20] Er nennt den von Berners-Lee favorisierten Namen „Universal Resource Identifiers“ im Titel und definiert bereits die Begriffe URI, URL und URN. Im Dezember 1994 wurde von der Gruppe in RFC 1738 der Standard für „Uniform Resource Locators (URL)“ veröffentlicht.

Bestandteile

Berners-Lee entlehnte die einzelnen Bestandteile zum Teil bewusst bereits existierenden Systemen, um Webadressen neuen Anwendern möglichst unmittelbar vertraut resp. logisch erscheinen zu lassen:^[21]

• Der Path-Teil (http://www.example.com/foo/bar/baz.html) zitiert direkt die Pfad-Syntax in UNIX-Dateisystemen.^[21]
• Die mit einem Doppel-Schrägstrich eingeleitete Notation des Hosts stammt aus der Syntax des Netzwerk-Dateisystems von Apollo Domain/OS, in der Pfade auf entfernten Hosts nach dem Muster //example.com/foo/bar/... adressiert wurden.^[21]
• Das mit einem Doppelkreuz markierte Fragment ist der in den USA üblichen Schreibweise für Apartment- und Suitenummern in Postadressen entlehnt: „12 Foo Avenue #34“ steht für „Foo Avenue Nr. 12, Apartment 34“; entsprechend bedeutet foo.html#bar „Teil (Abschnitt, Kapitel...) bar innerhalb des Dokuments foo.html“.^[21]

Literatur

• Tim Berners-Lee, Mark Fischetti: Der Web-Report. Der Schöpfer des World Wide Webs über das grenzenlose Potential des Internets. Econ, München 1999 (Originaltitel: Weaving the Web: The Original Design and Ultimate Destiny of the World Wide Web), ISBN 3-430-11468-3.

Siehe auch

• Digital Object Identifier
• Linkresolver, OpenURL, Ex Libris SFX
• Semacode
• Typosquatting
• URL-Kodierung (Prozentzeichen-Kodierung)
• URL-Template

Weblinks

• RFC 3986 – Uniform Resource Identifier (URI): Generic Syntax
• RFC 1738 – Uniform Resource Locators (URL)
• RFC 1808 – Relative Uniform Resource Locators (veraltet, aktuell: RFC 3986)

Einzelnachweise

1. ↑ Duden – Deutsches Universalwörterbuch, 6. Auflage
2. ↑ Internet und World Wide Web – der Unterschied. News.de, 29. Oktober 2009, abgerufen am 11. Dezember 2010. 
3. ↑ RFC 3986 Uniform Resource Identifier (URI); 1.1.3. URI, URL, and URN
4. ↑ RFC 3966 The tel URI for Telephone Numbers
5. ↑ ^{a b} RFC3986: Uniform Resource Identifier (URI): Generic Syntax. Abgerufen am 12. Januar 2009. 
6. ↑ Projekt-externe Verweise. Selfhtml, abgerufen am 11. Dezember 2010. 
7. ↑ RFC 1738 Uniform Resource Locators (URL); 3.10 FILES
8. ↑ Class File (Java 1.5.0 API). Oracle, abgerufen am 11. Dezember 2010. 
9. ↑ RFC2616: Hypertext Transfer Protocol – HTTP/1.1, 3.2.2 http URL
10. ↑ RFC 1738 Uniform Resource Locators (URL); 3.1. Common Internet Scheme Syntax
11. ↑ RFC 1738 Uniform Resource Locators (URL); 3.3. HTTP
12. ↑ Duden – Deutsches Universalwörterbuch, siehe auch Online-Suche auf duden.de
13. ↑ Antwort des Bertelsmann-Verlags auf Frage nach Genus von „URL“
14. ↑ RFC 3986, Abschnitt 4.2
15. ↑ W3 Project (CERN): Technical details. CERN / W3C, 13. November 1992, abgerufen am 22. Dezember 2010. 
16. ↑ ^{a b} W3 Project (CERN): W3 Naming Schemes. CERN / W3C, 24. Februar 1992, abgerufen am 22. Dezember 2010. 
17. ↑ W3 Project (CERN): W3 address syntax: BNF. CERN / W3C, 29. Juni 1992, abgerufen am 22. Dezember 2010. 
18. ↑ Berners-Lee 1999, S.63
19. ↑ Berners-Lee 1999, S.62
20. ↑ Berners-Lee 1999, S.63
21. ↑ ^{a b c d} Tim Berners-Lee: Frequently asked questions - Why the //, #, etc? 20. November 2007, abgerufen am 22. Dezember 2010.