Generador de UUID

Dónde se usan los UUID

Un UUID (identificador único universal, también llamado GUID en Windows) es un valor de 128 bits escrito como 32 dígitos hexadecimales en cinco grupos: 8-4-4-4-12, por ejemplo 3f1c2b7e-9a4d-4c1e-8b2f-6d0e5a7c9b13. La gracia está en que cualquier sistema puede crear uno por su cuenta, sin consultar un contador central, y aun así estar seguro de que nunca chocará con un ID creado en otro sitio.

Esa propiedad es útil en muchos lugares:

• Claves primarias en bases de datos, sobre todo cuando los registros se crean en varios servidores o sin conexión en dispositivos cliente y se sincronizan después.
• IDs de petición y de correlación que siguen una misma operación a través de los logs de muchos servicios.
• Nombres de archivo para subidas, para que dos usuarios que suben photo.jpg nunca se pisen.
• Claves de idempotencia para API de pagos y pedidos.
• Datos de prueba y de inicialización que necesitan IDs realistas.

Versión 4 y versión 7

La herramienta ofrece las dos versiones que importan hoy para proyectos nuevos. Ambas tienen el mismo formato y la misma longitud; la diferencia está en lo que contienen los bits.

UUID v4 (aleatorio)

Salvo 6 bits fijos que marcan la versión y la variante, los 122 bits restantes son aleatorios. Un v4 se reconoce por el 4 al principio del tercer grupo. Se obtienen con crypto.randomUUID() del navegador, que se alimenta de la fuente aleatoria criptográficamente segura del sistema operativo.

Usa v4 cuando el ID no deba revelar nada: tokens de invitación en URL, IDs públicos de recursos, cualquier caso en que conocer un ID no deba ayudar a adivinar otro ni a saber cuándo se creó.

UUID v7 (ordenado por tiempo)

Estandarizado en la RFC 9562 en 2024, v7 coloca al principio un timestamp Unix de 48 bits en milisegundos y rellena los 74 bits restantes con datos aleatorios. El tercer grupo empieza por 7. Como el timestamp va primero, los valores v7 se ordenan por orden de creación como simples cadenas o bytes.

Eso importa en las bases de datos. Los índices B-tree guardan las claves ordenadas, y las claves v4 aleatorias caen en páginas al azar, provocando divisiones de página y un mal aprovechamiento de la caché a medida que las tablas crecen hasta millones de filas. Las claves ordenadas por tiempo se añaden cerca del final del índice, de forma muy parecida a un entero autoincremental, sin perder la propiedad de «generar en cualquier sitio». Para tablas nuevas en PostgreSQL, MySQL o SQL Server, v7 suele ser mejor clave primaria.

Dos salvedades: el timestamp es legible, así que un v7 revela cuándo se creó el registro, al milisegundo. Y este generador no añade un contador por debajo del milisegundo, así que los IDs generados dentro del mismo milisegundo, como ocurre dentro de un mismo lote, se ordenan entre sí por su parte aleatoria y no por el orden de generación.

Qué probabilidad hay de un duplicado

Con 122 bits aleatorios hay unos 5,3 × 10^36 valores v4 posibles. Según la paradoja del cumpleaños, tendrías que generar alrededor de 2,7 × 10^18 para llegar a un 50 % de probabilidad de una sola colisión. A mil millones por segundo, eso lleva más de 80 años.

En v7 la parte aleatoria es de 74 bits, pero solo tiene que ser única entre los IDs creados en el mismo milisegundo. Incluso a un millón de IDs por milisegundo, la probabilidad de choque sigue siendo despreciable.

En la práctica, los duplicados vienen de errores, no de las matemáticas: un ID de ejemplo escrito a mano que acaba en producción, un generador aleatorio con semilla o no criptográfico, o una máquina virtual clonada que repite su estado. Generar en el navegador con la aleatoriedad segura del sistema evita los dos últimos.

Detalles de formato y almacenamiento

• Mayúsculas y minúsculas. La RFC 9562 indica que los UUID se escriben en minúsculas y se comparan sin distinguir mayúsculas. La opción Mayúsculas existe para sistemas y documentación que usan el estilo GUID de Windows.
• Llaves y guiones. Algunas herramientas de Microsoft muestran los GUID entre {llaves}. Quítalas, o quita los guiones, solo si el sistema de destino espera esa forma.
• Almacenamiento. Guarda los UUID en un tipo nativo (uuid en PostgreSQL, BINARY(16) en MySQL) en lugar de CHAR(36). La forma binaria ocupa 16 bytes en vez de 36 y se compara más rápido.
• Tamaño del lote. Hasta 500 a la vez, uno por línea, listos para pegar en un script SQL o en una hoja de cálculo. Al pulsar Generar nuevos se sustituye toda la lista.

Los UUID son identificadores, no secretos. Un v4 es difícil de adivinar, pero si da acceso a algo, trátalo como un enlace de conveniencia, no como autenticación. Para credenciales usa el generador de contraseñas. Para descifrar la hora de creación de un v7, toma sus primeros 12 dígitos hexadecimales, conviértelos a decimal y pega el número en el convertidor de timestamp Unix.