Uniform Resource Identifier - Uniform Resource Identifier

"URI" omdirigerer her. For annen bruk, se URI (disambiguation) .
Uniform Resource Identifier (URI)
Domene Verdensveven
Forkortelse URI

En Uniform Resource Identifier ( URI ) er en unik sekvens av tegn som identifiserer en logisk eller fysisk ressurs som brukes av webteknologier. URIer kan brukes til å identifisere alt, inkludert virkelige objekter, for eksempel mennesker og steder, konsepter eller informasjonsressurser som nettsider og bøker. Noen URIer gir et middel til å finne og hente informasjonsressurser på et nettverk (enten på Internett eller på et annet privat nettverk, for eksempel et datafilsystem eller et intranett); disse er Uniform Resource Locators (URLs). En URL angir plasseringen av ressursen. En URI identifiserer ressursen ved navn på det angitte stedet eller URL. Andre URI -er gir bare et unikt navn, uten at det er mulig å finne eller hente ressursen eller informasjon om den, dette er Uniform Resource Names (URN). Nettteknologiene som bruker URI er ikke begrenset til nettlesere. URI brukes til å identifisere alt som er beskrevet ved hjelp av RDF ( Resource Description Framework ), for eksempel begreper som er en del av en ontologi som er definert ved hjelp av Web Ontology Language (OWL), og personer som er beskrevet ved hjelp av Friend of a Friend -ordforråd ville hver ha en individuell URI.

Historie

Oppfatning

URIer og nettadresser har en delt historie. I 1990 introduserte Tim Berners-Lees forslag til hypertekst implisitt ideen om en URL som en kort streng som representerer en ressurs som er målet for en hyperkobling . På den tiden omtalte folk det som et "hypertekstnavn" eller "dokumentnavn".

I løpet av de neste tre og et halvt årene, etter hvert som World Wide Webs kjerneteknologier for HTML, HTTP og nettlesere utviklet seg, dukket det opp et behov for å skille en streng som ga en adresse til en ressurs fra en streng som bare navngav en ressurs. Selv om det ennå ikke er formelt definert, kom begrepet Uniform Resource Locator til å representere førstnevnte, og det mer omstridte Uniform Resource Name kom til å representere sistnevnte. I juli 1992 nevner Berners-Lees rapport om IETF "UDI (Universal Document Identifiers) BOF " URLer (som Uniform Resource Locators), URN (opprinnelig som Unique Resource Numbers) og behovet for å chartre en ny arbeidsgruppe. I november 1992 møttes IETF "URI Working Group" for første gang.

Under debatten om definer webadresser og urner, ble det klart at de konseptene som er ved de to begrepene var bare deler av den grunnleggende, overordnede, begrepet ressurs identifikasjon . I juni 1994 publiserte IETF Berners-Lees første forespørsel om kommentarer som anerkjente eksistensen av nettadresser og URN-er. Viktigst, det definerte en formell syntaks for Universal Resource Identifiers (dvs. URL-lignende strenger hvis presise syntakser og semantikk var avhengig av deres ordninger). I tillegg forsøkte RFC  1630 å oppsummere syntakser for URL -ordninger som var i bruk den gangen. Den anerkjente - men standardiserte ikke - eksistensen av relative nettadresser og fragmentidentifikatorer.

Forfining

I desember 1994 definerte RFC  1738 formelt relative og absolutte nettadresser, raffinerte den generelle URL -syntaksen, definerte hvordan relative URLer skal løses til absolutt form, og oppregnet URL -ordningene som da var i bruk bedre. Den avtalte definisjonen og syntaksen til URN måtte vente til publiseringen av IETF RFC 2141 i mai 1997.

Ved publiseringen av IETF RFC 2396 i august 1998 ble URI -syntaksen en egen spesifikasjon, og de fleste delene av RFC 1630 og 1738 knyttet til URI og URL -er generelt ble revidert og utvidet av IETF . Den nye RFC endret betydningen av "U" i "URI" til "Uniform" fra "Universal".

I desember 1999 ga RFC  2732 en mindre oppdatering av RFC 2396, slik at URI kunne ta imot IPv6 -adresser. En rekke mangler oppdaget i de to spesifikasjonene førte til et samfunnsinnsats, koordinert av RFC 2396-medforfatter Roy Fielding , som kulminerte med publiseringen av IETF RFC 3986 i januar 2005. Mens den tidligere standarden ble foreldet, gjengitt den ikke detaljene av eksisterende URL -ordninger foreldet; RFC 1738 fortsetter å styre slike ordninger, bortsett fra når de ellers er erstattet. IETF RFC 2616 forfiner for eksempel httpopplegget. Samtidig publiserte IETF innholdet i RFC 3986 som den komplette standarden STD 66, noe som gjenspeiler etableringen av den generiske URI -syntaksen som en offisiell internettprotokoll.

