UUID v7-generator

UUID v7-generator: Tidsordnede, uforudsigelige ID'er i browseren

UUID v7 er et standardiseret identifikatorformat, der kombinerer et 48-bit Unix-millisekund-tidsstempel med tilfældige bits. Resultatet er en 36 tegn lang streng, der kan sorteres kronologisk efter oprettelsestidspunkt, samtidig med at den forbliver kryptografisk uforudsigelig. Denne side lader dig generere mellem 1 og 100 UUID v7‑ID'er med et enkelt klik – uden at sende noget til nogen server.

Hvad gør UUID v7 anderledes end UUID v4?

UUID v4 består udelukkende af tilfældige bits (122 bit tilfældighed). Det gør ID'erne fuldstændigt uforudsigelige, men også fuldstændigt usorterbare i forhold til oprettelsestid. Når en database gemmer UUID v4 som primær nøgle, spredes nye rækker tilfældigt i B‑træets sider, hvilket forårsager fragmentering, hyppige sideopdelinger og dårlig cache‑lokalitet.

UUID v7 placerer et 48‑bit Unix‑millisekund-stempel i de første 6 byte (12 hexadecimaltegn) af ID'et. De resterende 74 bit (version 7, variant 10xx, plus tilfældige bits) gør ID'et fortsat svært at gætte. Fordi tidsstemplet er først, lander nye ID'er i databasen ved siden af hinanden, når de indsættes sekventielt. Det reducerer fragmentering markant og forbedrer skrive‑ og læseydelse.

Den væsentligste begrænsning: UUID v7 garanterer ikke streng rækkefølge for ID'er, der genereres inden for samme millisekund. Hvis din applikation producerer to ID'er i samme millisekund, kan de to ID'er komme i vilkårlig rækkefølge, fordi den tilfældige del bestemmer den indbyrdes orden. Det er en bevidst afvejning for at tillade parallel generering på tværs af tråde eller maskiner – ellers ville man skulle bruge en central sekvensgenerator.

Inputs og outputs: Hvad kan du styre?

Siden giver dig fire kontroller:

Når du ændrer en hvilken som helst indstilling, regenereres listen øjeblikkeligt. Det sker helt lokalt i browseren. BroBroGo får aldrig kendskab til de genererede ID'er.

Outputtet viser:

• En liste af UUID v7-identifikatorer, hver på 36 tegn.
• ID count: Antallet af genererede ID'er.
• Statuslinjen skifter mellem Ready. (tomgang) og Generated. (efter generering).
• Når du kopierer alle ID'er med knappen, vises Copied all! i et par sekunder.
• Klik på et enkelt ID for at kopiere det til udklipsholderen.

Hvis du slår bindestreger fra, bliver strengen 32 tegn lang (128 bit uden separatorer). Hvis du slår store bogstaver til, vises alle hexadecimale tegn (A–F) med versaler. Standardformatet følger RFC 9562, som anbefaler små bogstaver og bindestreger, men nogle systemer kræver store bogstaver eller en kompakt repræsentation.

Hvordan UUID v7 er bygget op

Formatet følger RFC 9562 (og dets forgænger, draft‑ietf‑uuidrev‑rfc4122bis). Bit‑layoutet ser sådan ud (vist som hex‑streng med bindestreger):

tttttttt-tttt-Vttt-axxx-yyyyyyyyyyyyyyyy

• t: 48 bit timestamp (Unix millisekunder). De første 12 hexadecimale tegn.
• V: 4 bit version (altid 0111 for v7, dvs. hex 7).
• a: 2 bit variant (altid 10 for RFC 9562-varianten, dvs. hex 8, 9, A eller B).
• x: 2 bit tilfældige bits (eller kan være en monotomisk tæller i nogle implementationer, men denne generator bruger tilfældige bits).
• y: 56 bit tilfældige bits (14 hexadecimale tegn).

I alt 128 bit. Timestamp-delen gør ID'et sorterbart efter oprettelsestidspunkt, men kun med millisekund‑præcision. Hvis du har brug for strengere rækkefølge inden for millisekundet, skal du overveje ULID (som har en 48‑bit timestamp + en 80‑bit tilfældig del, men ULID er ikke et UUID‑format) eller en anden monotomisk konstruktion.

Eksempel på et UUID v7 genereret på denne side:

018f3a6e-7a80-7f23-b4c5-1a2b3c4d5e6f

Første 12 tegn (018f3a6e7a80) er timestamp i hex. Den 13. er 7 = version 7. Den 17. er b = variant (binært 1011). Resten er tilfældigt.

Hvem har brug for dette?

