Uniform Resource Locator

En Uniform Resource Locator (Forkortet URL ; engelsk for ensartet ressursindikator ) for å identifisere og finne en ressurs, for eksempel en webside der tilgangsmetoden brukes (for eksempel den brukte nettverksprotokollen som HTTP eller FTP ) og plasseringen ( engl. plassering av ressursen) i datanettverk . Den opprinnelige standarden ble utgitt som RFC 1738 i desember 1994 , og har siden blitt foreldet med publiseringen av flere andre RFCer . De nåværende RFC-ene er (fra og med 2016):

• RFC 3986 . - Uniform Resource Identifier (URI): Generisk syntaks . (Engelsk).
• RFC 4248 . - Telnet URI-ordningen . (Engelsk).
• RFC 4266 . - Gopher URI-ordningen . (Engelsk).
• RFC 6068 . - URI-ordningen 'mailto' . (Engelsk).
• RFC 6196 . - Flytter e-postserver: URI-ordningen til historisk . (Engelsk).
• RFC 6270 . - URI-ordningen 'tn3270' . (Engelsk).

URL-er er en undertype av den generelle identifikasjonsbetegnelsen ved bruk av Uniform Resource Identifiers (URI). Siden URL-er er den første og vanligste typen URI, brukes begrepene ofte om hverandre . I vanlig språkbruk blir URL-er også referert til som Internett- adresser eller nettadresser , hvorved (etter den generelle ligningen av Internett og WWW ) menes det meste spesifikke nettadresser til nettsteder .

konstruksjon

Den grunnleggende strukturen består av en URL-tilgangsmetode som definerer skjema navn (engelsk ordning ) og en skjemaspesifikk del (ordningsspesifikk del) , som er atskilt med et kolon:

<scheme>:<scheme-specific-part>

hvor schemeofte, men ikke nødvendigvis, er det samme som den underliggende nettverksprotokollen (med ftpeller httper tilfelle for eksempel, men ikke mailtoeller file).

Mulige URL-deler er for eksempel http:

       |------------------ Schema-spezifischer Teil ------------------|

 https://max:muster@www.example.com:8080/index.html?p1=A&p2=B#ressource
 \___/   \_/ \____/ \_____________/ \__/\_________/ \_______/ \_______/
   |      |    |           |         |       |          |         |
Schema⁺   | Kennwort      Host      Port    Pfad      Query    Fragment
       Benutzer

⁺ (hier gleich Netzwerkprotokoll)

på mailto:

mailto:max@example.org
\____/ \______________/
   |          |
Schema⁺       |
        E-Mail-Adresse gemäß RFC 5322

⁺ (hier kein Netzwerkprotokoll)

på news(i dette eksemplet er verken en nettverksprotokoll eller en vertsadresse inkludert):

 news:alt.hypertext
 \__/ \___________/
   |        |
Schema      |
       Name der Newsgroup

på file:

 file:///verzeichnis/unterverzeichnis/datei
 \__/ \___________________________________/
   |                    |
Schema                  |
       Pfad zu einer lokalen Datei im Dateisystem des Rechners, der den URL interpretiert

Strengt tatt har denne ordningen skjemaet file://<host>/<path>, men vertsdelen brukes praktisk talt ikke, siden fileordningen knapt kan brukes meningsfullt over et nettverk på grunn av mangel på en måte å spesifisere en nettverksprotokoll for tilgang til filen. Fil-URL-er brukes i programmeringsspråket Java , for eksempel for å få tilgang til lokale filer på denne måten. Avhengig av nettleser kan filelenker ofte bare åpnes etter en spesiell konfigurasjon på klientsiden eller ved hjelp av tillegg osv.

Ordning (ordning)

Spesifiserer den tekniske metoden som ressursen skal adresseres med. Er for det meste, men ikke nødvendigvis, identisk med nettverksprotokollen som brukes , som ressursen kan lokaliseres gjennom. Eksempler er HTTP , HTTPS eller FTP , men også mailto(for å skrive en e-post) eller file(for å få tilgang til lokale filer).

Skjemaspesifikk del (ordningsspesifikk del)

Avhengig av ordningen, er det nødvendig og mulig med annen spesifikk informasjon. I de fleste tilfeller begynner det med tegnstrengen //, men i noen varianter er bare kolon definert. Følgende eksempler relaterer seg til Hypertext Transfer Protocol (HTTP).

Bruker og passord (bruker, passord)

Om nødvendig kan du logge på - Informasjon fra bruker (bruker) og passord (passord) som skal overføres. Disse er skilt fra hverandre med et kolon og foran en vert med en separering ved tegn ( @ ).

