Uniform Resource Locator

fra Wikipedia, den gratis encyklopædi
Spring til navigation Spring til søgning

En Uniform Resource Locator ( URL ; engelsk for uniform resource pointer ) identificerer og lokaliserer en ressource, f.eks. Et websted , via den adgangsmetode, der skal bruges (f.eks. Den anvendte netværksprotokol, f.eks. HTTP eller FTP ) og placeringen af ressourcen i computernetværk . Den originale standard blev udgivet som RFC 1738 i december 1994 og er siden blevet forældet på grund af offentliggørelsen af ​​flere andre RFC'er . De nuværende RFC'er er (fra 2016):

  • RFC 3986 . - Uniform Resource Identifier (URI): Generisk syntaks . (Engelsk).
  • RFC 4248 . - Telnet URI -ordningen . (Engelsk).
  • RFC 4266 . - Gopher URI -ordningen . (Engelsk).
  • RFC 6068 . - "Mailto" URI -ordningen . (Engelsk).
  • RFC 6196 . - Flytende mailserver: URI -ordning til Historisk . (Engelsk).
  • RFC 6270 . - 'tn3270' URI -ordningen . (Engelsk).

URL'er er en undertype af den generelle identifikationsbetegnelse ved hjælp af Uniform Resource Identifiers (URI'er). Da URL'er er den første og mest almindelige type URI, bruges udtrykkene ofte i flæng . I almindelig sprogbrug omtales URL'er også som internetadresser eller webadresser , [1] hvorved (efter den almindelige ligning mellem Internet og WWW [2] ) for det meste menes med specifikke webadresser på websteder .

konstruktion

Grundstrukturen består af en URL-adgangsmetode, der definerer skemnavn (engelsk skema) og en skemaspecifik del ( skemaspecifik del), som er adskilt af et kolon:

 <skema>: <skema-specifik-del>

hvor scheme ofte, men ikke nødvendigvis, er den samme som den underliggende netværksprotokol (dette er f.eks. tilfældet med ftp eller http , men ikke med mailto eller file ). [3]

Mulige URL -dele er f.eks. Med http :

 | ------------------ Skemaspecifik del ------------------ |

 https: // max: [email protected]: 8080 / index.html? p1 = A & p2 = B # ressource
 \ ___ / \ _ / \ ____ / \ _____________ / \ __ / \ _________ / \ _______ / \ _______ /
   | | | | | | | |
Ordning⁺ | Adgangskodeværtsport -sti -forespørgselsfragment
       bruger

⁺ (her det samme som netværksprotokol)

mailto :

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

⁺ (ingen netværksprotokol her)

for news (i dette eksempel er hverken en netværksprotokol eller en værtsadresse inkluderet):

 nyheder: alt.hypertext
 \ __ / \ ___________ /
   | |
Ordning |
       Nyhedsgruppens navn

ved file :

 fil: /// bibliotek / underkatalog / fil
 \ __ / \ ___________________________________ /
   | |
Ordning |
       Sti til en lokal fil i computerens filsystem, der fortolker URL'en

Strengt taget er denne ordning har formen file://<host>/<path> , selvom værten del er stort set ikke brugt, da den file ordning næppe er aldrig brugt, fordi der ikke er nogen mulighed for at angive en netværksprotokol for adgang til fil kan bruges fornuftigt over et netværk. [4] Fil -URL'er bruges f.eks. I programmeringssproget Java til at få adgang til lokale filer på denne måde. [5] Afhængigt af browseren, file links kan ofte kun åbnes efter en særlig klientsiden konfiguration eller ved hjælp af add-ons, etc. [6] [7]

Skema (skema)

Angiver den tekniske metode, hvormed ressourcen skal adresseres. Er for det meste, men ikke nødvendigvis, identisk med den anvendte netværksprotokol , via hvilken ressourcen kan lokaliseres. Eksempler er HTTP , HTTPS eller FTP , men også mailto (til at skrive en e-mail) eller file (for at få adgang til lokale filer).

Skemaspecifik del (skemaspecifik del)

Afhængigt af ordningen er forskellige specifikke oplysninger påkrævet og mulige. I de fleste tilfælde begynder det med tegnstrengen // , men i nogle varianter er kun kolon defineret. Følgende eksempler vedrører Hypertext Transfer Protocol (HTTP).

Bruger og adgangskode (bruger, adgangskode)

Hvis det er nødvendigt, kan du logge -Information fra bruger (bruger) og adgangskode overføres (adgangskode) med. Disse adskilles fra hinanden med et kolon og præfikseres til værten med et adskillelsestegn ( @ ).

