Uniform Resource Identifier - Uniform Resource Identifier

"URI" omdirigerer her. For anden anvendelse, se URI (disambiguation) .
Uniform Resource Identifier (URI)
Domæne Internettet
Forkortelse URI

En Uniform Resource Identifier ( URI ) er en unik karaktersekvens, der identificerer en logisk eller fysisk ressource, der bruges af webteknologier. URI'er kan bruges til at identificere alt, inklusive virkelige objekter, såsom mennesker og steder, begreber eller informationsressourcer såsom websider og bøger. Nogle URI'er giver et middel til at lokalisere og hente informationsressourcer på et netværk (enten på Internettet eller på et andet privat netværk, f.eks. Et computerfilsystem eller et intranet); disse er Uniform Resource Locators (URL'er). En URL angiver ressourcens placering. En URI identificerer ressourcen ved navn på den angivne placering eller URL. Andre URI'er giver kun et unikt navn, uden at det er muligt at lokalisere eller hente ressourcen eller information om den, er disse Uniform Resource Names (URN'er). De webteknologier, der bruger URI'er, er ikke begrænset til webbrowsere. URI'er bruges til at identificere alt, der er beskrevet ved hjælp af RDF ( Resource Description Framework ), f.eks. Begreber, der er en del af en ontologi, der er defineret ved hjælp af Web Ontology Language (OWL), og personer, der beskrives ved hjælp af Friend of a Friend -ordforråd, ville hver have en individuel URI.

Historie

Forestilling

URI'er og webadresser har en delt historik. I 1990 introducerede Tim Berners-Lees forslag til hypertekst implicit ideen om en URL som en kort streng, der repræsenterer en ressource, der er målet for et hyperlink . På det tidspunkt omtalte folk det som et "hypertekstnavn" eller "dokumentnavn".

I løbet af de næste tre og et halvt år, da World Wide Web's kerneteknologier inden for HTML, HTTP og webbrowsere udviklede sig, opstod der et behov for at skelne mellem en streng, der gav en adresse til en ressource fra en streng, der blot navngav en ressource. Selvom det endnu ikke er formelt defineret, kom udtrykket Uniform Resource Locator til at repræsentere førstnævnte, og det mere omstridte Uniform Resource Name kom til at repræsentere sidstnævnte. I juli 1992 omtaler Berners-Lees rapport om IETF "UDI (Universal Document Identifiers) BOF " URL'er (som Uniform Resource Locators), URN'er (oprindeligt som Unique Resource Numbers) og behovet for at chartre en ny arbejdsgruppe. I november 1992 mødtes IETF "URI Working Group" for første gang.

Under debatten definerer URL'er og urner, blev det klart, at begreberne indeholdt af de to begreber var blot aspekter af de grundlæggende, overordnede, begrebet ressource identifikation . I juni 1994 offentliggjorde IETF Berners-Lees første anmodning om kommentarer, der anerkendte eksistensen af ​​URL'er og URN'er. Vigtigst af alt definerede den en formel syntaks for Universal Resource Identifiers (dvs. URL-lignende strenge, hvis præcise syntaks og semantik var afhængig af deres skemaer). Derudover forsøgte RFC  1630 at opsummere syntakser for URL -skemaer, der var i brug på det tidspunkt. Det anerkendte - men standardiserede ikke - eksistensen af ​​relative webadresser og fragmentidentifikatorer.

Forfining

I december 1994 definerede RFC  1738 formelt relative og absolutte URL'er, raffinerede den generelle URL -syntaks, definerede, hvordan relative URL'er skal løses til absolut form, og opregner bedre de URL -skemaer, der derefter er i brug. Den aftalte definition og syntaks for URN'er måtte vente, indtil IETF RFC 2141 blev offentliggjort i maj 1997.

Ved offentliggørelsen af ​​IETF RFC 2396 i august 1998 blev URI -syntaksen en separat specifikation, og de fleste dele af RFC'erne 1630 og 1738 vedrørende URI'er og URL'er generelt blev revideret og udvidet af IETF . Den nye RFC ændrede betydningen af ​​"U" i "URI" til "Uniform" fra "Universal".

I december 1999 leverede RFC  2732 en mindre opdatering til RFC 2396, så URI'er kunne rumme IPv6 -adresser. En række mangler opdaget i de to specifikationer førte til en fællesskabsindsats, koordineret af RFC 2396-medforfatter Roy Fielding , der kulminerede i udgivelsen af ​​IETF RFC 3986 i januar 2005. Mens den tidligere standard blev forældet, gengav den ikke detaljerne af eksisterende URL -ordninger forældede; RFC 1738 fortsætter med at styre sådanne ordninger, medmindre andet er afløst. IETF RFC 2616 forfiner f.eks. Skemaet http. Samtidig offentliggjorde IETF indholdet af RFC 3986 som den fulde standard STD 66, hvilket afspejler oprettelsen af ​​den generiske URI -syntaks som en officiel internetprotokol.

I 2001 udgav W3C's Technical Architecture Group (TAG) en vejledning til bedste praksis og kanoniske URI'er til udgivelse af flere versioner af en given ressource. For eksempel kan indholdet variere efter sprog eller størrelse for at justere efter kapacitet eller indstillinger for den enhed, der bruges til at få adgang til dette indhold.

I august 2002 påpegede IETF RFC  3305 , at udtrykket "URL" trods udbredt offentlig brug var falmet til næsten forældelse og kun tjener som en påmindelse om, at nogle URI'er fungerer som adresser ved at have ordninger, der indebærer netværksadgang, uanset sådan faktisk brug. Som URI-baserede standarder som f.eks. Ressourcebeskrivelsesramme gør det klart, behøver ressourceidentifikation ikke at foreslå hentning af ressourcepræsentationer over internettet, og de behøver slet ikke at indebære netværksbaserede ressourcer.

Det semantiske web bruger HTTP URI -skemaet til at identificere både dokumenter og begreber i den virkelige verden, en sondring, der har skabt forvirring om, hvordan de to skal skelnes. TAG offentliggjorde en e-mail i 2005 om, hvordan man løser problemet, som blev kendt som httpRange-14-opløsningen . W3C offentliggjorde efterfølgende en interessegruppenote med titlen Cool URIs for the Semantic Web , som forklarede brugen af indholdsforhandling og HTTP 303 -svarskoden til omdirigeringer mere detaljeret.

Design

URL'er og URN'er

Et Uniform Resource Name (URN) er en URI, der identificerer en ressource ved navn i et bestemt navneområde. Et URN kan bruges til at tale om en ressource uden at antyde dens placering eller hvordan man får adgang til den. For eksempel identificerer ISBN 0-486-27557-4 i systemet International Standard Book Number (ISBN) en specifik udgave af Shakespeares skuespil Romeo og Julie . URN for denne udgave ville være urne: isbn: 0-486-27557-4 . Den giver imidlertid ingen oplysninger om, hvor man kan finde en kopi af bogen.

En Uniform Resource Locator (URL) er en URI, der angiver midlerne til at handle på eller opnå repræsentationen af ​​en ressource, dvs. at angive både dens primære adgangsmekanisme og netværksplacering. For eksempel http://example.org/wiki/Main_Pagerefererer URL'en til en ressource, der er identificeret som /wiki/Main_Page, hvis repræsentation i form af HTML og relateret kode kan fås via Hypertext Transfer Protocol ( http :) fra en netværksvært, hvis domænenavn er example.org.

Et URN kan sammenlignes med en persons navn, mens en URL kan sammenlignes med deres gadenavn. Med andre ord identificerer et URN et element, og en URL giver en metode til at finde det.

Tekniske publikationer, især standarder produceret af IETF og W3C , afspejler normalt en opfattelse skitseret i en W3C -henstilling af 30. juli 2001, som anerkender forekomsten af ​​udtrykket URI frem for at godkende enhver formel underinddeling i URL og URN.

URL er et nyttigt, men uformelt koncept: en URL er en type URI, der identificerer en ressource via en repræsentation af dens primære adgangsmekanisme (f.eks. Dens netværks "placering"), snarere end ved andre attributter, den kan have.

Som sådan er en URL simpelthen en URI, der tilfældigvis peger på en ressource over et netværk. I ikke-tekniske sammenhænge og i software til World Wide Web forbliver udtrykket "URL" imidlertid stadig meget udbredt. Derudover forekommer udtrykket "webadresse" (som ikke har nogen formel definition) ofte i ikke-tekniske publikationer som et synonym for en URI, der bruger http- eller https- ordningerne. Sådanne antagelser kan føre til forvirring, for eksempel i tilfælde af XML -navnerum, der har en visuel lighed med URI'er, der kan løses .

Specifikationer produceret af WHATWG foretrækker URL frem for URI , og derfor nyere HTML5 API'er bruger URL frem for URI .

Standardiser på udtrykket URL. URI og IRI [Internationaliseret ressourceidentifikator] er bare forvirrende. I praksis bruges en enkelt algoritme til begge dele, så det ikke hjælper nogen at holde dem adskilt. URL vinder også let i søgeresultatets popularitetskonkurrence.

Mens de fleste URI -ordninger oprindeligt var designet til at blive brugt med en bestemt protokol og ofte har samme navn, er de semantisk forskellige fra protokoller. For eksempel bruges skemaet http generelt til at interagere med webressourcer ved hjælp af HTTP, men skemafilen har ingen protokol.

Syntaks

Se også: Liste over URI -ordninger

Hver URI begynder med et skema -navn, der refererer til en specifikation for tildeling af identifikatorer inden for dette skema. Som sådan er URI -syntaksen et fødereret og udvideligt navnesystem, hvor hvert skemas specifikation yderligere kan begrænse syntaksen og semantikken for identifikatorer, der bruger det skema. Den generiske URI -syntaks er et supersæt af syntaksen for alle URI -skemaer. Det blev først defineret i RFC  2396 , udgivet i august 1998 og afsluttet i RFC  3986 , udgivet i januar 2005.

Den generiske URI -syntaks består af en hierarkisk sekvens af fem komponenter : 

URI = scheme:[//authority]path[?query] [#fragment]

hvor autoritetskomponenten opdeles i tre delkomponenter : 

authority = [userinfo@]host[:port]

Dette er repræsenteret i et syntaksdiagram som:

URI -syntaksdiagram

URI'en omfatter:

  • En ikke-tom ordningskomponent efterfulgt af et kolon (:), der består af en sekvens af tegn, der begynder med et bogstav og efterfulgt af enhver kombination af bogstaver, cifre plus (+), punktum (.) eller bindestreg (-). Selvom ordninger ikke er store og små bogstaver, er den kanoniske form små bogstaver, og dokumenter, der angiver ordninger, skal gøre det med små bogstaver. Eksempler på populære ordninger omfatterhttp,https,ftp,mailto,file,data, ogirc. URI-ordninger bør registreres hosInternet Assigned Numbers Authority (IANA), selvom ikke-registrerede ordninger bruges i praksis.
  • En valgfri autoritetskomponent forud for to skråstreger (//), der omfatter:
    • En valgfri userinfo -delkomponent, der kan bestå af etbrugernavnog en valgfriadgangskodeforud for et kolon (:) efterfulgt af et at -symbol (@). Brug af formatetusername:passwordi brugerinfo -delkomponenten udfases af sikkerhedsmæssige årsager. Applikationer bør ikke som klar tekst gengive data efter den første kolon (:) fundet i en brugerinfo -underkomponent, medmindre dataene efter kolon er den tomme streng (angiver ingen adgangskode).
    • EN vært -delkomponent, der består af enten et registreret navn (inklusive men ikke begrænset til etværtsnavn) eller enIP -adresse. IPv4-adresser skal være idot-decimal notation, ogIPv6-adresser skal være omsluttet i parentes ([]).
    • En valgfri port -delkomponent forud for et kolon (:).
  • EN stikomponent , der består af en sekvens af stisegmenter adskilt af et skråstreg (/). En sti er altid defineret for en URI, selvom den definerede sti kan være tom (nul længde). Et segment kan også være tomt, hvilket resulterer i to på hinanden følgende skråstreger (//) i stikomponenten. En stikomponent kan ligne eller knytte nøjagtigt til enfilsystemsti,men indebærer ikke altid en relation til en. Hvis en autoritetskomponent er til stede, skal stikomponenten enten være tom eller begynde med et skråstreg (/). Hvis en autoritetskomponent er fraværende, kan stien ikke begynde med et tomt segment, det vil sige med to skråstreger (//), da følgende tegn ville blive fortolket som en autoritetskomponent. Det sidste segment af stien kan betegnes som en 'slug'.
Forespørgselsafgrænser Eksempel
Ampersand ( &) key1=value1&key2=value2
Semikolon ( ;) key1=value1;key2=value2
  • En valgfri forespørgselskomponent forud for et spørgsmålstegn (?), der indeholder enforespørgselsstrengmed ikke-hierarkiske data. Dens syntaks er ikke veldefineret, men ved konvention er det oftest en sekvens afattribut -værdiparadskilt af enafgrænser.
  • En valgfri fragmentkomponent forud for enhash(#). Fragmentet indeholder enfragmentidentifikator, dergiver retning til en sekundær ressource, f.eks. En sektionsoverskrift i en artikel identificeret med resten af ​​URI. Når den primære ressource er etHTML-dokument, er fragmentet ofte enidattributfor et specifikt element, og webbrowsere ruller dette element til visning.

Strenge af dataoketter inden for en URI er repræsenteret som tegn. Tilladte tegn i en URI er ASCII -tegnene for små og store bogstaver i det moderne engelske alfabet , de arabiske tal , bindestreg , punktum , understregning og tilde . Oktetter repræsenteret af ethvert andet tegn skal være procent-kodet .

Af ASCII-tegnsættet er tegnene : / ? # [ ] @forbeholdt brug som afgrænsere for de generiske URI-komponenter og skal være procentkodede-for eksempel %3Ftil et spørgsmålstegn. Tegnene ! $ & ' ( ) * + , ; =er tilladt af generisk URI -syntaks at blive brugt ukodet i brugeroplysninger, vært og sti som afgrænsere. Derudover :og @kan forekomme ukodet inden for stien, forespørgslen og fragmentet; og ?og /kan forekomme ukodet som data i forespørgslen eller fragmentet.

Den følgende figur viser eksempler på URI'er og deres komponentdele. 

          brugerinfo        host       port 
          ┌──┴───┐  ┌──────┴──────┐  ┌┴┐
  https: //john.doe@www.example.com: 123/forum/spørgsmål/? tag = netværk & ordre = nyeste#top
  └─┬─┘    └───────────┬──────────────┘ └───────┬───────┘  └───────────┬─────────────┘  └┬┘ 
  ordning           myndighed                   sti                  forespørgsel            fragment

  ldap: // [2001: db8 :: 7]/c = GB? objectClass? one
  └┬─┘ └──────┬─────┘└─┬─┘ └──────┬──────┘
  skema autoritet sti forespørgsel

  mailto: John.Doe@example.com
  └─┬──┘ └────┬──────────────┘
  skema sti

  nyheder: comp.infosystems.www.servers.unix
  └┬π┘
  skema sti

  tlf .:+1-816-555-1212
  └┬┘ └───────┬──────┘
  skema sti

  telnet: //192.0.2.16: 80/
  └─┬──┘ └─────┬──────┘│
  skema myndighedssti

  urne: oase: navne: specifikation: docbook: dtd: xml: 4.1.2
  └┬┘
  skema sti

URI -referencer

En URI -reference er enten en URI eller en relativ reference, når den ikke begynder med en skemakomponent efterfulgt af et kolon ( :). Et stisegment, der indeholder et kolontegn (f.eks. foo:bar), Kan ikke bruges som det første stisegment i en relativ reference, hvis dets stikkomponent ikke begynder med et skråstreg ( /), da det ville forveksles med en skemakomponent. Et sådant stisegment skal gå forud for et punktstiksegment (f.eks. ./foo:bar).

Web dokument kodesprog ofte bruger URI referencer til punkt til andre ressourcer, såsom eksterne dokumenter eller specifikke dele af det samme logiske dokument:

  • i HTML giver værdien af elementets srcattribut imgen URI -reference, ligesom værdien af hrefattributten for aeller linkelementet;
  • i XML er systemidentifikatoren, der vises efter SYSTEMsøgeordet i en DTD , en fragmentfri URI -reference;
  • i XSLT er værdien af hrefattributten for xsl:importelementet/instruktionen en URI -reference; ligeledes det første argument til document()funktionen.
https://example.com/path/resource.txt#fragment
//example.com/path/resource.txt
/path/resource.txt
path/resource.txt
../resource.txt
./resource.txt
resource.txt
#fragment

Løsning

Løsning af en URI -reference mod en basis -URI resulterer i en mål -URI . Dette indebærer, at basis -URI eksisterer og er en absolut URI (en URI uden fragmentkomponent). Basis -URI'en kan fås i prioritetsrækkefølge fra:

  • selve reference -URI'en, hvis det er en URI;
  • repræsentationens indhold
  • den enhed, der indkapsler repræsentationen
  • den URI, der blev brugt til selve hentningen af ​​repræsentationen;
  • ansøgningens kontekst.

Inden for en repræsentation med en veldefineret base URI af 

http://a/b/c/d;p?q

en relativ reference løses til dens mål -URI som følger: 

"g:h"     -> "g:h"
"g"       -> "http://a/b/c/g"
"./g"     -> "http://a/b/c/g"
"g/"      -> "http://a/b/c/g/"
"/g"      -> "http://a/g"
"//g"     -> "http://g"
"?y"      -> "http://a/b/c/d;p?y"
"g?y"     -> "http://a/b/c/g?y"
"#s"      -> "http://a/b/c/d;p?q#s"
"g#s"     -> "http://a/b/c/g#s"
"g?y#s"   -> "http://a/b/c/g?y#s"
";x"      -> "http://a/b/c/;x"
"g;x"     -> "http://a/b/c/g;x"
"g;x?y#s" -> "http://a/b/c/g;x?y#s"
""        -> "http://a/b/c/d;p?q"
"."       -> "http://a/b/c/"
"./"      -> "http://a/b/c/"
".."      -> "http://a/b/"
"../"     -> "http://a/b/"
"../g"    -> "http://a/b/g"
"../.."   -> "http://a/"
"../../"  -> "http://a/"
"../../g" -> "http://a/g"

URL munging

URL -munging er en teknik, ved hvilken en kommando føjes til en URL, normalt i slutningen, efter et "?" token . Det bruges ofte i WebDAV som en mekanisme til tilføjelse af funktionalitet til HTTP . I et versioneringssystem, f.eks. For at tilføje en "checkout" -kommando til en URL, skrives det som http://editing.com/resource/file.php?command=checkout. Det har fordelen af ​​både at være let for CGI -parsere og fungerer også som mellemmand mellem HTTP og underliggende ressource, i dette tilfælde.

Forhold til XML -navnerum

I XML er et navnerum et abstrakt domæne, hvortil en samling af element- og attributnavne kan tildeles. Navneområdet er en tegnstreng, der skal overholde den generiske URI -syntaks. Navnet anses dog generelt ikke for at være en URI, fordi URI -specifikationen ikke kun baserer beslutningen på leksikale komponenter, men også på deres tilsigtede anvendelse. Et navnerum indebærer ikke nødvendigvis nogen af ​​semantikken i URI -ordninger; for eksempel har et navneområde, der begynder med http:, muligvis ingen forbindelse til brugen af HTTP .

Oprindeligt kunne navneområdet navne matche syntaksen for enhver ikke-tom URI-reference, men brugen af ​​relative URI-referencer blev forældet af W3C. En separat W3C -specifikation for navneområder i XML 1.1 tillader internationaliserede ressourceidentifikator (IRI) referencer at tjene som grundlag for navneområder ud over URI -referencer.

Se også

Noter

Referencer

Yderligere læsning

eksterne links