for begge varianter 1 og 2 er fem «versjoner» definert i standardene, og hver versjon kan være mer hensiktsmessig enn de andre i spesifikke brukstilfeller. Versjonen er angitt med M i strengrepresentasjonen.

Versjon-1 Uuider genereres fra en tid OG en node-ID (vanligvis MAC-adressen); versjon-2 Uuider genereres fra en identifikator (vanligvis en gruppe ELLER bruker-ID), tid og en node-ID; versjon 3 og 5 produserer deterministiske Uuider generert ved å hashe en navneområdeidentifikator og navn; og versjon-4 Uuider genereres ved hjelp av et tilfeldig eller pseudo-tilfeldig tall.

Nil Uuidit

» nil «UUID, et spesielt tilfelle, er UUID 00000000-0000-0000-0000-000000000000; det vil si at alle biter er satt til null.

Versjon 1 (dato-klokkeslett OG MAC-adresse)Rediger

Versjon 1 setter sammen 48-biters MAC-adressen til «noden» (det vil si datamaskinen som genererer UUID), med et 60-biters tidsstempel, som er antall 100-nanosekundintervaller siden midnatt 15.oktober 1582 Coordinated Universal Time (UTC), datoen Da Den Gregorianske kalenderen først ble vedtatt. RFC 4122 sier at tidsverdien ruller over rundt 3400 AD,: 3 avhengig av algoritmen som brukes, noe som innebærer at 60-biters tidsstempel er en signert mengde. Men noen programvare, for eksempel libuuid biblioteket, behandler tidsstempel som usignert, sette roll tiden i 5236 AD. Rollover tid som definert AV ITU-T Rec. X. 667 er 3603 AD.: v

En 13-eller 14-bit «uniquifying» klokkesekvens utvider tidsstempelet for å håndtere tilfeller der prosessorklokken ikke går fort nok, eller hvor det er flere prosessorer og uuid-generatorer per node. Når Uuider genereres raskere enn systemklokken kan gå videre, kan de nedre bitene av tidsstempelfeltene genereres ved å øke den hver GANG EN UUID genereres, for å simulere et høyoppløselig tidsstempel. Med hver VERSJON 1 UUID som tilsvarer et enkelt punkt i rommet (noden) og tid (intervaller og klokkesekvens), er sjansen for at to riktig genererte versjon-1 Uuider utilsiktet er det samme, praktisk talt null. Siden tid og klokke sekvens totalt 74 biter, 274 (1.8×1022 eller 18 sekstillion) versjon – 1 Uuider kan genereres per node-ID, med en maksimal gjennomsnittlig hastighet på 163 milliarder per sekund per node-ID.

i motsetning TIL ANDRE UUID-versjoner, er Versjon-1 og -2 Uuider basert PÅ MAC-adresser fra nettverkskort avhengige av sin unikhet delvis på en identifikator utstedt av en sentral registreringsmyndighet, nemlig Den Organisatorisk Unike Identifikatoren (Oui) delen AV MAC-adressen, som er utstedt av IEEE til produsenter av nettverksutstyr. Det unike med versjon-1 Og Versjon-2 Uuider basert på nettverkskort MAC-adresser avhenger også av nettverkskort produsenter riktig tildele unike MAC-adresser til sine kort, som i likhet med andre produksjonsprosesser er utsatt for feil.

Bruk AV nodens mac-adresse for node-ID betyr at en VERSJON-1 UUID kan spores tilbake til datamaskinen som opprettet den. Dokumenter kan noen ganger spores til datamaskinene der de ble opprettet eller redigert gjennom Uuider innebygd i dem av tekstbehandlingsprogramvare. Dette personvernhullet ble brukt når man fant skaperen Av Melissa-viruset.RFC 4122 tillater MAC-adressen i en VERSJON-1 (eller 2) UUID å bli erstattet av en tilfeldig 48-biters node-ID, enten fordi noden ikke har EN MAC-adresse, eller fordi det ikke er ønskelig å avsløre den. I så fall krever RFC at den minst signifikante biten av den første oktetten til noden ID skal settes til 1. Dette tilsvarer multicast-biten I MAC-adresser, og innstillingen tjener til å skille Uuider der node-ID er tilfeldig generert fra Uuider basert PÅ MAC-adresser fra nettverkskort, som vanligvis har unicast MAC-adresser.

Versjon 2 (dato-klokkeslett OG MAC-adresse, dce-sikkerhetsversjon)Rediger

