raatools/

UUID-generator

Generer tilfeldige v4-UUIDer — en eller flere.

1

Hva er en UUID?

En UUID (Universally Unique Identifier) er et 128-bits tall som brukes til å identifisere informasjon unikt på tvers av distribuerte systemer uten å kreve en sentral myndighet. UUID-er er standardisert i RFC 4122 og brukes overalt — fra databaseprimærnøkler og API-forespørselssporing til sesjonsadministrasjon og filnavngiving.

Standard UUID-formatet er 36 tegn med fire bindestreker: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, der M angir versjonen (1–5) og N angir varianten. Den mest brukte versjonen er UUID v4, som genererer identifikatorer ved hjelp av kryptografisk tilfeldighet. Dette verktøyet genererer UUID v4 som standard.

UUID v4-format

UUID v4 bruker 122 tilfeldige bits (de resterende 6 bitene koder versjon og variant). Formatet er xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx der hver x er et tilfeldig heksadesimalt siffer og y er en av 8, 9, A eller B. 4-tallet i den tredje gruppen identifiserer det som versjon 4. Hver UUID v4 genereres uavhengig ved hjelp av kryptografisk tilfeldighet.

Slik bruker du dette verktøyet

Klikk generer-knappen for å opprette en ny UUID v4. Hvert klikk produserer en fersk, kryptografisk tilfeldig identifikator. Du kan generere flere UUID-er samtidig for batchoperasjoner. Klikk kopier-knappen for å kopiere UUID-en til utklippstavlen for bruk i kode, konfigurasjoner eller databaser.

Vanlige bruksområder for UUID

  • Databaseprimærnøkler: UUID-er gjør det mulig for distribuerte systemer å opprette poster uavhengig uten nøkkelkollisjoner, i motsetning til auto-inkrementerende heltall som krever koordinering.
  • API-forespørsels-IDer: Knytt en UUID til hver API-forespørsel for ende-til-ende-sporing på tvers av mikrotjenester.
  • Sesjonstokener: Opprett unike sesjons­identifikatorer som er umulige å gjette.
  • Filnavn: Generer unike filnavn for å forhindre kollisjoner når flere brukere laster opp samtidig.
  • Idempotens-nøkler: Bruk UUID-er i betalings-API-er for å sikre at den samme transaksjonen ikke behandles to ganger.

Kollisjonssannsynlighet

UUID v4 har 122 tilfeldige bits, noe som gir 5,3 × 10³⁶ mulige verdier. Sannsynligheten for å generere to identiske UUID-er er astronomisk liten. Du måtte generere 2,71 × 10¹⁸ UUID-er (2,71 kvintillioner) før du når en 50 % sannsynlighet for en enkelt kollisjon. I praksis er kollisjoner ikke en realistisk bekymring for noen applikasjon.

Nil-UUID

Nil-UUID-en (00000000-0000-0000-0000-000000000000) er en spesiell verdi definert i RFC 4122 som en plassholder eller standardverdi. Noen applikasjoner bruker den til å representere «ingen verdi» eller «ukjent» i UUID-typede databasekolonner, på samme måte som null fungerer for andre datatyper.

Sammenligning av UUID-versjoner

UUID v1 bruker gjeldende tidsstempel og enhetens MAC-adresse — raskt, men kan lekke enhetsinformasjon. UUID v3 og v5 genererer deterministiske UUID-er fra et navnerom og et navn ved hjelp av henholdsvis MD5 og SHA-1. UUID v4 bruker ren tilfeldighet og tilbyr den beste kombinasjonen av unikhet, enkelhet og personvern. UUID v7 (utkast til standard) kombinerer et tidsstempelprefiks med tilfeldighet for tidssorterbare UUID-er.

Er min UUID sikker?

Ja. Generering bruker nettleserens native crypto.randomUUID() API, som gir kryptografisk sikker tilfeldighet. All prosessering skjer lokalt på enheten din. Ingen UUID-er logges, lagres eller overføres til noen server.

Ofte stilte spørsmål

Bør jeg bruke UUID-er eller auto-inkrementerende IDer?

UUID-er er bedre for distribuerte systemer, mikrotjenestearkitekturer og ethvert scenario der poster opprettes på flere servere. Auto-inkrementerende IDer er enklere, mindre (4–8 byte vs. 16 byte) og mer effektive for databaseindeksering. Velg basert på arkitekturen din — sentraliserte systemer kan bruke auto-inkrementering, distribuerte systemer drar nytte av UUID-er.

Må UUID-er lagres som strenger i en database?

Nei. De fleste databaser støtter en innebygd UUID-type som lagrer verdien som 16 byte i stedet for den 36-byte lange strengrepresentasjonen. PostgreSQL har en UUID-kolonnetype, MySQL kan bruke BINARY(16), og MongoDB bruker sin egen UUID binære undertype. Bruk av innebygde typer sparer lagringsplass og forbedrer søkeytelse.