Uniform Resource Locator

En Uniform Resource Locator ( URL ; engelsk for uniform resource pointer ) identifiserer og lokaliserer en ressurs, for eksempel et nettsted , via tilgangsmetoden som skal brukes (for eksempel nettverksprotokollen som brukes som HTTP eller FTP ) og plasseringen av ressursen i datanettverk . Den opprinnelige standarden ble utgitt som RFC 1738 i desember 1994, og har siden blitt foreldet på grunn av publiseringen av flere andre RFC -er . De nåværende RFC -ene er (fra 2016):

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

URL -er er en undertype av den generelle identifikasjonsbetegnelsen ved bruk av Uniform Resource Identifiers (URI). Siden URLer er den første og vanligste typen URI, brukes begrepene ofte om hverandre . Vanligvis blir URL -er også referert til som Internett -adresser eller webadresser , ^[1] der (etter den alminnelige ligningen for Internett og WWW ^[2] ) for det meste er spesifikke nettadresser for nettsteder ment.

konstruksjon

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

 : 

der scheme ofte, men ikke nødvendigvis, er det samme som den underliggende nettverksprotokollen (dette er tilfellet med for eksempel ftp eller http , men ikke med mailto eller file ). ^[3]

Mulige URL -deler er for eksempel med http :

 | ------------------ Schemaspesifikk del ------------------ |

 https: // max: [email protected]: 8080 / index.html? p1 = A & p2 = B # ressurs
 \ ___ / \ _ / \ ____ / \ _____________ / \ __ / \ _________ / \ _______ / \ _______ /
   | | | | | | | |
Ordning⁺ | Fragment for passordvertsportbane
       bruker

⁺ (her samme som nettverksprotokoll)

på mailto :

 mailto: [email protected]
\ ____ / \ _____________ /
   | |
Ordning⁺ |
        E -postadresse i henhold til RFC 5322

⁺ (ingen nettverksprotokoll her)

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

 nyheter: alt.hypertext
 \ __ / \ ___________ /
   | |
Ordning |
       Navnet på nyhetsgruppen

på file :

 fil: /// katalog / underkatalog / fil
 \ __ / \ ___________________________________ /
   | |
Ordning |
       Veien til en lokal fil i datamaskinens filsystem som tolker URL -en

Strengt tatt er dette skjema formen file:/// , selv om vertsdelen er praktisk talt ikke anvendes, ettersom den file ordningen er nesten aldri brukt fordi det ikke er noen måte å angi en nettverksprotokoll for tilgang til filen kan brukes fornuftig over et nettverk. ^[4] Filadresser brukes for eksempel i Java -programmeringsspråket for å få tilgang til lokale filer på denne måten. ^[5] Avhengig av nettleseren, file linker kan ofte bare bli åpnet etter en spesiell klientsiden konfigurasjon eller med hjelp av add-ons, etc. ^{[6] [7]}

Ordning (ordning)

Spesifiserer den tekniske metoden som ressursen skal adresseres med. Er stort sett, men ikke nødvendigvis, identisk med nettverksprotokollen som brukes , og som ressursen kan lokaliseres via. 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 å ha spesifikk informasjon. I de fleste tilfeller begynner den med tegnstrengen // , men i noen varianter er bare tykktarmen definert. Følgende eksempler er knyttet til Hypertext Transfer Protocol (HTTP).

Bruker og passord (bruker, passord)

Om nødvendig kan du logge inn -Informasjon fra bruker (bruker) og passord overføres (passord) med. Disse er atskilt fra hverandre med et kolon og prefikset til verten med et separeringstegn ( @ ).

Selv om HTTP -protokollen ble valgt for dette eksemplet, er ikke spesifisering av brukernavn og passord som en del av URL -adressen en del av HTTP -spesifikasjonen! ^[8] Nåværende nettlesere godtar denne URL -syntaksen, men spør brukeren om han virkelig vil logge inn med de angitte dataene. Internet Explorer 6 (fra Windows XP SP2) og nyere versjoner faller utenom det vanlige her ved å forkaste denne URL -syntaksen blankt som feil. Med en registeroppføring kan du tvinge dem til å oppføre seg på samme måte som forgjengerne opp til versjon 5.5 viser: De tar over påloggingsdataene uten å bli spurt og overfører dem direkte til serveren.

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

Vert

Vertskomponenten er atskilt med prikker i form av en IPv4 -adresse i desimalnotasjon , i form av en IPv6 -adresse i heksadesimal notasjon med kolon og plassert i firkantede parenteser eller notert i form av et FQDN . ^[9]

havn

Ved å spesifisere porten kan en TCP -port kontrolleres. Hvis ingen port er spesifisert, brukes standardporten til den respektive protokollen - for eksempel med HTTP 80, med HTTPS 443 og med FTP 21.

Sti

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

Tolkningen ( fil eller katalog ; levere tekstfil eller kjøre skript ) overlates til serveren. Et typisk eksempel på tolkningsfrihet er oppførselen når banen / forespurt av en klient: Avhengig av innstillingen forsyner serveren innholdet i en fil med et navn (for eksempel /index.html , /README , /HEADER ) uten at dette er nødvendig for den forespurende klienten kan sees. Avhengig av protokollen kan imidlertid serveren også eksplisitt videresende til denne ressursen eller sende ut en katalogoppføring.

Spørring (forespørsel)

Når det gjelder HTTP, kan den faktiske ressurspekeren følges av en spørringsstreng, atskilt med et spørsmålstegn . ^[10] Dette betyr at tilleggsinformasjon kan overføres som kan behandles videre på server- eller klientsiden.

fragment

Etter et hash -tegn kan det refereres til en del av ressursen, vanligvis et anker på en HTML -side, som automatisk rulles ned etter at siden er hentet : URL http://example.com/dokument.html#absatz3 vil være , der fiktivt dokument her, får nettleseren til å bla til begynnelsen av tredje ledd.

Eksempler

• ftp://max:[email protected] FTP med bruker og passord
• http://de.wikipedia.org nettsted uten sti (tilgang til startsiden )
• http://de.wikipedia.org/wiki/Uniform_Resource_Locator nettsted med bane
• https://de.wikipedia.org //de.wikipedia.org ... liker å ringe nettstedet uten å angi en bane, men med den krypterte Hypertext Transfer Protocol Secure
• mailto:[email protected] ... for å 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 news:alt.hypertext (generisk, uten å spesifisere nettverksprotokollen NNTP )
• nntp:alt.hypertext ... Visning av en Usenet -nyhetsgruppe (med spesifikasjon av 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 fullstendige nettadressene som er vist så langt, er det også relative nettadresser. ^[11] De er bare gyldige i en kontekst de arver eiendommer fra. Du mangler plasseringen på World Wide Web eller et ekte intranett . De er hovedsakelig mulig i gruppen http, https og ftp, men også med mailto. Det tilsvarer et telefonnummer uten retningsnummer (i landet, det lokale nettverket ).

Relative nettadresser for http, https, ftp

Begynnelse	betydning	merknad	eksempel
//	Samme protokoll	er fornuftig å bruke http: eller https: av det nåværende miljøet	//example.com/pfad/zu/datei
/	Samme domene ( host:port ), " rotkatalog "		/pfad/zu/datei
#	Samme ressurs	Effekt over bivirkning	#
# fragment	Samme ressurs, hoppetikett		#knoten
Ingenting	Samme ressurs
../	ett banesegment opp	En server må ikke / strukturere segmentering av støttebaner.	/pfad/zur/../zur/datei ./relativer/pfad
./ annen	samme stisegment

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 å koble dem til hverandre. Forresten, tolkningen av identifikatoren (tegnstreng mellom host:port og # ) er gratis for hver server - selv om den håndterer de aller fleste servere og all standard programvare som nevnt ovenfor, kan / nøyaktig hvordan ? % & blir evaluert i henhold til sine egne regler.

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

Liste over tillatte tegn

Reserverte tegn er:

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

Tegn uten forbehold er:

• Spesialtegn - . _ ~
• Bokstavene A–Z, a–z
• Siffer 0–9

I visse tilfeller er det også mellomrom   (dette kan også representeres alternativt med + , ^[12] og % ) i prosentvis koding . ^{[1. 3]}

Språkbruk

I tysk bruk har URL ofte den feminine artikkelen , men brukes også med den maskuline artikkelen. ^[14] Valget av kjønn, avhenger av om det er basert på tysk oversettelse av adressen (feminine) eller ved hjelp av grammatikk regel som substantiver begynne med eller (her locator eller ID) eller -er (-descriptor, -lokalisierer, volumindikatorer) på tysk er alltid maskulin. ^[15]

Nettadresser i tekster

Vedlegg C i RFC 3986 anbefaler bruk av URI (og derfor URLer) i tekster

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

å avgrense mot konteksten og spesielt mot punktumet i setningen.

Nettadresser og søkemotorer

Selv om URL -adresser kan ha en teknisk kompleks struktur, resulterer feil bruk av URL -strukturer ofte i problemer med optimal søkbarhet av innhold for søkemotorer. Av denne grunn kan søkemotoroperatører som B. Googles samsvar med visse anbefalinger, z. B. forsiktig bruk av parametere i nettadresser. ^[16] URL -strukturen sjekkes ofte 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 nettadressen til siden som Google mener er den mest representative for flere dupliserte sider på et nettsted. Sett fra en søkemotor z. B. URL -variantene "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 begynnelsen av WWW (fra slutten av 1990) hadde dokumentasjonen på info.cern.ch opprinnelig ingen spesifikk betegnelse for adressering av nettsteder, emnet ble bare beskrevet som "W3 -dokumentadresse", "W3 -navn", " W3 -adresse ”eller“ Hypertekstnavn ”. ^{[17] [18] [19]} Adresseformen spesifisert på den tiden (og brukt på de første nettstedene) tilsvarer allerede skjemaet som ble standardisert senere som "URL"; Selv om endringer ble vurdert i standardiseringsprosessen, ble de avvist på grunn av den avanserte spredningen av WWW. ^{[18] [20]}

Sommeren 1992 prøvde Tim Berners-Lee å opprette en arbeidsgruppe på IETF-møtet i Boston for å standardisere tilgangen til dokumenter på nettet. Han foreslo navnet Universal Document Identifier (UDI) , som han mente skulle definere en generell internettstandard. Navnet ble kritisert som for "arrogant", som hovedsakelig skyldtes ordet universelt (engelsk for generelt gyldig , omfattende ). I stedet var begrepet mer beskjeden uniform (Engl. For definert) av gruppen som ble foreslått. I tillegg har “Document” blitt erstattet av “Resource” for å understreke at nettet bør integreres med andre informasjonssystemer. URI -arbeidsgruppen ble endelig til, med et ytterligere navneendring for standarden som skulle defineres: "Identifier" ble erstattet av "Locator" for å understreke at webadresser ikke er permanent registrerte adresser. ^[21]

På grunn av gruppens konfliktfylte arbeidsmetoder ble det første - fremdeles uformelle - utkastet til standard RFC 1630 bare presentert av Berners -Lee i juni 1994. ^[20] 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 å virke så kjente eller logiske for nye brukere som mulig: ^[22]

• Banen ( http://www.example.com /verzeichnis/unterverzeichnis/datei.html ) siterer http://www.example.com /verzeichnis/unterverzeichnis/datei.html direkte i UNIX -filsystemer . ^[22]
• Vertsnotasjonen som ble introdusert med en dobbel skråstrek kommer fra syntaksen til nettverksfilsystemet til Apollo Domain / OS , der stier på eksterne verter ble adressert i henhold til mønsteret //example.com /verzeichnis/unterverzeichnis/… . ^[22]
• Fragmentet merket med et dobbelt kryss er lånt fra USAs rettskrivning for leilighets- og suitenummer i postadresser: 12 Foo Avenue # 34 står for Foo Avenue No. 12, Apartment 34 . Følgelig datei.html #ressource del (seksjon, kap ...) ressource i dokumentet datei.html . ^[22]

Se også

• Digital Object Identifier
• Homografisk angrep
• Internasjonalisert domenenavn
• Kort url -tjeneste
• Link resolver , OpenURL , Ex Libris SFX
• Semakode
• Skrivefeil
• URL -koding (prosenttegnkoding)
• URL -mal

litteratur

• Tim Berners-Lee , Mark Fischetti: Nettrapporten . Skaperen av World Wide Web om 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 . [Feil: 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 Uniform Resource Locators . Juni 1995. (foreldet av RFC 3986 - engelsk).

Individuelle bevis

1. ↑ Duden - German Universal Dictionary. 6. utgave.
2. ↑ Internett og World Wide Web - 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 -skjema #Nettleseratferd i det engelske Wikipedia
7. ^ Firefox, for eksempel, har blokkert all lokal tilgang med file: av sikkerhetsmessige årsaker siden 2012 hvis det omkringliggende dokumentet kommer fra http:// .
8. ↑ RFC 2616 - Hypertext Transfer Protocol . Del 3.2.2: http URL. Standard: [HTTP / 1.1]. (Engelsk).
9. ↑ RFC 1738 - Uniform Resource Locators (URL) . Desember 1994. Avsnitt 3.1: Felles Internett -ordningssyntaks. (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 -koding for mellomromstegnet: + eller% 20? I: stackoverflow.com. 29. april 2015, åpnet 8. april 2016 .  
13. ↑ HTML URL -kodingsreferanse. I: w3schools.com. Hentet 8. april 2016 .  
14. ↑ Duden - German Universal Dictionary , se også duden.de
15. ↑ korkturen.de - Forum - Nettadressen - (reklame) banneret . 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 navngivningsordninger. 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 .