UUID v4 – 122 bit tilfældighed i et standardiseret format
UUID v4 (Universally Unique Identifier version 4) er en 36 tegn lang streng, der består af hexadecimale tegn opdelt i fem grupper: 8‑4‑4‑4‑12. De tre første grupper indeholder 8, 4 og 4 tegn, de to sidste 4 og 12 – i alt 32 hex-cifre plus fire bindestreger. Men det, der gør UUID v4 til et helt særligt værktøj, er den underliggende tilfældighed: 122 bits af ren, kryptografisk sikker tilfældighed. De resterende 6 bits er faste og angiver version (version 4) og variant (RFC 4122). Det betyder, at hver eneste UUID v4, du genererer på denne side, er uforudsigelig og uden nogen tidsmæssig eller sekventiel orden.
Denne side adskiller sig fra andre ID-generatorer ved at give dig fuld kontrol over formatet: du kan vælge antal (fra 1 til 100), slå store bogstaver til/fra (A-F vs. a-f) og fjerne bindestreger for at få en kompakt 32-tegns streng. Alle ID’er genereres lokalt i din browser ved hjælp af crypto.randomUUID eller tilsvarende stærk tilfældighed – intet sendes til en server. Det gør værktøjet ideelt til udviklere, der arbejder i offline-miljøer, eller som har brug for at generere tusindvis af nøgler uden forsinkelse.
Hvorfor UUID v4 bruges i stedet for tidsbaserede ID’er
I mange systemer er tidsbaserede ID’er som UUID v7 eller sekventielle auto-increment-numre langt mere almindelige, fordi de er sorterbare og mindsker indeksfragmentering i databaser. Men UUID v4 har en række fordele, der gør det uundværligt i specifikke scenarier.
For det første kan du ikke udlede noget om tidspunktet for oprettelsen af en UUID v4. Det er afgørende for sikkerhedsingeniører, der bygger API-nøgler, session tokens eller request ID’er, hvor en angriber ikke må kunne gætte eller korrelere rækkefølgen. Hvis en token var tidsbaseret, ville en angriber med én token kunne estimere, hvornår den næste blev udstedt, og dermed gætte den. UUID v4 forhindrer det.
For det andet fungerer UUID v4 perfekt i distribuerede systemer, hvor der ikke er nogen central koordinering. To noder kan generere UUID v4 uafhængigt af hinanden uden risiko for at producere det samme ID – sandsynligheden for en kollision er så lille, at den i praksis er nul. Med 122 bits tilfældighed er antallet af mulige UUID v4-værdier 2^122 ≈ 5,3 × 10^36. For at få en 50% sandsynlighed for en kollision skal man generere omkring 2^61 ≈ 2,3 × 10^18 ID’er. Det er langt ud over, hvad nogen praktisk implementering nogensinde når.
For det tredje giver UUID v4 mulighed for at skjule antallet af poster i en database. Hvis du bruger sekventielle nøgler, kan en konkurrent eller bruger aflæse, hvor mange rækker der er, ved at se på ID’ernes værdier. Med UUID v4 er der ingen sammenhæng.
Indvirkning på databaseindekser – den største ulempe
Den største ulempe ved UUID v4 er dens effekt på B-træindekser i relationelle databaser. Fordi UUID v4-værdier er tilfældige og ikke har nogen sorteringsorden, indsættes nye rækker i tilfældige positioner i indekset. Det fører til fragmentering: indekssider bliver delvist fyldte, og databasen skal konstant omorganisere sig selv. Det kan reducere skrivehastigheden betydeligt, især når tabellen har mange rækker.
I praksis betyder det, at UUID v4 er et dårligt valg som primærnøgle i en stor, skrivetung OLTP-database. Tidsbaserede UUID’er som v7 eller ULID er bedre, fordi de er monotone og bevarer en kronologisk rækkefølge. Men i læsetunge systemer eller i NoSQL-databaser, der ikke bruger B-træer (f.eks. nogle key-value stores), er ulempen mindre markant.
Hvis du alligevel vælger UUID v4 som primærnøgle i en SQL-database, kan du afbøde fragmentering ved at bruge en clustered index på en separat tidsstempelkolonne, eller ved at vælge en UUID v4-implementering, der grupperer bits på en måde, så de første bits er mere stabile (f.eks. UUID v7). Men værktøjet på denne side genererer ægte tilfældige v4-UUID’er – der er ingen præfikssortering.
Format-indstillinger: store bogstaver og bindestreger
Selvom UUID v4’s kerne er de 122 tilfældige bits, giver formatet mulighed for to valgfrie justeringer: store bogstaver og bindestreger. Disse indstillinger ændrer ikke ID’ets værdi, men de påvirker, hvordan det præsenteres og bruges.
Når du slår store bogstaver til, vises hex-cifrene A-F som store bogstaver. Dette kan være nyttigt, hvis dit system forventer store bogstaver i UUID’er – nogle ældre protokoller eller formateringsbiblioteker gør det. Andre systemer er case-insensitive, så valget er ofte et spørgsmål om læsbarhed. Store bogstaver kan gøre UUID’en lettere at læse for mennesker, især når den vises på skrift.
Bindestreger er en anden historie. Den kanoniske UUID-notation kræver bindestreger: 8-4-4-4-12. Men i URL’er, filnavne eller andre kompakte kontekster kan bindestreger være generende. Hvis du vælger "udelad bindestreger", får du en 32-tegns streng med kun hex-cifre. Den er kortere, men stadig lige så tilfældig. Nogle systemer kræver UUID’er uden bindestreger – f.eks. i Microsofts GUID-format (som er det samme som UUID v4) bruges bindestreger sjældent internt.
En vigtig pointe: når du ændrer nogen af disse indstillinger, regenereres alle ID’er med det samme. Det skyldes, at værktøjet ikke gemmer de genererede værdier; hver gang du trykker på en toggle, trækkes der nye tilfældige bits. Det er en bevidst designbeslutning for at sikre, at du altid får frisk tilfældighed.
Hvem har gavn af en UUID v4-generator?
-
Applikationsudviklere – har brug for unikke nøgler til objekter, sessioner eller events i distribuerede systemer, hvor koordinering er umulig. Værktøjet kan generere op til 100 ID’er ad gangen, hvilket sparer tid, når man skal fylde testdata eller oprette initiale objekter.
-
Databasearkitekter – som kender til indeksfragmenteringens konsekvenser og alligevel har brug for standard random UUID til bestemte formål, f.eks. til replication eller offline-oprettelse.
-
Sikkerhedsingeniører – der har brug for uforudsigelige identifikatorer til tokens, hemmeligheder eller nonces. UUID v4 er ikke et kryptografisk hemmeligt token (det er kun 122 bits, hvilket er for lidt til en session key), men det er godt nok til de fleste brugerdefinerede ID’er, der ikke må kunne gættes.
-
Test- og data-generatorer – som hurtigt skal skabe realistiske, unikke nøgler til testdatabaser. Det er langt hurtigere at bruge dette værktøj end at skrive en manuel script, især hvis du har brug for ID’er i bestemte formater.
Ofte stillede spørgsmål
Hvad er sandsynligheden for en kollision med UUID v4? Den er ekstremt lille. Med 122 bits tilfældighed skal du generere omkring 2,3 × 10^18 ID’er for at have 50% chance for en enkelt kollision. I praksis er det sikkert at antage, at du aldrig får en kollision, medmindre du genererer milliarder af ID’er.
Kan jeg bruge UUID v4 som primærnøgle i en MySQL-database? Teknisk set ja, men det anbefales ikke til store, skrivetunge tabeller på grund af indeksfragmentering. Overvej UUID v7 eller en sekventiel nøgle i stedet.
Hvorfor vises der “Genereret.” i stedet for “Klar.” når jeg ændrer en indstilling? Værktøjet opdaterer status til “Genereret.”, så snart der er foretaget en ændring. “Klar.” vises efter en klikhandling, der kopierer ID’er.
Kan jeg kopiere alle ID’er på én gang? Ja. Der er en knap til at kopiere alt indholdet. Status skifter til “Kopieret alt!” efter klik. Du kan også klikke på et enkelt ID for at kopiere det individuelt.
Er UUID v4 sikker at bruge som session token? Nej, 122 bits er for lidt til en session key, hvis systemet er under angreb. Brug i stedet en kryptografisk sikker tilfældig streng med mindst 256 bits. UUID v4 er dog god til ikke-sikkerhedskritiske ID’er.
Hvad er forskellen på UUID v4 og v7? UUID v7 er tidsbaseret: de første 48 bits er en tidsstempel. Det gør dem sorterbare og bedre til databaseindekser, men de afslører tidspunktet for oprettelse. UUID v4 er fuldstændig tilfældig og skjuler tid.