Generador de UUID
Todas las versiones, en lote y con lector

Lo que ofrece este generador de UUID

Este generador de UUID crea ID únicos para bases de datos, API, archivos y pruebas. Primero elige una versión y cuántos necesitas, y la lista aparece al instante. Después puedes copiarla o guardarla como archivo de texto.

Cubre todas las versiones que se usan hoy. La versión 4 es puro azar, la 7 se ordena por tiempo, y las 3 y 5 convierten un nombre siempre en el mismo ID. Además, están las antiguas 1 y 6, y los valores especiales nil y max.

Pega un UUID y te dice su versión y su fecha. Pega cualquier UUID y el lector te dice su versión y su variante y, en los basados en tiempo, el momento exacto en que se creó.

¿Qué es un UUID?

Un UUID (identificador único universal) no es más que una cifra de 128 bits. A menudo se escribe con 32 dígitos hexadecimales en cinco grupos, como 017f22e2-79b0-7cc3-98c4-dc0c0c07398f. Como hay tantísimos valores posibles, cualquiera puede crear uno sin pedirlo a un servidor central, y no chocará con el de nadie.

Dos partes pequeñas dicen qué tipo de UUID es. El primer dígito del tercer grupo es la versión, y el primero del cuarto grupo contiene la variante. Por lo demás, todo es tiempo, azar o un hash, según la versión.

¿Con qué versión de UUID me quedo?

Para casi todo, usa la versión 4, porque es aleatoria, sencilla y compatible en todas partes. Sin embargo, si los ID serán claves de una tabla, elige la versión 7. Empieza con la hora, así que las filas nuevas se guardan en orden y las inserciones siguen siendo rápidas.

Cuando algo debe recibir siempre el mismo ID, usa la versión 5. Por ejemplo, una URL o un correo se pueden convertir en un UUID estable que cualquier sistema puede recrear. En cambio, las versiones 1, 3 y 6 existen sobre todo para sistemas antiguos.

Por qué UUID v7 es mejor para bases de datos

Los ID aleatorios de versión 4 caen por todo el índice, así que cada inserción toca una página distinta. Con el tiempo, eso frena las escrituras y gasta memoria. En cambio, UUID v7 empieza con una marca de tiempo en milisegundos, por eso cada ID nuevo cae al final del índice, como un número autoincremental.

Además, este generador mantiene el lote en orden. Cuando muchos ID comparten un milisegundo, un contador en los 12 bits siguientes los mantiene ordenados, tal como recomienda la RFC 9562, el estándar de los UUID.

Versiones 3 y 5: UUID a partir de un nombre

Los UUID basados en nombres salen de dos datos: un espacio de nombres, que también es un UUID, y un nombre. El par se resume con un hash, así que los mismos datos dan siempre el mismo resultado. Hay espacios estándar para dominios, URL, OID y nombres X.500, y además puedes usar uno propio.

La versión 5 usa SHA-1 y la 3 usa MD5. Aquí ningún hash protege nada. Ambos solo reparten bien los bits. Aun así, elige la versión 5 para trabajos nuevos, ya que el estándar la prefiere.

Lee cualquier UUID con el lector

Pega un UUID en el lector y se desmonta al instante. Así ves la forma estándar, la variante y la versión. Además, las versiones 1, 6 y 7 llevan una marca de tiempo. El lector muestra ese momento en UTC y en tu zona horaria.

En las versiones 1 y 6 también muestra la secuencia de reloj y el nodo. Antes el nodo era la dirección de la tarjeta de red del equipo, por eso el lector te dice si parece real o aleatorio. Además, al hacer clic en un UUID de la lista, se comprueba al momento.

Comprueba una lista completa con el validador de UUID

Un UUID de uno en uno va bien hasta que tienes cuatrocientos. En cambio, pega la lista completa en el validador de UUID y cada línea recibe su propio veredicto. La página separa por espacios, comas, puntos y comas, barras verticales y saltos de línea. Así, una columna de una hoja de cálculo, un array JSON y un resultado de SQL entran tal cual. Lee hasta 5.000 ID de una vez. Además, todo lo que pase de ahí aparece como omitido en lugar de desaparecer sin avisar.

Sobre todo, aquí hay tres veredictos, no dos. Una fila cuenta como válida cuando el estándar la describe. Cuenta como no válida cuando no es un UUID en absoluto. Entre esas dos queda la nota, para una fila con forma correcta que aun así merece una mirada. Por ejemplo, una variante antigua de Microsoft o NCS es un UUID real que los sistemas reales siguen emitiendo. Esas dos variantes vienen de la RFC 4122, el estándar de UUID más antiguo. Luego está la variante RFC que lleva un número de versión que nadie ha asignado todavía, que también recibe una nota. Llamar no válida a cualquiera de ellas sería mentir, porque hay sistemas en funcionamiento que las reparten cada día.

