Uniform Resource Locator – einfach erklärt

Definition und Einordnung

Ein Uniform Resource Locator (URL; englisch für „einheitlicher Verorter für Ressourcen“) identifiziert und lokalisiert eine Ressource in Computernetzwerken. Eine Ressource kann beispielsweise eine Webseite sein. Dazu gibt die URL sowohl die zu verwendende Zugriffsmethode – etwa ein Netzwerkprotokoll wie HTTP oder FTP – als auch den Ort der Ressource an.

URLs sind eine Unterart der allgemeinen Identifikationsbezeichnungen Uniform Resource Identifier (URI). Weil URLs die erste und häufigste URI-Art sind, werden beide Begriffe oft synonym verwendet. Im allgemeinen Sprachgebrauch heißen URLs auch Internetadresse oder Webadresse; meist sind damit speziell Adressen von Webseiten gemeint.

Der ursprüngliche URL-Standard wurde im Dezember 1994 als RFC 1738 veröffentlicht und ist inzwischen durch mehrere andere RFCs obsolet. Im Jahr 2023 waren unter anderem RFC 3986 („Uniform Resource Identifier (URI): Generic Syntax“), RFC 6874 zu IPv6-Zonenbezeichnern, RFC 8820 zu URI-Entwurf und Besitz sowie Standards für telnet, gopher, mailto, tn3270 und file aktuell.

Grundaufbau und Bestandteile

Der grundsätzliche Aufbau besteht aus einer Schema-Bezeichnung und einem Schema-spezifischen Teil. Beide werden durch einen Doppelpunkt getrennt:

Das Schema legt fest, mit welcher technischen Methode eine Ressource angesprochen wird. Es entspricht meistens, aber nicht zwingend dem verwendeten Netzwerkprotokoll. Bei http, https und ftp sind Schema und Protokoll gleichnamig. mailto dient dagegen zum Schreiben einer E-Mail und file zum Zugriff auf lokale Dateien.

Je nach Schema gelten unterschiedliche Regeln für den spezifischen Teil. Häufig beginnt er mit //; bei manchen Varianten ist nur der Doppelpunkt festgelegt. Für HTTP können folgende Bestandteile vorkommen:

Benutzername und Kennwort: Falls erforderlich, werden Benutzername und Kennwort durch einen Doppelpunkt getrennt und dem Host mit @ vorangestellt. In HTTP ist diese Schreibweise nicht Bestandteil der HTTP-Spezifikation. Aktuelle Browser akzeptieren sie, fragen aber nach, ob die angegebenen Daten verwendet werden sollen. Bei einigen anderen Protokollen, etwa FTP, ist die Angabe standardkonform.
Host: Er wird als IPv4-Adresse in dezimaler, durch Punkte getrennter Schreibweise, als IPv6-Adresse in hexadezimaler, durch Doppelpunkte getrennter Schreibweise in eckigen Klammern oder als FQDN (vollqualifizierter Domänenname) angegeben.
Port: Er bezeichnet einen TCP-Port. Fehlt er, wird der Standard-Port des jeweiligen Protokolls verwendet: bei HTTP 80, bei HTTPS 443 und bei FTP 21.
Pfad: Er beschreibt eine bestimmte Ressource auf dem Server. Er darf leer sein; ein leerer Pfad und ein einzelner Slash / sind gleichbedeutend. Obwohl der Pfad klassischerweise einem relativen Pfad unterhalb eines konfigurierbaren Stammverzeichnisses entspricht, entscheidet allein der Server über seine Bedeutung. Ein URL-Pfad muss daher keine Entsprechung im Dateisystem haben.
Abfrage (Query): Bei HTTP kann nach dem Ressourcenzeiger, durch ? getrennt, ein Query-String folgen. Er überträgt zusätzliche Informationen zur server- oder clientseitigen Verarbeitung.
Fragment: Nach # kann ein Teil der Ressource bezeichnet werden, typischerweise eine Sprungmarke in einer HTML-Seite. Das Fragment wird nicht an den Server übertragen, sondern nur vom Client oder von clientseitigen Skripten ausgewertet.

Typische URL-Formen

Ein vollständiges HTTP-Beispiel ist:

https://maxmuster:[email protected]:8080/documentation/index.html?p1=A&p2=B#ressource

Es enthält das Schema https, den Benutzer maxmuster, das Kennwort geheim, den Host www.example.com, den Port 8080, den Pfad /documentation/index.html, die Abfrage p1=A&p2=B und das Fragment ressource. In diesem Beispiel ist das Schema zugleich das Netzwerkprotokoll.

Andere Schemata haben andere spezifische Teile:

mailto:[email protected] bezeichnet eine E-Mail-Adresse gemäß RFC 5322; das Schema ist hier kein Netzwerkprotokoll.
news:alt.hypertext bezeichnet eine Newsgroup ohne Host-Adresse und ohne Angabe eines Netzwerkprotokolls.
file:///verzeichnis/unterverzeichnis/datei bezeichnet den Pfad zu einer lokalen Datei. Streng genommen hat file die Form file://<host>/<path>, der Host wird praktisch jedoch nicht verwendet. File-URLs werden beispielsweise in Java für den Zugriff auf lokale Dateien eingesetzt; Browser können das Öffnen solcher Links von einer speziellen clientseitigen Konfiguration oder Add-ons abhängig machen.

