Provided by: manpages-de_4.15.0-9_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,
⟨http://www.ietf.org/rfc/rfc1036.txt⟩ 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 ⟨http://www.ietf.org
/rfc/rfc2255.txt⟩ 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 ⟨http://www.ietf.org/rfc
/rfc2253.txt⟩ 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
⟨http://www.ietf.org/rfc/rfc2254.txt⟩ 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
⟨http://www.ietf.org/rfc/rfc1625.txt⟩ 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 lateinische 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, wird in Großbritannien und
vielen europäischen Sprachen der Vorzug gegeben. Ältere Dokumente empfahlen, der URI den
Text »URL:« voranzustellen, aber diese Form hat keine Anhänger gefunden.
Die URI-Syntax wurde entwickelt, um eindeutig zu sein. Als URIs aber Gemeingut wurden,
haben traditionelle Medien (Fehrnsehen, Radio, Zeitungen, Werbeplakate usw.) zunehmend
abgekürzte URI-Referenzen verwandt, die nur aus den Anteilen der Autorität und dem
Pfadabschnitt der identifizierten Ressource bestehen (z.B. <www.w3.org/Addressing>).
Solche Referenzen sind primär zur menschlichen Auswertung (statt durch Maschinen) gedacht,
unter der Annahme, dass Kontext-basierte Heuristiken ausreichen, um die URI zu
vervollständigen (z.B. wird bei Rechnernamen, die mit »www« anfangen, angenommen, dass das
URI-Präfix »http://« ist und bei Rechnernamen, die mit »ftp« anfangen, dass sie das Präfix
»ftp://« haben). Viele Client-Implementierungen lösen diese Referenzen heuristisch auf.
Solche Heuristiken können sich im Laufe der Zeit ändern, insbesondere wenn neue Schemata
eingeführt werden. Da eine abgekürzte URI die gleiche Syntax wie ein relativer URI-Pfad
hat, können abgekürzte URI-Referenzen nicht an Stellen eingesetzt werden, an denen
relative URIs erlaubt sind, und können nur verwandt werden, wenn es keine definierte Basis
gibt (wie in Dialog-Elementen). Verwenden Sie abgekürzte URIs nicht als Hypertext-Links
innerhalb eines Dokuments, verwenden Sie das hier beschriebene Standardformat.
KONFORM ZU
(IETF RFC 2396) ⟨http://www.ietf.org/rfc/rfc2396.txt⟩, (HTML 4.0) ⟨http://www.w3.org/TR
/REC-html40⟩.
ANMERKUNGEN
Jedes Werkzeug auf einem Linux-System, das URIs akzeptiert (z.B. ein Web-Browser), sollte
in der Lage sein, alle hier beschriebenen Schemata (direkt oder indirekt) zu handhaben,
einschließlich der Schemata man: und info:. Werden hierzu andere Programme aufgerufen, ist
dies ausreichend und in der Tat sogar erwünscht.
Technisch ist das Fragment kein Teil der URI.
Für Informationen, wie URIs (einschließlich URLs) in ein Datenformat eingebettet werden,
siehe die Dokumentation des jeweiligen Formats. HTML verwendet das Format <A HREF="URI">
Text </A>. Texinfo-Dateien verwenden das Format @uref{uri}. Man und Mdoc haben kürzlich
das Makro »UR« hinzugefügt - alternativ fügen Sie die URI einfach in den Text ein
(Anzeigeprogramme sollten in der Lage sein, das »://« als Teil einer URI zu erkennen).
Die GNOME- und KDE-Desktop-Umgebungen unterscheiden sich derzeit in den URIs, die sie
akzeptieren, insbesondere in ihren jeweiligen Hilfe-Browsern. Um Handbuchseiten
aufzulisten, verwendet GNOME <toc:man>, während KDE <man:(index)> verwendet, und um
Info-Seiten aufzulisten, verwendet GNOME <toc:info>, während KDE <info:(dir)> verwendet
(der Autor dieser Handbuchseite bevorzugt hier den KDE-Ansatz, obwohl ein noch
regelmäßigeres Format noch besser wäre). Im Allgemeinen verwendet KDE <file:/cgi-bin/> als
Präfix, um eine Gruppe von erstellten Dateien einzustellen. KDE bevorzugt Dokumentation in
HTML, auf die mittels <file:/cgi-bin/helpindex> zugegriffen wird. GNOME bevorzugt das
Ghelp-Schema, um Dokumentation zu speichern und zu finden. Zum Zeitpunkt der Erstellung
dieses Textes kann keiner der Browser mit file:-Referenzen auf Verzeichnisse umgehen,
wodurch es schwierig wird, sich auf ein ganzes Verzeichnis mit einer durchsuchbaren URI zu
beziehen. Wie oben angegeben, unterscheiden sich diese Umgebungen darin, wie sie das
info:-Schema handhaben, was wahrscheinlich der größte Unterschied ist. Es wird erwartet,
dass GNOME und KDE zu einem gemeinsamen URI-Format zusammenfinden, und das zukünftige
Versionen dieser Handbuchseite das zusammengeführte Ergebnis beschreiben. Wir begrüßen
alle Bemühungen, die die Zusammenführung unterstützen.
Sicherheit
Eine URI an sich stellt kein Sicherheitsproblem dar. Es gibt keine allgemeine Garantie,
dass eine URL, die sich zu einem Zeitpunkt unter einer bestimmten Ressource befand, dies
auch weiterhin tut. Noch gibt es eine Garantie, dass eine URL nicht eine andere Ressource
zu einem späteren Zeitpunkt verortet. Diese Garantien können nur von der oder den
Person(en) erhalten werden, die den Namensraum und die in Frage stehende Ressource
kontrollieren.
Manchmal ist es möglich, eine URL zu konstruieren, so dass ein Versuch, etwas anscheinend
Harmloses durchzuführen, wie den Abruf eines einer Ressource zugeordneten Objektes,
tatsächlich zu einer möglicherweise beschädigenden Aktion auf dem fernen Rechner führen
kann. Die unsichere URL ist oft so konstruiert, dass sie eine Port-Nummer enthält, die
sich von der unterscheidet, die für das in Frage kommende Netzwerkprotokoll reserviert
ist. Der Client nimmt dann unbeabsichtigt Kontakt zu einer Site auf, die tatsächlich ein
anderes Protokoll ausführt. Der Inhalt der URL enthält Anweisungen, die zu einer
unbeabsichtigten Aktion führen, wenn sie gemäß dieses anderen Protokolls interpretiert
werden. Ein Beispiel war eine Gopher-URL, die zu einer ungewollten und jemand anders
vorgebenden Nachricht führte, die über einen SMTP-Server versandt wurde.
Wird eine URL verwandt, die eine Port-Nummer verwendet, die sich von der Vorgabe für das
Protokoll unterscheidet, sollte aufgepasst werden, insbesondere wenn es eine Nummer
innerhalb des reservierten Bereichs ist.
Wenn eine URI maskierte Begrenzungen für ein angegebenes Protokoll enthält (beispielsweise
CR- und LF-Zeichen für das Telnet-Protokoll), sollte Vorsicht walten gelassen werden, dass
diese Maskierung vor der Übertragung nicht aufgehoben wird. Dies könnte das Protokoll
verletzen, aber vermeidet die Möglichkeit, dass solche Zeichen dazu verwandt werden, eine
zusätzliche Aktion oder einen zusätzlichen Parameter in diesem Protokoll zu simulieren,
der zur Ausführung von unerwarteten und möglicherweise schädigenden Aktionen führen kann.
Es ist eindeutig eine sehr schlechte Idee, eine URI zu verwenden, die geheim zu haltende
Passwörter enthält. Es wird insbesondere dringend davon abgeraten, Passwörter in der
Komponente »userinfo« zu verwenden, außer in den sehr seltenen Fällen, bei denen eine
Veröffentlichung des Parameters »password« gewünscht ist.
FEHLER
Dokumentation kann an beliebigen Orten abgelegt werden, daher gibt es derzeit kein gutes
URI-Schema für allgemeine Online-Dokumentation in beliebigen Formaten. Referenzen der Form
<file:///usr/doc/ZZZ> funktionieren nicht, da verschiedene Distributionen und lokale
Installationsanforderungen Dateien in verschiedenen Verzeichnissen ablegen könnten (sie
könnten in »/usr/doc«, »/usr/local/doc«, »/usr/share« oder ganz woanders liegen). Auch
ändert sich das Verzeichnis normalerweise, wenn sich die Version ändert (obwohl die
Verwendung von Globbing das im Allgemeinen vermeiden könnte). Schließlich erlaubt das
file:-Schema keine leichte Unterstützung für Leute, die Dokumentation dynamisch aus dem
Internet laden (anstatt der Ablage der Dateien auf einem lokalen System). Es könnte
zukünftig ein URI-Schema hinzugefügt werden (z.B. »userdoc:«), um es Programmen zu
erlauben, Kreuzreferenzen auf detailliertere Dokumentation aufzunehmen, ohne den genauen
Ablageort dieser Dokumentation zu kennen. Alternativ könnte eine zukünftige Version der
Dateisystemspezifikation Dateiorte ausreichend festlegen, so dass das file:-Schema in der
Lage ist, Dokumentation zu verorten.
Viele Programme und Dateiformate enthalten keine Möglichkeit, Links mittels URIs
aufzunehmen oder zu integrieren.
Viele Programme können alle diese verschiedenen URI-Formate nicht handhaben. Es sollte
einen Standardmechanismus geben, um eine beliebige URI zu laden, der dann automatisch die
Umgebung des Benutzers erkennt (z.B. Text oder graphisch, Desktop-Umgebung, lokale
Benutzervoreinstellungen und aktuell ausgeführte Werkzeuge) und das richtige Werkzeug für
jede URI aufruft.
SIEHE AUCH
lynx(1), man2html(1), mailaddr(7), utf-8(7)
IETF RFC 2255 ⟨http://www.ietf.org/rfc/rfc2255.txt⟩
KOLOPHON
Diese Seite ist Teil der Veröffentlichung 5.13 des Projekts Linux-man-pages. Eine
Beschreibung des Projekts, Informationen, wie Fehler gemeldet werden können sowie die
aktuelle Version dieser Seite finden sich unter https://www.kernel.org/doc/man-pages/.
ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann
<debian@helgefjell.de> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License
Version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ oder neuer bezüglich der Copyright-
Bedingungen. Es wird KEINE HAFTUNG übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-
Mail an die Mailingliste der Übersetzer ⟨debian-l10n-german@lists.debian.org⟩.