- Type
- Versie 7: sorteerbare Unix-datum
- Variant
- RFC 9562 (voorheen RFC 4122)
- Aanmaakdatum
- 22 feb 2022, 16:22:22 2022-02-22T19:22:22.000Z · 1645557742000 ms
017f22e2-79b0-7cc3-98c4-dc0c0c07398f017F22E2-79B0-7CC3-98C4-DC0C0C07398F{017F22E2-79B0-7CC3-98C4-DC0C0C07398F}urn:uuid:017f22e2-79b0-7cc3-98c4-dc0c0c07398f01FWHE4YDGFK1SHH6W1G60EECF017f22e279b07cc398c4dc0c0c07398f1989357241971137676463954034883508623AX8i4nmwfMOYxNwMDAc5jw==Hoe het werkt
Een UUID is een getal van 128 bits, geschreven als 32 hexadecimale cijfers in vijf groepen (8-4-4-4-12). Het identificeert een record zonder dat je hoeft te vragen of de waarde al in gebruik is: twee servers, twee mobiele apps of twee processen kunnen tegelijk identifiers maken zonder afstemming en zonder botsingen. Het formaat staat in RFC 9562, die in 2024 RFC 4122 verving en versie 6, 7 en 8 toevoegde.
Het cijfer aan het begin van de derde groep geeft de versie aan, en elke versie deelt de bits anders in. Versie 4 is puur toeval. Versie 7 begint met de datum in milliseconden, waardoor identifiers op aanmaakmoment gesorteerd zijn. Versie 3 en 5 bevatten niets willekeurigs: ze komen uit de hash van een namespace en een naam en geven dus altijd hetzelfde resultaat. Versie 1 en 6 bevatten een datum met een precisie van 100 nanoseconden en een node die vroeger het MAC-adres van de computer was.
De analyser werkt andersom: hij leest de versie en variant, haalt de datum uit UUID's van versie 1, 6 en 7 en uit ULID's, en toont dezelfde waarde als GUID, URN, hexadecimaal, geheel getal of Base64. Alles wordt in je browser berekend; geen enkele identifier gaat naar een server.
Voorbeelden
v5 · DNS · www.example.com2ed6657d-e927-568b-95e1-2665a8aea6a2Dit is de testvector uit RFC 9562. Elke bibliotheek die versie 5 goed implementeert, moet voor die naam in de DNS-namespace precies deze waarde teruggeven.017F22E2-79B0-7CC3-98C4-DC0C0C07398F2022-02-22T19:22:22.000ZDe eerste 12 cijfers van een v7-UUID zijn de Unix-milliseconden in hexadecimaal: 0x017F22E279B0 is 1645557742000.C232AB00-9414-11EC-B3C8-9F6BDECED8461EC9414C-232A-6B00-B3C8-9F6BDECED846Hetzelfde moment als versie 1 en als versie 6. Versie 6 zet de datumbits van meest naar minst significant, zodat de tekst chronologisch sorteert; de klokvolgorde en de node veranderen niet.01ARZ3NDEKTSV4RRFFQ69G5FAV01563e3a-b5d3-d676-4c61-efb99302bd5bEen ULID beslaat dezelfde 128 bits als een UUID en past dus in een uuid-kolom. Maar hij heeft geen versie of variant: als UUID gelezen horen die cijfers bij het willekeurige deel.Gebruiksscenario's
- De primaire sleutel in de client of in meerdere services tegelijk maken, zonder te wachten tot de database een auto-increment toekent.
- Idempotentiesleutels genereren zodat een opnieuw geprobeerde betaling of bestelling niet twee keer wordt verwerkt.
- Elk verzoek voorzien van een correlatie-ID om het te volgen door de logs van meerdere microservices.
- Met v5 een stabiele identifier afleiden van een natuurlijke sleutel (een e-mail, een URL, een SKU), zodat twee systemen zonder gedeelde tabel op dezelfde waarde uitkomen.
- Achterhalen wanneer een record is aangemaakt aan de hand van zijn v7-UUID of ULID als die in een log of foutrapport opduikt.
- Testdata in één keer vullen met honderden geldige identifiers.
Veelgestelde vragen
v4 of v7 als primaire sleutel?
v7, tenzij je een reden hebt om de aanmaakdatum te verbergen. B-tree-indexen bewaren sleutels op volgorde, en een v4 belandt overal in de index: elke insert raakt een andere pagina, pagina's worden gesplitst en de cache presteert minder. Een v7 komt altijd achteraan, zoals een auto-increment. Let op bij SQL Server: het type uniqueidentifier sorteert vanaf de laatste zes bytes, dus daar is ook een v7 niet sequentieel.
Kunnen twee v4-UUID's gelijk zijn?
In theorie wel, in de praktijk niet. Een v4 heeft 122 willekeurige bits, en om een kans van 50 % op minstens één herhaling te halen zou je er ongeveer 2,7 × 10¹⁸ moeten maken, oftewel een miljard per seconde gedurende meer dan 85 jaar. Voorwaarde is een cryptografische generator: de echte duplicaten die worden gemeld komen van slecht geïnitialiseerde seeds, niet van de wiskunde.
Zijn UUID en GUID hetzelfde?
Ja, GUID is de naam die Microsoft gebruikt en de tekst is identiek; in Windows staat hij meestal in hoofdletters en tussen accolades. Het verschil zit in de binaire vorm: Guid.ToByteArray van .NET slaat de eerste drie groepen op in little-endian, dus als je die ruwe bytes vanuit een andere taal leest, zie je de eerste cijfers omgedraaid.
Kan ik een UUID als geheim token gebruiken?
Een goed gegenereerde v4 heeft 122 onvoorspelbare bits, genoeg voor een moeilijk te raden link, maar RFC 9562 zegt duidelijk dat UUID's niet bedoeld zijn als inloggegevens: veel bibliotheken garanderen geen cryptografische generator, en versie 1, 6 en 7 verraden de aanmaakdatum. Voor sessie- of wachtwoordhersteltokens kun je beter aparte willekeurige bytes genereren.
ULID of UUID v7?
Ze bevatten bijna dezelfde informatie: 48 bits milliseconden en de rest willekeurig. Een ULID wordt geschreven in 26 tekens zonder koppeltekens of dubbelzinnige letters, handiger in een URL. Een v7 is een standaard-UUID en past dus zonder conversie in uuid-kolommen van PostgreSQL en in elke validator. Begin je vanaf nul en heeft je database een uuid-type, kies dan v7.
Waarom is de node van mijn v1-UUID's niet mijn MAC-adres?
Omdat het MAC-adres van de netwerkkaart verraadt welke machine elke identifier heeft gemaakt; zo werd in 1999 de maker van het Melissa-virus geïdentificeerd. RFC 9562 raadt een willekeurige node met de multicastbit aan, en dat doet deze tool; de analyser meldt het als een v1-UUID een echt MAC-adres bevat.