Generador cron d’AWS
Generador cron
Comptador de text
JSON a CSV
CSV a JSON
Conversor de timestamp Unix
Generador d’UUID v4 i v7
JSON a TypeScript
Markdown a PDF
Base 64
Imatges
JSON
Codi QR
Contrasenyes
Unitats
Hash
Colors
Eines PDF
Editor de PDF
Codificador d'URL
Conversor de majúscules i minúscules
Lorem Ipsum
Comprovador de regex
Descodificador JWT
Diferència de text
Optimitzador SVG
Visualitzador EXIF
Extractor de colors
Generador de favicons
Convertidor universal
Convertidor d'hores
Divisor de PDF
Imatges a PDF
PDF a Imatge
Eliminar Fons
Tornar al BlogUTILX / Notes i guies

UUID v4 i v7: com generar-los, comprovar-los i triar-ne el format

Comparació d’identificadors UUID v4 i v7

Els UUID permeten que sistemes independents generin identificadors de 128 bits sense demanar el següent número a un comptador central. Això és útil quan es creen registres sense connexió, en diversos serveis o abans d’inserir-los en una base de dades. Aquesta propietat no converteix l’identificador en un secret ni demostra que no hi hagi cap col·lisió o que el registre associat sigui correcte.

Aquesta guia utilitza el generador i validador UUID per inspeccionar exemples fixos i generar un lot petit. Compara la versió 4 aleatòria amb la versió 7 orientada a l’ordre temporal, explica NIL i MAX i delimita què es pot verificar sense inventar garanties d’unicitat ni de rendiment.

Tria un format adequat per al sistema

La versió 4 omple amb dades aleatòries o pseudoaleatòries els bits que no estan reservats a la versió i la variant. Té una compatibilitat àmplia i la seva disposició definida no inclou una marca de creació. La versió 7 incorpora una marca Unix en mil·lisegons als 48 bits més significatius i utilitza els bits disponibles restants per a dades aleatòries i tècniques opcionals de monotonicitat.

La tria depèn de la interoperabilitat, l’ordenació necessària i les biblioteques disponibles a tots els participants. No assumeixis que v7 accelera qualsevol base de dades. Hi influeixen el format d’emmagatzematge, els índexs, la càrrega i el comportament del generador. Tampoc triïs v4 perquè sembli més secret: qualsevol UUID publicat en una URL o una resposta funciona com a identificador públic.

Valors fixos per inspeccionar

Utilitza aquests valors sense modificar-los:

550e8400-e29b-41d4-a716-446655440000
017f22e2-79b0-7cc3-98c4-dc0c0c07398f
00000000-0000-0000-0000-000000000000
ffffffff-ffff-ffff-ffff-ffffffffffff

El validador identifica el primer com a UUID v4 i el segon com a UUID v7. El tercer és el valor especial NIL; el quart és MAX. Tots dos són formes especials vàlides, però no informen d’una versió ordinària. Si substitueixes l’últim caràcter del primer per z, la validació ha de fallar: la representació permet dígits hexadecimals, no qualsevol lletra.

Els valors generats no tenen un resultat fix que es pugui copiar d’aquesta guia. Selecciona v7 i genera tres identificadors; tots han de validar com a v7, però el text concret serà diferent. Repeteix l’operació amb v4 i compara la versió i el nombre de resultats, no una captura prèvia de les cadenes.

Genera i comprova un lot petit

Obre l’eina, selecciona v4, introdueix tres com a quantitat i genera el lot. Confirma que apareixen tres línies. Copia-les i valida cada identificador de manera independent. Repeteix el procediment amb v7. Si vols estudiar l’ordenació a la base de dades, conserva l’ordre de generació i utilitza sempre la mateixa representació per comparar els valors.

Enganxa cadascun dels quatre exemples fixos al validador. Anota la validesa, la versió detectada i l’estat especial. Prova després 550e8400-e29b-41d4-a716-44665544000z: ha de ser rebutjat. Aquest resultat comprova la forma textual, no l’existència d’un registre en cap sistema. Mantén separades aquestes dues preguntes quan dissenyis la interfície d’una aplicació.

Per a lots més grans, la quantitat admesa va d’1 a 1.000 i ha de ser entera. Descarrega el fitxer de text i compta les línies no buides. El màxim evita sortides excessives al navegador; no recomana reservar blocs de mil identificadors. En producció, genera els valors al punt que determini l’arquitectura i amb una biblioteca fiable.

Llegeix els camps sense atribuir-los més informació

RFC 9562 defineix la representació hexadecimal canònica amb grups de longitud 8-4-4-4-12, el camp de variant i els quatre bits de versió. En v4, el dígit de versió és 4; en v7 és 7. La variant RFC comença amb els bits binaris 10. Aquests camps permeten reconèixer la disposició, però no descriuen la identitat del productor.

