.\" -*- coding: UTF-8 -*-
.\" (C) Copyright 1999-2000 David A. Wheeler (dwheeler@dwheeler.com)
.\"
.\" SPDX-License-Identifier: Linux-man-pages-copyleft
.\"
.\" Fragments of this document are directly derived from IETF standards.
.\" For those fragments which are directly derived from such standards,
.\" the following notice applies, which is the standard copyright and
.\" rights announcement of The Internet Society:
.\"
.\" Copyright (C) The Internet Society (1998). All Rights Reserved.
.\" This document and translations of it may be copied and furnished to
.\" others, and derivative works that comment on or otherwise explain it
.\" or assist in its implementation may be prepared, copied, published
.\" and distributed, in whole or in part, without restriction of any
.\" kind, provided that the above copyright notice and this paragraph are
.\" included on all such copies and derivative works. However, this
.\" document itself may not be modified in any way, such as by removing
.\" the copyright notice or references to the Internet Society or other
.\" Internet organizations, except as needed for the purpose of
.\" developing Internet standards in which case the procedures for
.\" copyrights defined in the Internet Standards process must be
.\" followed, or as required to translate it into languages other than English.
.\"
.\" Modified Fri Jul 25 23:00:00 1999 by David A. Wheeler (dwheeler@dwheeler.com)
.\" Modified Fri Aug 21 23:00:00 1999 by David A. Wheeler (dwheeler@dwheeler.com)
.\" Modified Tue Mar 14 2000 by David A. Wheeler (dwheeler@dwheeler.com)
.\"
.\"*******************************************************************
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
.TH uri 7 "30. April 2023" "Linux man\-pages 6.05.01"
.SH BEZEICHNUNG
uri, url, urn \- einheitliche Bezeichner für Ressourcen (URI), einschließlich
einer URL oder URN
.SH ÜBERSICHT
.SY "\fIURI\fP ="
[\~\fIabsoluteURI\fP | \fIrelativeURI\fP\~] [\~»\fB#\fP«\~\fIFragment\fP\~]
.YS
.PP
.SY "\fIabsoluteURI\fP ="
\fIscheme\~\fP »\fB:\fP« (\~\fIhierarchischer_Anteil\fP |
\fIundurchsichtiger_Anteil\fP\~)
.YS
.PP
.SY "\fIrelativeURI\fP ="
(\~\fINetzpfad\fP | \fIabsoluter_Pfad\fP | \fIrelativer_Pfad\fP\~)
[\~»\fB?\fP»\~\fIAnfrage\fP\~]
.YS
.PP
.SY "\fIschema\fP ="
»\fBhttp\fP« | »\fBftp\fP« | »\fBgopher\fP« | »\fBmailto\fP« | »\fBnews\fP« | »\fBtelnet\fP« |
»\fBfile\fP« | »\fBftp\fP« | »\fBman\fP« | »\fBinfo\fP« | »\fBwhatis\fP« | »\fBldap\fP« |
»\fBwais\fP« | …
.YS
.PP
.SY "\fIhierarchischer_Anteil\fP ="
(\~\fINetzpfad\fP | \fIabsoluter_Pfad\fP\~) [\~»\fB?\fP«\~\fIAnfrage\fP\~]
.YS
.PP
.SY "\fINetzpfad\fP ="
»\fB//\fP«\~\fIAutorität\fP [\~\fIabsoluter_Pfad\fP\~]
.YS
.PP
.SY "\fIabsoluter_Pfad\fP ="
»\fB/\fP«\~\fIPfad\-Segmente\fP
.YS
.PP
.SY "\fIrelativer_Pfad\fP ="
\fIrelatives_Segment\fP [\~\fIabsoluter_Pfad\fP\~]
.YS
.SH 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.
.PP
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).
.PP
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.
.PP
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.
.SS 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 \fIIP\-Server\fP genannt (Anteile
in eckigen Klammern sind optional).
.PP
\fIIP\-Server = \fP[\fIBenutzer\fP [ : \fIPasswort\fP ] @ ] \fIRechner\fP [ : \fIPort\fP]
.PP
Dieses Format erlaubt Ihnen, optional einen Benutzernamen, einen Benutzer
plus ein Passwort und/oder eine Port\-Nummer einzufügen. Der \fIRechner\fP 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 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.
.PP
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.
.PP
\fBhttp \- Web\- (HTTP\-)Server\fP
.PP
http://\fIIP\-Server\fP/\fIPfad\fP
.br
http://\fIIP\-Server\fP/\fIPfad\fP?\fIAbfrage\fP
.PP
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 .
.PP
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 \fISchlüssel\fP=\fIWert\fP durch ein
kaufmännisches und\-Zeichen (&) getrennt werden. Beachten Sie, dass
\fISchlüssel\fP 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
.UR http://www.w3.org\:/CGI
.UE
für
weitere Informationen.
.PP
\fBftp \- Dateiübertragungsprotokoll (FTP)\fP
.PP
ftp://\fIIP\-Server\fP/\fIPfad\fP
.PP
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
.
.PP
\fBgopher \- Gopher\-Server\fP
.PP
gopher://\fIIP\-Server\fP/\fIGophertyp\-Auswähler\fP
.br
gopher://\fIIP\-Server\fP/\fIGophertyp\-Auswähler\fP%09\fISuche\fP
.br
gopher89://\fIIP\-Server\fP/\fIGophertyp\-Auswähler\fP%09\fISuche\fP%09\fIGopher+\-Zeichenkette\fP
.br
.PP
Der Standard\-Gopher\-Port ist 70. \fIGophertyp\fP 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«.
.PP
\fIAuswähler\fP 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.
.PP
\fBmailto \- E\-Mail\-Adresse\fP
.PP
mailto:\fIE\-Mail\-Adresse\fP
.PP
Dies ist eine E\-Mail\-Adresse, normalerweise in der Form
\fIName\fP@\fIRechnername\fP. Siehe \fBmailaddr\fP(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
.
.PP
\fBnews \- Newsgruppe oder News\-Nachricht\fP
.PP
news:\fINewsgruppenname\fP
.br
news:\fINachrichtenkennung\fP
.PP
Ein \fINewsgruppenname\fP ist ein durch Punkte getrennter hierarchischer Name,
wie »comp.infosystems.www.misc«. Falls ein »*« ist
(wie in ), so wird dieser als Bezug auf »alle verfügbaren
Newsgruppen« verwandt. Ein Beispiel ist .
.PP
Eine \fINachrichtenkennung\fP entspricht einer Nachrichtenkennung gemäß
.UR http://www.ietf.org\:/rfc\:/rfc1036.txt
IETF RFC\ 1036,
.UE
ohne die
einschließenden »<« und »>«; sie ist von der Form
\fIEindeutiger\fP@\fIvollständiger_Domain\-Name\fP. Eine Nachrichtenkennung kann
von einem Newsgruppennamen durch das Vorhandensein des Zeichens »@«
unterschieden werden.
.PP
\fBtelnet \- Telnet\-Anmeldung\fP
.PP
telnet://\fIIP\-Server\fP/
.PP
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
.
.PP
\fBfile \- Normale Datei\fP
.PP
file://\fIIP\-Server\fP/\fIPfad\-Segmente\fP
.br
file:\fIPfad\-Segmente\fP
.PP
Dies stellt eine lokal zugreifbare Datei oder Verzeichnis dar. Als
Spezialfall kann \fIIP\-Server\fP 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 . Falls die übergebene Datei
nicht gefunden wird, könnten Browser\-Programmierer implementieren, dass der
Dateiname über Dateinamen\-Globbing (siehe \fBglob\fP(7) und \fBglob\fP(3))
expandiert wird.
.PP
Das zweite Format (z.B. ) 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 . 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 .
.PP
\fBman \- Handbuchseiten\-Dokumentation\fP
.PP
man:\fIBefehlsname\fP
.br
man:\fIBefehlsname\fP(\fIAbschnitt\fP)
.PP
Dies bezieht sich auf lokale Handbuchreferenzseiten (»man pages«). Dem
Befehlsnamen kann optional eine Klammer und eine Abschnittsnummer folgen;
siehe \fBman\fP(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
.
.PP
\fBinfo \- Infoseiten\-Dokumentation\fP
.PP
info:\fIvirtueller_Dateiname\fP
.br
info:\fIvirtueller_Dateiname\fP#\fIKnotenname\fP
.br
info:(\fIvirtueller_Dateiname\fP)
.br
info:(\fIvirtueller_Dateiname\fP)\fIKnotenname\fP
.PP
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 und
. Beispiele für das KDE\-Format sind
und .
.PP
\fBwhatis \- Documentationssuche\fP
.PP
whatis:\fIZeichenkette\fP
.PP
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 \fBwhatis\fP(1). Dieses URI\-Schema ist für
UNIX\-artige Systeme (wie Linux) speziell und ist derzeit bei der IETF nicht
registriert.
.PP
\fBghelp \- GNOME\-Hilfedokumentation\fP
.PP
ghelp:\fIName_der_Anwendung\fP
.PP
Dies lädt GNOME\-Hilfe für die angegebene Anwendung. Beachten Sie, dass
derzeit nicht viele Dokumentation in diesem Format existiert.
.PP
\fBldap \- Leichtgewichtiges Verzeichniszugriffsprotokoll\fP
.PP
ldap://\fIRechnerport\fP
.br
ldap://\fIRechnerport\fP/
.br
ldap://\fIRechnerport\fP/\fIDN\fP
.br
ldap://\fIRechnerport\fP/\fIDN\fP?\fIAttribute\fP
.br
ldap://\fIRechnerport\fP/\fIDN\fP?\fIAttribute\fP?\fIGeltungsbereich\fP
.br
ldap://\fIRechnerport\fP/\fIDN\fP?\fIAttribute\fP?\fIGeltungsbereich\fP?\fIFilter\fP
.br
ldap://\fIRechnerport\fP/\fIDN\fP?\fIAttribute\fP?\fIGeltungsbereich\fP?\fIFilter\fP?\fIErweiterungen\fP
.PP
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
.UR http://www.ietf.org\:/rfc\:/rfc2255.txt
RFC\ 2255
.UE
für weitere Informationen über das LDAP\-URL\-Schema. Die
Komponenten dieser URL sind:
.TP
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.
.TP
DN
Der »ausgezeichnete Name« (distinguished name) des LDAPs, der das
Basis\-Objekt der LDAP\-Suche identifiziert (siehe
.UR http://www.ietf.org\:/rfc\:/rfc2253.txt
RFC\ 2253
.UE
Abschnitt 3).
.TP
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.
.TP
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.
.TP
filter
Gibt den Suchfilter an (Teilmenge der zurückzuliefernden Einträge). Falls
nicht angegeben, sollen alle Einträge zurückgeliefert werden. Siehe
.UR http://www.ietf.org\:/rfc\:/rfc2254.txt
RFC\ 2254
.UE
Abschnitt 4.
.TP
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).
.PP
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:
.PP
.nf
ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US
.fi
.PP
Um nur das Postadressen\-Attribut zu erhalten, fordern Sie Folgendes an:
.PP
.nf
ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US?postalAddress
.fi
.PP
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:
.PP
.nf
ldap://host.com:6666/o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen)
.fi
.PP
\fBwais \- Weitbereichs\-Informations\-Server\fP
.PP
wais://\fIRechnerport\fP/\fIDatenbank\fP
.br
wais://\fIRechnerport\fP/\fIDatenbank\fP?\fISuche\fP
.br
wais://\fIRechnerport\fP/\fIDatenbank\fP/\fIWTyp\fP/\fIWPfad\fP
.PP
Dieses Schema kennzeichnet eine WAIS\-Datenbank, \-Suche oder \-Dokument (siehe
.UR http://www.ietf.org\:/rfc\:/rfc1625.txt
IETF RFC\ 1625
.UE
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).
.PP
Die erste Form kennzeichnet eine WAIS\-Datenbank zum Durchsuchen. Die zweite
Form kennzeichnet eine bestimmte Suche in der WAIS\-Datenbank
\fIDatenbank\fP. Die dritte Form kennzeichnet die Abfrage eines bestimmten
Dokuments innerhalb einer WAIS\-Datenbank. \fIWTyp\fP ist die WAIS\-Kennzeichnung
des Objekttyps und \fIWPfad\fP ist die WAIS\-Dokumentenkennzeichnung.
.PP
\fBandere Schemas\fP
.PP
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.
.SS Zeichenkodierung
URIs verwenden eine begrenzte Anzahl von Zeichen, so dass sie in einer
Vielzahl von Situationen eingegeben und verwandt werden können.
.PP
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):
.IP
.in +4n
.EX
; / ? : @ & = + $ ,
.EE
.in
.PP
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:
.IP
.in +4n
.EX
\- _ . ! \[ti] * ' ( )
.EE
.in
.PP
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.
.PP
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 »\[ti]« in einem HTTP\-URL\-Pfad verwandt, aber die
zwei sind für eine HTTP\-URL äquivalent.
.PP
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\~3986 (letzter Absatz von Abschnitt 2.5) den folgenden Ansatz:
.IP (1) 5
Übersetzen der Zeichenabfolge in UTF\-8 (IETF RFC\~3629)\[en]siehe
\fButf\-8\fP(7)\[en]und dann
.IP (2)
Verwendung des URI\-Maskierungsmechanismus, d.h. die Verwendung der
%HH\-Kodierung für unsichere Oktetts.
.SS "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. ) oder frei auf einer einzelnen
Zeile angegeben werden. Eine Warnung an alle, die in englischen Texten
doppelte englische Anführungszeichen verwenden: Packen Sie \fBniemals\fP
ü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.
.PP
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. ). 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.
.SH STANDARDS
.UR http://www.ietf.org\:/rfc\:/rfc2396.txt
(IETF RFC\ 2396)
.UE ,
.UR http://www.w3.org\:/TR\:/REC\-html40
(HTML 4.0)
.UE .
.SH 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.
.PP
Technisch ist das Fragment kein Teil der URI.
.PP
Für Informationen, wie URIs (einschließlich URLs) in ein Datenformat
eingebettet werden, siehe die Dokumentation des jeweiligen Formats. HTML
verwendet das Format \fIText\fP
. Texinfo\-Dateien verwenden das Format @uref{\fIuri\fP}. 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).
.PP
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
, während KDE verwendet, und um
Info\-Seiten aufzulisten, verwendet GNOME , während KDE
verwendet (der Autor dieser Handbuchseite bevorzugt
hier den KDE\-Ansatz, obwohl ein noch regelmäßigeres Format noch besser
wäre). Im Allgemeinen verwendet KDE als Präfix, um
eine Gruppe von erstellten Dateien einzustellen. KDE bevorzugt Dokumentation
in HTML, auf die mittels 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.
.SS 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.
.PP
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.
.PP
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.
.PP
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.
.PP
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.
.SH 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
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.
.PP
Viele Programme und Dateiformate enthalten keine Möglichkeit, Links mittels
URIs aufzunehmen oder zu integrieren.
.PP
.\" .SH AUTHOR
.\" David A. Wheeler (dwheeler@dwheeler.com) wrote this man page.
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.
.SH "SIEHE AUCH"
\fBlynx\fP(1), \fBman2html\fP(1), \fBmailaddr\fP(7), \fButf\-8\fP(7)
.PP
.UR http://www.ietf.org\:/rfc\:/rfc2255.txt
IETF RFC\ 2255
.UE
.PP
.SH ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von
Helge Kreutzmann
erstellt.
.PP
Diese Übersetzung ist Freie Dokumentation; lesen Sie die
.UR https://www.gnu.org/licenses/gpl-3.0.html
GNU General Public License Version 3
.UE
oder neuer bezüglich der
Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.
.PP
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden,
schicken Sie bitte eine E-Mail an die
.MT debian-l10n-german@lists.debian.org
Mailingliste der Übersetzer
.ME .