UUID v4-generator – tilfeldige identifikatorer med høy kvalitet
Denne siden genererer én eller flere UUID v4-strenger – 36 tegn lange identifikatorer i standard 8-4-4-4-12-format med heksadesimale tegn. Du styrer antall ID-er (opptil 100), om de skal vises med store bokstaver, og om bindestreker skal inkluderes. Genereringen skjer umiddelbart i nettleseren din, uten at noe sendes til en server. Du kan kopiere en enkelt ID eller alle på én gang.
Hva UUID v4 er og hvordan denne siden skiller seg ut
UUID (Universally Unique Identifier) versjon 4 bruker 122 bit tilfeldig data. De resterende 6 bitene er reservert for versjons- og variantmarkører, slik at totalen blir 128 bit. Hver UUID v4 består av 16 oktetter (32 heksadesimale tegn) pluss 4 bindestreker når disse er slått på. Ingen tidsstempel er innebygd – verdiene er rent tilfeldige og helt uforutsigbare.
Det som gjør denne siden annerledes fra en hvilken som helst annen UUID-generator, er kontrollen over formatet og den umiddelbare tilbakemeldingen. Du kan veksle mellom små og store bokstaver, eller slå av bindestreker. Hver gang du endrer en innstilling – enten det er antall, store bokstaver eller bindestreker – regenereres hele settet med ID-er. Standardutgangen er små bokstaver med bindestreker.
Siden skiller seg også fra verktøy som genererer UUID v7, ULID eller NanoID. For UUID v4 er formatet fast: 122 bit tilfeldighet i 32 heksadesimale tegn med bindestreker på faste plasser. Du kan ikke endre antall tilfeldige bit eller legge til tidsinformasjon. Det eneste du kan påvirke er visningsformatet.
Hvordan identifikatorene genereres – tilfeldighetskilde og format
Alle UUID v4-verdier produseres lokalt i nettleseren din ved hjelp av nettleserens kryptografiske tilfeldighetsgenerator (CSPRNG). I moderne nettlesere er dette crypto.getRandomValues(), som henter tilfeldige byte fra operativsystemets entropikilde. Ingenting sendes til en server – verken ID-ene du genererer, antallet du velger, eller innstillingene dine. Derfor fungerer siden også uten nettverk, så lenge den er lastet inn én gang.
Hver UUID v4 bygges slik:
- Det genereres 16 tilfeldige byte (128 bit).
- Versjonsbitene settes til
0100(binært) i den syvende oktetten, slik at det heksadesimale tegnet på posisjon 12 (0-indeksert) blir 4. - Variantbitene settes i den niende oktetten, slik at de to første bitene blir
10. Dette gir et heksadesimalt tegn som er 8, 9, A eller B. - De resterende 122 bitene forblir tilfeldige.
Resultatet er en 36-tegns streng med fire bindestreker: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx, der x er en tilfeldig heksadesimal siffer (0–f) og y er en tilfeldig siffer i området 8–b (heksadesimalt).
Når du slår av bindestreker, fjernes bare de fire bindestrekene – de underliggende bitene endres ikke. Det samme gjelder når du velger store bokstaver: tegnene konverteres til versaler, men tilfeldigheten forblir den samme.
Effekten av bryterne: store bokstaver og bindestreker
To brytere gir deg kontroll over hvordan UUID-ene vises.
Store bokstaver (Uppercase)
Som standard er UUID-ene i små bokstaver: 550e8400-e29b-41d4-a716-446655440000. Slår du på uppercase, blir de til 550E8400-E29B-41D4-A716-446655440000. Store bokstaver kan være nyttig i sammenhenger der lesbarhet eller systemkonvensjoner krever det – for eksempel i enkelte loggingssystemer eller når identifikatorene skal vises på skjermer med små skrifttyper der b og d kan forveksles.
Inkluder bindestreker (Include hyphens)
Bindestreker er standard på, fordi det er det vanligste formatet. Uten bindestreker blir UUID-en en sammenhengende streng på 32 tegn: 550e8400e29b41d4a716446655440000. Dette kan være nyttig for lagring i databaser, når formatet må være rent alfanumerisk, eller når identifikatoren trenger å være kortere i overføringsprotokoller.
Regenerering ved endring
Hver gang du endrer en innstilling – eller telleren – regenereres samtlige ID-er. Det er ingen mulighet til å "låse" et sett med ID-er mens du endrer visningsformat. Dette er fordi siden alltid presenterer et konsistent sett med tilfeldige verdier; hvis du endrer formatet, må alle ID-ene genereres på nytt for å unngå uforutsigbar oppførsel.
Kollisjonssannsynlighet og hvorfor det er trygt
UUID v4 bruker 122 bit tilfeldighet. Antall mulige unike verdier er 2^122 ≈ 5,3 × 10^36. For å sette det i perspektiv: Hvis du genererer én milliard UUID-er per sekund i 100 år, vil du ha produsert omtrent 3 × 10^18 ID-er. Kollisjonssannsynligheten er da fremdeles under 10^-15 – det vil si mindre enn én av en million milliarder.
Sannsynligheten for en enkelt kollisjon beregnes med bursdagsparadokset: For n tilfeldige verdier fordelt over N mulige verdier, er sannsynligheten for minst én kollisjon omtrent n²/(2N). Med N = 2^122 og n = 10^10 (10 milliarder ID-er), blir kollisjonssannsynligheten rundt 10^-13. I praksis betyr dette at du kan generere UUID-er resten av livet uten å få en duplikat.
Det er likevel viktig å merke seg at UUID v4 ikke har noen tidskomponent. To UUID-er generert etter hverandre har ingen relasjon i tid. Dette har konsekvenser for databaseytelse, som vi ser på i neste avsnitt.
UUID v4 og databaseytelse – fragmentering og sorteringsproblemer
Siden UUID v4 er helt tilfeldig, sorteres de i en vilkårlig rekkefølge i indeksen. Når du bruker UUID v4 som primærnøkkel i en database, vil nye rader plasseres tilfeldig i indeksens B-tre-struktur. Dette fører til såkalte indeksfragmentering og side-splitting (page splits), fordi databasen stadig må omorganisere treet.
Forskjellen er stor sammenlignet med tidsbaserte identifikatorer som UUID v7 eller ULID. Disse inkluderer et tidsstempel i de mest signifikante bitene, slik at nye verdier som regel legges til på slutten av indeksen. Det gir bedre skriveytelse og mindre fragmentering, spesielt for høyvolum-systemer.
Hvis du ikke har behov for uforutsigbare ID-er – for eksempel i en offentlig API der det er viktig å unngå at noen kan gjette neste ID – bør du vurdere å bruke UUID v7 eller en sekvensiell nøkkel. UUID v4 er best egnet når unpredictability er viktigere enn sorterbarhet: sikkerhetstokens, sesjons-ID-er, eller identifikatorer i distribuerte systemer der du ikke har én sentral kilde for tidsinformasjon.
Praktiske bruksområder for UUID v4
UUID v4 brukes mye i situasjoner der det trengs unike, uforutsigbare identifikatorer uten mulighet for kollisjon:
- Sikkerhetstokens – engangspassord, CSRF-tokens og autentiseringsøkter krever at verdiene er umulige å gjette. Randomiteten i 122 bit gir tilstrekkelig entropi.
- Sesjons-ID-er – i webapplikasjoner kan UUID v4 brukes som sesjonsnøkkel, siden den ikke avslører noe om når eller i hvilken rekkefølge den ble opprettet.
- Distribuerte systemer – når flere noder genererer ID-er uten sentral koordinering, unngår UUID v4 kollisjoner med høy sannsynlighet.
- Testdata – utviklere trenger ofte et sett med unike identifikatorer for testing. Med opptil 100 ID-er per generering og muligheten til å kopiere alle på én gang, sparer siden tid.
- Anonymiserte nøkler – i databaser der du vil skjule rekkefølgen på rader (for eksempel i en offentlig katalog), er tilfeldige ID-er å foretrekke fremfor sekvensielle tall.
Siden er også nyttig for databaseadministratorer som vil eksperimentere med effekten av UUID v4 på indeksytelse – du kan generere et sett med ID-er, sette dem inn i en tabell, og observere fragmentering.
Vanlige spørsmål (FAQ)
Hvorfor er UUID v4 122 bit tilfeldig og ikke 128 bit?
Av de 128 bitene i en UUID v4 er 6 reservert for versjonsnummeret (4) og variantbitene. De resterende 122 bitene er tilfeldig. Dette er spesifisert i RFC 4122.
Kan jeg generere mer enn 100 UUID-er om gangen?
Nei, telleren er begrenset til 100. Det er en praktisk begrensning for å unngå at siden blir treg. Hvis du trenger flere, kan du bare trykke på genereringsknappen på nytt – hver gang får du et nytt sett.
Er UUID v4 trygt å bruke som passord eller API-nøkkel?
UUID v4 har 122 bit entropi, noe som er mer enn nok for de fleste tokens. Men for svært sensitive nøkler (for eksempel masterpassord) anbefales ofte lengre strenger (for eksempel 256 bit). UUID v4 er trygt for sesjons-ID-er og temporære tokens.
Hva er forskjellen på UUID v4 og UUID v7?
UUID v4 er rent tilfeldig; UUID v7 inkluderer et tidsstempel i de første bitene, slik at ID-ene sorteres kronologisk. Det gir bedre databaseytelse, men mindre uforutsigbarhet. Vår side støtter UUID v7 i et annet formatvalg.
Hvorfor endres ID-ene når jeg slår av bindestreker?
Siden genererer alltid et nytt sett med tilfeldige verdier når innstillinger endres. Dette sikrer at formatet er konsistent, men betyr at du ikke kan "beholde" et sett mens du prøver visningsalternativer. Hvis du trenger å beholde ID-ene, kopier dem først.
Må jeg være tilkoblet internett for å bruke siden?
Nei, all generering skjer lokalt i nettleseren. Siden fungerer offline etter første lasting (forutsatt at den er bufret).