Provided by: manpages-de_4.13-4_all 
BEZEICHNUNG
uri, url, urn - einheitliche Bezeichner für Ressourcen (URI), einschließlich einer URL oder URN
ÜBERSICHT
URI = [ absoluteURI | relativeURI ] [ »#« Fragment ]
absoluteURI = Schema »:« ( hierarchischer_Anteil | undurchsichtiger_Anteil )
relativeURI = ( Netzpfad | absoluter_Pfad | relativer_Pfad ) [ »?« Anfrage ]
Schema= »http« | »ftp« | »gopher« | »mailto« | »news« | »telnet« | »file« |
»man« | »info« | »whatis« | »ldap« | »wais« | …
hierarchischer_Anteil = ( Netzpfad | absoluter_Pfad ) [ »?« Anfrage ]
Netzpfad = »//« Autorität [ absoluter_Pfad ]
absoluter_Pfad = »/« Pfadsegment
relativer_Pfad = relatives_Segment [ absoluter_Pfad ]
BESCHREIBUNG
Ein einheitlicher Bezeichner für Ressourcen (URI, »Uniform Resource Identifier«) ist eine kurze
Zeichenkette, die eine abstrakte oder physische Ressource identifiziert (beispielsweise eine Webseite).
Ein einheitlicher Ressourcenzeiger (URL, »Uniform Resource Locator«) ist eine URI, die eine Ressource
über ihren primären Zugangsmechanismus kennzeichnet (z.B. seinen »Netzwerkort«), statt über seinen Namen
oder ein anderes Attribut dieser Ressource. Ein einheitlicher Ressourcenname (URN, »Uniform Resource
Name«) ist eine URI, die global eindeutig und dauerhaft sein muss, selbst wenn die Ressource aufhört zu
existieren oder unverfügbar wird.
URIs sind die Standardart, Ziele von Hypertextlinks für Werkzeuge wie Webbrowser zu benennen. Die
Zeichenkette »http://www.kernel.org« ist eine URL (und daher auch eine URI). Viele Leute verwenden den
Ausdruck URL locker als Synonym für URI (obwohl URLs technisch eine Teilmenge von URIs sind).
URIs können absolut oder relativ sein. Ein absoluter Bezeichner bezieht sich auf einen
Ressourcen-unabhängigen Kontext, während sich ein relativer Bezeichner auf eine Ressource bezieht, indem
der Unterschied vom aktuellen Kontext beschrieben wird. Innerhalb einer relativen Pfadreferenz haben die
Segmente ».« und »..« eines kompletten Pfads eine besondere Bedeutung: »die aktuelle Hierarchieebene«
bzw. »die Stufe oberhalb dieser Hierarchieebene«, genau wie es bei UNIX-artigen Systemen der Fall ist.
Ein Pfadsegment, das einen Doppelpunkt enthält, kann nicht als erstes Segment eines relativen URI-Pfades
verwandt werden (z.B. »dies:das«), da es als Schema-Namen missverstanden würde; stellen Sie solchen
Segmenten »./« voran (z.B. »./dies:das«). Beachten Sie, dass Abkömmlinge von MS-DOS (z.B. Microsoft
Windows) die Doppelpunkte von Gerätenamen in URIs durch einen vertikalen Strich ersetzen (»|«) ersetzen,
so dass »C:« zu »C|« wird.
Falls ein Fragmentbezeichner enthalten ist, bezieht er sich auf einen bestimmten benannten Anteil
(Fragment) einer Ressource; Text nach »#« identifiziert das Fragment. Eine URI, die mit »#« anfängt,
bezieht sich auf das Fragment in der aktuellen Ressource.
Verwendung
Es gibt viele verschiedene URI-Schemas, jede mit besonderen zusätzlichen Regeln und Bedeutungen, aber mit
Absicht werden sie so ähnlich wie möglich gestaltet. Beispielsweise erlauben viele URL-Schemas, dass die
Autorität im folgenden Format vorliegt, sie wird hier ein IP-Server genannt (Anteile in eckigen Klammern
sind optional).
IP-Server = [Benutzer [ : Passwort ] @ ] Rechner [ : Port]
Dieses Format erlaubt Ihnen, optional einen Benutzernamen, einen Benutzer plus ein Passwort und/oder eine
Port-Nummer einzufügen. Der Rechner ist der Name des Rechners, entweder sein Name, wie er durch DNS
bestimmt wird, oder eine IP-Adresse (durch Punkte getrennte Nummern). Daher meldet sich die URI
<http://fred:fredpassword@example.com:8080/> in einem Web-Server auf dem Rechner example.com als fred
(mit fredpassword) über Port 8080 an. Vermeiden Sie die Angabe eines Passworts in einer URI falls
möglich, da es viele Sicherheitsrisiken gibt, wenn Passwörter niedergeschrieben werden. Falls die URL
einen Benutzernamen, aber kein Passwort bereitstellt, und der ferne Server ein Passwort verlangt, sollte
das Programm, das die URL auswertet, dieses Passwort vom Benutzer abfragen.
Es folgen einige der häufigsten Schemas, die in UNIX-artigen Systemen verwandt und von vielen Werkzeugen
verstanden werden. Beachten Sie, dass viele Werkzeuge, die URIs verwenden, über interne Schemas oder
spezialisierte Schemas verfügen. Lesen Sie die Dokumentation dieser Werkzeuge für Informationen über
diese Schemas.
http - Web- (HTTP-)Server
http://IP-Server/Pfad
http://IP-Server/Pfad?Abfrage
Dies ist eine URL, die auf einen Web- (HTTP-)Server zugreift. Der Standard-Port ist 80. Falls sich dieser
Pfad auf ein Verzeichnis bezieht, wird der Web-Server auswählen, was er zurückliefert; normalerweise wird
der Inhalt einer Datei namens »index.html« oder »index.htm«, falls sie existiert, zurückgeliefert,
andernfalls wird eine Liste von Dateien im aktuellen Verzeichnis (mit geeigneten Links) erzeugt und
zurückgeliefert. Ein Beispiel ist <http://lwn.net>.
Eine Abfrage kann im archaischen »isindex«-Format erfolgen. Dieses besteht aus einem Wort oder einer
Phrase und enthält kein Gleichheitszeichen (=). Eine Abfrage kann auch im längeren »GET«-Format erfolgen,
bei dem eine oder mehrere Abfrageeinträge der Form Schlüssel=Wert durch ein kaufmännisches und-Zeichen
(&) getrennt werden. Beachten Sie, dass Schlüssel mehr als einmal angegeben werden kann, es aber von dem
Web-Server und seinen Anwendungsprogrammen abhängt, ob dies einer Bedeutung zugeordnet wird. Es gibt eine
unglückliche Interaktion zwischen HTML/XML/SGML und dem GET-Abfrageformat: Wenn solche URIs mit mehr als
einem Schlüssel in SGML/XML-Dokumenten (einschließlich HTML) eingebettet werden, muss das kaufmännische
Und (&) als & umgeschrieben werden. Beachten Sie, dass nicht alle Abfragen dieses Format verwenden;
längere Formulare könnten zu lang sein, um als URI abgespeichert zu werden, daher verwenden sie einen
anderen Interaktionsmechanismus (genannt POST), bei dem die Daten nicht in der URI enthalten sind. Lesen
Sie dazu die »Common Gateway Interface«-Spezifikation unter http://www.w3.org/CGI für weitere
Informationen.
ftp - Dateiübertragungsprotokoll (FTP)
ftp://IP-Server/Pfad
Dies ist eine URL für den Zugriff auf eine Datei über das Dateiübertragungsprotokoll (FTP). Der
Standardport (für die Steuerung) ist 21. Falls kein Benutzername enthalten ist, wird der Benutzername
»anonymous« bereitgestellt, und in diesem Fall stellen viele Clients als Passwort die
Internet-E-Mail-Adresse des Anfragenden bereit. Ein Beispiel ist <ftp://ftp.is.co.za/rfc/rfc1808.txt>.
gopher - Gopher-Server
gopher://IP-Server/Gophertyp-Auswähler
gopher://IP-Server/Gophertyp-Auswähler%09Suche
gopher89://IP-Server/Gophertyp-Auswähler%09Suche%09Gopher+-Zeichenkette
Der Standard-Gopher-Port ist 70. Gophertyp ist ein Feld mit einem einzelnen Zeichen, um den Typ der
Ressource, auf den sich die URL bezieht, zu bezeichnen. Der gesamte Pfad darf auch leer sein. In diesem
Fall ist das begrenzende »/« auch optional und der Gophertyp ist standardmäßig »1«.
Auswähler ist eine Gopher-Auswählerzeichenkette. Im Gopher-Protokoll ist die Gopher-Auswählerzeichenkette
eine Sequenz von Oktetten, die sämtliche Oktets außer 09 hexadezimal (US-ASCII HT oder Tab), 0A
hexadezimal (US-ASCII Zeichen LF) und 0D (US-ASCII Zeichen CR) enthalten dürfen.
mailto - E-Mail-Adresse
mailto:E-Mail-Adresse
Dies ist eine E-Mail-Adresse, normalerweise in der Form Name@Rechnername. Siehe mailaddr(7) für weitere
Informationen über das korrekte Format einer E-Mail-Adresse. Beachten Sie, dass sämtliche %-Zeichen als
%25 umgeschrieben werden müssen. Ein Beispiel ist <mailto:dwheeler@dwheeler.com>.
news - Newsgruppe oder News-Nachricht
news:Newsgruppenname
news:Nachrichtenkennung
Ein Newsgruppenname ist ein durch Punkte getrennter hierarchischer Name, wie »comp.infosystems.www.misc«.
Falls <Newsgruppenname> ein »*« ist (wie in <news:*>), so wird dieser als Bezug auf »alle verfügbaren
Newsgruppen« verwandt. Ein Beispiel ist <news:comp.lang.ada>.
Eine Nachrichtenkennung entspricht einer Nachrichtenkennung gemäß IETF RFC 1036, ohne die einschließenden
»<« und »>«; sie ist von der Form Eindeutiger@vollständiger_Domain-Name. Eine Nachrichtenkennung kann von
einem Newsgruppennamen durch das Vorhandensein des Zeichens »@« unterschieden werden.
telnet - Telnet-Anmeldung
telnet://IP-Server/
Das Telnet-URL-Schema wird zur Kennzeichnung von interaktiven Textdiensten verwandt, auf die über das
Telnet-Protokoll zugegriffen werden kann. Das abschließende »/« kann entfallen. Der Standard-Port ist 23.
Ein Beispiel ist <telnet://melvyl.ucop.edu/>.
file - Normale Datei
file://IP-Server/Pfad-Segmente
file:Pfad-Segmente
Dies stellt eine lokal zugreifbare Datei oder Verzeichnis dar. Als Spezialfall kann IP-Server die
Zeichenkette »localhost« oder die leere Zeichenkette sein; dies wird als »die Maschine, von der die URL
aus interpretiert wird« verstanden. Falls der Pfad ein Verzeichnis ist, sollte das Anzeigeprogramm den
Inhalt mit Links zu jedem Inhaltsobjekt anzeigen, derzeit machen das nicht alle Anzeigeprogramme. KDE
unterstützt erzeugte Dateien über die URL <file:/cgi-bin>. Falls die übergebene Datei nicht gefunden
wird, könnten Browser-Programmierer implementieren, dass der Dateiname über Dateinamen-Globbing (siehe
glob(7) und glob(3)) expandiert wird.
Das zweite Format (z.B. <file:/etc/passwd>) ist ein korrektes Format für Bezüge zu einer lokalen Datei.
Allerdings erlaubten ältere Standards dieses Format nicht und einige Programme erkennen es nicht als URI.
Eine portablere Syntax ist die Verwendung der leeren Zeichenkette als Servernamen, beispielsweise
<file:///etc/passwd>. Diese Form erzielt das gleiche und wird leicht durch Mustererkenner und ältere
Programme als URI erkannt. Beachten Sie, dass Sie das Schema überhaupt nicht verwenden sollten, wenn Sie
wirklich »starte bei dem aktuellen Ort« angeben möchten. Verwenden Sie in diesem Fall Adressen wie
<../test.txt>, die den Nebeneffekt haben, dass sie Schema-unabhängig sind. Ein Beispiel für dieses Schema
ist <file:///etc/passwd>.
man - Handbuchseiten-Dokumentation
man:Befehlsname
man:Befehlsname(Abschnitt)
Dies bezieht sich auf lokale Handbuchreferenzseiten (»man pages«). Dem Befehlsnamen kann optional eine
Klammer und eine Abschnittsnummer folgen; siehe man(7) für weitere Informationen zu der Bedeutung der
Abschnittsnummern. Dieses URI-Schema ist für UNIX-artige Systeme (wie Linux) speziell und ist derzeit bei
der IETF nicht registriert. Ein Beispiel ist <man:ls(1)>.
info - Infoseiten-Dokumentation
info:virtueller_Dateiname
info:virtueller_Dateiname#Knotenname
info:(virtueller_Dateiname)
info:(virtueller_Dateiname)Knotenname
Dieses Schema bezieht sich auf Online-Info-Referenzseiten (die aus Texinfo-Dateien erstellt werden). Dies
ist ein von Programmen wie den GNU-Werkzeugen verwandtes Dokumentationsformat. Dieses URI-Schema ist für
UNIX-artige Systeme (wie Linux) speziell und ist derzeit bei der IETF nicht registriert. Zum Zeitpunkt
der Erstellung dieses Dokuments unterschieden sich GNOME und KDE in ihrer URI-Syntax und akzeptierten die
jeweils andere Syntax nicht. Die ersten beiden Formate sind das GNOME-Format: in Knotennamen werden alle
Leerzeichen als Unterstrich geschrieben. Die anderen beiden Formate sind das KDE-Format: Leerzeichen in
Knotennamen müssen als Leerzeichen geschrieben werden, obwohl dies vom URI-Standard verboten ist. Es
bleibt zu hoffen, dass in der Zukunft die meisten Werkzeuge alle diese Formate verstehen werden und immer
Unterstriche für Leerzeichen in Knotennamen akzeptieren werden. Sowohl in GNOME als auch KDE wird bei der
Form ohne Knotennamen angenommen, dass der Knotenname »Top« ist. Beispiele für das GNOME-Format sind
<info:gcc> und <info:gcc#G++_and_GCC>. Beispiele für das KDE-Format sind <info:(gcc)> und <info:(gcc)G++
and GCC>.
whatis - Documentationssuche
whatis:Zeichenkette
Dieses Schema durchsucht die Datenbank der kurzen (einzeiligen) Beschreibungen von Befehlen und liefert
eine Liste von Beschreibungen zurück, die diese Zeichenkette enthalten. Nur vollständige Worttreffer
werden zurückgeliefert. Siehe whatis(1). Dieses URI-Schema ist für UNIX-artige Systeme (wie Linux)
speziell und ist derzeit bei der IETF nicht registriert.
ghelp - GNOME-Hilfedokumentation
ghelp:Name_der_Anwendung
Dies lädt GNOME-Hilfe für die angegebene Anwendung. Beachten Sie, dass derzeit nicht viele Dokumentation
in diesem Format existiert.
ldap - Leichtgewichtiges Verzeichniszugriffsprotokoll
ldap://Rechnerport
ldap://Rechnerport/
ldap://Rechnerport/DN
ldap://Rechnerport/DN?Attribute
ldap://Rechnerport/DN?Attribute?Geltungsbereich
ldap://Rechnerport/DN?Attribute?Geltungsbereich?Filter
ldap://Rechnerport/DN?Attribute?Geltungsbereich?Filter?Erweiterungen
Dieses Schema unterstützt Abfragen an das leichtgewichtige Verzeichniszugriffsprotokoll (LDAP), einem
Protokoll zur Abfrage einer Reihe von Servern für hierarchische Informationen (wie Personen und
Rechnerressourcen). Siehe RFC 2255 für weitere Informationen über das LDAP-URL-Schema. Die Komponenten
dieser URL sind:
Rechnerport
Der abzufragende LDAP-Server, geschrieben als Rechnername, optional gefolgt von einem
Doppelpunkt und der Port-Nummer. Der Vorgabe-LDAP-Port ist TCP-Port 389. Falls leer, bestimmt
der Client den zu verwendenden LDAP-Server.
DN Der »ausgezeichnete Name« (distinguished name) des LDAPs, der das Basis-Objekt der LDAP-Suche
identifiziert (siehe RFC 2253 Abschnitt 3).
Attribute Eine Kommata-getrennte Liste von zurückzuliefernden Attributen; siehe RFC 2251 Abschnitt
4.1.5. Falls nicht angegeben, sollen alle Attribute zurückgeliefert werden.
Geltungsbereich
Gibt den Geltungsbereich der Suche an, der entweder »base« (für eine Basisobjekt-Suche),
»one« (für eine einstufige Suche) oder »sub« (für eine Unterbaum-Suche) sein kann. Falls
nicht angegeben, wird »base« angenommen.
filter Gibt den Suchfilter an (Teilmenge der zurückzuliefernden Einträge). Falls nicht angegeben,
sollen alle Einträge zurückgeliefert werden. Siehe RFC 2254 Abschnitt 4.
Erweiterungen
Eine Kommata-getrennte Liste von Typ=Wert-Paaren, wobei der =Wert-Anteil bei Optionen, die
diesen nicht benötigen, entfallen kann. Eine Erweiterung, der »!« vorangestellt ist, ist
kritisch (sie muss für die Gültigkeit unterstützt werden), andernfalls ist sie nicht kritisch
(optional).
LDAP-Anfragen sind am einfachsten an einem Beispiel zu erklären. Hier ist eine Abfrage, die
ldap.itd.umich.edu zu Informationen über die Universität von Michigan in den USA fragt:
ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US
Um nur das Postadressen-Attribut zu erhalten, fordern Sie Folgendes an:
ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US?postalAddress
Um einen host.com am Port 6666 nach Informationen über die Person mit dem allgemeinen Namen (cn) »Babs
Jensen« an der Universität von Michigan zu fragen, fordern Sie Folgendes an:
ldap://host.com:6666/o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen)
wais - Weitbereichs-Informations-Server
wais://Rechnerport/Datenbank
wais://Rechnerport/Datenbank?Suche
wais://Rechnerport/Datenbank/WTyp/WPfad
Dieses Schema kennzeichnet eine WAIS-Datenbank, -Suche oder -Dokument (siehe IETF RFC 1625 für weitere
Informationen zu WAIS). Rechnerport ist der Rechnername, optional gefolgt von einem Doppelpunkt und einer
Port-Nummer (die Standard-Port-Nummer ist 210).
Die erste Form kennzeichnet eine WAIS-Datenbank zum Durchsuchen. Die zweite Form kennzeichnet eine
bestimmte Suche in der WAIS-Datenbank Datenbank. Die dritte Form kennzeichnet die Abfrage eines
bestimmten Dokuments innerhalb einer WAIS-Datenbank. WTyp ist die WAIS-Kennzeichnung des Objekttyps und
WPfad ist die WAIS-Dokumentenkennzeichnung.
andere Schemas
Es gibt viele weitere URI-Schemata. Die meisten Werkzeuge, die URIs akzeptieren, unterstützen eine Reihe
interner URIs (z.B. hat Mozilla das about:-Schema für interne Informationen und der GNOME-Hilfe-Browser
hat das toc:-Schema für verschiedene Startorte). Es gibt viele Schemata, die definiert wurden, aber
derzeit nicht so in der Breite genutzt werden (z.B. prospero). Das nntp:-Schema ist veraltet (verwenden
Sie stattdessen das news:-Schema). URNs werden vom urn:-Schema mit einem hierarchischen Namensraum (z.B.
würde urn:ietf:… IETF-Dokumente identifizieren) unterstützt. Derzeit sind URNs aber nicht in der Fläche
implementiert. Nicht alle Werkzeuge unterstützen alle Schemata.
Zeichenkodierung
URIs verwenden eine begrenzte Anzahl von Zeichen, so dass sie in einer Vielzahl von Situationen
eingegeben und verwandt werden können.
Die folgenden Zeichen sind reserviert. Dies bedeutet, dass sie in einer URI erscheinen dürfen, ihr
Einsatz aber auf ihren reservierten Zweck beschränkt ist (Daten, die dazu in Konflikt stehen, müssen
maskiert werden, bevor sie in einer URI auftauchen):
; / ? : @ & = + $ ,
Nicht reservierte Zeichen können in einer URI aufgenommen werden. Nicht reservierte Zeichen schließen
englische Groß- und Kleinbuchstaben, dezimale Ziffern und die folgende begrenzte Menge an Satzzeichen und
Symbolen ein:
- _ . ! ~ * ' ( )
Alle anderen Zeichen müssen maskiert werden. Ein maskiertes Oktett wird als ein Zeichen-Triplett kodiert,
das aus einem Prozentzeichen »%« gefolgt von zwei hexadezimalen Ziffern, die den Oktett-Code darstellen,
besteht. Die hexadezimalen Ziffern können die Buchstaben in Groß- oder Kleinschreibung verwenden. Ein
Leerzeichen muss beispielsweise als »%20«, ein Tabulatorzeichen als »%09« und das »&« als "%26" maskiert
werden. Da das Prozentzeichen »%« immer den reservierten Zweck des Maskieranzeigers hat, muss es als
»%25« maskiert werden. Es ist gängige Praxis, Leerzeichen in Abfragetexten als Plus-Symbol (+) zu
maskieren. Diese Praxis ist in den relevanten RFC (die stattdessen %20 empfehlen), nicht durchgängig
definiert, aber jedes Werkzeug, das URIs mit Abfragetext akzeptiert, sollte darauf vorbereitet sein. Eine
URI wird immer in ihrer »maskierten« Form dargestellt.
Nicht reservierte Zeichen können maskiert werden, ohne dass sich die Semantik der URI ändert. Dies sollte
aber nur in Umgebungen erfolgen, bei denen das nicht maskierte Zeichen nicht auftauchen darf.
Beispielsweise wird manchmal »%7e« anstatt von »~« in einem HTTP-URL-Pfad verwandt, aber die zwei sind
für eine HTTP-URL äquivalent.
Für URIs, die mit Zeichen außerhalb des US-ASCII-Zeichensatzes umgehen müssen, empfiehlt die HTML
4.01-Spezifikation (Abschnitt B.2) und IETF RFC 2718 (Abschnitt 2.2.5) den folgenden Ansatz:
1. Übersetzen der Zeichenabfolge in UTF-8 (IETF RFC 2279)—siehe utf-8(7)—und dann
2. Verwendung des URI-Maskierungsmechanismus, d.h. die Verwendung der %HH-Kodierung für unsichere
Oktetts.
Schreiben einer URI
Beim Aufschreiben von URLs sollten diese innerhalb doppelter englischer Anführungszeichen (z.B.
"http://www.kernel.org"), in spitze Klammern eingeschlossen (z.B. <http://lwn.net>) oder frei auf einer
einzelnen Zeile angegeben werden. Eine Warnung an alle, die in englischen Texten doppelte englische
Anführungszeichen verwenden: Packen Sie niemals überflüssige Satzzeichen (wie einen Satzpunkt, der einen
Satz beendet oder ein Komma in einer Liste) innerhalb der URI, da dies den Wert der URI ändert. Verwenden
Sie stattdessen spitze Klammern oder wechseln Sie auf ein Zitiersystem, das niemals überflüssige Zeichen
innerhalb der Anführungszeichen verwendet. Diese anderen Systeme, die in der englischen Literatur als
»new« (neue) oder »logical« (logische) Zitiersysteme von »Hart's Rules« und dem »Oxford Dictionary for
Writers and Editors« genannt werden, werden in Großbritannien und von Hackern weltweit der Vorzug gegeben