plucky (7) uri.7.gz

Provided by: manpages-de_4.25.1-1_all bug

BEZEICHNUNG

       uri, url, urn - einheitliche Bezeichner für Ressourcen (URI), einschließlich einer URL oder URN

ÜBERSICHT

       URI = [ absoluteURI | relativeURI ] [ »#« Fragment ]

       absoluteURI = scheme .RB » : « ( hierarchischer_Anteil | undurchsichtiger_Anteil )

       relativeURI = ( Netzpfad | absoluter_Pfad | relativer_Pfad )  [ »?« Anfrage ]

       schema = »http« | »ftp« | »gopher« | »mailto« | »news« | »telnet« | »file« | »ftp« | »man« | »info« |
                »whatis« | »ldap« | »wais« | …

       hierarchischer_Anteil = ( Netzpfad | absoluter_Pfad )  [ »?« Anfrage ]

       Netzpfad = »//« Autorität [ absoluter_Pfad ]

       absoluter_Pfad = »/« Pfad-Segmente

       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
       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 3986 (letzter Absatz von  Abschnitt  2.5)  den  folgenden
       Ansatz:

       (1)  Übersetzen der Zeichenabfolge in UTF-8 (IETF RFC 3629)–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.

STANDARDS

       (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

Ü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⟩.