About
Viser på Norsk Bytt til engelsk

UUID-generator

Generer v4 (tilfeldige) eller v7 (tidssorterte) UUID-er i nettleseren. Bruker Web Crypto API for tilfeldighet.

  1. Velg v4 for tilfeldige UUID-er eller v7 for tidssorterte.
  2. Sett Antall (opptil 1000) og klikk Generer.
  3. Bruk Kopier alle for å ta hele listen, eller velg en enkelt linje manuelt.
Hva gjør det?

v4 UUID-er er 122 bit med kryptografisk sterk tilfeldighet — den allestedsnærværende standarden for idempotency-nøkler, sesjons-ID-er, og overalt hvor du vil ha en ugjennomsiktig, usortert identifikator. v7 UUID-er bygger inn et 48-bits Unix-millisekund-tidsstempel i de ledende bytene, slik at verdier generert nær hverandre i tid sorterer nær hverandre i leksikografisk orden. Det gjør v7 bedre egnet som primærnøkkel i databaser, der innsetting av v4 ellers kan fragmentere en B-tree-indeks.

Eksempel

Tre v4 UUID-er (tilfeldige, uten orden):

f47ac10b-58cc-4372-a567-0e02b2c3d479
6ba7b810-9dad-11d1-80b4-00c04fd430c8
d1b2c3e4-5678-4abc-9def-0123456789ab

Tre v7 UUID-er generert innenfor samme millisekund (merk det delte prefikset):

018f8e50-fcaa-7c3c-8d2a-6f5b72e1fd90
018f8e50-fcaa-7c3d-a41f-8c9b07e2c0d1
018f8e50-fcab-7c01-b3e7-1d9a4f5c6e82

Vanlige feil og fallgruver

Dette er de reelle fallgruvene utviklere støter på når de kobler UUID-er inn i en applikasjon:

  • Bruke v4 der innsettingsrekkefølge betyr noe. Å indeksere 10 millioner tilfeldige v4-er gir tunge sideoppdelinger i en B-tree. Hvis du beholder v4, enten lev med skrive-forsterkningen eller bytt primærnøkkelen til v7.
  • Fjerne bindestreker og miste versjonsnibblen. f47ac10b58cc4372a5670e02b2c3d479 er fortsatt en gyldig 32-tegns hex-UUID, men det 13. tegnet (4) er versjonsmarkøren — ikke en tilfeldig nibble. Ikke anta at alle 32 tegn er tilfeldige.
  • Stole på Math.random(). Eldre biblioteker bygget på Math.random() er ikke kryptografisk sterke og kan være forutsigbare. Bruk crypto.randomUUID() (nettlesere og Node 19+) eller et v7-bibliotek som leser fra crypto.
  • Behandle v7 som et tidsstempel. De ledende 48 bitene bærer tid, men resten er tilfeldig, så to v7-er med samme millisekund er ikke deterministisk sortert. Ikke stol på uavgjort-løsning.
  • Lagring som VARCHAR(36). Det fungerer, men dobler lagringen vs en native 16-byte UUID / BINARY(16)-kolonne og bremser join-er. Bruk databasens native type (uuid i Postgres, UNIQUEIDENTIFIER i SQL Server).
  • Regex som krever en spesifikk versjon. /[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-.../i matcher kun v4. Hvis du senere sender ut v7, avviser den regexen stille gyldige ID-er.
Ofte stilte spørsmål

Hva er forskjellen mellom UUID v4 og v7?

v4 er 122 bit tilfeldighet pluss versjons- og variantmarkører, uten tidskomponent. v7 prefikser et 48-bits Unix-millisekund-tidsstempel og fyller resten med tilfeldige bit, så v7-verdier generert nær hverandre i tid sorterer leksikografisk. Bruk v7 som primærnøkkel i databaser for å holde B-tree-innsettinger lokale; bruk v4 når du ikke vil ha noe sorteringssignal i det hele tatt.

Vil jeg noen gang få en duplisert UUID?

Praktisk talt nei. En v4 UUID har 122 tilfeldige bit, så sannsynligheten for at noen to kolliderer i en batch på én milliard er omtrent 10^-18. Du måtte generert i størrelsesorden 2,7 trillioner v4 UUID-er før du nådde 50 % sjanse for en enkelt kollisjon. Behandle unik generering som gitt, og ikke legg til en unikhetssjekk.

Er v4 kryptografisk tilfeldig?

Dette verktøyet bruker crypto.randomUUID() som er pålagt av spesifikasjonen å trekke fra en kryptografisk sterk PRNG. Det er nok for sesjons-ID-er, idempotency-nøkler og de fleste sikkerhetstokens. Det er ikke en erstatning for et signert token eller en lang API-hemmelighet, og du bør ikke utlede krypteringsnøkler fra en UUID.

Er UUID v7 standardisert?

Ja. UUID v7 er definert i RFC 9562 (mai 2024), som erstattet RFC 4122 og formaliserte v6, v7 og v8 sammen med de opprinnelige versjonene. De fleste moderne språk har v7-implementasjoner — Postgres, MySQL og SQL Server godtar alle v7-verdier som en UUID-kolonne uten endringer.

Hvordan ser binærformen ut og betyr endianness noe?

En UUID er 16 byte. Den kanoniske tekstformen grupperer dem som 8-4-4-4-12 hex-tegn. Byte skrives i nettverks- (big-endian) rekkefølge per RFC 9562, så 018f8e50-fcaa-7c3c-8d2a-6f5b72e1fd90 starter med byten 0x01. Microsoft GUID-er lagrer historisk de første tre gruppene little-endian i minnet — pass på ved interop med .NET binærdumper.

Lagrer dere UUID-ene dette verktøyet genererer?

Nei. Vi lagrer ikke UUID-ene du genererer her. Hver verdi vises i utdataområdet og er borte i det øyeblikket du oppdaterer eller lukker fanen — ingenting lagres, ingen telemetri samles om verdiene. Du er velkommen til å verifisere i nettleserens utviklerverktøy.