uri

URI(7)                      Linux-Programmierhandbuch                     URI(7)



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 &amp;
       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 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 (siehe den Abschnitt Über den Schreibstil von Hackern in
       der Jargon-Datei, für weitere Informationen). Ä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.txtKOLOPHON
       Diese Seite ist Teil der Veröffentlichung 5.10 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⟩.



Linux                            13. August 2020                          URI(7)