URL ist eine Weiterleitung auf diesen Artikel. Zu weiteren Bedeutungen sieheUrl.
EinUniform Resource Locator (Abk.URL;englisch für „einheitlicher Verorter fürRessourcen“) identifiziert und lokalisiert eine Ressource, beispielsweise eineWebseite, über die zu verwendende Zugriffsmethode (zum Beispiel das verwendeteNetzwerkprotokoll wieHTTP oderFTP) und den Ort (englischlocation) der Ressource inComputernetzwerken. Der ursprüngliche Standard wurde im Dezember 1994 als RFC 1738[1] publiziert; er ist inzwischen durch die Veröffentlichung mehrerer andererRFCs obsolet. Im Jahr 2023 waren folgende RFCs aktuell:
URLs sind eine Unterart der generellen Identifikationsbezeichnung mittelsUniform Resource Identifiern (URIs). Da URLs die erste und häufigste Art von URIs darstellen, werden die Begriffe häufigsynonym verwendet. Im allgemeinen Sprachgebrauch werden URLs auch alsInternetadresse oderWebadresse bezeichnet,[2] wobei damit (der umgangssprachlich häufigen Gleichsetzung vonInternet undWWW[3] folgend) meist speziell URLs vonWebseiten gemeint sind.
Der grundsätzliche URL-Aufbau besteht aus einer die Zugriffsmethode festlegenden Schema-Bezeichnung (englischscheme) und einem Schema-spezifischen Teil(scheme-specific part), die durch einen Doppelpunkt getrennt sind:
Legt fest, mit welcher technischen Methode die Ressource angesprochen werden soll.[4] Ist meistens, aber nicht zwingend gleichlautend mit dem verwendetenNetzwerkprotokoll, über das die Ressource lokalisiert werden kann. Beispiele sind:
Je nach Schema sind unterschiedliche spezifische Angaben erforderlich und möglich. In den meisten Fällen beginnt er mit der Zeichenkette//, jedoch ist bei manchen Varianten auch lediglich der Doppelpunkt definiert. Die folgenden Beispiele beziehen sich auf das Hypertext Transfer Protocol (HTTP).
Falls benötigt, könnenLogin-Informationen ausBenutzername(user) undKennwort(password) mit übermittelt werden.[7] Diese werden, voneinander durch Doppelpunkt getrennt, dem Host mit einem trennenden At-Zeichen (@) vorangestellt.
Auch wenn für dieses Beispiel das ProtokollHTTP gewählt wurde, ist die Angabe von Benutzername und Kennwort als Teil des URLsnicht Teil der HTTP-Spezifikation.[8] Aktuelle Browser akzeptieren diese URL-Syntax zwar, fragen aber beim Benutzer nach, ob er sich wirklich mit den angegebenen Daten anmelden möchte. DerInternet Explorer 6 (ab Windows XP SP2) und neuere Versionen fallen hier aus dem Rahmen, indem sie diese URL-Syntax rundweg als fehlerhaft ablehnen. Mit einemRegistry-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, etwaFTP, ist die Angabe der Benutzerdaten in der gezeigten Form dagegen völlig korrekt und durch die Standards abgedeckt.
Die Host-Komponente wird in Form einerIPv4-Adresse indezimaler Schreibweise durch Punkte getrennt, in Form einerIPv6-Adresse inhexadezimaler Schreibweise durch Doppelpunkte getrennt und in eckige Klammern gesetzt oder in Form einesFQDN notiert.[9]
Die Angabe desPorts erlaubt die Ansteuerung einesTCP-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.[10]
Der Pfad beschreibt eine bestimmte Ressource auf demServer.[11] Der Pfad kann auch leer sein; dieser leere Pfad kann optional durch einenSchrägstrich (englischSlash) ersetzt werden und ist zu diesem gleichbedeutend.
Klassischerweise (bei manchen Protokollen ist das auch so vorgeschrieben) entspricht der Pfad in der URL einem relativen Pfad unterhalb eines konfigurierbaren „Stammverzeichnisses“ auf dem Server. Die Interpretation des Pfades ist jedoch allein Sache des Servers und es ist durchaus üblich, dass Ressourcen über URL-Pfade angeboten werden, diekeine Entsprechung im Dateisystem des Servers haben.
Traditionell stellt ein Pfad, der mit einem Slash abgeschlossen wird, ein Verzeichnis dar, während ein Pfad, der nicht mit einem Schrägstrich abgeschlossen ist, gewöhnlich eine „Datei“ kennzeichnet – also ein „Blatt“ am Ende eines Zweiges, während Verzeichnisse die möglichen Verzweigungen darstellen. Suchmaschinen behandeln beide Schreibweisen meist gleich. Da dies für Nutzer allerdings verwirrend sein kann, sollte unterschiedlicher Content auch in unterschiedlichen Pfaden abgelegt werden.[12]
Die Interpretation (Datei oderVerzeichnis; Textdatei liefern oderSkript 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.
Im Fall des HTTP kann nach dem eigentlichen Ressourcenzeiger – getrennt durch einFragezeichen – ein Query-String folgen.[13] Damit können zusätzliche Informationen übertragen werden, die server- oder clientseitig weiterverarbeitet werden können.
Nach einemDoppelkreuz kann ein Teil der Ressource referenziert werden, typischerweise einAnker in einer HTML-Seite, zu dem nach dem Aufrufen der Seite automatischhinuntergescrollt wird:[14] Der URLhttp://example.com/dokument.html#absatz3 würde, in dem hier fiktiven Dokument, den Browser dazu veranlassen, zum Anfang des dritten Absatzes zu scrollen.
Der Fragmentbezeichner wird – im Gegensatz zum Query-String –nicht an den Server übertragen, sondern nur vom Client und etwaigen clientseitigen Skripten ausgewertet. Er kann alsonicht dazu benutzt werden, z. B. nur Teile einer Ressource vom Server anzufragen.
Fürnews (in diesem Beispiel ist weder ein Netzwerkprotokoll noch eine Host-Adresse enthalten):
news:alt.hypertext \__/ \___________/ | |Schema | Name der Newsgroup
Fürfile:
file:///verzeichnis/unterverzeichnis/datei \__/ \_________________________________/ | |Schema | Pfad zu einer lokalen Datei im Dateisystem des Rechners, der den URL interpretiert
Streng genommen hat dasfile-Schema die Formfile://<host>/<path>, wobei aber der Host-Teil praktisch nicht verwendet wird, da dasfile-Schema mangels einer Möglichkeit, ein Netzwerkprotokoll für den Zugriff auf die Datei anzugeben, kaum sinnvoll über ein Netzwerk benutzt werden kann.[15]File-URLs werden beispielsweise in der ProgrammierspracheJava verwendet, um auf diese Weise auf lokale Dateien zuzugreifen.[16] Je nach Browser ist oftmals das Öffnen vonfile-Links nur nach spezieller clientseitiger Konfiguration oder unter Zuhilfenahme vonAdd-ons etc. möglich.[17][18]
mailto:hans@example.org … zum Schreiben einerE-Mail an die angegebene Mailadresse (öffnet den Standard-Mailclient mit einer neuen, leeren Nachricht, in der die TO-Adresse vorausgefüllt ist)
news:alt.hypertext … Anzeige einerUsenet-Newsgruppe (generisch, ohne Angabe des NetzwerkprotokollsNNTP)
nntp:alt.hypertext … Anzeige einer Usenet-Newsgruppe (mit Angabe des Netzwerkprotokolls NNTP)
Neben den bisher dargestellten absoluten oder vollständigen URLs gibt es auch relative URLs.[19] Sie sind nur innerhalb eines Kontextes gültig, von dem sie Eigenschaften erben. Ihnen fehlt die Ortsangabe imWorld Wide Web oder einem echtenIntranet. Sie sind vor allem in der Gruppe http, https und ftp möglich, aber auch bei mailto. Das entspräche einer Telefonnummer ohneVorwahl (des Landes, desOrtsnetzes).
Relative URLs für http, https, ftp
Beginn
Bedeutung
Anmerkung
Beispiel
//
Selbes Protokoll
sinnvoll, umhttp: oderhttps: der momentanen Umgebung zu verwenden
Ein Server muss keine durch/ gegliederte Pfad-Segmentierung unterstützen.
/pfad/zur/../zur/datei ./relativer/pfad
./ sonstige
Selbes Pfad-Segment
Relative URLs werden oft eingesetzt, um eine Gruppe zusammengehörender Ressourcen wahlweise in einem lokalenDateisystem oder an unterschiedlichen Orten in verschiedenen Netzwerk-Domänen unverändert abzulegen und aufeinander zu verlinken. Im Übrigen ist die Interpretation des Identifikators (Zeichenkette zwischenhost: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.
Beimailto: wäre eine relative URLmailto:addr1 (ohne @) möglich – sie gilt nur im lokalen Netzwerk.[20]
Im deutschen Sprachgebrauch hatURL häufig den weiblichenArtikel, wird aber auch mit männlichem Artikel verwendet.[23] Die Wahl des Genus hängt davon ab, ob es in Anlehnung an die deutsche Übersetzungdie Adresse (feminin) gebildet wird oder mittels der Grammatikregel, dass Hauptwörter auf-or (hierLocator oder-identifikator) oder-er (-bezeichner,-lokalisierer,-anzeiger) im Deutschen stets maskulin sind.[24]
Auch wenn URLs technisch komplex aufgebaut sein können, können schlecht gestaltete URLs die Auffindbarkeit von Inhalten durch Suchmaschinen behindern. Aus diesem Grund empfiehlt der Suchmaschinenbetreiber Google z. B. den bedachten Einsatz von Parametern in URLs.[26] Google hat auch die Begrifflichkeit derkanonischen URL eingeführt. Eine kanonische URL ist demnach die URL der Seite, von der Google annimmt, dass sie die repräsentativste von mehrfachen Verweisen auf einer Website ist. Aus Sicht einer Suchmaschine sind z. B. die URL-Varianten"http://www.example.com/" , "http://example.com/" , "https://www.example.com/" und "https://example.com/"vier eigenständige Versionen, die – wenn keine kanonische URL definiert ist – zu „Duplicate-Content“ und damit einer suboptimalen Sichtbarkeit führen können.
Die Prüfung der URL-Struktur wird oft im Rahmen der sogenanntenSuchmaschinenoptimierung durchgeführt.
In der Anfangszeit des WWW (ab Ende 1990) fand sich in der Dokumentation aufinfo.cern.ch zunächst keine dedizierte Bezeichnung für die Adressierung von Webseiten, das Thema wurde nur beschreibend als „W3 document address“, „W3 name“, „W3 address“ oder „Hypertext Name“ dokumentiert.[27][28][29] 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.[28][30]
Im Sommer 1992 versuchteTim Berners-Lee beimIETF-Meeting in Boston eine Arbeitsgruppe ins Leben zu rufen, die den Zugriff auf Dokumente im Web standardisieren sollte. Er schlug als NamenUniversal 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 Wortuniversal (englisch für „allgemeingültig“, „umfassend“) lag. Stattdessen wurde von der Gruppe der bescheidenere Begriffuniform (englisch für „einheitlich“) vorgeschlagen. Außerdem 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.[31]
Aufgrund der konfliktreichen Arbeitsweise der Gruppe wurde der erste – noch informelle – Standardisierungsentwurf RFC 1630[32] erst im Juni 1994 von Berners-Lee vorgelegt.[30] Er nennt den von Berners-Lee favorisierten Namen „Universal Resource Identifiers“ im Titel und definiert bereits die Begriffe URI, URL undURN. Im Dezember 1994 wurde von der Gruppe mit RFC 1738[1] der Standard mit dem Titel „Uniform Resource Locators (URL)“ veröffentlicht.
Berners-Lee entlehnte die einzelnen Bestandteile zum Teil bewusst von bereits existierenden Systemen, um Webadressen neuen Anwendern möglichst unmittelbar vertraut respektive logisch erscheinen zu lassen:[33]
Der Pfad (http://www.example.com/verzeichnis/unterverzeichnis/datei.html) zitiert direkt die Pfad-Syntax inUNIX-Dateisystemen.[33]
Die mit einem Doppel-Schrägstrich eingeleitete Notation des Hosts stammt aus der Syntax desNetzwerk-Dateisystems vonApollo Domain/OS, in der Pfade auf entfernten Hosts nach dem Muster//example.com/verzeichnis/unterverzeichnis/… adressiert wurden.[33]
Das mit einemDoppelkreuz markierte Fragment ist der in denUSA üblichen Schreibweise fürApartment- undSuitenummern in Postadressen entlehnt:12 Foo Avenue #34 steht fürFoo Avenue Nr. 12, Apartment 34. Entsprechend bedeutetdatei.html#ressourceTeil (Abschnitt, Kapitel …)ressource innerhalb des Dokumentsdatei.html.[33]
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,ISBN 3-430-11468-3 (englisch:Weaving the Web: The Original Design and Ultimate Destiny of the World Wide Web.).
T. Berners-Lee, L. Masinter, M. McCahill: RFC:1738 –Uniform Resource Locators (URL) [Errata: RFC1738]. Dezember 1994 (aktualisiert durchRFC 1808, englisch).
R. Fielding: RFC:1808 –Relative Uniform Resource Locators. Juni 1995 (Wurde durch RFC 3986 obsolete, englisch).
↑abTim Berners-Lee, Mark Fischetti:Der Web-Report. Der Schöpfer des World Wide Webs über das grenzenlose Potential des Internets. Econ, München 1999,ISBN 3-430-11468-3,S.63 (englisch:Weaving the Web: The Original Design and Ultimate Destiny of the World Wide Web.).
↑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,ISBN 3-430-11468-3,S.62 (englisch:Weaving the Web: The Original Design and Ultimate Destiny of the World Wide Web.).
