Generador de UUID: v4, v7, v5 y listas en lote

¿Qué versión debería darte un generador de UUID?

Todo UUID son 128 bits escritos como 32 dígitos hexadecimales en cinco grupos, 8-4-4-4-12. Dos de esos dígitos son de control: el 13.º es la versión y el 17.º lleva la variante (8, 9, a o b en los UUID de RFC 9562). Todo lo demás es lo que cada versión decide meter ahí: bits aleatorios, una marca de tiempo, un contador o un hash. Elegir la versión es, en realidad, elegir cuál de esas cosas quieres dentro de tu clave.

Mi regla práctica: v4, salvo que el ID sea una clave de base de datos con muchas inserciones; entonces, v7. La propia RFC 9562 dice que las implementaciones deberían usar v7 en lugar de v1 y v6 siempre que sea posible. El v5 basado en nombre es el raro del grupo: no va de unicidad en el tiempo, sino de obtener la misma respuesta dos veces, que es justo lo que quieres cuando dos servicios deben ponerse de acuerdo en el ID de "https://example.com/item/42" sin hablar entre ellos. La guía v4 vs v7 repasa la parte de los índices en esa decisión.

Un aviso práctico sobre v7: sus primeros 12 dígitos hexadecimales son el momento de creación en milisegundos, legible para cualquiera. Pega 017f22e2-79b0-7cc3-98c4-dc0c0c07398f en la pestaña Validar & decodificar y obtendrás el instante exacto en que se creó. Si un ID se muestra a los usuarios y el momento de creación es sensible, dales un v4.

Formatos: los mismos 128 bits, siete formas de escribirlos

La mayoría de los errores de «UUID no válido» que he perseguido no eran ID incorrectos, sino la forma de escritura equivocada para el sistema del otro lado. El generador de UUID conserva los bits y solo cambia el texto, así que el mismo valor puede ir en cualquiera de estos formatos:

La opción de separador (guion, ninguno, punto o guion bajo) solo se aplica a las formas estándar, en mayúsculas y con llaves; un URN con puntos dejaría de ser un URN válido, así que la herramienta bloquea el separador en ese caso. Con la entrada es al revés: RFC 9562 pide salida en minúsculas pero entrada sin distinguir mayúsculas, y el decodificador acepta todas las formas anteriores excepto Base64. Si necesitas el orden de bytes de .NET o las costumbres de SQL Server, lee UUID vs GUID.

Listas en lote para fixtures y archivos de seed

La pestaña En lote crea de 1 a 10.000 ID de una vez y los exporta como texto plano, CSV con cabecera uuid, un array JSON o una sentencia INSERT INTO items (id) VALUES … lista para usar (cambia la tabla y la columna por las tuyas). Hay dos detalles que importan más que la cantidad:

• Las listas v7 van en orden estrictamente ascendente. Diez mil ID se crean en pocos milisegundos, así que la mayoría comparten marca de tiempo. Sin contador saldrían en orden aleatorio dentro de cada milisegundo; con él, la lista se ordena igual como texto y como bytes, y la línea de información confirma «en orden estrictamente ascendente».
• v5 y v3 reciben nombres, uno por línea. Pega una columna de dominios, URL o códigos de producto y obtendrás un ID determinista por línea, idéntico al que devuelve uuid5() de Python para el mismo espacio de nombres y nombre.

¿Pueden coincidir dos UUID alguna vez?

Para los v4 aleatorios, la respuesta honesta es «sí, con una probabilidad que puedes calcular y después dejar de preocuparte». Con 122 bits aleatorios, la aproximación del cumpleaños da:

Ejemplo resuelto: creas mil millones de ID v4, n = 10⁹. Entonces n² = 10¹⁸, 2 × 2¹²² ≈ 1,063 × 10³⁷, el exponente es de unos 9,4 × 10⁻²⁰ y p ≈ 9,4 × 10⁻²⁰. Con un billón de ID ronda los 9,4 × 10⁻¹⁴. Necesitas aproximadamente 2,7 × 10¹⁸ ID para que la probabilidad de un solo duplicado llegue a la mitad.