En v7, els primers 48 bits contenen mil·lisegons Unix. Els 74 bits disponibles restants, excloent versió i variant, contenen dades aleatòries o una combinació definida que pot millorar la monotonicitat dins d’un mil·lisegon. L’ordre temporal de la disposició no equival a un ordre causal complet dels esdeveniments d’un sistema distribuït.

El generador utilitza una biblioteca UUID mantinguda i l’aleatorietat criptogràfica de l’entorn. No recorre a Math.random. Si no hi ha una font segura disponible, la generació falla en lloc de substituir-la per un mecanisme més feble. La validació inspecciona la sintaxi, la variant, la versió i les formes especials segons la biblioteca; no consulta cap registre central.

NIL té tots els bits a zero i MAX tots a u. Poden servir de sentinelles quan un protocol els defineix així. Documenta si el teu esquema els reserva, els prohibeix o els assigna algun significat. Una convenció local no documentada pot provocar interpretacions incompatibles entre serveis.

Entén què pot revelar un error

Les causes habituals d’invalidesa són una longitud incorrecta, guionets desplaçats, caràcters no hexadecimals, una variant no admesa o una versió no reconeguda. Copia la forma canònica sense claus ni prefixos, tret que el receptor els accepti expressament. Eliminar espais externs no és el mateix que modificar els dígits de l’identificador.

Un resultat vàlid no demostra existència, propietat, actualitat, unicitat a la base de dades ni autorització d’accés. Consulta el magatzem corresponent per comprovar l’existència i imposa una restricció d’unicitat quan una col·lisió sigui perjudicial. Gestiona els conflictes d’inserció encara que siguin molt improbables. El validador tampoc pot saber si un v4 es va generar amb una font aleatòria segura.

Si falta criptografia segura, utilitza un navegador o entorn compatible. No escriguis un substitut amb cadenes aleatòries improvisades. Si la quantitat és inferior a 1, superior a 1.000 o no és entera, corregeix la petició. No tractis l’error com si l’eina hagués generat una part vàlida del lot que encara es pugui utilitzar.

Defineix la política que envolta els identificadors

Emmagatzema els UUID coherentment com a text canònic o com a 16 bytes segons el suport de la base de dades i el controlador. Les diferències en l’ordre dels bytes poden alterar comparacions i ordenacions. Emet una representació textual coherent als registres i a les API, encara que un protocol permeti comparar sense distingir majúscules i minúscules.

No utilitzis un UUID com a contrasenya, clau d’API, testimoni d’accés o prova d’autorització. La versió 7 revela una hora aproximada de creació al seu camp temporal. L’opacitat de v4 tampoc autentica una petició. Els secrets i les comprovacions d’autorització necessiten mecanismes separats, encara que l’URL contingui un identificador difícil d’endevinar.

En URL públiques, revisa si l’ordre de creació o l’enumeració de recursos exposen informació rellevant. Els límits de peticions, les respostes i els controls d’accés continuen important. La política de registres també depèn de la classificació de les dades: substituir un secret per un UUID no fa que tota la informació que l’acompanya sigui innòcua.

Límits del generador i del validador

L’eina genera lots v4 i v7 d’entre 1 i 1.000 valors i inspecciona text UUID, inclosos NIL i MAX. No genera totes les versions, no reserva identificadors, no comprova bases de dades ni proporciona un registre central d’unicitat. La resistència a les col·lisions no substitueix les regles de consistència de l’aplicació.

L’ordenació v7 no resol tots els problemes dels rellotges distribuïts. Els rellotges poden canviar, diversos valors poden compartir mil·lisegon i les implementacions poden aplicar tècniques diferents. Tampoc és una API temporal general. Extreu una hora de creació del camp definit només si el protocol depèn explícitament d’aquesta informació i n’accepta les limitacions.

Comprovacions finals dels UUID

Tria v4 o v7 per un requisit explícit de compatibilitat o d’ordre. Fes servir un generador mantingut amb aleatorietat segura. Conserva una representació coherent i imposa unicitat on sigui necessari. Separa sempre els identificadors, els secrets i l’autorització. Documenta què signifiquen NIL i MAX al teu sistema.

Valida els exemples com a v4, v7, NIL i MAX, i rebutja el valor acabat en z. En lots generats, comprova el recompte i la versió sense esperar cadenes predeterminades. Abans d’adoptar una afirmació sobre emmagatzematge, prova insercions, conflictes, serialització i ordenació amb el controlador real. Una prova petita i reproduïble aporta més informació que suposar que tots els motors tracten els UUID igual.

Fonts: RFC 9562: identificadors UUID, documentació del paquet uuid i especificació de l’API de criptografia web.