Selvom HTTP -protokollen blev valgt til dette eksempel, er angivelse af brugernavn og adgangskode som en del af URL'en ikke en del af HTTP -specifikationen! [8] Nuværende browsere accepterer denne URL -syntaks, men spørg brugeren, om han virkelig vil logge ind med de angivne data. Internet Explorer 6 (fra Windows XP SP2) og nyere versioner falder ud over det sædvanlige her ved blankt at afvise denne URL -syntaks som forkert. Med en registreringspost kan du tvinge dem til at opføre sig på samme måde som forgængerne op til version 5.5 viser: De overtager login -data uden at blive spurgt og overfører dem direkte til serveren.

Med nogle andre protokoller, f.eks. FTP , er specifikationen af ​​brugerdata i den viste form fuldstændig korrekt og omfattet af standarderne.

Vært

Værtskomponenten er adskilt af prikker i form af en IPv4 -adresse i decimalnotation , i form af en IPv6 -adresse i hexadecimal notation med kolon og placeret i firkantede parenteser eller noteret i form af et FQDN . [9]

Havn

Ved at angive porten kan en TCP -port kontrolleres. Hvis der ikke er angivet en port, bruges standardporten for den respektive protokol - f.eks. Med HTTP 80, med HTTPS 443 og med FTP 21.

Sti

Stien beskriver en bestemt ressource (dette kan f.eks. Falde sammen med mappesystemets mappestruktur, f.eks. En fil eller et bibliotek) på serveren . Stien kan også være tom. En tom sti kan eventuelt erstattes af et skråstreg og har samme betydning. [3]

Fortolkningen ( fil eller bibliotek ; lever tekstfil eller eksekver script ) overlades til serveren. Et typisk eksempel på fortolkningsfriheden er adfærden, når stien / efterspørges af en klient: Afhængigt af indstillingen forsyner serveren indholdet i en fil med et navn (f.eks. /index.html , /README , /HEADER ) uden at dette er nødvendigt for den anmodende klient kan ses. Afhængigt af protokollen kan serveren imidlertid også eksplicit videresende til denne ressource eller sende en biblioteksliste.

Forespørgsel (forespørgsel)

I tilfælde af HTTP kan den faktiske ressourcemarkør efterfølges af en forespørgselsstreng adskilt af et spørgsmålstegn . [10] Det betyder, at der kan overføres yderligere oplysninger, der kan behandles yderligere på server- eller klientsiden.

fragment

Efter et hash -tegn kan der refereres til en del af ressourcen, typisk et anker på en HTML -side, som automatisk rulles ned efter at have kaldt siden op: URL'en http://example.com/dokument.html#absatz3 ville være , hvor fiktivt dokument her, hvilket får browseren til at rulle til begyndelsen af ​​tredje afsnit.

Eksempler

  • ftp://max:[email protected] FTP med bruger og adgangskode
  • http://de.wikipedia.org websted uden sti (adgang til startsiden )
  • http://de.wikipedia.org/wiki/Uniform_Resource_Locator websted med sti
  • https://de.wikipedia.org //de.wikipedia.org ... som at ringe til webstedet uden at angive en sti, men med den krypterede Hypertext Transfer Protocol Secure
  • mailto:[email protected] ... for at skrive en e-mail til den angivne mailadresse (åbner standard mailklienten med en ny, tom besked, hvor TO-adressen er udfyldt på forhånd)
  • news:alt.hypertext ... Visning af en Usenet news:alt.hypertext (generisk, uden at angive netværksprotokollen NNTP )
  • nntp:alt.hypertext ... Visning af en Usenet nntp:alt.hypertext (med specifikation af netværksprotokollen NNTP)
  • telnet:example.org ... start en Telnet -session
  • file:///foo/bar.txt adgang til en lokal fil

Relative webadresser

Ud over de absolutte eller fulde webadresser, der er vist hidtil, er der også relative webadresser. [11] De er kun gyldige inden for en kontekst, hvorfra de arver ejendomme. Du mangler placeringen på World Wide Web eller et rigtigt intranet . De er hovedsageligt mulige i http-, https- og ftp -gruppen, men også med mailto. Det svarer til et telefonnummer uden et områdenummer (af landet, lokalnetværket ).

Relative webadresser til http, https, ftp
Starten betyder annotation eksempel
// Samme protokol giver mening at bruge http: eller https: i det aktuelle miljø //example.com/pfad/zu/datei
/ Samme domæne ( host:port ), " rodmappe " /pfad/zu/datei
# Samme ressource Effekt over bivirkning #
# fragment Samme ressource, spring etiket #knoten
Ikke noget Samme ressource
../ et stisegment op En server må ikke / struktureret segmentering af supportstier. /pfad/zur/../zur/datei
./relativer/pfad
./
Andet
samme stisegment

