URL

Aus SELFHTML-Wiki
(Weitergeleitet von Origin)
Wechseln zu: Navigation, Suche

Ein Uniform Resource Locator (URL) gibt den Ort (location) einer Ressource im Netz an. URLs waren ursprünglich die einzige Art von URIs, weshalb der Begriff URL oft gleichbedeutend mit URI verwendet wird.

Zusammenhang zwischen URN, URL, URI und IRI[Bearbeiten]

IRI-Venn-Diagramm

Der Zweck eines URN ist es, einer Ressource einen eindeutigen Namen zu vergeben. Das Buch zu SELFHTML 8.0 kann etwa über den URN urn:isbn:3772305989 identifiziert werden. Ein URN kann nicht direkt aufgerufen werden, sondern muss in einen URL oder anderen IRI übersetzt werden. Dabei kann es durchaus mehrere URLs zu diesem URN geben, etwa weil es mehrere Stellen gibt, an denen man das Buch online lesen oder kaufen kann.

Zweck eines URL ist es, eine Ressource zu lokalisieren, ihren Ort anzugeben. Die konkreten Inhalte, die an diesem Ort zu finden sind, können sich ständig ändern, wie das zum Beispiel für die Forumshauptseite (http://forum.selfhtml.org/self) des SELFHTML-Forums der Fall ist. Verallgemeinernd wird eine URL meist als Internetadresse bezeichnet, aber auch lokale vorliegende Dateien lassen sich über einen URL (file:///C:/selfhtml-wird-20.txt) lokalisieren.

URIs bilden die Obermenge, ihr Zweck ist es, eine Ressource zu identifizieren, egal ob über den Namen oder über den Ort. Es gibt auch URIs, die sich nicht eindeutig einer der beiden Klassen zuordnen lassen, etwa mailto:selfhtml@example.com. Die strenge Einteilung in URL und URN ist historisch gewachsen, künftige Spezifikationen und Dokumentationen sollten den allgemeineren Begriff URI anstelle der restriktiven Bezeichnungen URL und URN verwenden.[1]

In URIs sind nur Zeichen des ASCII-Zeichensatzes erlaubt. IRIs heben diese Beschränkung auf. http://самоягр.рф, könnte die fiktive Domain eines russischen SELFHTML-Projektes sein. Intern wird diese Adresse allerdings in einen URI umgewandelt (http://%D1%81%D0%B0%D0%BC%D0%BE%D1%8F%D0%B3%D1%80.%D1%80%D1%84), der nun aber für Menschen nicht mehr leicht lesbar ist. Trägt man letzteres in die Adresszeile eines (aktuellen) Browsers ein, wird daraus wieder http://самоягр.рф.

Reales Beispiel: http://кто.рф


Der oder die URL?[Bearbeiten]

Heißt es "der URL" oder "die URL"? Das "L" steht für "Locator", und Worte auf "-or" sind im Deutschen maskulin. Also: der URL. Andererseits ist es die Adresse und die Location, wodurch sich der Gebrauch des weiblichen Artikels ergibt.

Ist URL also nun männlich oder weiblich? Klare Antwort: Ja. Der Duden gestattet beides, führt aber an, dass der Gebrauch des männlichen Artikels selten sei. Wenn Sie "der URL" sagen, erlangen Sie bei Ihren Mitmenschen vermutlich eine Extraportion Nerd-Punkte.

Aufbau einer URI[Bearbeiten]

Eine URI hat prinzipiell den folgenden Aufbau:

   schema ":" adressteil [ "?" query ] [ "#" fragment ]

Das Schema legt fest, welchen Aufbau der Adressteil der URI hat. Zusätzlich verbinden sich mit etlichen Schemas weitere Festlegungen bezüglich des Kommunikationsprotokolls (z.B. bei HTTP oder FTP).

Die Teile query und fragment sind optional, was durch die eckigen Klammern angezeigt wird. Aus Sicht der URI-Norm (RFC 3986) ist ihr Aufbau ziemlich beliebig, sofern sie die zulässigen Zeichen verwenden. Es ist allerdings üblich, den Query-Teil in Form von schlüssel=wert Angaben zu notieren und diese Angaben durch ein & voneinander zu trennen.

Der Adressteil hat bei den bekannten Schemas http, https, ftp, ws und wss den Aufbau

   ["//" [ user "@" ] host [":" port ] ] [ "/" pfad ] 

Das sind abscheulich viele eckige Klammern, und tatsächlich lässt RFC 3986 hier eine Menge Varianten zu. Ein https-Adressteil kann so aussehen:

   https://foo:bar@example.org:8080/mein/ordner/bericht.html

Dabei ist foo:bar die User-Angabe und stellt eine Möglichkeit dar, die für den Zugriff auf eine Ressource erforderlichen Anmeldeinformationen mitzugeben. In der guten alten Zeit des ARPANET mag das praktikabel gewesen sein, aber seit das Internet das geschlossene Netz des amerikanischen Militärs verlassen hat, wird von dieser Form der Anmeldung strikt abgeraten.

example.org gibt an, auf welchem Host (=Computer im Internet) die gewünschte Ressource liegt. Ein Hostname kann eine IP-Adresse im IPv4-Format sein (4 Zahlen von 0-255, getrennt durch einen Punkt), eine in eckige Klammern gesetzte IP-Adresse im IPv6-Format (bis zu 6 hexadezimal notierte Zahlen von 0-FFFF, getrennt durch Doppelpunkte), oder ein vollständiger Domänen-Name (FQDN), der für den Datenzugriff mit Hilfe eines DNS Servers zunächst in eine IP-Adresse übersetzt werden muss (Informationen über FQDN und DNS).

8080 gibt schließlich an, dass die TCP-Verbindung zum Server nicht über den für https typischen Port 443, sondern über Port 8080 aufzubauen ist. Weil IPv6 Adressen ebenfalls den Doppelpunkt als Trennzeichen verwenden, wird eine IPv6 Adresse in eckige Klammern gesetzt, um sie vom Port unterscheiden zu können.

Schema, Hostname und Port bilden den so genannten Origin (Herkunft) des Dokuments, das von der URI spezifiziert wird.

Innerhalb des Origins wird nun die gewünschte Ressource (z. B. ein Dokument) in Form eines Ordnerpfades angegeben. Die einzelnen Pfad-Teile werden dabei durch Schrägstriche "/" voneinander getrennt. Es ist allerdings nicht gesagt, dass diese Teile tatsächlich realen Verzeichnissen auf dem Server entsprechen - es ist Sache des Webservers, wie er den Pfad interpretiert und ob er für eine Pfadangabe lediglich eine Datei ausliefert, oder ein Programm aufruft, um den gewünschten Inhalt aus einer Datenbank zu lesen. Aus Sicht eines Browsers wird der letzte Namensteil im Pfad als Name der angeforderten Ressource interpretiert, die Teile davor als die Kette der Ordner, um dorthin zu gelangen. Dabei kann der letzte Pfadteil auch leer sein (http://example.org/test/), in diesem Fall ist test ein Ordnername und der Dateiname leer. Es ist Sache des Servers, ob er in diesem Fall ein Standarddokument in diesem Ordner ausliefert, z.B. die Datei index.html.

Zugriff auf Ressourcen mittels einer URL[Bearbeiten]

Wenn ein Programm - z. B. Ihr Browser, ein Dokument an Hand einer URL beschaffen möchte, muss es in mehreren Schritten vorgehen.

Zunächst muss der Origin abgetrennt werden, denn daraus ergibt sich, von welchem Computer die Ressource zu beschaffen ist. An Hand des Schemas wird ein Zugriffsverfahren ausgewählt und mit dem Computer Verbindung aufgenommen.

Als nächstes wird der Fragmentteil abgetrennt, denn der wird nicht vom Server verwendet. Die Anwendung des Fragments ist Sache des Client-Programms.

Was nun verbleibt, sind Pfad und Query-String. Der Pfad wird noch normalisiert. Darunter versteht man die Verarbeitung der Pseudo-Pfadteile "." und "..", die beim Verbinden von Teilpfaden zu einem Gesamtpfad auftreten können. Der Pfad-Teil "." bedeutet: Dieser Ordner - und wird einfach entfernt. Die Pfade "/a/./b" und "/a/b" haben die gleiche Bedeutung. Der Pfad-Teil ".." bedeudet: Der Ordner darüber - und das heißt, dass aus "/a/b/../c" der Pfad "/a/c" wird. Pfade dieser Art entstehen beim Auflösen von relativen URLs, dazu gleich mehr.

Absolute und relative URL[Bearbeiten]

Wenn die URL mit einer Schema-Angabe beginnt, so ist sie absolut und kann für sich alleine stehen. Ohne das Schema ist sie relativ und benötigt eine weitere, absolute URL, zu der sie in Relation steht.

Dabei gibt es folgende Varianten:

  • Die relative URL beginnt mit "//" - es wird lediglich das Schema von der Bezugs-URL übernommen
  • Die relative URL beginnt mit "/" (aber nicht mit "//") - von der Bezugs-URL wird der vollständige Origin übernommen
  • Die relative URL beginnt mit "?" - von der Bezugs-URL werden Origin und Pfad übernommen, die relative URL wird als Query (und ggf. Fragment) angehängt
  • Die relative URL beginnt mit "#" - dies nennt man einen same resource Zugriff. Der Browser fordert die Ressource nicht neu an, er wendet lediglich das Fragment auf das vorhandene Dokument an. Für ein HTML-Dokument bedeutet das, dass das Element mit der ID, die dem Fragment entspricht, an den oberen Rand des Browserfensters positioniert wird. Allerdings lässt sich dieses Verhalten mit JavaScript auch überschreiben.
  • Jede andere relative URL wird als ein Pfad aufgefasst, der relativ zum Ordnerpfad aus der Bezugs-URL ist. Das bedeutet: Der Dateiname der Bezugs-URL wird entfernt, und die relative URL angehängt.

Der letzte dieser Fälle ist der Grund für die im vorigen Abschnitt erwähnte Normalisierung. Sie können beispielsweise die HTML Seite "http://example.org/test/index.html" aufrufen. Dort wird ein Bild verwendet, das unter "http://example.org/bilder/wetter/sonne.jpg" zu finden ist. Dieses Bild kann nun auf der index.html Seite relativ adressiert werden, mittels: "../bilder/wetter/sonne.jpg". Die Bezugs-URL ist in diesem Fall die URL des HTML-Dokuments, und das Auflösen des relativen Bezugs ergibt "http://example.org/test/../bilder/wetter/sonne.jpg". Die URL Normalisierung des Browsers macht daraus dann das Gewünschte: "http://example.org/bilder/wetter/sonne.jpg"

All diese Erklärungen stellen nur einen Ausschnitt dessen dar, was im IETF RFC 3986 beschrieben ist. Wenn Sie es wirklich ganz genau wissen wollen, schauen Sie bei der IETF vorbei.

URLs und Suchmaschinenoptimierung[Bearbeiten]

Sprechende URL[Bearbeiten]

In Bezug auf die Suchmaschinenoptimierung ist es wichtig, dass URLs als „sprechender Link“ sichtbar sind. Sie sollten also einen Sinn für einen Nutzer signalisieren.

Dabei gelten die Regeln des Referenzieren in HTML.

Auslesbarkeit[Bearbeiten]

Auch unverlinkte URLs können von Google ausgelesen werden und so als Webseiten-Adresse identifiziert werden. Wie genau dies gewertet wird, ist nicht bekannt.

Erlaubte Parameter[Bearbeiten]

Nicht jedes Zeichen ist als URL-Parameter erlaubt. Zum Beispiel Umlaute wie ö,ä,ü sind nicht erlaubt. Dagegen sind alle lateinischen Buchstaben, arabische Zahlen und diese Zeichen – _ . ~ erlaubt. Allerdings gibt es auch Zeichen, welche maskiert, d. h. in „Prozentcodierung“ geschrieben werden müssen:

! * ‘ ( ) ; : @ & = + $ , / ? % # [ ]

Verkürzte URLs[Bearbeiten]

Für bestimmte Anwendungen (zum Beispiel Soziale Netzwerke) oder auch nur für eine bessere Übersicht können URLs verkürzt werden. Hierfür gibt es verschiedene, kostenlose Dienste, wie bspw. Bitly. So könnte eine verkürzte URL aussehen:

http://bit.ly/1JAdNWa

Allerdings können bei verkürzten Links einige Probleme bezüglich des Datenschutzes auftreten. Zum einen speichern die meisten kostenlose Dienste Nutzerdaten, ohne ein Einverständnis der Betroffenen einzuholen.

Zum anderen kann man bei verkürzten URLs nicht sehen wohin der Link tatsächlich führt. weshalb gekürzte URLs auch mit Vorsicht verwendet bzw. angeklickt werden sollten. Es kann die Gefahr bestehen, dass diese Links zu schädlichen Webseiten führen.

Siehe auch[Bearbeiten]

Quellen[Bearbeiten]

  1. RFC 3986