I 2001 publiserte W3Cs Technical Architecture Group (TAG) en guide til beste praksis og kanoniske URIer for publisering av flere versjoner av en gitt ressurs. For eksempel kan innholdet variere etter språk eller størrelse for å justere for kapasitet eller innstillinger for enheten som brukes for å få tilgang til innholdet.

I august 2002 påpekte IETF RFC  3305 at begrepet "URL", til tross for utbredt offentlig bruk, hadde bleknet til nesten utdatert, og fungerer bare som en påminnelse om at noen URIer fungerer som adresser ved å ha ordninger som innebærer nettverkstilgjengelighet, uavhengig av slike faktisk bruk. Som URI-baserte standarder som Ressursbeskrivelsesramme gjør det klart, trenger ikke ressursidentifikasjon å foreslå hentning av ressursrepresentasjoner over Internett, og de trenger heller ikke innebære nettverksbaserte ressurser.

The Semantic Web bruker HTTP URI -opplegget til å identifisere både dokumenter og konsepter i den virkelige verden, et skille som har forårsaket forvirring om hvordan de to skilles. TAG publiserte en e-post i 2005 om hvordan man løser problemet, som ble kjent som httpRange-14-oppløsningen . W3C publiserte deretter en interessegruppenotat med tittelen Cool URIs for the Semantic Web , som forklarte bruken av innholdsforhandlinger og HTTP 303 -svarskoden for omdirigeringer mer detaljert.

Design

Nettadresser og URN -er

Et Uniform Resource Name (URN) er en URI som identifiserer en ressurs ved navn i et bestemt navneområde. Et URN kan brukes til å snakke om en ressurs uten å antyde plasseringen eller hvordan du får tilgang til den. For eksempel, i International Standard Book Number (ISBN) -systemet, identifiserer ISBN 0-486-27557-4 en spesifikk utgave av Shakespeares skuespill Romeo og Julie . URN for den utgaven vil være urne: isbn: 0-486-27557-4 . Den gir imidlertid ingen informasjon om hvor du kan finne en kopi av boken.

En Uniform Resource Locator (URL) er en URI som spesifiserer hvordan man kan handle på eller skaffe representasjonen av en ressurs, dvs. spesifisere både dens primære tilgangsmekanisme og nettverksplassering. For eksempel er nettadressen http://example.org/wiki/Main_Pagerefererer til en ressurs som er identifisert /wiki/Main_Page, hvis representasjon, i form av HTML og tilhørende kode, er oppnåelig via Hypertext Transfer Protocol ( http: ) fra et nettverk vert hvis domenenavn er example.org.

Et URN kan sammenlignes med en persons navn, mens en URL kan sammenlignes med gateadressen. Med andre ord, et URN identifiserer et element, og en URL gir en metode for å finne det.

Tekniske publikasjoner, spesielt standarder produsert av IETF og W3C , gjenspeiler normalt et syn skissert i en W3C -anbefaling av 30. juli 2001, som anerkjenner fortrinnet til begrepet URI i stedet for å godkjenne noen formell underavdeling i URL og URN.

URL er et nyttig, men uformelt konsept: en URL er en type URI som identifiserer en ressurs via en representasjon av dens primære tilgangsmekanisme (f.eks. Nettverkets "plassering"), i stedet for med noen andre attributter den kan ha.

Som sådan er en URL rett og slett en URI som tilfeldigvis peker til en ressurs over et nettverk. I ikke-tekniske sammenhenger og i programvare for World Wide Web forblir imidlertid begrepet "URL" mye brukt. I tillegg forekommer begrepet "webadresse" (som ikke har noen formell definisjon) ofte i ikke-tekniske publikasjoner som et synonym for en URI som bruker http- eller https- ordningene. Slike forutsetninger kan føre til forvirring, for eksempel når det gjelder XML -navneområder som har en visuell likhet med URIer som kan løses .

Spesifikasjoner produsert av WHATWG foretrekker URL fremfor URI , og derfor bruker nyere HTML5 APIer URL -adresse fremfor URI .

Standardiser på begrepet URL. URI og IRI [Internationalized Resource Identifier] er bare forvirrende. I praksis brukes en enkelt algoritme for begge, så det hjelper ikke noen å holde dem distinkte. URL vinner også enkelt søkeresultatets popularitetskonkurranse.

Selv om de fleste URI -ordninger opprinnelig ble designet for å brukes med en bestemt protokoll , og ofte har samme navn, er de semantisk forskjellige fra protokoller. For eksempel ordningen http blir vanligvis brukt til å kommunisere med nettressurser ved hjelp av HTTP, men ordningen filen har ingen protokoll.