Selv om HTTP- protokollen ble valgt for dette eksemplet , er det ikke en del av HTTP-spesifikasjonen å spesifisere brukernavn og passord som en del av URL- en! Nåværende nettlesere godtar denne URL-syntaksen, men spør brukeren om han virkelig vil logge på med de angitte dataene. The Internet Explorer  6 (Windows XP SP2) og senere faller her ut av rammen ved kategorisk avvise denne URL-syntaks for å være defekt. Med en registeroppføring kan du tvinge dem til å oppføre seg på samme måte som forgjengerne frem til versjon 5.5 viser: De overtar påloggingsdataene uten å bli spurt og overfører dem direkte til serveren.

Med noen andre protokoller, for eksempel FTP , er spesifikasjonen av brukerdataene i det viste skjemaet helt korrekt og dekket av standardene.

Vert

Vertkomponenten er atskilt i form av en IPv4- adresse i desimalnotasjon med prikker, i form av en IPv6- adresse i heksadesimal notasjon av kolon og plassert i firkantede parenteser eller notert i form av en FQDN .

havn

Spesifisere den porten gjør at en TCP -port som skal styres . Hvis ingen port er spesifisert, brukes standardporten til den respektive protokollen - for eksempel med HTTP 80, med HTTPS 443 og med FTP 21.

Sti (Sti)

Banen beskriver en bestemt ressurs (dette kan for eksempel sammenfalle med katalogstrukturen til målsystemet, f.eks. En fil eller en katalog) på serveren . Stien kan også være tom. En tom bane kan eventuelt erstattes av en skråstrek og har samme betydning.

Tolkningen ( fil eller katalog ; lever tekstfil eller kjør skript ) overlates til serveren. Et typisk eksempel for tolkningen av frihet er virkemåten på anmodning fra banen /ved en klient: Serveren leverer omtrent Avhengig av innstillingen av innholdet av en spesiell utmerket fil (for eksempel /index.html, /README, /HEADER), uten at dette er klart for den forespørrende klient. Avhengig av protokollen kan serveren imidlertid også videresende eksplisitt til denne ressursen eller sende en katalogoppføring.

Spørring (spørring)

I tilfelle HTTP kan den faktiske ressurspekeren følges av  en spørringsstreng, atskilt med et spørsmålstegn . Dette betyr at det kan overføres tilleggsinformasjon som kan behandles videre på server- eller klientsiden.

fragment

Etter et hash-merke kan det refereres til en del av ressursen, vanligvis et anker i en HTML-side, som automatisk rulles ned etter at siden er kalt: URL-en http://example.com/dokument.html#absatz3i det fiktive dokumentet her vil føre til at nettleseren går til begynnelsen av den tredje For å bla gjennom avsnittet.

Eksempler

• ftp://max:muster@ftp.example.com... FTP med bruker og passord
• http://de.wikipedia.org... nettsted uten sti (ring opp startsiden )
• http://de.wikipedia.org/wiki/Uniform_Resource_Locator ... nettsted med sti
• https://de.wikipedia.org... som å ringe opp nettstedet uten å spesifisere en sti, men med den krypterte Hypertext Transfer Protocol Secure
• mailto:hans@example.org... å skrive en e-post til den angitte e-postadressen (åpner standard e-postklient med en ny, tom melding der TO-adressen er forhåndsutfylt)
• news:alt.hypertext... visning av en Usenet- nyhetsgruppe (generisk, uten å spesifisere NNTP- nettverksprotokollen )
• nntp:alt.hypertext ... visning av en Usenet-nyhetsgruppe (spesifiserer nettverksprotokollen NNTP)
• telnet:example.org... Start en Telnet- økt
• file:///foo/bar.txt ... Tilgang til en lokal fil

Relative nettadresser

I tillegg til de absolutte eller fulle URL-ene som er vist hittil, er det også relative URL-er. De er bare gyldige i en sammenheng som de arver eiendommer fra. Du mangler stedet på Internett eller et ekte intranett . De er hovedsakelig mulige i http-, https- og ftp-gruppen, men også med mailto. Det tilsvarer et telefonnummer uten retningsnummer (av landet, lokalnettverket ).