RFC 4122 reserverer versjon 2 for» DCE-sikkerhet » Uuider; men det gir ingen detaljer. Av denne grunn utelater MANGE uuid-implementeringer versjon 2. Spesifikasjonen av Versjon 2 UUIDs er imidlertid levert AV Dce 1.1 Authentication And Security Services specification.

Versjon-2 Uuider ligner versjon 1, bortsett fra at de minst signifikante 8 bitene i klokkesekvensen erstattes av et» lokalt domene » – nummer, og de minst signifikante 32 bitene av tidsstempelet erstattes av en heltallsidentifikator som er meningsfull innenfor det angitte lokale domenet. PÅ POSIX-systemer er lokale domenenumre 0 og 1 henholdsvis for bruker-id-er (uid-er) og gruppe-id-er (Gid-Er), og andre lokale domenenumre er områdedefinerte. På ikke-POSIX-systemer er alle lokale domenenumre områdedefinerte.

muligheten til å inkludere et 40-biters domene / identifikator i UUID kommer med en bytte. På den ene siden tillater 40 bits omtrent 1 trillion domene / identifikatorverdier per node-ID. På den annen side, med klokkeverdien avkortet til de 28 mest signifikante biter, sammenlignet med 60 biter i versjon 1, vil klokken i en VERSJON 2 UUID «krysse» bare en gang hver 429.49 sekunder, litt mer enn 7 minutter, i motsetning til hver 100 nanosekunder for versjon 1. Og med en klokkesekvens på bare 6 biter, sammenlignet med 14 biter i versjon 1, kan bare 64 unike Uuider per node/domene/identifikator genereres per 7-minutters klokkekryss, sammenlignet med 16 384 klokkesekvensverdier for versjon 1. Dermed Kan Versjon 2 ikke være egnet for tilfeller der Uuider kreves, per node / domene / identifikator, med en hastighet som overstiger omtrent ett hvert syv sekund.

Versjon 3 og 5 (navneområdenavnbasert)Rediger

Versjon-3 Og versjon-5 Uuider genereres ved å hashe en navneområdeidentifikator og navn. Versjon 3 bruker MD5 som hashing algoritme, og versjon 5 bruker SHA-1.

navneområdeidentifikatoren er i seg selv EN UUID. Spesifikasjonen gir Uuider til å representere navnerom for Nettadresser, fullt kvalifiserte domenenavn, objektidentifikatorer og x. 500 distinguished names; men eventuelle ønskede UUID kan brukes som navnerom designator.

for å bestemme VERSJON-3 UUID som svarer til et gitt navneområde og navn, transformeres uuid av navneområdet til en streng byte, sammenkoblet med inngangsnavnet, deretter hashed MED MD5, som gir 128 biter. Deretter erstattes 6 eller 7 biter med faste verdier, 4-bit-versjonen (f. eks. 00112 for versjon 3), og 2-eller 3-biters UUID «variant» (f. eks 102 indikerer EN RFC 4122 UUIDs, eller 1102 indikerer en eldre Microsoft GUID). Siden 6 eller 7 biter er således forhåndsbestemt, bidrar bare 121 eller 122 biter til uuids unikhet.

Versjon-5 Uuider er like, MEN SHA-1 brukes i stedet FOR MD5. SIDEN SHA-1 genererer 160-bit fordøyelser, blir fordøyelsen avkortet til 128 biter før versjonen og variantbitene erstattes.

Versjon-3 Og Versjon-5 Uuider har egenskapen at samme navneområde og navn vil kartlegge til samme UUID. Imidlertid kan verken navneområdet eller navnet bestemmes fra UUID, selv om en av dem er spesifisert, unntatt ved brute-force-søk. RFC 4122 anbefaler versjon 5 (SHA-1) over versjon 3 (MD5), og advarer mot bruk av Uuider av begge versjoner som sikkerhetsinformasjon.

versjon 4 (tilfeldig)Rediger

en VERSJON 4 UUID genereres tilfeldig. Som i andre Uuider brukes 4 biter for å indikere versjon 4, og 2 eller 3 biter for å indikere varianten (102 eller 1102 for henholdsvis 1 og 2). For variant 1 (det vil si de Fleste Uuider) vil en tilfeldig versjon-4 UUID ha 6 forhåndsbestemte variant-og versjonsbiter, noe som gir 122 biter for den tilfeldig genererte delen, for totalt 2122, eller 5,3×1036 (5,3 undecillion) mulig versjon-4 variant-1 Uuider. Det er halvparten så mange mulige versjon – 4 variant – 2 Uuider (legacy GUIDs) fordi det er en færre tilfeldig bit tilgjengelig, 3 biter blir konsumert for varianten.