Los UUID permiten que sistemas independientes creen identificadores de 128 bits sin pedir el siguiente valor a un contador central. Resultan útiles fuera de línea, entre servicios o antes de insertar en una base. No convierten el identificador en secreto, no prueban que jamás haya colisión ni validan el registro asociado.
Esta guía usa el generador y validador UUID con ejemplos fijos del RFC y un lote pequeño. Distingue v4 aleatorio de v7 ordenado temporalmente, explica NIL y MAX y evita garantías inventadas.
Elegir formato para el sistema
UUID v4 llena con datos aleatorios o pseudoaleatorios los bits que no son versión o variante. Tiene soporte amplio y su diseño no incluye fecha. UUID v7 coloca milisegundos Unix en los 48 bits más significativos y usa los demás bits disponibles para aleatoriedad y técnicas monotónicas opcionales. Su orden de bytes sigue mejor el tiempo de creación.
Elige por interoperabilidad, orden y bibliotecas disponibles en todos los participantes. No afirmes que v7 acelera cualquier base: formato de almacenamiento, índice, carga, generador y motor influyen. Tampoco elijas v4 porque parezca secreto. Ambos son identificadores públicos si aparecen en URL o payload.
Ejemplos fijos para inspeccionar
Usa estos valores sin cambios:
550e8400-e29b-41d4-a716-446655440000
017f22e2-79b0-7cc3-98c4-dc0c0c07398f
00000000-0000-0000-0000-000000000000
ffffffff-ffff-ffff-ffff-ffffffffffff
El primero es un v4 válido y el segundo, v7. El tercero es NIL y el cuarto MAX: formas especiales válidas sin versión ordinaria. Cambia la última letra del v4 por z; debe fallar porque la representación solo admite hexadecimales.
Los generados no son fijos. Crea tres v7: cada uno debe validar como versión 7, pero no puedes predecir su texto. Repite con v4 y comprueba versión, no una captura exacta.
Generar y validar un lote
Selecciona v4, cantidad tres y genera. Confirma tres líneas, copia el lote y valida cada una. Repite con v7. Mantén el orden de generación si vas a probar cómo ordena tu almacenamiento y compara siempre la misma representación binaria o textual.
Pega los cuatro valores fijos en el validador y registra validez, versión y estado especial. Después prueba 550e8400-e29b-41d4-a716-44665544000z. El rechazo solo habla de formato; no dice si un UUID válido existe en tu base.
Para lotes mayores elige entre 1 y 1.000. Descarga el .txt y cuenta líneas no vacías. El límite evita resultados accidentales pesados; no recomienda reservar bloques de mil. En producción genera donde lo requiera la arquitectura con una biblioteca contrastada.
Leer los bits sin exagerar su significado
RFC 9562 define grupos hexadecimales 8-4-4-4-12, variante y campo de versión de cuatro bits. En v4 el nibble es 4; en v7 es 7 y los primeros 48 bits contienen milisegundos Unix. Los 74 bits restantes, descontadas versión y variante, contienen aleatoriedad o una combinación especificada para mejorar monotonía dentro de un milisegundo.
El generador delega en una biblioteca mantenida y en la aleatoriedad criptográfica del entorno; no usa Math.random. Si no hay fuente segura, falla en vez de sustituirla. La validación comprueba sintaxis, variante, versión y especiales, pero no consulta un registro mundial.
NIL son todos ceros y MAX todos unos. Pueden ser centinelas en protocolos que los definan. Documenta si tu esquema los prohíbe, reserva o interpreta para evitar significados locales incompatibles.
Entender lo que validar no demuestra
Una entrada inválida suele tener longitud incorrecta, guiones mal situados, carácter no hexadecimal, variante o versión no reconocida. Copia la forma canónica sin llaves ni prefijos salvo contrato expreso. Quitar espacios externos no equivale a cambiar el identificador.
Un resultado válido no prueba existencia, propiedad, antigüedad, unicidad en base de datos ni autorización. Consulta el almacén adecuado y aplica restricción única donde importe. Gestiona conflictos aunque sean extremadamente improbables. Tampoco puedes saber si un v4 usó aleatoriedad segura mirando solo los bits finales.
Si falta criptografía segura, cambia a un navegador compatible; no uses cadenas aleatorias caseras. Si el recuento está fuera de 1–1.000 o no es entero, corrígelo en vez de recortar silenciosamente.
Diseñar la política alrededor del UUID
Almacena siempre texto canónico o 16 bytes según soporte de base y driver. Mezclar órdenes de bytes altera comparaciones. Acepta mayúsculas/minúsculas según protocolo, pero emite una sola forma en logs y APIs.
Nunca uses un UUID como contraseña, clave API, token portador o prueba de acceso. V7 expone aproximadamente el tiempo de creación y la opacidad de v4 no es autenticación. Genera secretos con entropía suficiente y autoriza por separado.
En URLs públicas, considera si el orden temporal o la enumeración de recursos importan, aunque no se adivinen IDs exactos. Siguen siendo necesarios control de acceso, límites y respuestas prudentes. Sustituir secretos por UUID no vuelve inocuo un log.
Límites del generador y validador
La herramienta genera v4/v7 entre 1 y 1.000 e inspecciona texto, NIL y MAX. No crea todas las versiones, consulta un registro central, reserva valores, verifica una base ni promete unicidad global. La aplicación debe imponer consistencia y manejar conflictos.
El orden temporal de v7 no es un orden total de eventos entre máquinas. Los relojes retroceden, varios valores comparten milisegundo y las implementaciones usan técnicas diferentes. Un UUID tampoco sustituye una API de timestamps; extrae fecha solo si tu protocolo lo define.
La herramienta tampoco demuestra rendimiento de índices. Para decidir almacenamiento, prepara una carga representativa con el mismo volumen, patrón de inserción, índice y driver de producción. Mide v4 y v7 bajo las mismas condiciones y documenta tamaño binario o textual. Una diferencia observada en una base no se convierte automáticamente en recomendación para otra.
Validar un lote línea por línea no reserva los valores ni evita que se vuelvan a usar por error. Mantén una restricción única y define qué hace la aplicación si una inserción entra en conflicto. No sustituyas ese manejo por un bucle ilimitado de regeneración: registra el problema y limita reintentos según la criticidad del proceso.
Lista final de UUID
Elige v4 o v7 por compatibilidad y orden explícitos. Usa biblioteca mantenida y criptografía segura. Guarda una representación uniforme, impón unicidad necesaria y separa autenticación de identificación.
Valida los ejemplos v4 y v7, reconoce NIL/MAX y rechaza el terminado en z. En lotes, comprueba cantidad y versión, no texto esperado. Prueba inserción, conflicto, serialización y orden con el driver real antes de publicar una conclusión de rendimiento.
Comprueba también que copiar y descargar producen exactamente una línea por identificador, sin caracteres invisibles añadidos. Reimporta el archivo con el mismo parser que usará el consumidor. Si la API acepta mayúsculas y minúsculas, normaliza solo en el borde acordado y conserva una forma canónica en respuestas, pruebas y logs para que las comparaciones sean legibles.
Registra la versión de la biblioteca generadora y el formato de almacenamiento usado en la prueba. Si migras de v4 a v7, permite que ambos convivan durante la transición y valida cada uno por su versión real; no reescribas identificadores históricos. Comprueba claves foráneas, copias de seguridad y procesos de importación antes de cambiar el valor predeterminado.
Ensaya además una inserción duplicada deliberada: ambos textos pasan la validación de formato, pero la segunda operación debe chocar con la restricción única. Así queda demostrada la responsabilidad distinta de cada control.
Fuentes: RFC 9562: UUID, documentación de uuid y Web Cryptography API.