Wat deze tool doet
Kies een versie, geef aan hoeveel je er wilt en klik op Genereren. Versie 4 — de willekeurige, waar vrijwel iedereen "UUID" mee bedoelt — is de standaard, en een aantal van één is meestal wat je wilt; verhoog dat wanneer je een database seedt, een fixture-bestand vult of testdata voorbereidt, en kopieer de hele batch in één keer.
Versies 3 en 5 werken anders, dus het formulier verandert wanneer je ze kiest: in plaats van een aantal nemen ze een namespace en een naam, want de identifier wordt uit die twee afgeleid in plaats van bedacht. Om er honderd vragen zou je honderd keer dezelfde waarde geven, wat precies het hele punt ervan is.
De NIL-UUID is de waarde met allemaal nullen, hier opgenomen omdat het een echte, gespecificeerde identifier is die "geen UUID" betekent, en omdat tweeëndertig nullen met de hand typen een goede manier is om het verkeerd te doen.
Elke batch verschijnt boven de vorige, zodat je een paar sets kunt genereren zonder de eerdere kwijt te raken terwijl je ze plakt. Er wordt niets opgeslagen: een herlaad wist alles.
Wat een UUID eigenlijk is
Een UUID is 128 bits, geschreven als 32 hexadecimale cijfers in vijf groepen gescheiden door koppeltekens: 8-4-4-4-12. Die koppeltekens zijn pure conventie — de waarde bestaat uit de 128 bits, en dezelfde identifier mag terecht ook verschijnen tussen accolades, als een urn:uuid:-string, of als 32 tekens zonder enig koppelteken. Hoofdlettergebruik is ook niet significant; de specificatie zegt om in kleine letters te genereren en beide te accepteren.
Twee kleine stukjes van de waarde zijn niet vrij. Het eerste cijfer van de derde groep is de versie, en daarom heeft elke versie 4 UUID daar een 4 staan en elke versie 1 een 1. Het eerste cijfer van de vierde groep codeert de variant, en voor het moderne formaat is dat altijd 8, 9, a of b. Samen nemen ze respectievelijk vier en twee bits in beslag, en daarom draagt een versie 4 UUID 122 willekeurige bits in plaats van 128.
Die twee posities kunnen aflezen is echt nuttig: gegeven een identifier uit een log of een database kun je in één oogopslag zien of hij willekeurig, tijdgebaseerd of van een naam afgeleid was — en dus of twee systemen die "dezelfde soort id" produceren werkelijk hetzelfde doen.
De versies, en welke te gebruiken
Versie 4 — willekeurig. De juiste standaard voor bijna alles. 122 bits uit de random-generator van het besturingssysteem, geen structuur, geen informatie over wanneer of waar hij gemaakt werd. Gebruik hem voor primaire sleutels, request-identifiers, bestandsnamen, idempotentiesleutels en al het andere dat alleen uniek hoeft te zijn.
Versie 1 — tijdgebaseerd. Opgebouwd uit een tijdstempel in intervallen van 100 nanoseconden sinds 1582, een kloksequentie en een node-identifier. De aantrekkingskracht is dat identifiers die kort na elkaar gemaakt zijn, ook dicht bij elkaar sorteren, wat vriendelijk is voor database-indexen. Het historische probleem is dat de node-identifier oorspronkelijk het MAC-adres van de machine was, waardoor hardware-identiteit in elk record lekte — deze pagina gebruikt in plaats daarvan een willekeurige node met de multicast-bit ingesteld, precies zoals de specificatie toestaat, zodat er niets over je machine ingebed wordt.
Versies 3 en 5 — afgeleid van een naam. Deze zijn helemaal niet willekeurig: ze hashen een namespace-UUID samen met een naam, zodat hetzelfde paar altijd dezelfde identifier oplevert, op elke machine, voor altijd. Versie 3 gebruikt MD5, versie 5 gebruikt SHA-1; geef de voorkeur aan versie 5 tenzij iets anders vereist wordt. Ze zijn het antwoord op "ik heb een stabiele id nodig voor deze URL, deze hostnaam, dit bestandspad" zonder ergens een opzoektabel bij te houden.
NIL. Allemaal nullen, wat expliciet "geen identifier" betekent. Nuttig als sentinelwaarde, maar wees voorzichtig: sommige systemen behandelen hem als een geldige sleutel en sommige wijzen hem af, en een NIL die per ongeluk binnenkwam ziet er identiek uit aan een die bedoeld was.
Twee nieuwere versies zijn de moeite waard om te kennen, ook al worden ze hier niet aangeboden: versie 7 bevat een Unix-tijdstempel op een manier die correct sorteert en is nu de aanbevolen keuze voor databasesleutels, en versie 6 is een herordende versie 1 met hetzelfde doel. De ondersteuning is nog ongelijk, en versie 4 blijft het veilige antwoord waar het niet beschikbaar is.
Hoe uniek is versie 4, echt?
122 willekeurige bits is ongeveer 5,3 × 10³⁶ mogelijke waarden. Het getal dat mensen eigenlijk willen weten is de kans op een botsing, en die volgt het verjaardagsprobleem in plaats van intuïtie: je zou ruwweg 2,7 × 10¹⁸ identifiers moeten genereren voordat de kans dat er twee overeenkomen één op een miljard bereikt. Bij een miljoen UUID's per seconde is dat langer dan het universum bestaan heeft.
Wat betekent dat het eerlijke antwoord is: voor elk echt systeem, nee, je zult geen botsing zien — mits de willekeur echt is. Die laatste voorwaarde is waar het in de praktijk misgaat. Botsingen in het wild zijn ontstaan uit generators die geseed werden met de huidige tijd, uit virtuele machines die gekloond werden met identieke entropiepools, en uit taalbibliotheken die stilletjes terugvallen op een zwakke random-bron. Deze pagina gebruikt crypto.getRandomValues, de browserinterface naar de cryptografische random-bron van het besturingssysteem.
Eén ding is een UUID niet, ondanks de bits: een geheim. Versie 4 is in de praktijk niet te raden, dus is redelijk als een niet te raden URL-component, maar versie 1 is sterk voorspelbaar als je ongeveer weet wanneer hij gemaakt werd, en versies 3 en 5 zijn volledig reproduceerbaar door iedereen die de naam kan raden. Behandel "er zit een UUID in de URL" nooit als toegangscontrole.
Namespaces, en waar versies 3 en 5 voor dienen
De namespace is zelf een UUID, en hij bestaat zodat dezelfde naam in verschillende contexten verschillende identifiers oplevert. De specificatie definieert vier standaardnamespaces — DNS, URL, OID en X.500 — en je kunt evengoed je eigen gebruiken: genereer eenmalig een versie 4 UUID, schrijf hem op, en hij wordt voor altijd de namespace voor jouw applicatie.
Het gebruiksscenario is deterministische identiteit. Als elk systeem in jouw landschap dezelfde identifier nodig heeft voor dezelfde klantreferentie, hetzelfde documentpad of dezelfde hostnaam, betekent afleiding met versie 5 dat er geen coördinatie en geen gedeelde tabel nodig is: elk systeem berekent hem onafhankelijk en komt op hetzelfde antwoord. Het betekent ook dat een identifier na gegevensverlies opnieuw berekend kan worden in plaats van verloren te zijn.
De afweging is dat de identifier onthult dat een bepaalde naam bestaat, aan iedereen die de naam kan raden en de namespace kent. Een UUID afleiden van een e-mailadres verbergt het e-mailadres niet — iedereen kan een lijst kandidaten hashen en vergelijken. Als de naam gevoelig is, is versie 4 met een opgeslagen koppeling het veiligere ontwerp.
Ze opslaan zonder spijt
Een UUID is 16 bytes. Opgeslagen als een tekenreeks van 36 tekens is het meer dan het dubbele daarvan, en elke index, join en foreign key betaalt het verschil. Gebruik in PostgreSQL het native uuid-type; gebruik in MySQL BINARY(16), en let op dat MySQL UUID_TO_BIN(x, 1) ook de tijdvelden van een versie 1 UUID omwisselt zodat hij chronologisch sorteert.
Die sorteervraag is het andere waar het de moeite waard is om op voor te bereiden. Willekeurige identifiers komen in geen enkele volgorde binnen, dus elke invoeging belandt op een willekeurige plek in de index — op een grote tabel met een geclusterde primaire sleutel is dat merkbaar trager dan opeenvolgende sleutels, en het fragmenteert de index naarmate hij groeit. Als een tabel heel groot gaat worden, is dat het argument voor een tijdgeordende identifier zoals versie 7, of voor het behouden van een interne auto-increment-sleutel terwijl de UUID publiekelijk wordt blootgesteld.
Twee kleinere gewoontes die de moeite waard zijn: normaliseer hoofdlettergebruik bij binnenkomst, want dezelfde identifier kan in beide vormen binnenkomen, en accepteer de vorm zonder koppeltekens en de vorm met accolades in plaats van ze af te wijzen — elk daarvan is dezelfde 128 bits, en een validator die op één schrijfwijze staat, zal uiteindelijk een waarde afwijzen die volkomen geldig is.
Een uitgewerkt voorbeeld
Laat de versie op 4 en het aantal op 1 staan, en klik op Genereren: je krijgt zoiets als 3f2b1c4e-…-4a9d-…, waarbij de 4 aan het begin van de derde groep de versie is en het eerste cijfer van de vierde groep 8, 9, a of b is. Verhoog het aantal naar 10 en je krijgt een genummerde batch die je in één actie kunt kopiëren.
Schakel nu over naar versie 5, laat de namespace op DNS staan en typ example.com als naam. Het resultaat is cfbff0d1-9375-5685-968c-48ce8b15ae17 — en dat zal die waarde zijn op elke machine, in elke taal, elke keer, want hij wordt afgeleid in plaats van gegenereerd. Verander de namespace naar URL met dezelfde naam en je krijgt een volledig andere identifier, wat precies is waar namespaces voor dienen. Schakel over naar versie 1 en genereer er tien: let op hoeveel van de tekenreeks de tien delen, omdat de tijdstempel het voorste deel is.
Nee. Ze worden in je browser gegenereerd en bestaan alleen in de pagina voor je. Er is geen cookie, geen lokale opslag en geen logging van wat er gegenereerd is, wat ook waarom een herlaad de resultaten wist.
Versie 4, tenzij je een specifieke reden hebt om dat niet te doen. Kies versie 5 wanneer de identifier reproduceerbaar moet zijn vanuit een naam, en versie 1 alleen wanneer iets dat vereist. Als jouw platform versie 7 ondersteunt en de identifier een databasesleutel is op een grote tabel, is dat nu de betere tijdgeordende keuze.
Hier niet. De specificatie staat een willekeurige node-identifier toe met de multicast-bit ingesteld in plaats van een hardware-adres, en dat is wat deze pagina gebruikt. Versie 1 UUID's van oudere server-side bibliotheken kunnen best een echt MAC-adres bevatten, wat één reden is waarom de versie uit de gratie raakte.
Omdat versies 3 en 5 deterministisch zijn: dezelfde namespace en naam leveren altijd dezelfde identifier op. Tien kopieën van één waarde is geen batch, dus de tool geeft de enkele waarde terug. Verander de naam om het resultaat te veranderen.
In theorie. In de praktijk zou je in de orde van 10¹⁸ versie 4-identifiers moeten genereren voordat het een kans van één op een miljard wordt. Botsingen in het echte leven komen voort uit kapotte willekeur — een voorspelbare seed, een gekloonde virtuele machine — eerder dan uit het opraken van de wiskunde.
Een versie 4 UUID is onvoldoende te raden om als niet-gelinkte URL te dienen, maar het is geen credential en belandt meestal toch in logs, referrers en analytics. Versies 1, 3 en 5 zijn voorspelbaar of reproduceerbaar en zouden nooit als geheim behandeld moeten worden. Genereer voor een echt geheim in plaats daarvan een token.
Genereer kleine letters, accepteer beide. De specificatie is daar expliciet over, en elke verstandige parser ook — de hexadecimale cijfers zijn in beide gevallen dezelfde waarde. Het selectievakje is er voor de systemen en documenten die ze met hoofdletters weergeven.