Syntaks

Se også: Liste over URI -ordninger

Hver URI begynner med et skjemnnavn som refererer til en spesifikasjon for tildeling av identifikatorer innenfor dette skjemaet. Som sådan er URI -syntaksen et sammenslått og utvidbart navnesystem der spesifikasjonene til hvert skema kan begrense syntaksen og semantikken til identifikatorer som bruker det skjemaet. Den generiske URI -syntaksen er et oversett av syntaksen til alle URI -ordninger. Den ble først definert i RFC  2396 , publisert i august 1998, og avsluttet i RFC  3986 , publisert i januar 2005.

Den generiske URI -syntaksen består av en hierarkisk sekvens av fem komponenter : 

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

der autoritetskomponenten deler seg i tre delkomponenter : 

authority = [userinfo@]host[:port]

Dette er representert i et syntaksdiagram som:

URI -syntaksdiagram

URI består av:

  • En ikke-tom ordningskomponent etterfulgt av et kolon (:), bestående av en sekvens av tegn som begynner med en bokstav og etterfulgt av en hvilken som helst kombinasjon av bokstaver, sifre, pluss (+), punktum (.) eller bindestrek (-). Selv om ordninger er små og små bokstaver, er den kanoniske formen liten og dokumenter som angir ordninger må gjøre det med små bokstaver. Eksempler på populære ordninger omfatterhttp,https,ftp,mailto,file,data, ogirc. URI-ordninger bør registreres hosInternet Assigned Numbers Authority (IANA), selv om ikke-registrerte ordninger brukes i praksis.
  • Valgfritt autoritetskomponent foran to skråstreker (//), omfattende:
    • Valgfritt userinfo -delkomponent som kan bestå av etbrukernavnog et valgfrittpassordforan et kolon (:), etterfulgt av et at -symbol (@). Bruk av formatetusername:passwordi brukerinformasjon -delkomponenten er av sikkerhetshensyn utdatert. Applikasjoner bør ikke gjengi som klar tekst noen data etter det første kolon (:) som finnes i en brukerinformasjon -delkomponent, med mindre dataene etter kolon er den tomme strengen (indikerer ikke noe passord).
    • EN vert underkomponenten, består av enten et registrert navn (inkludert, men ikke begrenset til etvertsnavn) eller enIP-adresse. IPv4-adresser må være ipunkt-desimal notasjon, ogIPv6-adresser må være vedlagt i parentes ([]).
    • Valgfritt port -delkomponent foran et kolon (:).
  • EN banekomponent , bestående av en sekvens av stisegmenter atskilt med et skråstrek (/). En bane er alltid definert for en URI, selv om den definerte banen kan være tom (null lengde). Et segment kan også være tomt, noe som resulterer i to påfølgende skråstreker (//) i banekomponenten. En banekomponent kan ligne eller kartlegge nøyaktig til enfilsystembane,men betyr ikke alltid en relasjon til en. Hvis en autoritetskomponent er til stede, må banekomponenten enten være tom eller begynne med en skråstrek (/). Hvis en autoritetskomponent er fraværende, kan banen ikke begynne med et tomt segment, det vil si med to skråstreker (//), ettersom følgende tegn vil bli tolket som en autoritetskomponent. Det siste segmentet av banen kan bli referert til som en 'slug'.
Spørreskilletegn Eksempel
Ampersand ( &) key1=value1&key2=value2
Semikolon ( ;) key1=value1;key2=value2
  • Valgfritt spørrekomponent foran et spørsmålstegn (?), som inneholder enspørringsstrengmed ikke-hierarkiske data. Syntaksen er ikke godt definert, men etter konvensjon er det oftest en sekvens avattributt -verdi -paratskilt med enskilletegn.
  • Valgfritt fragmentkomponent foran enhash(#). Fragmentet inneholder enfragmentidentifikator somgir retning til en sekundær ressurs, for eksempel en seksjonens overskrift i en artikkel identifisert av resten av URI. Når den primære ressursen er etHTML-dokument, er fragmentet ofte etidattributtfor et bestemt element, og nettlesere vil bla dette elementet til visning.

Strenger med dataoketter i en URI er representert som tegn. Tillatte tegn i en URI er ASCII -tegnene for små og store bokstaver i det moderne engelske alfabetet , arabiske tall , bindestrek , punktum , understreking og tilde . Oktetter representert med andre tegn må være prosentkodet .

Av ASCII-tegnsettet er tegnene : / ? # [ ] @reservert for bruk som avgrensere for de generiske URI-komponentene og må være prosentkodet-for eksempel %3Ffor et spørsmålstegn. Tegnene ! $ & ' ( ) * + , ; =er tillatt av generisk URI -syntaks å bli brukt ukodet i brukerinformasjonen, verten og banen som skilletegn. I tillegg, :og @kan vises ukodet i banen, forespørselen og fragmentet; og ?og /kan vises ukodet som data i spørringen eller fragmentet.

Figuren nedenfor viser eksempler på URIer og deres komponentdeler. 

          userinfo        vert       port 
          ┌──┴───┐  ┌──────┴──────┐  ┌┴┐
  https: //john.doe@www.example.com: 123/forum/questions/? tag = networking & order = newest#top
  └─┬─┘    └───────────┬──────────────┘ └───────┬───────┘  └───────────┬─────────────┘  └┬┘ 
  ordningen           myndighet                   banen                  spør            fragment

  ldap: // [2001: db8 :: 7]/c = GB? objectClass? one
  └┬─┘ └──────┬─────┘└─┬─┘ └──────┬──────┘
  ordningsautoritet banen forespørsel

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

  nyheter: comp.infosystems.www.servers.unix
  └┬─┘ └────────────────────────────────┘
  ordningsbane

  tlf:+1-816-555-1212
  └┬┘ └───────┬──────┘
  ordningsbane

  telnet: //192.0.2.16: 80/
  └─┬──┘ └─────┬──────┘│
  ordningsmyndighetens bane

  urne: oase: navn: spesifikasjon: dokbok: dtd: xml: 4.1.2
  └┬┘ └ ─ ─ ─
  ordningsbane

URI -referanser

En URI -referanse er enten en URI eller en relativ referanse når den ikke begynner med en skjemakomponent etterfulgt av et kolon ( :). Et stisegment som inneholder et kolontegn (f.eks. foo:bar) Kan ikke brukes som det første banesegmentet i en relativ referanse hvis banekomponenten ikke begynner med en skråstrek ( /), ettersom det ville bli feilaktig som en skjemakomponent. Et slikt banesegment må gå foran med et prikkbanesegment (f.eks. ./foo:bar).

Web dokumentmarkeringsspråk ofte bruker URI referanser til punkt til andre ressurser, for eksempel eksterne dokumenter eller bestemte deler av det samme logiske dokument:

  • i HTML gir verdien til srcattributtet til imgelementet en URI -referanse, det samme gjør verdien til hrefattributtet til elementet aeller linkelementet;
  • i XML er systemidentifikatoren som vises etter SYSTEMnøkkelordet i en DTD en fragmentløs URI -referanse;
  • i XSLT er verdien av hrefattributtet til xsl:importelementet/instruksjonen en URI -referanse; på samme måte det første argumentet til document()funksjonen.
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

Vedtak

Å løse en URI -referanse mot en base -URI resulterer i en mål -URI . Dette innebærer at basis -URI eksisterer og er en absolutt URI (en URI uten fragmentkomponent). Basen URI kan fås, i prioritetsrekkefølge, fra:

  • selve referansen URI hvis det er en URI;
  • innholdet i representasjonen;
  • enheten som omslutter representasjonen;
  • URI -en som ble brukt til selve hentingen av representasjonen;
  • konteksten for søknaden.

Innenfor en representasjon med en veldefinert base URI av 

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

en relativ referanse 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 teknikk der en kommando legges til en URL, vanligvis på slutten, etter en "?" token . Den brukes ofte i WebDAV som en mekanisme for å legge funksjonalitet til HTTP . I et versjoneringssystem, for eksempel for å legge til en "checkout" -kommando i en URL, skrives det som http://editing.com/resource/file.php?command=checkout. Det har fordelen av både å være enkelt for CGI -parsere og fungerer også som et mellomledd mellom HTTP og underliggende ressurs, i dette tilfellet.

Forhold til XML -navnerom

I XML er et navneområde et abstrakt domene som en samling av element- og attributtnavn kan tilordnes. Navneområdet er en tegnstreng som må følge den generiske URI -syntaksen. Imidlertid anses navnet generelt ikke for å være en URI, fordi URI -spesifikasjonen ikke bare baserer beslutningen på leksikale komponenter, men også på den tiltenkte bruken. Et navneplassnavn betyr ikke nødvendigvis noen av semantikkene i URI -ordninger; for eksempel kan et navneområde som begynner med http: ikke ha noen konnotasjon til bruk av HTTP .

Opprinnelig kunne navneplassnavnet stemme overens med syntaksen til en ikke-tom URI-referanse, men bruken av relative URI-referanser ble avskrevet av W3C. En egen W3C -spesifikasjon for navneområder i XML 1.1 gjør at internasjonaliserte ressursidentifikator (IRI) referanser kan tjene som grunnlag for navneområder i tillegg til URI -referanser.

Se også

Merknader

Referanser

Videre lesning

Eksterne linker