|
|
| Zeile 61: |
Zeile 61: |
| <div class="mw-collapsible-content">'''Antwort5'''</div> | | <div class="mw-collapsible-content">'''Antwort5'''</div> |
| </div> | | </div> |
|
| |
| = TMP =
| |
| '''Uniform Resource Identifier''' ('''URI''')
| |
|
| |
|
| |
| , {{enS}} für ''einheitlicher Bezeichner für [[Ressource]]n'') ist ein [[Identifikator]] und besteht aus einer Zeichenfolge, die zur Identifizierung einer abstrakten oder physischen [[Ressource#Informatik|Ressource]] dient. ''URI''s werden zur Bezeichnung von Ressourcen (wie [[Webseite]]n, sonstigen Dateien, Aufruf von [[Web Service|Webservices]], aber auch z. B. [[E-Mail]]-Empfängern) im [[Internet]] und dort vor allem im [[World Wide Web|WWW]] eingesetzt.
| |
| * Der aktuelle Stand 2016 ist als RFC 3986 publiziert.
| |
|
| |
| Ursprünglich führte [[Tim Berners-Lee]] den Begriff 1994 im RFC 1630 als ''Universal Resource Identifier'' ein.
| |
| * Erst später tauchte dann in offiziellen [[World Wide Web Consortium|W3C]]-Dokumenten die Auflösung ''Uniform'' auf.
| |
| * Aus diesem Grund wird ''Universal'' gelegentlich – selbst in der Fachliteratur – als erster Namensbestandteil genannt.
| |
|
| |
| URIs können als Zeichenfolge (kodiert mit einem [[Zeichensatz]]) in digitale Dokumente, insbesondere solche im [[Hypertext Markup Language|HTML]]-Format eingebunden oder auch von Hand auf Papier aufgeschrieben werden.
| |
| * Einen Verweis von einer [[Webseite]] auf eine andere nennt man [[Hyperlink]] oder kurz „Link“.
| |
|
| |
| Eine Erweiterung der nur aus druckbaren [[American Standard Code for Information Interchange|ASCII]]-Zeichen bestehenden URIs sind die [[Internationalized Resource Identifier]]s (IRIs).
| |
|
| |
| == Konzeption ==
| |
|
| |
| Ein URI (oder in der Erweiterung IRI) ist das abstrakte Prinzip, die Syntax, einer Kennzeichnung, bei dem ein Satz an Regeln vorgegeben ist.
| |
| * Dieses Grundkonzept der URI wird dann auf verschiedene konkrete Anwendungsbereiche übertragen, für die dann die entsprechenden Regeln und Begriffe gelten.
| |
| * Zum Beispiel:
| |
|
| |
| * „URI dürfen keine Leerzeichen enthalten.“ oder
| |
| * „Zu Beginn steht der Name eines Schemas in [[American Standard Code for Information Interchange|ASCII]]-Buchstaben und Ziffern, gegebenenfalls gegliedert durch Punkt und Bindestrich, beginnend mit Buchstaben, worauf ein Doppelpunkt folgt.“
| |
|
| |
| Grundsätzlich gibt es drei Typen von Anwendungen:
| |
|
| |
| * Name
| |
| ** Der ''Inhalt'' einer Ressource (und damit jede inhaltsgleiche Kopie) erhält eine eindeutige Kennung.
| |
| ** Beispiel: Die [[Internationale Standardbuchnummer|ISBN]] eines Buches.
| |
| * Es gibt unbegrenzt viele Exemplare dieses Buches.
| |
| * Locator
| |
| ** Der Ort einer Ressource ist über ihren Namen definiert.
| |
| * Sie wird also darüber identifiziert, ''wo'' sie zu finden ist; es wird damit jedoch nicht zwangsläufig ihr Inhalt festgelegt.
| |
| ** Beispiel: Aktueller Wetterbericht im Internet.
| |
| * Es ist bekannt, an welcher Stelle (URL) dieser zu finden ist; der Inhalt ändert sich ständig.
| |
| ** Beispiel: Ein Buch wird dadurch beschrieben, in welcher Bibliothek es steht: dort im zweiten Raum, drittes Regal, viertes Fach von oben, fünftes Buch von links.
| |
| * Dort könnten die aktuellen Top-5 der Bestsellerliste stehen – unabhängig von ihrem Inhalt.
| |
| * Individuum
| |
| ** Die Regeln der URI können auch angewendet werden, wenn etwas überhaupt keine klassische Ressource ist, trotzdem identifiziert werden soll.
| |
| ** Zunächst verstand man unter „Ressource“ etwas wie [[Ressource (Software)|Ressourcen]] im informationstechnischen Sinn, also im weitesten Sinne elektronische Dateien, die auch im Internet verfügbar gemacht werden könnten.
| |
| * Davon gingen 1994 die RFC 1630 und RFC 1738 aus.
| |
| * Dieses Konzept wurde jedoch erweitert.
| |
| * So war 1998 in der RFC 2396 (Abschnitt 1.1) festgelegt worden: „A resource can be anything that has identity.“ Auch Personen, Organisationen und gedruckte Bücher könnten als Ressource betrachtet werden.
| |
| * Diese Betrachtung zielt auf die Kennzeichnung zuordnungsfähiger Entitäten.
| |
| ** Beispiele: E-Mail-Adresse, Nummer eines Mobiltelefons, Reisepass sowie der legitime Inhaber, Sozialversicherungsnummer, Fingerabdruck und der Mensch dazu.
| |
| Im Januar 2005 wurde mit RFC 3986 das Konzept der Ressource im Sinne der URI auch noch um abstrakte Konzepte erweitert:
| |
| {{Zitat
| |
| |Text=A resource is not necessarily accessible via the Internet; e.g., human beings, corporations, and bound books in a library can also be resources.
| |
| * Likewise, abstract concepts can be resources, such as the operators and operands of a mathematical equation, the types of a relationship (e.g., ‘parent’ or ‘employee’), or numeric values (e.g., [[Zero One Infinity|zero, one, and infinity]]).
| |
| |Sprache=en
| |
| |Autor=
| |
| |Quelle=RFC 3986, Abschnitt 1.1
| |
| |Übersetzung=Eine Ressource ist nicht notwendigerweise über das Internet erreichbar; beispielsweise können Menschen, Firmen und gebundene Bücher in Bibliotheken ebenfalls eine Ressource darstellen.
| |
| * Ebenso können abstrakte Konzepte, wie Operatoren und Operanden einer mathematischen Gleichung, Arten einer Beziehung (z. B. 'Elter' oder 'Angestellter'), oder Zahlen (z. B.
| |
| * Null, Eins und Unendlich) eine Ressource sein.
| |
| |ref=}}
| |
|
| |
| == Aufbau ==
| |
|
| |
| Nach dem aktuellen Standard RFC 3986 besteht ein URI aus fünf Teilen: <code>scheme</code> (Schema oder Protokoll), <code>authority</code> (Anbieter oder Server), <code>path</code> (Pfad), <code>query</code> (Abfrage) und <code>fragment</code> (Teil), wovon nur <code>scheme</code> und <code>path</code> in jedem URI vorhanden sein müssen.
| |
| * Die generische Syntax ist:
| |
| <pre>
| |
| URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
| |
| </pre>
| |
| Dabei steht <code>hier-part</code> (hierarchischer Teil) für eine optionale <code>authority</code> und den <code>path</code>.
| |
| * Ist die Angabe einer <code>authority</code> erforderlich, um die Ressource letztlich zu verorten, so wird sie durch doppelten Schrägstrich eingeleitet und die darauf folgende Pfadangabe muss mit einem Schrägstrich beginnen.
| |
| * Der Standard verdeutlicht diese Komponenten mit zwei Beispielen:
| |
| <pre>
| |
| foo://example.com:8042/over/there?name=ferret#nose
| |
| \_/ \________________/\_________/ \_________/ \__/
| |
| | | | | |
| |
| scheme authority path query fragment
| |
| | _____________________|__
| |
| / \ / \
| |
| urn:example:animal:ferret:nose
| |
| </pre>
| |
|
| |
| === {{Anker|Schema|Scheme}} Schema (''Scheme'') ===
| |
|
| |
| Das Schema (der Teil vor dem Doppelpunkt) definiert den Kontext und bezeichnet so den Typ des URIs, was die Interpretation des folgenden Teils festlegt.
| |
| * Bekannte Schemata sind beispielsweise die Protokolle <code>[[Hypertext Transfer Protocol|http]]</code> und <code>[[File Transfer Protocol|ftp]]</code> sowie Notationskonzepte wie <code>[[Uniform Resource Name|urn]]</code> und <code>[[Digital Object Identifier|doi]]</code>.
| |
| * Mit dem Doppelpunkt endet der erste obligatorische Teil des URI.
| |
| * Gibt es keinen Bezug auf eine die Namensverwaltung organisierende (aktive) Autorität, so folgt direkt auf diesen Doppelpunkt der Pfad zur Verortung der Ressource.
| |
|
| |
| === Authority (im Sinne von ''Zuständigkeit'') ===
| |
|
| |
| Viele ''URI''-Schemata wie <code>http</code> oder <code>ftp</code> haben einen <code>authority</code>-Teil.
| |
| * Der Begriff ''authority'' bezieht sich auf eine Instanz, die die Namen in diesem (vom Schema angegebenen Interpretations-) Raum zentral verwalten kann.
| |
| * Ein Beispiel dafür ist das [[Domain Name System]], das von globalen und lokalen [[Domain Name Registrar|Registraren]] verwaltet wird.
| |
|
| |
| Die <code>authority</code> besteht aus einer optionalen Benutzerinformation (gefolgt von einem ‚<code>@</code>‘), dem [[Host (Informationstechnik)|Host]] und einer optionalen (durch einen Doppelpunkt eingeleiteten) Port-Angabe.
| |
| * Sie folgt auf zwei Schrägstriche (<code>//</code>) und wird von einem einfachen Schrägstrich (<code>/</code>), einem Fragezeichen (<code>?</code>), einem Doppelkreuz (<code>#</code>) oder dem Ende des URIs begrenzt.
| |
| * Der Host-Teil kann aus einer [[IP-Adresse]], einer [[IPv6]]-Adresse (in eckigen Klammern ‚<code>[…]</code>‘) oder einem registrierten Namen bestehen.
| |
| * Gültige Werte sind beispielsweise:
| |
|
| |
| * <code>de.wikipedia.org</code>
| |
| * <code>user@example.com:8080</code>
| |
| * <code>192.0.2.16:80</code>
| |
| * <code>[2001:db8::7]</code>
| |
|
| |
| Die mögliche Angabe von Benutzername und Kennwort in der Benutzerinformation (<code>user:password@…</code>) wird in [[RFC:3986#section-3.2.1|RFC 3986 (Abschnitt 3.2.1)]] als überholt bezeichnet und sollte nicht mehr verwendet werden, da URIs oft im Klartext übertragen und protokolliert werden.
| |
|
| |
| === Pfad (''Path'') ===
| |
|
| |
| Der Pfad enthält – oft hierarchisch organisierte – Angaben, die zusammen mit dem Abfrageteil eine Ressource identifizieren.
| |
| * Falls in der URI eine im vorangegangenen Abschnitt beschriebene <code>authority</code> angegeben wurde, muss der <code>path</code> mit einem Schrägstrich (<code>/</code>) beginnen; gibt es keine <code>authority</code>, darf der <code>path</code> nicht mit einem doppelten Schrägstrich (<code>//</code>) beginnen.
| |
| * Dadurch ist die eindeutige Interpretation gesichert.
| |
| * Er wird von einem Fragezeichen (<code>?</code>), einem Doppelkreuz (<code>#</code>) oder dem Ende des URI begrenzt.
| |
| * Gültige Pfade sind beispielsweise:
| |
|
| |
| * <code>/over/there</code>
| |
| * <code>example:animal:ferret:nose</code>
| |
|
| |
| === Abfrage (''Query'') ===
| |
|
| |
| Der Abfrageteil ([[Query-String]]) beinhaltet Daten zur Identifizierung von solchen Ressourcen, deren Ort durch die Pfadangabe allein nicht genau angegeben werden kann.
| |
| * Sie müssen aus der durch den Pfad bezeichneten Quelle, durch ebendiese Abfrage wie beispielsweise ein Datensatz aus einer Datenbank abgerufen werden.
| |
| * Er wird mit einem Fragezeichen (<code>?</code>) eingeleitet und von einem Doppelkreuz (<code>#</code>) oder dem Ende des URI begrenzt.
| |
| * Eine gültige Abfrage nach dem ‚<code>?</code>‘ ist beispielsweise:
| |
|
| |
| * <code>title=Uniform_Resource_Identifier&action=submit</code>
| |
|
| |
| Hier spielen ‚<code>&</code>‘ und ‚<code>=</code>‘ in etwa die gleiche Rolle wie ‚<code>.</code>‘ und ‚<code>:</code>‘ im Teil für die <code>authority</code>.
| |
|
| |
| === Fragment ===
| |
| <code>fragment</code> ist der optionale [[Fragmentbezeichner]] und referenziert eine Stelle innerhalb einer Ressource.
| |
| * Der Fragmentbezeichner bezieht sich immer nur auf den unmittelbar vorangehenden Teil des URI und wird von einem Doppelkreuz (<code>#</code>) eingeleitet.
| |
| * Ein Beispiel dafür ist der [[Anker (HTML)|Anker]] in HTML.
| |
|
| |
| === Beispiele ===
| |
| * <code><nowiki>https://de.wikipedia.org/wiki/Uniform_Resource_Identifier</nowiki></code>
| |
| * <code><nowiki>ftp://ftp.is.co.za/rfc/rfc1808.txt</nowiki></code>
| |
| * <code><nowiki>file:///C:/Users/Benutzer/Desktop/Uniform%20Resource%20Identifier.html</nowiki></code>
| |
| * <code><nowiki>file:///etc/fstab</nowiki></code>
| |
| * <code><nowiki>geo:48.33,14.122;u=22.5</nowiki></code>
| |
| * <code><nowiki>ldap://[2001:db8::7]/c=GB?objectClass?one</nowiki></code>
| |
| * <code><nowiki>gopher://gopher.floodgap.com</nowiki></code>
| |
| * <code><nowiki>mailto:John.Doe@example.com</nowiki></code>
| |
| * <code><nowiki>sip:911@pbx.mycompany.com</nowiki></code>
| |
| * <code><nowiki>news:comp.infosystems.www.servers.unix</nowiki></code>
| |
| * <code><nowiki>data:text/plain;charset=iso-8859-7,%be%fa%be</nowiki></code>
| |
| * <code><nowiki>tel:+1-816-555-1212</nowiki></code>
| |
| * <code><nowiki>telnet://192.0.2.16:80/</nowiki></code>
| |
| * <code><nowiki>urn:oasis:names:specification:docbook:dtd:xml:4.1.2</nowiki></code>
| |
| * <code><nowiki>git://github.com/rails/rails.git</nowiki></code>
| |
| * <code><nowiki>crid://broadcaster.com/movies/BestActionMovieEver</nowiki></code>
| |
| Ein Beispiel mit sehr vielen Elementen gleichzeitig in der URI:
| |
| * <code><nowiki>http://nobody:password@example.org:8080/cgi-bin/script.php?action=submit&pageid=86392001#section_2</nowiki></code>
| |
|
| |
| == URI-Referenzen ==
| |
|
| |
| Oft verwenden Anwendungen nicht den vollständigen URI, sondern eine abgekürzte Syntax, beispielsweise um Platz zu sparen oder den einfachen Umzug auf andere Server zu ermöglichen.
| |
| * Manche URI-Schemata begrenzen in ihrer Definition zudem die Syntax auf eine bestimmte Form.
| |
| * Unter dem Begriff der URI-Referenzen werden unterschiedliche Schreibweisen zusammengefasst.
| |
|
| |
| === Absolute URIs ===
| |
|
| |
| Ein absoluter URI identifiziert eine Ressource unabhängig vom Kontext der Verwendung des URI.<ref>[https://www.ietf.org/rfc/rfc2396.txt ietf.org]</ref>
| |
| Er besteht mindestens aus <code>scheme</code> und <code>hier-part</code> (also einer <code>authority</code> und/oder einem <code>path</code>).
| |
| Beispiele sind:
| |
|
| |
| * <code><nowiki>https://de.wikipedia.org</nowiki></code>
| |
| * <code>file://localhost/var/spool/dump.bin</code>
| |
|
| |
| === Relative Referenz ===
| |
|
| |
| Im Gegensatz zu einem absoluten URI beschreibt ein relativer URI nur die Abweichung zwischen dem absoluten URI einer Ressource und dem aktuellen Kontext in einem hierarchischen Namensraum.<ref>[https://www.ietf.org/rfc/rfc2396.txt ietf.org]</ref>
| |
|
| |
| Wenn eine URI-Referenz nicht mit einem <code>scheme</code> beginnt, wird angenommen, dass es sich um eine relative Referenz handelt.
| |
| * Die Auflösung einer relativen Referenz zu einem absoluten URI erfolgt abhängig vom Kontext nach standardisierten Regeln.
| |
| * Eine relative Referenz besteht aus einem <code>path</code> sowie optional aus <code>query</code> und <code>fragment</code>.
| |
| * Es werden drei Arten von relativen Referenzen unterschieden:
| |
|
| |
| * Beginnt der Pfad ohne Schrägstrich, handelt es sich um eine ''relative Pfad-Referenz'', beispielsweise <code>image.png</code>, <code>./image.png</code> und <code>../images/image.png</code>.
| |
| * Beginnt der Pfad mit einem einzelnen Schrägstrich (<code>/</code>), handelt es sich um eine ''absolute Pfad-Referenz''.
| |
| * Beginnt der Pfad mit doppelten Schrägstrichen (<code>//</code>), handelt es sich um eine ''Netzwerk-Pfad-Referenz''.
| |
|
| |
| === Referenz innerhalb desselben Dokumentes ===
| |
|
| |
| URI-Referenzen können auf dasselbe Dokument verweisen, dessen Teil sie sind.
| |
| * Die häufigste Anwendung ist das Doppelkreuz (<code>#</code>), gefolgt von einem Fragment-Bezeichner.
| |
|
| |
| === Suffix-Referenzen ===
| |
|
| |
| Weit verbreitet ist die Angabe von URI-Referenzen des Internets ohne Bezeichnung des Protokolls (des Schemas), etwa <code>www.wikipedia.de</code>.
| |
| * Unter der Annahme, dass sich aus dem [[Suffix]] (im Beispiel <code>www</code>, DNS-Namen werden von rechts nach links aufgebaut) auf das Protokoll (hier <code>http</code>) schließen lässt, funktioniert die Auflösung solcher Referenzen.
| |
| * Allerdings ist diese Auflösung von entsprechenden Annahmen und zudem von der jeweiligen Software abhängig.
| |
| * Deshalb sollten Suffix-Referenzen vermieden werden.
| |
|
| |
| == Schemata ==
| |
|
| |
| Unter anderem sind folgende Schemata definiert:
| |
|
| |
| {| class="wikitable sortable"
| |
| ! Schema !! Beschreibung
| |
| |-
| |
| | <code>crid</code> || [[Content Reference Identifier]] (für [[Fernsehsendung]]en)
| |
| |-
| |
| | <code>data</code> || [[Data-URL]]: direkt eingebettete Daten
| |
| |-
| |
| | <code>file</code> || Dateien im lokalen [[Dateisystem]]
| |
| |-
| |
| | <code>ftp</code> || [[File Transfer Protocol]]
| |
| |-
| |
| | <code>geo</code> || [[Geografische Koordinaten]]
| |
| |-
| |
| | <code>gopher</code> || [[Gopher]]
| |
| |-
| |
| | <code>http</code> || [[Hypertext Transfer Protocol]]
| |
| |-
| |
| | <code>ldap</code> || [[Lightweight Directory Access Protocol]]
| |
| |-
| |
| | <code>mailto</code> || [[E-Mail]]-Adresse
| |
| |-
| |
| | <code>news</code> || [[Newsgroup]] oder Newsartikel
| |
| |-
| |
| | <code>pop</code> || Mailboxzugriff über [[POP3]]
| |
| |-
| |
| | <code>rsync</code> || Synchronisation von Daten mit [[rsync]]
| |
| |-
| |
| | <code>sip</code> || [[Session Initiation Protocol|SIP]]-gestützter Sitzungsaufbau, z. B.
| |
| * für [[IP-Telefonie]]
| |
| |-
| |
| | <code>tel</code> || [[Telefonnummer]]
| |
| |-
| |
| | <code>telnet</code> || [[Telnet]]
| |
| |-
| |
| | <code>urn</code> || [[Uniform Resource Name]]s (URNs)
| |
| |-
| |
| | <code>ws</code> || rowspan="2" | [[WebSocket]]
| |
| |-
| |
| | <code>wss</code>
| |
| |-
| |
| | <code>xmpp</code> || [[Extensible Messaging and Presence Protocol]] für [[Jabber Identifier]]
| |
| |}
| |
|
| |
| Auf der Website der [[Internet Assigned Numbers Authority]] (IANA) befindet sich eine vollständige Liste der offiziellen Schemata.<ref name="IANA-Schemata" />
| |
|
| |
| Daneben haben sich einige inoffizielle, von der IANA auch als „vorläufig“ bezeichnete, Schemata für einzelne Anwendungen oder gängige Protokolle etabliert:
| |
|
| |
| {| class="wikitable sortable"
| |
| ! Schema !! Beschreibung
| |
| |-
| |
| |-
| |
| | <code>about</code> || [[Webbrowser|browserinterne]] Informationen<ref>[https://tools.ietf.org/html/draft-holsten-about-uri-scheme-06 tools.ietf.org]</ref>
| |
| |-
| |
| | <code>afp</code> || [[Apple Filing Protocol]]<ref>[https://tools.ietf.org/html/draft-ietf-svrloc-afp-service-01 tools.ietf.org]</ref>
| |
| |-
| |
| | <code>apt</code> || [[Advanced Packaging Tool]]
| |
| |-
| |
| | <code>callto</code> || Telefonnummern (u. a. [[Skype]] und [[NetMeeting]])
| |
| |-
| |
| | <code>coffee</code> || [[Hyper Text Coffee Pot Control Protocol]]
| |
| |-
| |
| | <code>daap</code> || [[Digital Audio Access Protocol]]
| |
| |-
| |
| | <code>doi</code> || [[Digital Object Identifier]]
| |
| |-
| |
| | <code>ed2k</code> || [[ED2k-URI-Schema]] von [[eDonkey2000]]/[[Kademlia]]
| |
| |-
| |
| | <code>feed</code> || [[Web-Feed]]s
| |
| |-
| |
| | <code>finger</code> || [[Finger (Internetprotokoll)|Finger]]<ref>[https://tools.ietf.org/html/draft-ietf-uri-url-finger-03 tools.ietf.org]</ref>
| |
| |-
| |
| | <code>fish</code> || [[FISH (Protokoll)|Files transferred over Shell protocol]]
| |
| |-
| |
| | <code>git</code> || [[Git]]
| |
| |-
| |
| | <code>irc</code>/<code>ircs</code> || [[Internet Relay Chat]]<ref>[https://tools.ietf.org/html/draft-butcher-irc-url-04 tools.ietf.org]</ref>
| |
| |-
| |
| | <code>itunes</code> || [[iTunes]]
| |
| |-
| |
| | <code>javascript</code> || Ausführung von [[JavaScript]]-Code<ref>[https://tools.ietf.org/html/draft-hoehrmann-javascript-scheme-03 tools.ietf.org]</ref>
| |
| |-
| |
| | <code>lastfm</code> || [[Last.fm]]
| |
| |-
| |
| | <code>magnet</code> || [[Magnet-Link]]
| |
| |-
| |
| | <code>mms</code> || [[Microsoft Media Server]]
| |
| |-
| |
| | <code>rtmp</code> || [[Real Time Messaging Protocol]]
| |
| |-
| |
| | <code>sftp</code> || [[SSH File Transfer Protocol]]<ref>[https://www.iana.org/assignments/uri-schemes/prov/sftp iana.org]</ref><ref name="sftpssh">[https://tools.ietf.org/html/draft-ietf-secsh-scp-sftp-ssh-uri-04 tools.ietf.org]</ref>
| |
| |-
| |
| | <code>skype</code> || Telefonnummern (nur [[Skype]])
| |
| |-
| |
| | <code>smb</code> || [[Server Message Block]]<ref>[https://tools.ietf.org/html/draft-crhertel-smb-url-12 tools.ietf.org]</ref>
| |
| |-
| |
| | <code>ssh</code> || [[Secure Shell]]<ref>[https://www.iana.org/assignments/uri-schemes/prov/ssh iana.org]</ref><ref name="sftpssh" />
| |
| |-
| |
| | <code>svn</code>/<code>svn+ssh</code> || [[Apache Subversion]]
| |
| |-
| |
| | <code>view-source</code> || Quelltextanzeige für eine Webseite<ref>[https://docs.microsoft.com/en-us/previous-versions//aa767742(v=vs.85) msdn.microsoft.com]</ref>
| |
| |-
| |
| | <code>webcal</code> || [[iCalendar]]
| |
| |-
| |
| | <code>wyciwyg</code> || What You Cache Is What You Get, Firefox-interne Anzeige für die Darstellung gecachter Inhalte
| |
| |-
| |
| | <code>ymsgr</code> || [[Yahoo Messenger]]
| |
| |}
| |
|
| |
| == Unterarten ==
| |
|
| |
| Es werden folgende Unterarten von URIs unterschieden:
| |
|
| |
| ; [[Uniform Resource Locator]] (URL)
| |
| : Benennen eine Ressource über ihren primären Zugriffsmechanismus wie zum Beispiel <code>[[Hypertext Transfer Protocol|http]]</code> oder <code>[[File Transfer Protocol|ftp]]</code>.
| |
| * Danach folgt die Bezeichnung des Ortes (engl. ''location'') der Ressource im Netz – meistens der Domain-Name.
| |
| * URLs waren ursprünglich die einzige Art von URIs, weshalb der Begriff URL oft gleichbedeutend mit URI verwendet wird.
| |
| ; [[Uniform Resource Name]] (URN)
| |
| : Mit dem URI-Schema <code>urn</code> identifizieren eine Ressource mittels eines vorhandenen oder frei zu vergebenden Namens, beispielsweise <code>[[Internationale Standardbuchnummer|urn:isbn]]</code> oder <code>[[SHA-1|urn:sha1]]</code>.
| |
|
| |
| Ursprünglich sollte jeder URI in eine dieser beiden Klassen (oder weitere noch zu definierende) eingeteilt werden.
| |
| * Diese strenge Aufteilung wurde jedoch aufgegeben, da sie unnötig ist und einige Schemata (wie <code>data</code> oder das früher den URLs zugeordnete <code>[[mailto]]</code>) in keine der beiden Klassen passen.
| |
|
| |
|
| [[Kategorie:Netzwerk/Adresse]] | | [[Kategorie:Netzwerk/Adresse]] |
|
| |
|
| </noinclude> | | </noinclude> |