UUID-generator

UUID v4 – struktur og tilfældighed

UUID v4 er en 128-bit identifikator, men kun 122 bit er egentlig tilfældige. De resterende 6 bit er fastlagt i RFC 4122 til at markere version (4) og variant (10xx). Disse 122 tilfældige bit fordeles over 16 oktetter og repræsenteres som 32 hexadecimale tegn, normalt sat sammen i mønsteret 8-4-4-4-12 (f.eks. 123e4567-e89b-42d3-a456-426614174000). Når bindestreger udelades, er strengen 32 tegn lang; med bindestreger bliver den 36 tegn.

Den side, du står på, genererer UUID v4 strengt efter dette format. Du kan vælge mellem store eller små bogstaver og slå bindestreger til eller fra. Den underliggende tilfældighed kommer fra crypto.getRandomValues i browseren – en kryptografisk pseudo-tilfældighedsgenerator, som er designet til at være uforudsigelig selv for en angriber med delvist kendskab til systemets tilstand.

Hvad gør denne side anderledes

De fleste UUID-generatorer på nettet tilbyder det samme – en knap, der spytter en enkelt UUID ud. Denne side skiller sig ud på flere punkter:

• 122 bit tilfældighed uden tidsstempel – UUID v4 indeholder ikke nogen tidsinformation. Hver værdi er rent tilfældig og har ingen kronologisk orden. Det betyder, at sortering af UUID v4-id'er giver en arbitrær rækkefølge, hvilket fragmenterer databaseindekser, når de bruges som primærnøgler.
• Ingen serverinteraktion – al generering foregår lokalt i browseren via crypto.getRandomValues. Intet sendes til serveren, hvilket giver både privatliv og mulighed for offline-brug.
• Fuld kontrol over format – du kan vælge antallet (1-100), slå store bogstaver til/fra og inkludere eller fjerne bindestreger. Hver ændring regenererer hele sættet øjeblikkeligt.
• Kopier enkeltværdier eller alle – et enkelt klik på en UUID kopierer den til udklipsholderen. Knappen "Kopier alle" kopierer samtlige viste id'er på én gang.

Denne side er ikke bare en simpel generator; den er bygget til at give dig præcis det output, du har brug for, uden overflødige mellemregninger.

Indstillinger og output – hvad du styrer

Inputfelterne er få og klare:

• Format – vælg UUID v4 blandt UUID v7, ULID eller NanoID. Når du skifter format, ændres indstillingerne for store bogstaver og bindestreger muligvis, men for UUID v4 er de altid tilgængelige.
• Antal – et heltal mellem 1 og 100. Værdier uden for dette interval accepteres ikke. Standard er 1.
• Store bogstaver – en kontakt, der som standard er slået fra. Når den aktiveres, udskrives alle hexadecimale tegn med store bogstaver (f.eks. ABCD i stedet for abcd).
• Inkluder bindestreger – en kontakt, der som standard er slået til. Hvis du slår den fra, får du 32 tegn uden bindestreger.

Outputtet vises som en liste. Ved siden af listen står antallet af genererede id'er. Statusmeddelelser angiver, om systemet er klar (Klar.), har genereret (Genereret.) eller har kopieret alle (Alle kopieret!). Hver gang du ændrer en indstilling, regenereres alle id'er øjeblikkeligt – du behøver ikke trykke på en separat knap.

Kollisionssandsynlighed og sikkerhed