Relative URL-er brukes ofte til å lagre en gruppe relaterte ressurser enten i et lokalt filsystem eller på forskjellige steder i forskjellige nettverksdomener uendret og for å knytte dem til hverandre. I tillegg er tolkningen av identifikatoren (tegnstreng mellom host:portog #) gratis for hver server - selv om den håndterer de aller fleste servere og all standard programvare som spesifisert ovenfor, kan den evalueres /nøyaktig som i ? % &henhold til sine egne regler.

Med mailto:vil være en relativ URL mailto:Nachbar(uten  @) - den er bare gyldig i det lokale nettverket.

Liste over tillatte tegn

Reserverte tegn er:

• spesiell karakter / ? # [ ] @ : $ & ' ( ) * + , ; =

Uforbeholdne tegn er:

• spesiell karakter - . _ ~
• bokstaver A–Z, a–z
• Sifre 0–9

I visse tilfeller må plassen  (alternativt med +, og %) også vises i prosentkoding .

Bruk av språk

I tysk bruk har URL ofte den feminine artikkelen , men brukes også med den maskuline artikkelen. Valget av slekten avhenger av om det er basert på den tyske oversettelsen av adressen (feminin) er dannet eller at substantiv ved bruk av grammatikkregelen -eller (her Locator eller -identifikator ) eller -er ( designator , -lokalisierer , - anzeiger ) er alltid maskuline på tysk.

URLer i tekster

Vedlegg C i RFC 3986 anbefaler bruk av URI-er (og derfor URL-er) i tekster

• uavhengig på en linje,
• med doble anførselstegn "http://example.com/"eller
• med vinkelfester <http://example.com/>

å avgrense mot sammenhengen og spesielt mot tegnsetting av setningen.

URLer og søkemotorer

Selv om URL-er kan ha en teknisk kompleks struktur, fører feil bruk av URL-strukturer ofte til problemer med hensyn til søkemotors optimale funn. Av denne grunn, søkemotoroperatører som B. Google overholder visse anbefalinger, z. B. nøye bruk av parametere i nettadresser. URL-strukturen blir ofte sjekket som en del av det som kalles søkemotoroptimalisering . Søkemotoroperatøren Google har også introdusert den kanoniske UR L som sin egen terminologi . En kanonisk URL er URL-en til siden som Google mener er den mest representative for flere dupliserte sider på et nettsted. Fra et søkemotors synspunkt z. URL-variantene er for eksempel "http://www.example.com/" , "http://example.com/" , "https://www.example.com/" und "https://example.com/"fire uavhengige versjoner som - hvis ingen kanonisk URL er definert - kan føre til "duplisert innhold" og dermed mindre enn optimal synlighet.

historie

Navn og standardisering

I de tidlige dagene av WWW (fra slutten av 1990) var det info.cern.chopprinnelig ingen spesifikk betegnelse for adressering av nettsteder i dokumentasjonen , emnet var bare beskrivende som "W3 dokumentadresse", "W3 navn", "W3 adresse" eller "Hypertext Name" er dokumentert. Adresseformen som ble spesifisert på det tidspunktet (og brukt på de første nettstedene) tilsvarer allerede skjemaet som senere ble standardisert som "URL"; Selv om endringer ble vurdert i standardiseringsprosessen, ble de avvist på grunn av den avanserte spredningen av WWW.

Sommeren 1992, på IETF-møtet i Boston , prøvde Tim Berners-Lee å sette opp en arbeidsgruppe for å standardisere tilgangen til dokumenter på nettet. Han foreslo navnet Universal Document Identifier (UDI) , som ifølge hans konsept en generell internettstandard skulle defineres. Navnet ble kritisert som for "arrogant", noe som hovedsakelig skyldtes ordet universal (engelsk for generelt gyldig , omfattende ). I stedet ble de mer beskjedne begrep skapt av gruppen uniform (Engl. For uniform ) foreslått. I tillegg er “Dokument” erstattet av “Ressurs” for å understreke at nettet skal integreres med andre informasjonssystemer. URI-arbeidsgruppen ble til slutt til, med en ytterligere navneendring for standarden som skulle defineres: "Identifier" ble erstattet av "Locator" for å understreke at nettadresser ikke er permanent registrerte adresser.

På grunn av gruppens konfliktfylte arbeidsmetoder ble det første - fortsatt uformelle - utkastet til standard RFC 1630 presentert av Berners-Lee i juni 1994. Han nevner navnet "Universal Resource Identifiers" favorisert av Berners-Lee i tittelen og definerer allerede begrepene URI, URL og URN . I desember 1994 publiserte gruppen RFC 1738, standarden "Uniform Resource Locators (URL)".

Komponenter

Berners-Lee lånte noen av de enkelte komponentene bevisst fra eksisterende systemer for å få webadresser til å fremstå så umiddelbart kjent eller logisk for nye brukere som mulig:

• Stien ( ) siterer direkte syntaks i UNIX-filsystemer .http://www.example.com/verzeichnis/unterverzeichnis/datei.html
• Vertnotasjonen introdusert med et dobbelt skråstrek kommer fra syntaksen til nettverksfilsystemet til Apollo Domain / OS , der baner på eksterne verter //example.com/verzeichnis/unterverzeichnis/…ble adressert i henhold til mønsteret .
• Fragmentet merket med et dobbelt kryss er lånt fra den amerikanske stavemåten for leilighets- og suitenumre i postadresser: 12 Foo Avenue # 34 står for Foo Avenue No. 12, Apartment 34 . Tilsvarende betyr del (seksjon, kapittel ...) i dokumentet .datei.html#ressource ressourcedatei.html

Se også

• Digital objektidentifikator
• Homografisk angrep
• Internasjonalisert domenenavn
• Kort url-tjeneste
• Link resolver , OpenURL , Ex Libris SFX
• Semakode
• Typosquatting
• URL-koding (prosenttegn-koding)
• URL-mal

Wiktionary: URL  - forklaringer av betydninger, ordets opprinnelse, synonymer, oversettelser

litteratur

• Tim Berners-Lee , Mark Fischetti: Nettrapporten . Skaperen av World Wide Web på internettets ubegrensede potensial . Econ, München 1999, ISBN 3-430-11468-3 (engelsk: Weaving the Web: The Original Design and Ultimate Destiny of the World Wide Web .). 

weblenker

• RFC 3986 . - Uniform Resource Identifier (URI): Generisk syntaks . [Errata: RFC 3986 ]. Januar 2005. (Erstatter RFC 2732 - Oppdatert av RFC 6874  - engelsk).
• T. Berners-Lee, L. Masinter, M. McCahill:  RFC 1738 . - Uniform Resource Locators (URL) . [Errata: RFC 1738 ]. Desember 1994. (Oppdatert av RFC 1808  - engelsk).
• R. Fielding:  RFC 1808 . - Relative enhetlige ressurssøkere . Juni 1995. (foreldet av RFC 3986 - engelsk).

Individuelle bevis

1. ↑ Duden - tysk universell ordbok. 6. utgave.
2. ↑ Internett og internett - forskjellen. News.de, 29. oktober 2009, åpnet 11. desember 2010 . 
3. ↑ ^{a b} RFC 3986  - Uniform Resource Identifier (URI): Generisk syntaks . Januar 2005. Avsnitt 3.3: Sti. (Engelsk).
4. ↑ RFC 1738  - Uniform Resource Locators (URL) . Desember 1994. Avsnitt 3.10: FILER. (Engelsk).
5. ↑ Klassefil (Java 1.5.0 API). Oracle , åpnet 11. desember 2010 . 
6. ↑ Fil URI-ordning #Browser-oppførsel på engelsk på Wikipedia
7. ↑ Firefox har for eksempel sperret all lokal tilgang av sikkerhetsmessige årsaker siden file:det omkringliggende dokumentet stammer fra http://.
8. ↑ RFC 2616  - Hypertext Transfer Protocol . Seksjon 3.2.2: http URL.  Standard: [HTTP / 1.1]. (Engelsk).
9. ↑ RFC 1738  - Uniform Resource Locators (URL) . Desember 1994. Avsnitt 3.1: Syntaks for felles internettplan. (Engelsk).
10. ↑ RFC 1738  - Uniform Resource Locators (URL) . Desember 1994. Avsnitt 3.3: HTTP. (Engelsk).
11. ↑ RFC 3986  - Uniform Resource Identifier (URI): Generisk syntaks . Januar 2005. Avsnitt 4.2: Relativ referanse. (Engelsk).
12. ↑ Matas Vaitkevicius: URL som koder mellomromstegnet: + eller% 20? I: stackoverflow.com. 29. april 2015, Hentet 8. april 2016 .  
13. ↑ Referanse til HTML-koding. I: w3schools.com. Hentet 8. april 2016 .  
14. ↑ Duden - German Universal Dictionary , se også duden.de
15. ↑ korkturen.de - Forum - URL: en - (reklamebanneret) . I: korkturen.de .
16. ↑ Hold URL-strukturen enkel | Google Search Central. Hentet 25. februar 2021 . 
17. ↑ Tekniske detaljer. CERN / W3C, 13. november 1992, åpnet 22. desember 2010 . 
18. ↑ ^{a b} W3 Navneplaner. CERN / W3C, 24. februar 1992, åpnet 22. desember 2010 . 
19. ↑ W3-adressesyntaks: BNF. CERN / W3C, 29. juni 1992, åpnet 22. desember 2010 . 
20. ↑ ^{a b} Berners-Lee 1999, s. 63.
21. ↑ Berners-Lee 1999, s. 62.
22. ↑ ^{a b c d} Tim Berners-Lee: Ofte stilte spørsmål - Hvorfor //, #, etc? 20. november 2007, åpnet 22. desember 2010 .