Elige la cantidad de UUID y el formato de las letras. Envía el formulario para generar los valores en el servidor y copia la lista para tus datos de prueba.
Elige cuántos identificadores necesitas (de 1 a 100) y si quieres las letras en minúscula o mayúscula; el formulario los genera en el servidor y devuelve la lista, uno por línea. Cada valor es un UUID versión 4 de 128 bits en la forma canónica 8-4-4-4-12, listo para pegar en un fixture, en datos de siembra o en una clave de base de datos.
La versión 4 se construye con bits aleatorios: no lleva marca de tiempo, dirección MAC ni hash de un nombre, así que el valor no revela qué máquina lo creó ni cuándo. Por eso sirve como identificador opaco, y por eso tampoco conviene usarlo para ordenar registros por fecha de creación.
Un UUID son 128 bits escritos como 32 dígitos hexadecimales en cinco grupos separados por guiones. En la versión 4, 122 de esos bits son aleatorios: el nibble que abre el tercer grupo se fija en 4 para que el valor se identifique como versión 4, y los dos bits más significativos del cuarto grupo se fijan en 10 para cumplir la variante del RFC 4122.
Esos seis bits fijos son la razón por la que un v4 auténtico no es simplemente 32 caracteres hexadecimales al azar: los validadores estrictos y las bibliotecas que comprueban la versión rechazan los valores generados con un hash o con un contador sin fijar esos bits.
Con 122 bits aleatorios hay unos 5,3 × 10^36 valores posibles; la probabilidad de repetir uno es despreciable para cualquier volumen realista. La página además comprueba los valores del lote y regenera cualquiera que salga repetido, así que un lote de 100 identificadores nunca trae duplicados.
La única colisión que importa en la práctica es la de tus propios datos: si comparas cadenas con distinto uso de mayúsculas según la intercalación de tu base de datos, puedes acabar con dos filas para el mismo valor. Guarda el UUID en una sola forma (por ejemplo, minúsculas) o usa una columna binaria.
Un v4 es una buena clave primaria cuando no necesitas orden: 16 bytes de entropía que no se pueden adivinar. Si la base de datos sufre por la localidad del índice (inserciones repartidas por todo el árbol), valora UUID v7 o ULID, que añaden una marca de tiempo ordenable; para el almacenamiento, CHAR(36) es legible y BINARY(16) ahorra espacio.
No lo uses como secreto: este valor se genera en el servidor y viaja de vuelta a la página, así que trátalo como un identificador público. Para tokens de sesión o claves, genera el secreto en tu propio backend con un generador criptográfico y guárdalo solo como hash.
Es aleatorio: la versión 4 no codifica marca de tiempo, dirección MAC ni nombre, a diferencia de la versión 1. Solo lleva 122 bits aleatorios y seis bits fijos que identifican la versión y la variante.
Sí. El RFC 4122 trata los UUID sin distinguir mayúsculas de minúsculas, así que 0BC4… y 0bc4… son el mismo valor. Elige una forma para tu base de datos y tus comparaciones y manténla, sobre todo si la intercalación de la columna es binaria.
De 1 a 100 por envío. Si modificas el formulario con un valor fuera de rango, el servidor lo ajusta: 0, los negativos o un texto no numérico se convierten en 1, y cualquier cosa por encima de 100 se limita a 100.
Cada petición genera la lista en el servidor, incluida la primera carga, que trae un UUID por defecto. No hay caché ni valores pregenerados: volver a cargar la página produce identificadores distintos.
Sí, es un uso habitual: no se repite y no revela información interna. Si te importa el orden de inserción en el índice, considera UUID v7 o ULID; si te importa el espacio, guarda los 16 bytes en BINARY(16) en lugar de una cadena de 36 caracteres.
No es lo adecuado. El valor se genera en el servidor y se muestra en la página, así que considéralo público: úsalo como identificador, no como secreto. Para tokens y claves, genera la entropía en tu propio backend y guárdala con hash.