Generador UUID

UUID (Universally Unique Identifier) es un estándar definido en RFC 4122 para generar identificadores de 128 bits que son únicos sin necesidad de coordinación central. UUID v4 es la versión más utilizada y genera identificadores puramente aleatorios. • Estructura — Un UUID v4 tiene el formato 8-4-4-4-12 hexadecimal: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx. El dígito '4' en la posición 13 indica la versión. El primer dígito del cuarto grupo (posición 17) indica la variante — en UUID RFC 4122, los dos bits más significativos son '10', resultando en valores 8, 9, a o b. • Entropía — De los 128 bits totales, 6 están fijos (4 bits de versión + 2 bits de variante), dejando 122 bits de entropía aleatoria. Esto produce un espacio de 5.3 × 10³⁶ combinaciones posibles. • Probabilidad de colisión — Para generar una colisión con probabilidad del 50% (paradoja del cumpleaños), necesitarías generar aproximadamente 2.7 × 10¹⁸ UUIDs. Si generas 1 billón de UUIDs por segundo, tardarías ~85 años. En la práctica, las colisiones son imposibles. • Versiones de UUID — v1 (timestamp + MAC), v2 (DCE security), v3 (hash MD5 de namespace), v4 (aleatorio), v5 (hash SHA-1 de namespace), v6 (timestamp reordenado), v7 (timestamp Unix + aleatorio). Esta herramienta genera v4 y valida todas las versiones.

ULID (Universally Unique Lexicographically Sortable Identifier) es una alternativa moderna a UUID diseñada para ser compatible en tamaño (128 bits) pero con ventajas prácticas: • Estructura — 26 caracteres en Crockford Base32: 10 caracteres de timestamp (48 bits, precisión de milisegundos) + 16 caracteres de aleatoriedad (80 bits). La codificación Crockford Base32 excluye las letras I, L, O y U para evitar confusiones visuales. • Ordenamiento lexicográfico — Los ULIDs generados en momentos diferentes se ordenan cronológicamente cuando se ordenan como strings. Esto es imposible con UUID v4 (aleatorio puro) y es una ventaja crucial para bases de datos que usan el identificador como clave primaria, ya que mantiene la localidad de datos en índices B-tree. • Timestamp — Los primeros 48 bits codifican milisegundos desde la época Unix (1 de enero de 1970). Esto permite extraer la fecha de creación de cualquier ULID sin almacenamiento adicional. El rango temporal alcanza hasta el año 10889. • Compatibilidad — Al ser 128 bits, un ULID se almacena en el mismo espacio que un UUID. Se puede convertir bidireccionalmente a UUID estándar para compatibilidad con sistemas existentes. • Monotonía — La especificación ULID define que dentro del mismo milisegundo, la parte aleatoria debe incrementarse monótonamente para garantizar ordenamiento estricto. Esta implementación genera aleatoriedad independiente por generación.

La elección entre UUID v4 y ULID depende del contexto: Usa UUID v4 cuando: • Necesitas compatibilidad máxima — UUID es soportado nativamente por PostgreSQL (tipo uuid), MySQL, SQL Server, MongoDB, y prácticamente toda base de datos y lenguaje. • El orden no importa — Si los identificadores son para referencia pura (tokens de sesión, IDs de correlación en logs, claves de API). • Seguridad es prioridad — UUID v4 no filtra información temporal, mientras que ULID revela cuándo fue creado. Usa ULID cuando: • Necesitas ordenamiento temporal — Claves primarias en bases de datos donde las inserciones se benefician de localidad (B-tree, LSM-tree). • Quieres extraer timestamps — Sin columna created_at adicional. • Rendimiento de escritura importa — Los ULIDs secuenciales causan menos page splits en índices B-tree que los UUID v4 aleatorios, mejorando el rendimiento de escritura hasta 10x en algunas bases de datos. • Sistemas distribuidos — Cada nodo puede generar ULIDs independientemente con garantía de orden global aproximado.

Esta herramienta utiliza la API Web Crypto (crypto.getRandomValues()) para generar aleatoriedad criptográficamente segura: • CSPRNG — El navegador usa un generador de números pseudoaleatorios criptográficamente seguro (Cryptographically Secure PRNG) respaldado por la entropía del sistema operativo (/dev/urandom en Linux, CryptGenRandom en Windows, SecRandomCopyBytes en macOS). • Diferencia con Math.random() — Math.random() usa un PRNG como xorshift128+ que NO es criptográficamente seguro. Sus valores son predecibles si se conoce el estado interno. Nunca debe usarse para generar identificadores en producción. • Rendimiento — crypto.getRandomValues() es lo suficientemente rápido para generar miles de identificadores por segundo en cualquier navegador moderno. Esta herramienta limita la generación a 100 IDs por lote para mantener la interfaz responsiva. • Ejecución local — Todo el proceso de generación ocurre en el navegador. No se envía ningún identificador ni dato a servidores externos.