för båda varianterna 1 och 2 definieras fem ”versioner” i standarderna, och varje version kan vara mer lämplig än de andra i specifika användningsfall. Versionen indikeras avM I strängrepresentationen.

Version – 1 UUID genereras från en tid och ett nod-ID( vanligtvis MAC-adressen); version – 2 UUID genereras från en identifierare( vanligtvis en grupp eller användar-ID), tid och en nod-ID; versioner 3 och 5 producerar deterministiska UUID genereras genom hashing en namnrymdsidentifierare och namn; och version-4 Uuider genereras med ett slumpmässigt eller pseudo-slumpmässigt tal.

Nil UUIDEdit

” nil ” UUID, ett speciellt fall, är UUID 00000000-0000-0000-0000-000000000000; det vill säga alla bitar inställda på noll.

Version 1 (Datum-tid och MAC-adress)redigera

Version 1 sammanfogar 48-bitars MAC-adressen för ”noden” (det vill säga datorn som genererar UUID), med en 60-bitars tidsstämpel, som är antalet 100-nanosekundintervall sedan midnatt 15 oktober 1582 Coordinated Universal Time (UTC), det datum då den gregorianska kalendern först antogs. RFC 4122 anger att tidsvärdet rullar över cirka 3400 AD,: 3 beroende på vilken algoritm som används, vilket innebär att 60-bitars tidsstämpel är en signerad kvantitet. Men vissa program, såsom libuuid biblioteket, behandlar tidsstämpeln som osignerad, sätta rollover tid i 5236 AD. Den rollover tid som definieras av ITU – T Rec. X. 667 är 3603 AD.: v

en 13-eller 14-bitars ”unik” klocksekvens förlänger tidsstämpeln för att hantera fall där processorklockan inte går tillräckligt snabbt, eller där det finns flera processorer och UUID-generatorer per nod. När UUID genereras snabbare än systemklockan kan gå framåt, kan de nedre bitarna i tidsstämpelfälten genereras genom att öka den varje gång en UUID genereras, för att simulera en högupplöst tidsstämpel. Med varje version 1 UUID som motsvarar en enda punkt i rymden (noden) och tiden (intervaller och klocksekvens) är chansen att två korrekt genererade version-1 UUID oavsiktligt är desamma praktiskt taget noll. Eftersom tid och klocksekvens totalt 74 bitar, 274 (1.8 1022, eller 18 sextillion) version-1 uuider kan genereras per nod-ID, med en maximal genomsnittlig hastighet på 163 miljarder per sekund per nod-ID.

i motsats till andra UUID-versioner är version-1 och -2 UUID baserade på MAC-adresser från nätverkskort delvis beroende av en identifierare som utfärdats av en central registreringsmyndighet, nämligen den organisatoriskt unika identifieraren (OUI) del av MAC-adressen, som utfärdas av IEEE till tillverkare av nätverksutrustning. Det unika med version-1 och version-2 UUIDs baserat på nätverkskort MAC-adresser beror också på nätverkskort tillverkare korrekt tilldela unika MAC-adresser till sina kort, som liksom andra tillverkningsprocesser är föremål för fel.

användning av nodens nätverkskort MAC-adress för nod-ID innebär att en version-1 UUID kan spåras tillbaka till datorn som skapade den. Dokument kan ibland spåras till datorerna där de skapades eller redigerades genom UUID inbäddade i dem genom ordbehandlingsprogram. Detta integritetshål användes när man lokaliserade skaparen av Melissa-viruset.

RFC 4122 tillåter MAC-adressen i en version-1 (eller 2) UUID att ersättas med ett slumpmässigt 48-bitars nod-ID, antingen för att noden inte har en MAC-adress eller för att det inte är önskvärt att exponera den. I så fall kräver RFC att den minst signifikanta biten av den första oktetten i nod-ID ska ställas in på 1. Detta motsvarar multicast-biten i MAC-adresser, och inställningen tjänar till att skilja UUID där nod-ID genereras slumpmässigt från UUID baserat på MAC-adresser från nätverkskort, som vanligtvis har unicast MAC-adresser.

Version 2 (datum-tid och MAC-adress, DCE security version)redigera