El riesgo real nunca está en las matemáticas, sino en una fuente aleatoria débil: un fragmento copiado basado en Math.random(), un proceso bifurcado que reutiliza su semilla o una imagen de VM clonada con el mismo estado. Este generador de UUID toma cada bit aleatorio de crypto.getRandomValues(), el generador criptográfico del navegador. En v7, dos generadores independientes solo chocan si eligen el mismo milisegundo y además coinciden en unos 73 bits aleatorios (el contador se inicializa con 41 bits aleatorios y otros 32 bits siguen siendo aleatorios). Aun así, pon una restricción de unicidad en la columna: no cuesta nada y convierte un problema teórico en un error ruidoso.

Validar y decodificar: lo que te dice un ID

Pega un UUID en la pestaña Validar & decodificar y obtendrás su forma canónica, la versión, la variante, la hora incrustada en v1, v6 y v7 (en UTC y en tu hora local), la secuencia de reloj y el nodo de v1/v6, además de las formas hex para BINARY(16) y Base64. La comprobación del nodo te dice si un ID v1 lleva un nodo aleatorio (bit multicast activado, como recomienda RFC 9562) o algo que parece la dirección de una tarjeta de red real, una fuga de privacidad que conviene conocer.

Si en cambio pegas una columna entera, se convierte en una revisión de lista: cuántas líneas son válidas, cuáles no y por qué («hay 31 dígitos hexadecimales», «los guiones deben separar los dígitos en 8-4-4-4-12»), cuántas están duplicadas, si la lista está en orden ascendente y qué versiones contiene. Es la forma más rápida que conozco de auditar un archivo de importación antes de que choque con un índice único.

Además es estricto donde los validadores antiguos eran descuidados. Un UUID cuyo dígito de versión es 0 no es el UUID Nil salvo que los 32 dígitos sean cero; un ID con la variante heredada de Microsoft (17.º dígito c o d) está bien formado, pero su dígito de versión no significa nada, y el resultado lo dice en lugar de inventarse una versión.

Guardar UUID sin arrepentirte

1. Usa el tipo nativo. uuid de PostgreSQL y uniqueidentifier de SQL Server ocupan 16 bytes. Una columna de texto de 36 caracteres ocupa más del doble en la tabla y en cada índice que la incluya. En MySQL, usa BINARY(16); el formato 0x te da el literal.
2. Elige v7 para claves agrupadas o con muchas inserciones. Los nuevos valores v7 caen al final del índice en lugar de en páginas aleatorias.
3. Mantén una sola forma canónica en tu API. Minúsculas con guiones. Compara sin distinguir mayúsculas si aceptas entradas de otros sistemas.
4. Nunca trates un UUID como un secreto. RFC 9562 dice que no hay que dar por hecho que los UUID son difíciles de adivinar. Los enlaces de restablecimiento de contraseña y las claves de API necesitan un token aleatorio dedicado.
5. No publiques v1 con una dirección MAC real. Identifica la máquina y el momento. Esta herramienta usa siempre un nodo aleatorio.

Para las líneas que crean UUID en PostgreSQL, JavaScript, Python, Java y C#, consulta cómo generar un UUID en código.

De dónde salen los bits y cómo los pruebo

Todo ocurre en tu navegador; la página no envía nada a ningún sitio. Los bits aleatorios vienen de crypto.getRandomValues(). La versión 7 sigue el método 1 de RFC 9562 §6.2 con un contador de 42 bits (el mismo esquema que uuid7() de Python): una semilla aleatoria nueva en cada milisegundo nuevo, más uno por cada ID adicional dentro de ese milisegundo, y si el reloj retrocede se reutiliza la última marca de tiempo para que el orden nunca se rompa. Las versiones 1 y 6 cuentan pasos de 100 nanosegundos desde el inicio del calendario gregoriano, suman un paso por ID dentro del mismo milisegundo y usan un nodo aleatorio con el bit multicast activado. Las versiones 5 y 3 calculan el hash de los 16 bytes del espacio de nombres seguidos del nombre en UTF-8 con SHA-1 o MD5 y luego fijan los bits de versión y variante, exactamente como hacen el texto de la RFC 9562 y el módulo uuid de Python.

El script anterior de este sitio tenía un bug real que vale la pena confesar: su aritmética del timestamp de v1 desbordaba un entero de 32 bits con signo, así que durante aproximadamente la mitad de cada siete minutos generaba ID que empezaban por un signo menos. Además, su salida v7 quedaba desordenada dentro de un milisegundo. Ambos están corregidos, y estos son algunos de los casos de control con los que se prueba la herramienta en cada cambio: