URN ( English Uniform Resource Name ) - et ensartet navn (navn) på ressourcen. På engelsk udtales det som ordet tjene, på russisk siger man ofte [ u-er-en ]. En URN er en konstant sekvens af tegn, der identificerer en abstrakt eller fysisk ressource. URN er en del af konceptet URI ( Engelsk Uniform Resource Identifier ) - ensartede ressourceidentifikatorer. URN'er er beregnet til at erstatte URL -locatorer ( engelsk Uniform Resource Locators ) i fremtiden - ensartede identifikatorer for ressourcernes placering. Men URN'er, i modsætning til URL'er, inkluderer ikke indikationer af, hvor og hvordan man får adgang til en ressource. URN-standarden er specifikt designet til at inkludere andre navnerum .
Ideen om en URN opstod fra en væsentlig fejl i URL-systemet. Ressourcer på World Wide Web og internettet flyttes, men links i form af URL'er forbliver, som peger på ressourcer, der ikke længere er der. Gamle URL'er bliver også gjort ubrugelige ved omstrukturering af ressourcer, omdøbning, sletning, flytning til et andet DNS- domæne . For at løse dette problem blev der udviklet et effektivt PURL-system ( Persistent Uniform Resource Locator ), der nu er meget brugt, samt et DOI -system ( Digital Object Identifier ) . Men disse er stadig kun delvise løsninger på problemet. Den grundlæggende løsning bør være standarden for ensartet navngivning af URN-ressourcer.
URN angiver det uændrede navn på ressourcen uden at specificere dens placering eller hvordan man refererer til den. Som et resultat er URN'er permanente, uafhængige af specifikke servere og protokoller. Med andre ord refererer en URN konceptuelt til selve ressourcen og ikke til den placering, hvor en eller anden ressource er placeret (eller måske ikke allerede er), som URL'en gør. Lad os sige, at der er en person ved navn Mikhail Petrov, der bor i Moskva ved st. Zemlyanoy Val, 14. Hvis nogen spørger ham: "Hvem er du?", vil han selvfølgelig svare "Jeg er Mikhail Petrov." Når alt kommer til alt, vil han ikke sige: "Jeg er en person, der bor på Zemlyanoy Val, 14." Så URN identificerer en person som "Mikhail Petrov", og URL'en rapporterer kun, at nogen bor på gadens adresse. Zemlyanoy Val, 14 (måske er der også en organisation der... URL'en siger det ikke).
For at finde ressourcer efter URN-navn skal du bruge et "URN-opløsningssystem" ( eng. URN-opløsning ). Så vil en person (eller et program ), der kender den nøjagtige URN for ressourcen, indtaste den i opløsningssystemet og straks få en masse specifikke steder ( servere eller f.eks. onlinebutikker ), hvor denne ressource kan findes. I 2002 blev et DDDS -system ( Dynamic Delegation Discovery System ) foreslået , som opløser URN'er til URL-links til specifikke ressourceplaceringer. Både URN'en og URL'en er en del af det samme URI-ressourceidentifikationssystem.
I 1994 blev RFC 1737 udstedt , som beskrev de konceptuelle og funktionelle krav til udvikling af en URN. Selve ideen om URN blev født lidt tidligere, men indtil 1994 blev den ikke formuleret på nogen måde. Siden udgivelsen af RFC 1737 er der brugt meget tid og kræfter på at udvikle URN. IETF 's URN-arbejdsgruppe ( Internet Engineering Task Force ) omfatter så mange interessenter (inklusive store konkurrerende virksomheder), så det ser ud til at være meget vanskeligt at nå til enighed. Allerede i maj 1997 blev RFC 2141- specifikationen dog offentliggjort , der beskriver den første version af URN-syntaksen. Selvom udviklingen af URN er langt fra færdig, og det endnu ikke har været muligt at nå til enighed om alle spørgsmål, er de grundlæggende træk ved URN allerede ved at træde ret tydeligt frem.
I 1999 blev RFC 2483 offentliggjort , som skitserede et system til at løse URN'er. I oktober 2002 blev en hel række dokumenter frigivet: RFC 3401 , RFC 3402 , RFC 3403 , RFC 3404 , RFC 3405 . Disse dokumenter definerede DDDS URN-opløsningssystemet (se ovenfor) - det sidste nødvendige link til implementering af URN'er. Omkring samme tid blev RFC 3406- specifikationen frigivet , hvilket præciserer specifikationen af URN-navneområder.
På nuværende tidspunkt har brugen af URN allerede fået betydelige proportioner. URN'er er blevet en integreret del af det udvidelige XML -markupsprog . Flere og flere URN'er bliver implementeret i populær software.
Ensartede ressourcenavne har følgende struktur:
<URN> ::= "urn:" <NID> ":" <NSS>I denne post:
<NID> navneområdeidentifikator ( eng. Navneområdeidentifikator ); er en syntaktisk fortolkning af NSS, der er ufølsom over for store og små bogstaver. <NSS> en streng fra et specifikt navneområde ( eng. Navneområde specifik streng ); hvis denne streng indeholder ikke - ASCII-tegn , skal de kodes i Unicode ( UTF-8 ) og foranstilles (hver af dem) med et procenttegn "%" (se URL for detaljer ).I dette tilfælde skelnes der ikke mellem store og små bogstaver i den indledende sekvens af tegn "urn: ". Og navneområdesidentifikatorerne "urn" og "URN" er slet ikke tilladt for at undgå forveksling med denne indledende streng "urn: ".
Disse URN'er indeholder i NID navnet på den hash, der blev brugt til at oprette dem. NSS indeholder værdien af denne hash beregnet ud fra dataene for det identificerede objekt (fil). Sådanne URN'er får hash-egenskaber, det vil sige, at der kan oprettes mange forskellige URN'er til dataene, men hver URN kan kun identificere ét datasæt (fil).
Disse URN'er bruges:
| NID | Lidt dybde | Indkodning | Eksempel |
|---|---|---|---|
| træ:tiger | 192 | Base 32 | urne:træ:tiger:7N5OAMRNGMSSEUE3ORHOKWN4WWIQ5X4EBOOTLJY |
| sha1 | 160 | Base 32 | urn:sha1:XRX2PEFXOOEJFRVUCX6HMZMKS5TWG4K5 |
| btih | 160 | Base 32 | urn:btih:QHQXPYWMACKDWKP47RRVIV7VOURXFE5Q |
| ed2k | 128 | hex | urn:ed2k:354B15E68FB8F36D7CD88FF94116CDC1 |
| md5 | 128 | hex | urn:md5:834CEF60EF3FD47162420FA25ABF2DFF |
| md4 | 128 | hex | urn:md4:bbd810ee7731921c4582daa00bbc531e |
| tiger | 192 | hex | urne:tiger:cf13102788e1e6ef6124cb9ca9ef879e4bb04c58fe297dd3 |
| aich | 160 | Base 32 | urn:aich:wbtmcm2wrbndylixh3jmwsg4uowzjcqm |
| boblebad | 512 | hex | Urn: Whirlpool: DC38CE741D9C8BE87A0D715FAD951460C5299DA2447C3FA8F1057B560F9253C7A017882DCC2390AB602C3B0F5FCF06D6D6D35F32FFA9B8E5555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555550 |
| ripemd160 | 160 | hex | urn:ripemd160:93f1cb4a43643136d730a3b94b0ebcec66928c02 |
| gost | 256 | hex | urn:gost:906fd73511810bafdaa33c05b9957b07edd8dca9b6982c04a86f6c642eb6b062 |
| har 160 | 160 | hex | urn:has160:85c292d359574b89985b2667c9725edb1c7d12fc |
| snefru128 | 128 | hex | urn:snefru128:646b932fee2529db11d05425cff21978 |
| snefru256 | 256 | hex | urn:snefru256:35879fc03ca60db551fa26ce8be6a6a04d542cf5a635ab203f95c6f1affb59a6 |
I de viste eksempler er "isbn", "ietf", "oid", "sha1", "uuid" og "træ" navneområder, såkaldte. <NID> (se ovenfor) og linjer efter det andet kolon er <NSS>.
| URI- ordninger | |
|---|---|
| Officiel | |
| uofficiel | |