Generador de UUID

Genera UUIDs aleatorios para identificadores únicos

Leer la guía completa

Versión:

Cantidad:

MayúsculasSin guiones

Sobre los UUIDs:

UUID v4: Generado aleatoriamente, el más comúnmente usado
UUID v1: Basado en timestamp y dirección MAC (nuestra versión usa datos aleatorios en lugar de MAC por privacidad)
Los UUIDs son identificadores de 128 bits globalmente únicos
Formato: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx (M = versión, N = variante)

UUID (Universally Unique Identifier) es un identificador de 128 bits estandarizado en RFC 4122 (2005). El formato canónico usa 32 dígitos hexadecimales en 5 grupos separados por guiones: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, donde M indica versión (1-5) y N indica variante. Con 2^122 posibles UUIDs v4, la probabilidad de colisión es astronómicamente baja—generando 1 billón de UUIDs por segundo, tomaría 100 años tener 50% de probabilidad de una colisión. Historia: UUIDs fueron originalmente desarrollados para Apollo Network Computing System en 1980s, adoptados por Open Software Foundation (OSF) para DCE (Distributed Computing Environment), y finalmente estandarizados por IETF. Hoy son fundamentales en desarrollo de software: claves primarias en bases de datos (PostgreSQL, MySQL, MongoDB), identificadores de sesión, tokens de APIs, y sistemas distribuidos donde IDs secuenciales son impracticables. En LATAM, UUIDs son estándar en aplicaciones de Mercado Libre, Rappi, Nubank, Ualá y cualquier sistema que requiera identificadores únicos sin base de datos centralizada.

UUIDs como claves primarias eliminan dependencia de secuencias de base de datos, facilitan replicación y sharding, y previenen enumeración de recursos (usuarios no pueden adivinar /user/123, /user/124). Desventaja: UUIDs son más grandes (16 bytes vs 4-8 bytes de integers) y pueden fragmentar índices B-tree. PostgreSQL tiene tipo UUID nativo con índices optimizados. MySQL usa BINARY(16). MongoDB usa ObjectId (similar a UUID). En LATAM, startups de fintech como Nubank, Ualá, Mercado Pago usan UUIDs para cuentas, transacciones y referencias.

En arquitecturas de microservicios, cada servicio puede generar UUIDs independientemente sin coordinación central. Esto es crítico para escalabilidad—no hay cuello de botella en un servicio de secuencias. Amazon, Netflix, Uber generan millones de UUIDs por segundo en sus sistemas distribuidos. En LATAM, empresas como Rappi, iFood, 99 con arquitecturas de microservicios dependen de UUIDs para identificar pedidos, usuarios y transacciones.

UUIDs en URLs (/api/users/550e8400-e29b-41d4-a716-446655440000) son más seguros que IDs secuenciales (/api/users/123). Usuarios no pueden enumerar recursos adivinando IDs consecutivos (IDOR - Insecure Direct Object Reference). GitHub usa UUIDs para gists, Slack para workspaces, Notion para páginas. En LATAM, APIs de Mercado Pago, OXXO Pay, dLocal usan UUIDs para referencias de pago y transacciones.

Apps móviles que funcionan offline necesitan crear registros sin conexión a servidor. UUIDs permiten que dispositivos generen IDs localmente y sincronicen después sin conflictos. Cuando el usuario vuelve a estar online, los registros con UUIDs se envían al servidor sin riesgo de colisiones. Apps de delivery (Rappi, PedidosYa), fintech (Nubank, Ualá) y productividad (Notion, Todoist) usan este patrón.

Request IDs (UUIDs generados al inicio de cada solicitud HTTP) permiten rastrear una operación a través de múltiples servicios y logs. Cuando algo falla, el UUID en los logs identifica exactamente qué solicitud causó el problema. Herramientas como Datadog, New Relic, Splunk usan UUIDs para correlación de logs. En LATAM, empresas con sistemas complejos (bancos, e-commerce, gobierno) implementan request tracing con UUIDs.

UUID v4 (aleatorio): Los 122 bits significativos (128 - 6 bits de versión/variante) se generan con un CSPRNG (Cryptographically Secure Pseudo-Random Number Generator). En navegadores, usamos crypto.getRandomValues() que obtiene entropía del sistema operativo. Estructura: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx, donde '4' indica versión 4 y 'y' es 8, 9, a, o b (variante RFC 4122). UUID v1 (tiempo): Combina timestamp de 100 nanosegundos desde 15 octubre 1582 (60 bits), clock sequence (14 bits para evitar duplicados si el reloj retrocede), y MAC address (48 bits). Revela información del dispositivo, por eso nuestra implementación usa datos aleatorios en lugar de MAC real por privacidad. UUID v1 son ordenables por tiempo. Otros: UUID v3 usa hash MD5 de namespace + nombre. UUID v5 usa SHA-1. UUID v6/v7 (draft) mejoran ordenamiento temporal. La generación de UUID v4 es extremadamente rápida—millones por segundo en JavaScript moderno.