Konkrete Beispiele sind ftp://max:[email protected] für FTP mit Benutzer und Kennwort, http://de.wikipedia.org für eine Website ohne Pfad, http://de.wikipedia.org/wiki/Uniform_Resource_Locator für eine Website mit Pfad und https://de.wikipedia.org für den entsprechenden Zugriff mit dem verschlüsselten Hypertext Transfer Protocol Secure. mailto:[email protected] öffnet den Standard-Mailclient mit vorausgefüllter Empfängeradresse. news:alt.hypertext zeigt eine Usenet-Newsgroup generisch an, nntp:alt.hypertext nennt dafür ausdrücklich das Netzwerkprotokoll NNTP. telnet:example.org startet eine Telnet-Sitzung, file:///foo/bar.txt greift auf eine lokale Datei zu.

Relative URLs

Absolute oder vollständige URLs enthalten alle erforderlichen Ortsangaben. Relative URLs sind dagegen nur innerhalb eines Kontextes gültig und erben Eigenschaften daraus. Ihnen fehlt die Ortsangabe im World Wide Web oder in einem echten Intranet-Web. Sie sind vor allem bei http, https und ftp möglich, außerdem bei mailto; vergleichbar ist eine Telefonnummer ohne Länder- oder Ortsvorwahl.

Bei http, https und ftp haben wichtige relative Formen folgende Bedeutungen:

//example.com/pfad/zu/datei: dasselbe Protokoll wie in der momentanen Umgebung.
/pfad/zu/datei: dieselbe Domäne (host:port), beginnend im „Wurzelverzeichnis“.
#: dieselbe Ressource; die Wirkung entsteht über die Auswertung des Fragments.
#knoten: dieselbe Ressource mit der Sprungmarke knoten.
Eine leere Angabe: dieselbe Ressource.
../: ein Pfad-Segment aufwärts.
./ oder ein sonstiger relativer Pfad: dasselbe Pfad-Segment beziehungsweise ein relativer Pfad.

Relative URLs ermöglichen es, zusammengehörende Ressourcen unverändert in einem lokalen Dateisystem oder an unterschiedlichen Orten in verschiedenen Netzwerk-Domänen abzulegen und zu verlinken. Die Interpretation des Bereichs zwischen host:port und # ist grundsätzlich dem Server freigestellt. Zwar behandeln die meisten Server und Standardprogramme Zeichen wie /, ?, % und & wie beschrieben, dies ist aber nicht zwingend. Bei mailto wäre mailto:addr1 ohne @ als relative URL möglich; sie gilt nur im lokalen Netzwerk.

Zeichen, Schreibweise, Suchmaschinen und Standardisierung

Zu den reservierten Zeichen einer URL gehören : / ? # [ ] @ ! $ & ' ( ) * + , ; =. Nicht reserviert sind die Buchstaben A–Z und a–z, die Ziffern 0–9 sowie - . _ ~. Ein Leerzeichen ␣ muss in bestimmten Fällen prozentkodiert werden, beispielsweise als %20; alternativ kann es mit + oder % dargestellt werden.

Anhang C von RFC 3986 empfiehlt, URLs in Texten gegen den umgebenden Satz und besonders gegen dessen Interpunktion abzugrenzen: eigenständig auf einer Zeile, mit doppelten Anführungszeichen wie „http://example.com/“ oder mit spitzen Klammern wie http://example.com/.

Schlecht gestaltete URLs können die Auffindbarkeit von Inhalten durch Suchmaschinen behindern. Google empfiehlt deshalb unter anderem einen bedachten Einsatz von Parametern. Eine kanonische URL ist die URL, von der Google annimmt, dass sie bei mehrfachen Verweisen auf einer Website die repräsentativste ist. Die Varianten http://www.example.com/, http://example.com/, https://www.example.com/ und https://example.com/ gelten für Suchmaschinen als vier eigenständige Versionen. Ohne definierte kanonische URL kann dies zu „Duplicate-Content“ und dadurch zu einer suboptimalen Sichtbarkeit führen. Die Prüfung der URL-Struktur ist daher häufig Bestandteil der Suchmaschinenoptimierung.

Im Deutschen wird URL häufig feminin als „die URL“ verwendet, angelehnt an „die Adresse“, aber auch maskulin als „der URL“. Die männliche Form wird mit deutschen Bezeichnungen wie Locator, Identifikator, Bezeichner, Lokalisierer oder Anzeiger begründet.

Die Bezeichnung entwickelte sich während der frühen Standardisierung des World Wide Web. Ab Ende 1990 wurden Webadressen zunächst beschreibend als „W3 document address“, „W3 name“, „W3 address“ oder „Hypertext Name“ bezeichnet. Tim Berners-Lee schlug im Sommer 1992 beim IETF-Meeting in Boston zunächst „Universal Document Identifier“ vor. Daraus wurde der Begriff „Uniform Resource Locator“: „Document“ wurde durch „Resource“ ersetzt, „universal“ durch „uniform“ und „Identifier“ durch „Locator“. Der informelle Entwurf RFC 1630 erschien im Juni 1994, der Standard RFC 1738 im Dezember 1994. Bestandteile wurden an ältere Systeme angelehnt: Der Pfad folgt der UNIX-Syntax, // für entfernte Hosts stammt aus Apollo Domain/OS, und # als Fragmentmarkierung ist von der US-amerikanischen Schreibweise für Apartment- und Suitennummern in Postadressen entlehnt.