UUID controleren

Een UUID is 128 bits, gewoonlijk geschreven als 32 hexadecimale cijfers in vijf groepen met streepjes ertussen. Aan zo’n reeks vallen drie dingen te controleren: of de vorm klopt, welke versie het dertiende teken opgeeft en welke variant de eerste bits van de vierde groep aangeven.

Wat niet te controleren valt, is of de identifier ooit is uitgegeven. Er is geen register en geen controlecijfer — een UUID draagt geen informatie over of hij echt is. Wie wil weten of er een record bij hoort, moet dat aan zijn eigen database vragen; deze pagina beantwoordt de vraag ervoor, namelijk of het de moeite van het vragen waard is.

Het versienummer is het eerste teken van de derde groep, oftewel het dertiende hexadecimale cijfer. Een `4` daar betekent willekeurig, een `1` op tijd gebaseerd, een `7` sorteerbaar op tijd volgens het nieuwere RFC 9562, en de `3` en de `5` horen bij de op naam gebaseerde varianten met MD5 en met SHA-1.

Het is met het blote oog te lezen zodra je weet waar je moet kijken, en het is de snelste manier om een vermoeden te bevestigen. Wie een identifier ziet die op die plek geen bekend cijfer heeft, kijkt naar een UUID van vóór de versienummering of naar iets dat er alleen op lijkt.

Het eerste teken van de vierde groep moet `8`, `9`, `a` of `b` zijn. Die vier cijfers delen de beginbits `10`, en dat is de variant die RFC 4122 voor zichzelf opeist; elke andere waarde hoort bij oude of gereserveerde schema’s.

In de praktijk: een identifier met de juiste versie maar met een `c` of een `f` op die plek is niet door een conforme bibliotheek gemaakt. De gebruikelijke oorzaak zijn zelfgebouwde generatoren die 32 willekeurige cijfers aaneenrijgen en de twee vaste posities over het hoofd zien — een fout die jarenlang onopgemerkt kan blijven.

De specificatie vraagt kleine letters bij het aanmaken en verdraagzaamheid bij het lezen. In de praktijk kom je beide tegen: .NET en veel Windows-gereedschap schrijven van oudsher in hoofdletters, het meeste andere in kleine letters.

Daar komen twee veelvoorkomende omhulsels bij: de accolades uit de notatie van het Windows-register, en een `urn:uuid:` ervoor uit de URN-naamruimte. Allebei worden ze hier herkend en genegeerd. Wie zelf vergelijkt, moet eerst normaliseren, anders vallen twee identieke identifiers uit elkaar op hun schrijfwijze.

Een UUID van versie 1 bevat het moment van aanmaken met een precisie van 100 nanoseconden en, in de laatste groep, van oudsher het MAC-adres van de netwerkkaart. Allebei zijn ze te reconstrueren door wie de identifier heeft.

Dat is niet theoretisch: het was de weg waarlangs in 1999 de maker van het Melissa-virus werd gevonden, omdat Word het MAC-adres in de document-id’s schreef. Waar een identifier van buiten zichtbaar is, is versie 4 de juiste keuze; moderne bibliotheken zetten er bovendien een willekeurige knoop in plaats van het echte adres in.

Versie 7 zet een tijdstempel in milliseconden vooraan en vult de rest met toeval, zodat de identifiers op hun eigen waarde op tijd geordend zijn — en dat lost het probleem op waarom veel teams UUID’s als primaire sleutel meden.

De oorzaak is de index van de database. Willekeurige sleutels schrijven op steeds wisselende plekken in een B-boom, wat pagina’s splitst en de cache verspilt; bij grote tabellen kost dat meetbaar schrijfprestatie. Een oplopende sleutel schrijft achteraan. De keerzijde is dat het moment van aanmaken weer leesbaar is.

Een identifier van louter nullen is de nil-UUID, uitdrukkelijk in de specificatie voorzien en formeel geldig, ook al draagt hij geen versie en geen variant. Hij betekent «geen» en komt voor waar een veld niet leeg mag zijn maar wel leeg hoort te zijn.

Sinds RFC 9562 bestaat zijn tegenhanger, de max-UUID van louter `f`. Allebei komen ze hier door de controle en worden ze als zodanig benoemd. Wie een nil-UUID in productiegegevens aantreft, doet er goed aan te wantrouwen: het is zelden een bewust gezette markering en meestal een generator die stil is gefaald.

De meest voorkomende fouten zijn banaal: 31 cijfers in plaats van 32 doordat er bij het kopiëren één is weggevallen, een spatie aan het eind uit een cel van een spreadsheet, of een reeks van 32 cijfers zonder streepjes. Dat laatste is een gangbare opslagvorm in een kolom en volkomen normaal, alleen is het niet de tekstuele vorm.

In zulke gevallen wordt hier gezegd wat er mis is, in plaats van het bij «ongeldig» te laten. Dat is de echte waarde: wie een identifier uit een foutmelding krijgt, wil weten of er een teken is weggevallen of dat de tegenpartij iets heeft gestuurd dat nooit een UUID was.

De streepjes horen bij de tekstuele weergave en niet bij de identifier. Veel systemen bewaren de 32 cijfers zonder streepjes in een kolom, en sommige bewaren de 16 bytes rechtstreeks, wat de helft van de ruimte kost.

Bij die binaire opslag zit een addertje dat veel tijd kost: .NET en SQL Server bewaren de eerste drie groepen in omgekeerde bytevolgorde. Dezelfde identifier ziet er dan als hex-dump anders uit dan in een systeem dat de bytes op volgorde bewaart, terwijl de tekstuele vorm identiek is. Vergelijk je op byteniveau tussen twee systemen, dan is dit de eerste verdachte.

De uitdrukking die overal rondslingert, controleert 8-4-4-4-12 hexcijfers en verder niets. Die laat identifiers door met een versie die niet bestaat en met een variant die nergens op slaat, en weigert tegelijk de nil-UUID, de vorm met accolades en de URN-vorm.

Hier worden die posities apart gelezen en wordt de omhulling eraf gehaald voordat er wordt gekeken. Dat is het verschil tussen «het ziet eruit als een UUID» en «het is er een, en dit is de versie» — en die tweede uitspraak is meestal de reden dat iemand het komt controleren.

Een UUID is op zichzelf geen persoonsgegeven, maar hij is vaak wel de sleutel die naar een persoon leidt: een gebruikers-id, een sessiesleutel, een zaaknummer uit een supportsysteem. Omdat de controle op de pagina gebeurt, wordt daar niets van aan ons verstrekt.

Bij identifiers van versie 1 komt daarbij dat ze informatie in zich dragen: het tijdstip en mogelijk het MAC-adres van de machine die ze maakte. Juist die waarden door een vreemd formulier sturen zou het slechtste idee zijn — en het is de reden dat de analyse hier gebeurt waar de identifier toch al is.