Med 122 tilfældige bit er sandsynligheden for en kollision (to identiske UUID'er) ekstremt lav. For at forstå hvor lav: Hvis du genererer 1 milliard UUID v4-id'er om sekundet i 100 år, vil du have en samling på omkring 3,2×10^18 id'er. Sandsynligheden for selv én kollision i det datasæt er stadig under 50%, hvis du bruger en ideel tilfældighedskilde. I praksis betyder det, at du kan generere id'er i det uendelige uden at bekymre dig om dubletter.

Sikkerheden afhænger af, at den kryptografiske tilfældighedsgenerator i browseren fungerer korrekt. De fleste moderne browsere bruger window.crypto.getRandomValues, som trækker på operativsystemets egen entropikilde (f.eks. /dev/urandom på Linux, CryptGenRandom på Windows). Det gør UUID v4 velegnet til sikkerhedstokens, sessions-id'er og andre formål, hvor uforudsigelighed er kritisk.

Bemærk dog, at al generering foregår lokalt i browseren. Hvis din computer er kompromitteret, kan en angriber teoretisk forudsige de genererede id'er ved at kende til systemets tilstand. Men for de fleste praktiske anvendelser er dette niveau af tilfældighed mere end tilstrækkeligt.

UUID v4 versus tidsbaserede alternativer

Når du vælger en identifikator, handler det ikke kun om unikhed, men også om, hvordan den opfører sig i databaser og systemer. UUID v4 adskiller sig fundamentalt fra tidsbaserede id'er som UUID v7 eller ULID.

UUID v4's manglende tidsstempel gør det ideelt, når du ikke ønsker at afsløre noget om tidspunktet for oprettelsen. Men når det bruges som primærnøgle i en B-tree indeks, vil tilfældige indsættelser sprede sig over hele indekset – hver ny række skal indsættes et tilfældigt sted i træet, hvilket forårsager mange sideopdelinger og dårligere skriveydelse. Tidssorterbare alternativer som UUID v7 placerer nye rækker konsekvent i slutningen af indekset og undgår derfor fragmenteringen.

Den side, du står på, inkluderer UUID v7 og ULID som separate formater. Hvis du arbejder med databaser og har mange indsættelser, bør du overveje at skifte til et tidsbaseret format. UUID v4 er mest anvendeligt, når sortering er irrelevant eller direkte uønsket.

Praktiske anvendelser og almindelige fejl

UUID v4 bruges især til:

• Sikkerhedstokens – login-sessions, CSRF-tokens, API-nøgler. Uforudsigelighed er afgørende.
• Eksterne identifikatorer – id'er, du deler med kunder, partnere eller offentligheden. De må ikke afsløre interne rækkefølger.
• Anonymiserede nøgler – i forskning eller dataudveksling, hvor du vil fjerne sporingsmuligheder.
• Testdata – hurtig generering af unikke værdier til manuelle tests.

Almindelige fejl inkluderer:

• Brug som primærnøgle i store tabeller uden overvejelse – fragmentering kan dræbe skriveydelsen. Overvej at bruge UUID v7 eller en sekventiel nøgle.
• Antagelse om kronologisk sortering – UUID v4 sorterer vilkårligt. Hvis du har brug for sortering efter oprettelsestidspunkt, skal du gemme en ekstra tidskolonne.
• Glemme bindestreger – nogle systemer forventer bindestreger, andre ikke. Sørg for at tilpasse formatet efter slutpunktet.
• Manglende opmærksomhed på store/små bogstaver – UUID er case-insensitive i de fleste sammenhænge, men konsistens kan undgå forvirring i logs og fejlmeddelelser.
• Generering på flere enheder uden koordinering – selvom kollisionssandsynligheden er lav, kan den ikke elimineres helt. I distribuerede systemer kan du overveje at tilføje en node-id eller bruge en central generator.

Ofte stillede spørgsmål

Hvorfor er der kun 122 tilfældige bit i UUID v4, når det er en 128-bit værdi? De 6 faste bit angiver version (4 bit) og variant (2 bit). De resterende 122 bit er tilfældige. Hvis alle 128 bit var tilfældige, ville det ikke længere være et gyldigt UUID efter RFC 4122.

Kan jeg generere mere end 100 id'er ad gangen? Nej, denne side understøtter maksimalt 100 id'er pr. generering. Hvis du har brug for flere, kan du gentage processen eller bruge et script, der trækker på samme tilfældighedskilde.

Påvirker valg af store bogstaver kollisionssandsynligheden? Nej. Store og små bogstaver er blot en forskel i repræsentation. Den underliggende hexadecimale værdi er den samme. ABCD og abcd udgør samme tal.

Er UUID v4 sikkert til brug i webauth-tokens? Ja, så længe du genererer dem korrekt med en kryptografisk tilfældighedsgenerator. Denne side bruger crypto.getRandomValues, som er browsersikker. Sørg dog for at holde tokens fortrolige og overføre dem over HTTPS.

Hvorfor regenereres id'erne, når jeg skifter en indstilling? Hver indstilling – antal, store bogstaver, bindestreger – ændrer outputformatet. For at sikre konsistens og undgå blandet output regenereres altid hele sættet. Det er den eneste måde at garantere, at alle id'er følger det valgte format.

Kan jeg bruge UUID v4 som primærnøgle i en stor PostgreSQL-tabel? Det kan du, men vær opmærksom på indeksfragmentering. Hvis tabellen har mange indsættelser, bør du overveje at bruge UUID v7 i stedet, eller indsætte med en sekventiel nøgle som supplement.