Versiones de UUID
Un UUID es un identificador de 128 bits escrito como 32 dígitos hexadecimales en grupos 8-4-4-4-12, estandarizado en RFC 9562. El nibble de versión te dice cómo se hizo: la v1 y la v6 de un reloj, la v3 y la v5 del hash de un nombre, la v4 de aleatoriedad y la v7 de una marca de tiempo Unix más aleatoriedad — cada una con concesiones distintas de orden y privacidad.
Versiones de UUID: explicación
Dos sistemas que jamás se han visto necesitan nombrar una fila, una petición o un archivo sin preguntar a nadie. Ese es el problema que resuelven los UUID: generar un identificador a partir de información local — un reloj, bits aleatorios, un nombre — y la probabilidad de que otra persona genere el mismo valor es lo bastante pequeña como para planificar en torno a ella. Sin servicio de coordinación, sin contador compartido que disputarse, sin registro central que consultar.
El estándar vigente es RFC 9562, publicado en mayo de 2024 como sucesor de RFC 4122, y su cambio estelar es el estatus oficial de dos versiones más nuevas: la v6 y la v7. La versión vive en el nibble más significativo del tercer grupo — el primer dígito hexadecimal tras el segundo guion — y los bits de variante abren el cuarto grupo. Leer esos dos dígitos te dice de un vistazo la procedencia de un UUID.
Esta guía explica la disposición de bits de cada versión, en qué es buena y hasta dónde llega su honestidad — incluido el precio en privacidad de la dirección MAC incrustada en la v1 y las matemáticas de colisiones detrás de la v4. El generador enlazado abajo produce varias versiones localmente, así que puedes inspeccionar el patrón en tu propia máquina.
Cada disposición de abajo se entiende mejor en un espécimen real — el generador de UUID genera identificadores v4 y v7 en tu navegador, y nada de lo que produce se registra ni se envía a ningún sitio.
Los identificadores también viajan dentro de tokens; la la guía de la estructura de un JWT muestra dónde un claim jti lleva un UUID y por qué el token que lo rodea está firmado pero no es secreto.
Anatomía: 128 bits en 36 caracteres
Un UUID son 128 bits, escritos canónicamente como 32 dígitos hexadecimales en minúscula repartidos en cinco grupos separados por guiones de 8-4-4-4-12 — 36 caracteres con los guiones, 32 sin ellos. La disposición no es decoración: rangos de bits concretos llevan significado. El campo de versión de cuatro bits ocupa el nibble superior del tercer grupo, y la variante de dos bits — que distingue los UUID al estilo RFC de los diseños más antiguos de Microsoft y de los heredados — ocupa los bits superiores del cuarto grupo, leyéndose siempre 8, 9, a o b en hexadecimal.
| Grupo | Dígitos de ejemplo | Contenido (mostrado en una v1) |
|---|---|---|
| 1 | 614e4000 | time_low — los bits menos significativos de la marca de tiempo |
| 2 | 26bc | time_mid — los bits intermedios de la marca de tiempo |
| 3 | 11ef | 12 bits de marca de tiempo y después la versión de 4 bits — el 1 significa v1 |
| 4 | b17d | variante de 2 bits (binario 10) y después 14 bits de secuencia de reloj |
| 5 | 0242ac120002 | 48 bits de nodo — en la v1, la dirección MAC de la máquina generadora |
Cuatro versiones, un vistazo
v1 614e4000-26bc-11ef-b17d-0242ac120002 v4 f7b17bde-5a0c-4174-8c95-407558615543 v6 1ec9414c-232a-6b00-b3c8-9e6bdeced846 v7 019b76da-a800-7c3e-8f2a-5b6c7d8e9f0a
Dónde mirar
3rd group, 1st hex digit = version (1, 4, 6, 7 here) 4th group, 1st hex digit = variant (b, 8, b, 8 here)
v1 y v6: un reloj y una dirección MAC
La v1 construye el identificador a partir de una marca de tiempo de 60 bits que cuenta intervalos de 100 nanosegundos desde el 15 de octubre de 1582 — el inicio del calendario gregoriano — más un contador de secuencia de reloj y la dirección MAC de 48 bits de la máquina. La marca de tiempo se divide de forma poco intuitiva en time_low, time_mid y time_high, un orden de campos elegido por una conveniencia de empaquetado de bits de los años 90 y lamentado después. La dirección MAC es la mina de la privacidad: cada UUID v1 revela qué hardware lo fabricó, razón por la que RFC 4122 ya permitía sustituir el nodo por uno multicast aleatorio.
La v6 es la v1 con el orden de campos corregido: los bits más significativos de la marca de tiempo pasan al frente, así que los UUID v6 se ordenan cronológicamente cuando se ordenan como cadenas. Mismo reloj, mismo campo de nodo, mismas advertencias de privacidad — pero un comportamiento en bases de datos mucho mejor, que es el punto entero del reordenamiento.
La misma marca de tiempo, dos órdenes de campos
v1: 614e4000-26bc-11ef-b17d-0242ac120002 v6: 1ec9414c-232a-6b00-b3c8-9e6bdeced846
Qué se ordena bien en un índice de cadenas
v6 — su campo timeHigh va primero, así que el orden lexicográfico es el orden cronológico. v1 empieza por los bits menos significativos y se dispersa.
v3 y v5: identidad a partir de un nombre
La v3 y la v5 derivan el identificador de un UUID de espacio de nombres y un nombre, con hash MD5 (v3) o SHA-1 (v5). Mismo espacio de nombres, mismo nombre, mismo UUID — en cada máquina, para siempre. Ese determinismo es la característica: deriva identificadores estables a partir de URLs, nombres de usuario o dominios sin almacenar una tabla de correspondencias, y regenera cuando quieras en cualquier sistema.
El precio es el reverso del determinismo: el identificador filtra información sobre el nombre. La v5 de un nombre de baja entropía se puede confirmar probando a lo tonto, y nombres idénticos producen identificadores idénticos a propósito. La v5 sustituye a la v3 — SHA-1 sobre MD5 — y aunque RFC 9562 no nombra ninguna versión nueva basada en nombres, los diseños nuevos que quieren determinismo y orden temporal a la vez suelen pasarse a la v7 guardando el nombre aparte.
Determinista: misma entrada, misma salida
namespace: DNS 6ba7b810-9dad-11d1-80b4-00c04fd430c8 name: python.org v3 6fa459ea-ee8a-3ca4-894e-db77e160355e v5 886313e1-3b8a-5372-9b90-0c9aee199e5d
Por qué se reproduce en cualquier sitio
hash(namespace bytes || "python.org") con la versión (3 o 5) y la variante (binario 10) escritas en posiciones de bits fijas: el mismo cálculo, bit a bit.
v4: 122 bits aleatorios y lo que se consigue con ellos
La v4 fija 122 bits con un generador aleatorio criptográficamente seguro; solo los nibbles de versión y variante están prefijados. Las probabilidades de colisión siguen la cota del cumpleaños: tras generar n valores, la probabilidad de algún duplicado es aproximadamente n²/2¹²³. Harían falta unos 2^61 UUID — cerca de 2,3 × 10^18 — para tener una probabilidad de lanzar moneda de una sola colisión. Cuando los duplicados aparecen en la práctica, la causa casi siempre es una aleatoriedad rota — una semilla débil, un estado de PRNG reutilizado, un fallo de hardware — nunca las probabilidades en sí.
La aleatoriedad también es la debilidad de la v4 como clave de base de datos: valores completamente desordenados caen en páginas B-tree aleatorias, fragmentan los índices y agotan las cachés de escritura a escala. Esa queja es justo lo que la v6 y la v7 se estandarizaron para arreglar, y el motivo por el que muchos ORM y bases de datos distribuidas ahora dirigen las tablas nuevas hacia la v7.
v7: milisegundos Unix más aleatoriedad
La v7 es la candidata moderna por defecto: 48 bits de marca de tiempo Unix en milisegundos y después 12 más 62 bits de carga aleatoria. La marca de tiempo al principio hace que los UUID v7 se puedan ordenar como cadenas — cómodos para los índices justo en las bases de datos que los guardan — mientras que los 74 bits aleatorios mantienen las probabilidades de colisión, en la práctica, al nivel de la v4. No necesita dirección MAC, ni época de 1582, ni conversiones de calendario.
Dentro del mismo milisegundo, RFC 9562 describe un contador monótono en el campo rand_a para que los identificadores creados en sucesión rápida sigan aumentando — una propiedad que a las claves primarias les importa aún más que la unicidad bruta. La marca de tiempo, además, es legible: se lee como 2026, no como un conteo de tics de 100 nanosegundos desde 1582, lo que hace agradable ojear la v7 en logs y resultados de consultas.
Ordenado en el tiempo por construcción
2026-01-01T00:00:00Z 019b76da-a800-7c3e-8f2a-5b6c7d8e9f0a 2026-01-01T00:00:01Z 019b76da-abe8-9d41-8c2f-4a5b6c7d8e9f
Ordenable como cadena, ordenado en el tiempo
019b76da-a800-… < 019b76da-abe8-… el orden lexicográfico coincide con el cronológico, y los 48 bits superiores son una marca de tiempo Unix en ms.
Elegir una versión, con honestidad
Para trabajo nuevo: v7 cuando los identificadores deban ordenarse por tiempo o vivir en un índice de base de datos; v4 en el resto de los casos — ambas no necesitan coordinación y no filtran nada sobre su origen. La v5 gana su sitio cuando el identificador debe ser reproducible a partir de un nombre. La v1 y la v6 siguen soportadas, pero filtran la identidad del hardware a menos que el generador aleatorice el campo de nodo, y la v3 es el legado MD5 que se arrastra por compatibilidad. Ninguna de las versiones es secreta y ninguna anonimiza datos: un UUID es un nombre, no una credencial.
| Versión | Origen de los bits | Ordenable como cadena | Cuidado con |
|---|---|---|---|
| v1 | Marca de tiempo gregoriana + secuencia de reloj + nodo MAC | No | Filtración de la dirección MAC |
| v3 | MD5 de espacio de nombres + nombre | No | Legado MD5; los nombres son adivinables |
| v4 | 122 bits aleatorios | No | El orden de inserción aleatorio fragmenta los índices |
| v5 | SHA-1 de espacio de nombres + nombre | No | Determinista — los nombres se confirman adivinando |
| v6 | v1 reordenada para que se pueda ordenar | Sí | La misma advertencia de MAC que la v1 |
| v7 | Marca de tiempo Unix en ms + 74 bits aleatorios | Sí | Empates en el mismo milisegundo sin contador monótono |
Preguntas frecuentes
¿Los UUID generados en este sitio se registran en algún lado?
No. El generador crea los identificadores con la API de aleatoriedad de tu propio navegador dentro de la pestaña — no hay que subir nada ni hay log del lado del servidor, porque el código nunca envía una petición. Puedes ver cómo el panel Network se queda en silencio mientras funciona, y la Content-Security-Policy del sitio bloquea las conexiones salientes durante toda la vida de la página.
¿Pueden colisionar dos UUID en la práctica?
Para la v4, la cota del cumpleaños sitúa la probabilidad de lanzar moneda de un duplicado en torno a 2^61 valores generados — aproximadamente 2,3 × 10^18. Las colisiones reales casi siempre indican aleatoriedad rota más que mala suerte: una semilla débil, un estado de PRNG reutilizado o un fallo del RNG de hardware. La v3 y la v5 «colisionan» a propósito — el mismo nombre en el mismo espacio de nombres da el mismo UUID por diseño.
¿Por qué algunos UUID se ordenan mal como claves primarias de base de datos?
Las versiones aleatorias (v4) esparcen las filas nuevas por un índice B-tree, escribiendo en páginas impredecibles y castigando la caché a medida que la tabla crece. Las versiones ordenadas en el tiempo (v6, v7) añaden cerca del borde derecho del índice. Si estás atado a claves v4, los remedios estándar son una columna de clustering aparte ordenada en el tiempo o pasar las filas nuevas a la v7.
¿Un UUID es secreto o anónimo?
Ninguna de las dos cosas. Un UUID es un identificador, no una credencial: no aporta prueba de quién lo tiene, y una v1 incluso difunde la dirección MAC de la máquina generadora a menos que el campo de nodo se haya aleatorizado. Trata los UUID como nombres — seguros de registrar, útiles para correlacionar — y pon la autenticación y la autorización en mecanismos que de verdad puedan verificar algo.
¿Cuál es la diferencia entre un GUID y un UUID?
Nombran la misma familia de identificadores de 128 bits; GUID es el término de Microsoft. La diferencia técnica vive en los bits de variante al comienzo del cuarto grupo, que distinguen los UUID al estilo RFC (binario 10 — primer dígito hexadecimal 8, 9, a o b) de los diseños más antiguos de Microsoft y de los heredados. Los GUID modernos se generan como variantes RFC, y por eso los dos términos se usan indistintamente en la mayoría de la documentación.
¿Por qué la marca de tiempo de la v1 empieza en 1582?
El contador de 60 bits avanza en intervalos de 100 nanosegundos desde la reforma del calendario gregoriano del 15 de octubre de 1582 — elegida para que el contador empezara lo bastante atrás como para no desbordarse en milenios. El precio es la legibilidad: una marca de tiempo v1 no significa nada sin un conversor. Los milisegundos Unix de la v7 se eligieron en parte porque se leen directamente como fechas.
¿Dónde puedo leer las normas citadas aquí?
¿Qué herramientas relacionadas debería usar después?
- Generar UUIDGenera UUID v4, v7 y v1 en lote e inspecciona los existentesAbrir
- Estructura de un JWTGuía en lenguaje sencilloAbrir
- Cómo funciona Base64Guía en lenguaje sencilloAbrir
- Qué es JSONGuía en lenguaje sencilloAbrir
- Herramientas JSONCompara, formatea, valida y explora documentos JSON.Abrir
- Formatear JSONIndenta, ordena claves y quita comentariosAbrir