UUID v4 generator

De UUID v4 generator is een gratis tool waarmee je een versie 4 Universally Unique Identifier maakt voor gebruik als identificatie van een record, object of verzoek.

Hoe gaat de UUID v4 generator om met mijn gegevens?

Het genereren gebeurt op de server. De invoer wordt via HTTPS naar de server verstuurd en niet opgeslagen. Het zou daarom onjuist zijn om te zeggen dat alles volledig in je browser gebeurt of dat gegevens je apparaat nooit verlaten.

Voor een UUID v4 hoef je geen persoonlijke tekst, naam of wachtwoord in te voeren. De waarde wordt als identificatie gegenereerd en niet berekend aan de hand van informatie die je verstrekt. Ken geen vertrouwelijke betekenis toe aan het resultaat, want iedereen die de waarde kan zien, kan deze kopiëren en hergebruiken.

Wat is een UUID v4?

Een UUID v4 is een 128-bits identificatie waarvan het variabele gedeelte willekeurig of pseudowillekeurig wordt gegenereerd. Enkele bits zijn gereserveerd om de UUID-versie en variant aan te duiden. Deze UUID wordt vaak gebruikt wanneer afzonderlijke systemen identificaties moeten kunnen maken zonder eerst bij een centrale dienst het volgende beschikbare nummer op te vragen.

De standaardnotatie bevat 32 hexadecimale tekens, door koppeltekens verdeeld over vijf groepen. Het patroon is 8-4-4-4-12. Met de vier koppeltekens erbij is de UUID 36 tekens lang.

Een syntactisch geldig voorbeeld is 550e8400-e29b-41d4-a716-446655440000. Bij een versie 4-UUID is het eerste teken van de derde groep een 4. De twee meest significante bits die de variant aangeven zijn 10. Daardoor begint de vierde groep met het hexadecimale teken 8, 9, a of b.

De waarde is een identificatie, geen gecodeerde informatie. Je kunt de UUID niet decoderen om een aanmaakdatum, accountnaam, machineadres of volgnummer te achterhalen.

Welke UUID-versie moet ik kiezen?

Kies versie 4 als je een onafhankelijk gegenereerde, nietszeggende identificatie nodig hebt en dezelfde invoer niet telkens hetzelfde resultaat hoeft op te leveren. Kort samengevat: v1 gebruikt tijd- en node-informatie, v2 is de DCE Security-variant, v3 leidt met MD5 een UUID af uit een namespace en naam, v4 is willekeurig, v5 gebruikt daarvoor SHA-1, v6 herschikt tijdgebaseerde gegevens, v7 combineert een Unix-tijdstempel met willekeurige gegevens en v8 is bedoeld voor experimentele of leveranciersspecifieke indelingen.

• Gebruik UUID v4 voor record-ID's, uploadreferenties, ID's van API-verzoeken en testfixtures waarvoor willekeurig verdeelde identificaties geschikt zijn.
• Gebruik UUID v5 als een bepaalde namespace en naam altijd dezelfde identificatie moeten opleveren. Dit is nuttig voor herhaalbare imports en regels voor deduplicatie.
• Overweeg UUID v7 wanneer identificaties van records globaal de aanmaaktijd moeten volgen en je database of software deze versie ondersteunt.
• Gebruik een normaal oplopend geheel getal wanneer één database de waarden aanmaakt en compacte, van nature geordende sleutels belangrijker zijn dan gedecentraliseerde generatie.

Oudere versies worden nog in bestaande systemen gebruikt. Kies voor een nieuw ontwerp echter de versie die bij de werkelijke vereisten past, in plaats van alle UUID-versies als onderling uitwisselbaar te beschouwen.

UUID v4 in de praktijk gebruiken

Genereer een UUID, neem de waarde uit het resultaatveld UUID v4 over en sla de volledige canonieke tekenreeks op, tenzij het ontvangende systeem een andere notatie voorschrijft.

1. Maak een nieuwe UUID voor het object of de gebeurtenis die een eigen identificatie nodig heeft.
2. Behoud alle vijf groepen en vier koppeltekens wanneer je de UUID tussen systemen uitwisselt.
3. Sla de waarde op in een UUID-gegevenstype van de database als dat beschikbaar is. Gebruik anders een tekst- of binair veld met voldoende ruimte voor de gekozen notatie.
4. Voeg een unieke beperking toe als de database dubbele, gegenereerde UUID v4-waarden moet weigeren.

Veelvoorkomende toepassingen zijn het identificeren van een bestelling voordat deze de hoofddatabase bereikt, het koppelen van logboekvermeldingen uit verschillende diensten, het benoemen van een geüpload object en het toewijzen van stabiele ID's aan rijen die voor import worden voorbereid. Gegevenssets die onafhankelijk van elkaar zijn gemaakt, zijn met UUID's vaak eenvoudiger samen te voegen dan met lokale reeksen van gehele getallen. Die reeksen kunnen in elke bron dezelfde waarden bevatten.