Además, cada fila rechazada dice por qué. Una línea de una lista solo puede fallar al leerse de tres maneras. Contiene un carácter fuera de 0-9, a-f y el guion. Tiene un número equivocado de dígitos hexadecimales. O tiene los 32 dígitos con los guiones en el sitio equivocado. Las dos primeras suelen ser una copia que arrastró un carácter suelto, o una que recortó un dígito al pegar. La tercera es un UUID cuyos guiones no están después del octavo, el duodécimo, el decimosexto y el vigésimo dígito. La fila lo dice exactamente así. Las líneas vacías, en cambio, no son errores en absoluto, porque la lista las salta antes de empezar el recuento.

El envoltorio se quita antes de la comprobación, porque las listas reales llegan envueltas. La página elimina las comillas, las comillas invertidas, los corchetes, los signos de mayor y menor, los paréntesis y un dos puntos o un punto final. También elimina el prefijo urn:uuid:. Las llaves reciben más cuidado que eso. Un GUID de Microsoft entre llaves se lee entero, mientras que una llave suelta de un objeto JSON simplemente se va. Asimismo, una tirada de 32 dígitos hexadecimales sin guiones sigue leyéndose. Lo mismo vale para cualquier mezcla de mayúsculas y minúsculas. Una palabra que nunca fue un ID, como una clave de JSON, también recibe su propia fila en vez de desaparecer. Así el recuento sigue siendo honesto con todo lo que había en el pegado.

A continuación, el validador busca duplicados en toda la lista. La comparación se hace sobre la forma canónica. Así, {X}, urn:uuid:X y el mismo ID en mayúsculas cuentan como uno solo. Después, la fila repetida señala la línea donde apareció primero. Dos líneas de basura idénticas, en cambio, nunca cuentan como duplicadas. Una fila que no es un UUID no tiene forma canónica que comparar. Luego, el resumen cuenta la lista por ti. Ves cuántas líneas pasaron y cuántas describe el estándar. Tres recuentos más cubren las filas que merecen una mirada, las que no son UUID en absoluto y las repeticiones.

Esos recuentos se mantienen aparte a propósito, y la razón importa. Una fila con nota tiene una forma correcta en lugar de una rota. Meterla en un único número de aprobado o suspendido escondería lo único que merece notarse de ella. Sin embargo, si solo quieres los problemas, el filtro deja a la vista las filas que no son UUID. Las filas con nota mantienen su sitio y su motivo. Por último, el informe copia lo que muestra la pantalla, así que la lista puede pasar directamente a un ticket.

¿UUID o GUID?

Son lo mismo. GUID, identificador global único, es solo el nombre que usa Microsoft. Por eso esta página también sirve como generador de GUID: activa mayúsculas y llaves, y obtienes el estilo {XXXXXXXX-XXXX-...} que a menudo muestran Windows y .NET.

Los GUID muy antiguos de COM usaban otra variante. El lector los detecta y los marca, así sabes cuándo un ID viene de ese sistema viejo.

¿Puede repetirse alguna vez un UUID?

En la versión 4, 122 de sus bits salen al azar. Por lo tanto, harían falta unos 2,7 trillones de ID para que la probabilidad de una repetición llegue al 50%. De hecho, un error en tu propio código es mucho más probable que una repetición.

Las versiones basadas en tiempo usan menos bits aleatorios, pero añaden la hora. Como resultado, dos ID solo chocan si nacen en el mismo milisegundo y además sacan los mismos bits aleatorios. El artículo de Wikipedia sobre los UUID explica las cifras en detalle.

¿UUID o números autoincrementales?

Los ID autoincrementales son cortos y rápidos, pero tienen límites. Primero, solo la base de datos puede darlos, así que una app debe esperar una inserción para conocer el ID. Segundo, revelan datos, porque el pedido 1043 le dice a cualquiera que tienes unos mil pedidos.

Los UUID resuelven ambos problemas. Cualquier servidor, móvil o navegador puede crear uno sin conexión, y los ID de sistemas distintos se unen sin choques. En cambio, ocupan más espacio, por eso la versión 7 y el almacenamiento binario importan en tablas grandes.

Los UUID en tu código

Los interruptores de formato cubren lo habitual. Quita los guiones para guardar menos, añade el prefijo urn:uuid: para XML y RDF, o también pon cada ID entre comillas con comas, listo para pegar en un array o una lista SQL.

Casi todas las bases de datos tienen un tipo propio para UUID. PostgreSQL tiene uuid, SQL Server tiene uniqueidentifier y en MySQL lo habitual es BINARY(16). Además, para las marcas de tiempo de tus datos, nuestro convertidor de marcas de tiempo Unix las pasa a fechas y al revés.

¿Son seguros estos UUID?

Sí. Los bits aleatorios vienen de la fuente segura de tu navegador, la función getRandomValues de Web Crypto, pensada para claves y tokens. Además, nada llega a nuestro servidor, así que nadie más ve los ID que creas.

Recuerda que un UUID es un ID, no un secreto, porque cualquiera que lo vea puede copiarlo. Para contraseñas y claves de API, usa en cambio nuestro generador de contraseñas.