Relative webadresser bruges ofte til at gemme en gruppe relaterede ressourcer enten i et lokalt filsystem eller på forskellige steder i forskellige netværksdomæner uændret og til at linke dem til hinanden. I øvrigt er fortolkningen af ​​identifikatoren (tegnstreng mellem host:port og # ) gratis for hver server - selvom den håndterer langt de fleste servere og al standardsoftware som angivet ovenfor, kan / præcis hvordan ? % & vurderes i henhold til deres egne regler.

Med mailto: en relativ URL ville være mailto:Nachbar (uden @ ) - den er kun gyldig i det lokale netværk.

Liste over tilladte tegn

Reserverede tegn er:

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

Tegn uden forbehold er:

  • Specialtegn - . _ ~
  • Bogstaverne A–Z, a–z
  • Cifre 0–9

I visse tilfælde er der også mellemrum   (dette kan også repræsenteres alternativt med + , [12] og % ) i procentvis kodning . [13]

Sprogbrug

I tysk brug har URL ofte den feminine artikel , men bruges også med den maskuline artikel. [14] Valget af køn afhænger af, om den er baseret på den tyske oversættelse af adressen (feminine) eller ved hjælp af grammatik regel, at substantiver starte med -eller (her locator eller identifikator) eller -er (-descriptor, -lokalisierer, indikatorer for volumen) på tysk er altid maskuline. [15]

URL'er i tekster

Tillæg C i RFC 3986 anbefaler at bruge URI'er (og derfor URL'er) i tekster

  • uafhængigt på en linje,
  • med dobbelte citater "http://example.com/" eller
  • med vinkelbeslag <http://example.com/>

at afgrænse mod konteksten og især mod sætningens tegnsætning .

URL'er og søgemaskiner

Selvom webadresser kan have en teknisk kompleks struktur, resulterer forkert brug af webadressestrukturer ofte i problemer med hensyn til optimal søgbarhed af indhold af søgemaskiner. Af denne grund vil søgemaskineoperatører som f.eks B. Googles overholdelse af visse anbefalinger, z. B. omhyggelig brug af parametre i webadresser. [16] URL -strukturen kontrolleres ofte som en del af det, der kaldes søgemaskineoptimering . Søgemaskineoperatøren Google har også introduceret den kanoniske UR L som sin egen terminologi. En kanonisk URL er webadressen til den side, som Google mener er den mest repræsentative for flere dublerede sider på et websted. Set fra en søgemaskine z. B. URL -varianterne "http://www.example.com/" , "http://example.com/" , "https://www.example.com/" und "https://example.com/" fire uafhængige versioner, som - hvis ingen kanonisk URL er defineret - kan føre til" duplikeret indhold "og dermed mindre end optimal synlighed.

historie

Navn og standardisering

I de tidlige dage af WWW (fra slutningen af ​​1990) havde dokumentationen på info.cern.ch oprindeligt ingen specifik betegnelse for adressering af websteder, emnet blev kun beskrevet som "W3 -dokumentadresse", "W3 -navn", " W3 -adresse ”eller“ Hypertekstnavn ”. [17] [18] [19] Den adresseringsform, der var angivet på det tidspunkt (og bruges på de første websteder), svarer allerede til den formular, der senere blev standardiseret som "URL"; Selvom ændringer blev overvejet i standardiseringsprocessen, blev de afvist på grund af WWW's avancerede spredning. [18] [20]

I sommeren 1992 forsøgte Tim Berners-Lee at nedsætte en arbejdsgruppe ved IETF-mødet i Boston for at standardisere adgangen til dokumenter på nettet. Han foreslog navnet Universal Document Identifier (UDI) , som han mente skulle definere en generel internetstandard. Navnet blev kritiseret som for "arrogant", hvilket hovedsageligt skyldtes ordet universal (engelsk for generelt gyldigt , omfattende ). I stedet var udtrykket mere beskeden ensartet (Engl. For defineret) af den foreslåede gruppe. Derudover er "Dokument" blevet erstattet af "Ressource" for at understrege, at nettet skal integreres med andre informationssystemer. URI -arbejdsgruppen blev endelig til, med et yderligere navneskift for standarden, der skulle defineres: "Identifier" blev erstattet af "Locator" for at understrege, at webadresser ikke er permanent registrerede adresser. [21]

På grund af gruppens konfliktramte arbejdsmetoder blev det første - stadig uformelle - udkast til standard RFC 1630 først præsenteret af Berners -Lee i juni 1994. [20] Han nævner navnet "Universal Resource Identifiers" foretrukket af Berners-Lee i titlen og definerer allerede udtrykkene URI, URL og URN . I december 1994 offentliggjorde gruppen RFC 1738, standarden med titlen "Uniform Resource Locators (URL)".