RFC 4122 reserver version 2 för ”DCE security” UUIDs; men det ger inga detaljer. Av denna anledning utelämnar många UUID-implementeringar version 2. Specifikationen för version – 2 UUID tillhandahålls emellertid av DCE 1.1-autentiserings-och Säkerhetstjänstspecifikationen.

Version – 2 UUID liknar version 1, förutom att de minst signifikanta 8 bitarna i klocksekvensen ersätts av ett ”lokalt domän” – nummer och de minst signifikanta 32 bitarna i tidsstämpeln ersätts av en heltalsidentifierare som är meningsfull inom den angivna lokala domänen. På POSIX-system är lokala domännummer 0 och 1 för användar-ID (uid) respektive grupp-ID (Gid), och andra lokala domännummer är webbplatsdefinierade. På icke-POSIX-system är alla lokala domännummer webbplatsdefinierade.

möjligheten att inkludera en 40-bitars domän/identifierare i UUID kommer med en avvägning. Å ena sidan tillåter 40 bitar cirka 1 biljon domän / identifieringsvärden per nod-ID. Å andra sidan, med klockvärdet avkortat till de 28 mest signifikanta bitarna, jämfört med 60 bitar i version 1, kommer klockan i en version 2 UUID att ”kryssa” bara en gång var 429.49 sekunder, lite mer än 7 minuter, i motsats till var 100 nanosekunder för version 1. Och med en klocksekvens på endast 6 bitar, jämfört med 14 bitar i version 1, kan endast 64 unika UUID per nod/domän/identifierare genereras per 7-minuters klockmarkering, jämfört med 16 384 klocksekvensvärden för version 1. Version 2 kanske inte är lämplig för fall där UUID krävs, per nod/domän/identifierare, med en hastighet som överstiger ungefär en var sjunde sekund.

versioner 3 och 5 (namespace name-based)redigera

Version-3 och version-5 UUID genereras genom att hashing en namespace identifierare och namn. Version 3 använder MD5 som hashingalgoritm, och version 5 använder SHA-1.

namnområdesidentifieraren är i sig en UUID. Specifikationen ger UUID för att representera namnrymderna för webbadresser, fullständigt kvalificerade domännamn, objektidentifierare och X. 500 utmärkta namn; men alla önskade UUID kan användas som namnrymdsbeteckning.

för att bestämma version-3 UUID som motsvarar ett givet namnområde och namn, omvandlas UUID för namnområdet till en rad byte, sammanfogas med inmatningsnamnet och hashas sedan med MD5, vilket ger 128 bitar. Sedan ersätts 6 eller 7 bitar med fasta värden, 4-bitarsversionen (t. ex. 00112 för version 3), och 2 – eller 3-bitars UUID ”variant” (t.ex. 102 indikerar en RFC 4122 UUID, eller 1102 indikerar en äldre Microsoft GUID). Eftersom 6 eller 7 bitar således är förutbestämda bidrar endast 121 eller 122 bitar till UUID: s unika egenskaper.

Version – 5 UUIDs är liknande, men SHA-1 används istället för MD5. Eftersom SHA-1 genererar 160-bitars digests, förkortas digesten till 128 bitar innan versionen och variantbitarna byts ut.

Version-3 och version-5 UUID har egenskapen att samma namnområde och namn kommer att mappas till samma UUID. Varken namnområdet eller namnet kan dock bestämmas från UUID, även om en av dem anges, förutom genom brute-force-sökning. RFC 4122 rekommenderar version 5 (SHA-1) över version 3 (MD5) och varnar för användning av UUIDs av någon version som säkerhetsuppgifter.

Version 4 (slumpmässig)redigera

en version 4 UUID genereras slumpmässigt. Som i andra UUIDs används 4 bitar för att indikera version 4 och 2 eller 3 bitar för att indikera varianten (102 eller 1102 för varianterna 1 respektive 2). För variant 1 (det vill säga de flesta UUID) kommer en slumpmässig version-4 UUID att ha 6 förutbestämda varianter och versionsbitar, vilket lämnar 122 bitar för den slumpmässigt genererade delen, för totalt 2122 eller 5,3 1036 (5,3 undecillion) möjlig version-4 variant-1 UUID. Det finns hälften så många möjliga version-4 variant-2 Uuider (legacy GUIDs) eftersom det finns en färre slumpmässig bit tillgänglig, 3 bitar konsumeras för varianten.