Spaties, leestekens, letters met accenten en niet-Latijnse tekens vormen geen lastige invoer voor UUID v4, omdat de identificatie niet uit tekst wordt afgeleid. Heb je een identificatie nodig die is gebaseerd op een naam met zulke tekens, gebruik dan een naamgebaseerd UUID-schema en leg de exacte tekencodering en normalisatieregels vast. Anders kan tekst die er hetzelfde uitziet uit verschillende bytereeksen bestaan en daardoor verschillende identificaties opleveren.

Kunnen twee UUID v4-waarden hetzelfde zijn?

Ja, een botsing is theoretisch mogelijk. Bij normaal gebruik van UUID v4 is dit echter geen praktisch probleem als voor het genereren een geschikte bron van willekeur wordt gebruikt. Een v4-UUID heeft 122 variabele bits, omdat de overige bits de versie en variant aangeven. Daardoor blijft een uitzonderlijk grote verzameling mogelijke waarden over.

"Universeel uniek" is dus een praktische omschrijving en geen wiskundige garantie. Per ongeluk gekopieerde of hergebruikte waarden, implementatiefouten en slechte generatie van willekeurige getallen door een ontoereikende bron vormen realistischer risico's op dubbele waarden dan het toeval alleen. Systemen waarin duplicaten onaanvaardbaar zijn, moeten uniciteit alsnog afdwingen in de database of applicatie.

Een UUID bewijst ook niet dat een verzoek echt is. Gebruik een zichtbare UUID niet als enige vorm van autorisatie. Ga er evenmin van uit dat een object beschermd is alleen omdat het adres moeilijk te raden is. Pas toegangscontroles toe op de onderliggende bron waarnaar de UUID verwijst.

Veelgestelde vragen

Zijn UUID's hoofdlettergevoelig?

Nee, bij hexadecimale letters in een UUID-notatie wordt normaal gesproken geen onderscheid gemaakt tussen hoofdletters en kleine letters. A en a stellen dus dezelfde waarde voor. Kleine letters zijn de gebruikelijke canonieke notatie. Door het hoofdlettergebruik vóór een tekstvergelijking te normaliseren, voorkom je inconsistente resultaten in systemen die tekenreeksen wel hoofdlettergevoelig vergelijken.

Kan ik een UUID v4 in een URL of bestandsnaam gebruiken?

Ja, de canonieke notatie gebruikt hexadecimale tekens en koppeltekens. Die zijn allemaal geschikt voor gewone URL-padsegmenten en gangbare bestandssystemen. Voeg geen accolades toe, tenzij een specifieke API deze vereist. Houd er ook rekening mee dat een bron niet privé wordt doordat je een UUID in de URL gebruikt.

Moet ik de koppeltekens uit een UUID verwijderen?

Verwijder ze alleen als de ontvangende indeling uitdrukkelijk 32 hexadecimale tekens verwacht. Veel bibliotheken en UUID-gegevenstypen van databases accepteren de canonieke notatie met koppeltekens. Deze is voor mensen makkelijker te herkennen en wordt minder snel verward met een niet-gerelateerde hexadecimale waarde.

Kan ik een UUID v4 als wachtwoord of API-geheim gebruiken?

Nee, een identificatie en een geheim dienen verschillende doelen. Sommige UUID-implementaties gebruiken mogelijk een geschikte bron van willekeur, maar de UUID-indeling zelf biedt geen garantie voor de verwerking, geheimhouding of hoeveelheid entropie die wachtwoorden, sessietokens en API-inloggegevens vereisen. Genereer inloggegevens en tokens met een methode die daarvoor is bedoeld, niet met een UUID v4 generator.

Kan een UUID v4 volgens de AVG een persoonsgegeven zijn?

Ja, een UUID kan een persoonsgegeven zijn wanneer deze iemand identificeert of aan een identificeerbare persoon kan worden gekoppeld, ook als de tekens niet rechtstreeks een naam onthullen. Behandel UUID's die aan klantaccounts, apparaten of activiteitsgegevens zijn gekoppeld volgens de context en de bewaar- en toegangsregels van de organisatie.

Kan ik UUID v4 als primaire databasesleutel gebruiken?

Ja, veel databases ondersteunen UUID's rechtstreeks als primaire sleutel. Willekeurig verdeelde sleutels kunnen indexinvoegingen minder lokaal maken dan geordende gehele getallen of tijdgebaseerde identificaties. Raadpleeg daarom de databaserichtlijnen voor tabellen waarin veel wordt geschreven. Behoud een unieke beperking en gebruik bij imports, query's en applicatiecode steeds dezelfde opslagnotatie.