Komponenter

Berners-Lee lånte bevidst nogle af de enkelte komponenter fra eksisterende systemer for at få webadresser til at fremstå så umiddelbart velkendte eller logiske for nye brugere som muligt: [22]

  • Stien ( http://www.example.com /verzeichnis/unterverzeichnis/datei.html ) citerer direkte stisyntaksen i UNIX -filsystemer . [22]
  • Værtsnotationen introduceret med et dobbelt skråstreg stammer fra syntaksen i netværksfilsystemet i Apollo Domain / OS , hvor stier på eksterne værter blev adresseret i henhold til mønsteret //example.com /verzeichnis/unterverzeichnis/… . [22]
  • Fragmentet markeret med et dobbelt kryds er lånt fra den amerikanske stavemåde til lejligheds- og suite -numre på postadresser: 12 Foo Avenue # 34 står for Foo Avenue No. 12, Apartment 34 . Derfor datei.html #ressource del (afsnit, kapitel ...) ressource i dokumentet datei.html . [22]

Se også

Wiktionary: URL - forklaringer på betydninger, ordoprindelse, synonymer, oversættelser

litteratur

  • Tim Berners-Lee , Mark Fischetti: Webrapporten . Skaberen af ​​World Wide Web om Internets ubegrænsede potentiale . Econ, München 1999, ISBN 3-430-11468-3 (engelsk: Weaving the Web: The Original Design and Ultimate Destiny of the World Wide Web .).

Weblinks

  • RFC 3986 . - Uniform Resource Identifier (URI): Generisk syntaks . [Fejl: RFC 3986 ]. Januar 2005. (Erstatter RFC 2732 - Opdateret af RFC 6874 - Engelsk).
  • T. Berners-Lee, L. Masinter, M. McCahill: RFC 1738 . - Uniform Resource Locators (URL) . [Fejl: RFC 1738 ]. December 1994. (Opdateret af RFC 1808 - engelsk).
  • R. Fielding: RFC 1808 . - Relative Uniform Resource Locators . Juni 1995. (Forældet af RFC 3986 - engelsk).

Individuelle beviser

  1. Duden - Tysk universel ordbog. 6. udgave.
  2. Internet og World Wide Web - forskellen. News.de, 29. oktober 2009, åbnede 11. december 2010 .
  3. a b RFC 3986 - Uniform Resource Identifier (URI): Generisk syntaks . Januar 2005. Afsnit 3.3: Sti. (Engelsk).
  4. RFC 1738 - Uniform Resource Locators (URL) . December 1994. Afsnit 3.10: FILER. (Engelsk).
  5. Klassefil (Java 1.5.0 API). Oracle , adgang til 11. december 2010 .
  6. Fil URI -skema #Browseradfærd i det engelske sprog Wikipedia
  7. ^ Firefox har for eksempel blokeret al lokal adgang med file: af sikkerhedsmæssige årsager siden 2012, hvis det omgivende dokument kommer fra http:// .
  8. ^ RFC 2616 - Hypertext Transfer Protocol . Afsnit 3.2.2: http URL. Standard: [HTTP / 1.1]. (Engelsk).
  9. RFC 1738 - Uniform Resource Locators (URL) . December 1994. Afsnit 3.1: Common Internet Scheme Syntax. (Engelsk).
  10. RFC 1738 - Uniform Resource Locators (URL) . December 1994. Afsnit 3.3: HTTP. (Engelsk).
  11. ^ RFC 3986 - Uniform Resource Identifier (URI): Generisk syntaks . Januar 2005. Afsnit 4.2: Relativ reference. (Engelsk).
  12. Matas Vaitkevicius: URL, der koder for mellemrumstegnet: + eller% 20? I: stackoverflow.com. 29. april 2015, adgang til 8. april 2016 .
  13. HTML URL -kodningsreference. I: w3schools.com. Hentet 8. april 2016 .
  14. Duden - German Universal Dictionary , se også duden.de
  15. korkturen.de - Forum - Webadressen - (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, adgang til 22. december 2010 .
  18. a b W3 navngivningsordninger. CERN / W3C, 24. februar 1992, adgang til 22. december 2010 .
  19. W3 -adressesyntaks: BNF. CERN / W3C, 29. juni 1992, adgang til 22. december 2010 .
  20. a b Berners-Lee 1999, s. 63.
  21. Berners-Lee 1999, s. 62.
  22. a b c d Tim Berners -Lee:Ofte stillede spørgsmål - Hvorfor //, #, osv.? 20. november 2007, adgang til 22. december 2010 .