Databaseadministratorer oplever direkte fordele: UUID v4 fører til dårlig indeks‑lokalitet i B‑træer, fordi nye rækker indsættes tilfældigt i hele indekset. UUID v7 skriver nye rækker i nærheden af hinanden, hvilket reducerer disk‑IO og cache‑misser. PostgreSQL, MySQL, SQL Server og andre understøtter UUID som kolonnetype, men indeksydelsen afhænger af, hvilken UUID‑version du bruger.

Distribuerede systemer drager fordel af, at ID'er kan sorteres på tværs af noder uden at kræve et centralt tidsserverkald. Hvis hver node genererer UUID v7 med sit eget ur, kan du stadig sortere hændelser kronologisk – så længe urene er nogenlunde synkroniserede (typisk inden for millisekunder på moderne hardware).

Sikkerhedsbevidste udviklere foretrækker UUID v7 frem for sekventielle heltal (f.eks. auto_increment), fordi den tilfældige del gør ID'er uforudsigelige. En angriber kan ikke gætte næste ID ved at se på tidligere ID'er. Samtidig får du stadig tidsordning, hvilket auto_increment giver, men uden at afsløre antallet af poster eller tillade sårbarheder som insecure direct object reference (IDOR).

Kanttilfælde og almindelige fejl

Streng rækkefølge er ikke garanteret inden for samme millisekund

Dette er den hyppigste misforståelse. UUID v7 garanterer kun, at ID'er med et tidligere tidsstempel kommer før ID'er med et senere tidsstempel. Hvis to ID'er har samme millisekund, kan de komme i vilkårlig rækkefølge. Det betyder, at du ikke kan bruge UUID v7 som eneste sorteringsnøgle, hvis du har brug for en total orden inden for millisekundet.

Store bogstaver vs små bogstaver påvirker sortering

Hexadecimale tegn er case‑ufølsomme i de fleste databaser, men hvis du kopierer ID'er i store bogstaver og indsætter dem i et system, der forventer små bogstaver, kan sammenligning fejle. Siden lader dig selv vælge. Standard er små bogstaver, som er mest almindeligt i RFC'erne.

Bindestreger er ikke påkrævet, men anbefales

UUID v7 uden bindestreger (32 tegn) er fuldt ud gyldig, men nogle biblioteker og UI‑komponenter forventer bindestreger. Hvis du gemmer UUID uden bindestreger i en database, kan du altid tilføje dem ved visning. Omvendt kan du fjerne dem programmatisk, hvis dit system kræver det.

Hvordan genereres ID'erne lokalt?

Siden kører helt i browseren. Den bruger crypto.getRandomValues() (tilgængelig i alle moderne browsere) til at generere de tilfældige bits. Timestamp hentes fra Date.now(), som returnerer millisekunder siden Unix‑epoken (1. januar 1970 00:00:00 UTC). Begge dele kombineres i overensstemmelse med RFC 9562. Der sendes ingen HTTP‑request, intet logges, og ingen data forlader din computer.

Det betyder, at du kan generere UUID v7 selv på en offline computer eller i et lukket netværk. Der er ingen rate‑limiting, og du kan generere op til 100 ID'er ad gangen (gentag efter behov).

Ofte stillede spørgsmål

Hvorfor kan jeg ikke generere mere end 100 ID'er ad gangen?

Grænsen er sat for at holde brugergrænsefladen responsiv. Du kan sagtens klikke flere gange for at få flere ID'er – hvert sæt er uafhængigt og bruger et nyt tidspunkt.

Kan UUID v7 kollidere?

Ekstremt usandsynligt. Med 74 bit tilfældighed kræves omkring 2^37 ≈ 137 milliarder ID'er, før chancen for en enkelt kollision overstiger 50 % (ifølge fødselsdagsparadokset). Hvis du genererer ID'er på samme maskine med samme millisekund, kommer den tilfældige del i spil. Hvis du bruger flere maskiner, er kollisionssandsynligheden stadig ubetydelig, medmindre du genererer astronomisk mange ID'er.

Skal jeg bruge UUID v7 i stedet for ULID?

Begge formater er tidssorterbare. ULID har en 48‑bit timestamp (samme som UUID v7) og 80 bit tilfældighed, men det er ikke et UUID‑format. Hvis dit økosystem forventer UUID'er (f.eks. PostgreSQL's uuid‑type), er UUID v7 nemmere at integrere. ULID har til gengæld en Crockford‑baseret kodning (26 tegn) og en tæller for samme millisekund, så det garanterer streng orden inden for millisekundet. Vælg det format, der passer til din database og dine krav.

Kan jeg kopiere alle ID'er på én gang?

Ja. Der er en knap til at kopiere hele listen til udklipsholderen. Du får en statusmeddelelsen "Copied all!" når det lykkes. Du kan også klikke på et enkelt ID for at kopiere det.