La generación de UUIDs usa crypto.getRandomValues() disponible en todos los navegadores modernos: Chrome 11+ (2011), Firefox 21+ (2013), Safari 6.1+ (2013), Edge 12+ (2015), y todos los navegadores móviles. Esta API obtiene entropía del CSPRNG del sistema operativo (CryptGenRandom en Windows, /dev/urandom en Linux/macOS, SecRandomCopyBytes en iOS). El rendimiento es excelente—generar 10,000 UUIDs toma ~50ms en dispositivos modernos. Para Node.js, usa el módulo 'uuid' (npm install uuid) o crypto.randomUUID() (Node 14.17+). En bases de datos: PostgreSQL tiene gen_random_uuid(), MySQL 8.0+ tiene UUID(), MongoDB genera ObjectIds automáticamente. En LATAM, donde el 85% de desarrolladores trabajan con aplicaciones web/móvil, la compatibilidad universal de UUIDs es crítica.

Preguntas frecuentes

¿Pueden colisionar dos UUIDs v4?

Técnicamente sí, pero la probabilidad es astronómicamente baja. UUID v4 tiene 122 bits aleatorios = 5.3 × 10^36 posibilidades. Para tener 50% de probabilidad de colisión (paradoja del cumpleaños), necesitarías generar 2.71 × 10^18 UUIDs. Generando 1 billón de UUIDs por segundo, tomaría 85 años. En términos prácticos, es más probable que tu servidor sea alcanzado por un meteorito. Usa UUIDs con confianza—las colisiones son un problema teórico, no práctico.

¿UUIDs son seguros para tokens de autenticación?

UUID v4 generados con crypto.getRandomValues() son criptográficamente seguros y apropiados para tokens de sesión, reset de contraseña, y verificación de email. Sin embargo, para autenticación de APIs de producción, considera tokens más cortos con alta entropía (tokens de 32 bytes en base64 = 256 bits) o estándares como JWT. UUID v1 NO es seguro—revela timestamp y potencialmente MAC address. En LATAM, APIs de Mercado Pago, Stripe, PayPal usan tokens propietarios más que UUIDs puros.

¿Debo usar UUID o auto-increment para claves primarias?

Depende del caso: UUID ventajas: No revela cantidad de registros, no hay conflictos en sistemas distribuidos, generación sin DB. UUID desventajas: 16 bytes vs 4-8, fragmentación de índices B-tree, URLs más largas. Auto-increment ventajas: Compacto, índices eficientes, ordenado por creación. Auto-increment desventajas: Revela info, requiere DB, problemas en sharding. Recomendación: Para APIs públicas y sistemas distribuidos, usa UUIDs. Para tablas internas de alto volumen, considera auto-increment + UUID público separado.

¿Cómo almaceno UUIDs eficientemente en MySQL?

MySQL no tiene tipo UUID nativo. Opciones: 1) CHAR(36)—simple pero ineficiente (36 bytes, comparaciones de strings). 2) BINARY(16)—eficiente (16 bytes, comparaciones binarias), pero requiere conversión UUID_TO_BIN()/BIN_TO_UUID() en MySQL 8.0+. 3) BIGINT x2—dos columnas de 8 bytes, complejo. Recomendación: BINARY(16) con funciones de conversión. Para PostgreSQL, usa el tipo UUID nativo que es óptimo. En LATAM, muchas empresas usan MySQL por legacy—la migración a BINARY(16) mejora rendimiento significativamente.

¿Cuál es la diferencia entre UUID y GUID?

Son lo mismo. GUID (Globally Unique Identifier) es el término de Microsoft, UUID es el término estándar (RFC 4122). Windows usa GUID en APIs COM, .NET tiene Guid.NewGuid(). Ambos siguen el mismo formato de 128 bits y las mismas versiones. En desarrollo web y sistemas abiertos, se prefiere 'UUID'. En ecosistema Microsoft (.NET, SQL Server, Azure), se usa 'GUID'. Son 100% interoperables.

¿Por qué UUID v1 revela información y es inseguro?

UUID v1 incluye: 1) Timestamp de 100ns desde 1582 (60 bits)—revela cuándo se creó. 2) MAC address del dispositivo (48 bits)—identifica el hardware. Esto permite rastrear cuándo y desde qué dispositivo se generó un UUID. Ataques: Un atacante puede correlacionar UUIDs para identificar patrones de uso. Nuestra herramienta genera UUID v1 'falsos' con datos aleatorios en lugar de MAC real por privacidad. Para producción, prefiere UUID v4.

¿Cómo valido si un string es un UUID válido?

Regex para UUID: /^[0-9a-f]{8}-[0-9a-f]{4}-[1-5][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i. El dígito de versión (1-5) está en posición 15, la variante (8, 9, a, b) en posición 20. Para validación estricta en JavaScript: usar biblioteca 'uuid' con uuid.validate(str). En bases de datos, PostgreSQL rechaza UUIDs inválidos automáticamente con el tipo UUID. Para APIs, siempre valida UUIDs de entrada para prevenir inyección de datos maliciosos.

¿Puedo generar el mismo UUID de forma determinística?

Sí, usa UUID v3 (MD5) o v5 (SHA-1). Dado un namespace UUID y un nombre string, siempre producen el mismo UUID: uuid.v5('mi-recurso', uuid.v5.URL). Útil para: generar IDs consistentes desde datos existentes, migración de sistemas legacy, deduplicación. El namespace define el contexto (URL, DNS, OID, X500 son predefinidos, o crea uno propio). UUID v5 es preferido sobre v3 (SHA-1 vs MD5). Ejemplo: todos los usuarios con email '[email protected]' siempre tendrían el mismo UUID.