Herramientas de desarrollo · UUID generador
UUID Versiones 1 a 8 Explicación: ¿Cuál debería generar?
· Antecedentes
uuid criptografía APIS del navegador
Ocho versiones comparten un formato pero resuelven diferentes problemas: ordenamiento temporal, reproducibilidad, aleatoriedad o diseños personalizados. Esta publicación explica cada uno y brinda una ruta de decisión.
Un formato, ocho recetas: por qué es importante la versión nibble cuando eliges una función de biblioteca
El estándar UUID define un formato de 128 bits como treinta y seis caracteres hexadecimales con guiones. RFC 9562 define ocho recetas distintas (versiones uno a ocho) para llenar esos bits con diferentes patrones y significados. La versión nibble (primer carácter del tercer grupo) identifica qué método produjo el valor y sirve como etiqueta. Elegir la versión incorrecta significa almacenar información temporal innecesaria, faltar garantías de pedido para el rendimiento de la base de datos o malinterpretar las funciones de seguridad de los identificadores. Esta publicación analiza cada versión, qué problema concreto resuelve, cuándo los desarrolladores la encuentran en la práctica y proporciona un marco de decisión para seleccionar la versión correcta para los requisitos específicos de su sistema.
v1 y v6: tiempo más nodo: el diseño original basado en el tiempo y la versión reordenada que ordena correctamente
La versión 1 combina una marca de tiempo de 60 bits con un identificador de nodo (originalmente una dirección MAC, aunque las implementaciones modernas usan valores aleatorios para evitar la filtración de información de hardware). La marca de tiempo registra intervalos de 100 nanosegundos desde octubre 15, 1582. El campo de nodo puede revelar cuándo se generó el identificador y dónde se originó geográficamente, razón por la cual las implementaciones modernas evitan las direcciones MAC. La versión 6 reorganiza la misma marca de tiempo y la misma información de nodo para mejorar la ordenación moviendo bits de tiempo de orden superior al frente, lo que hace que los UUID v6 se ordenen correctamente en orden lexicográfico. Si su aplicación necesita UUID que se ordenen naturalmente por tiempo de creación con una localidad de índice superior, la versión 6 es la opción moderna.
v2: Seguridad DCE: la variante poco utilizada que incorpora identificadores POSIX
La versión 2 rara vez se utiliza en sistemas nuevos. Incorpora identificadores de usuario o grupo POSIX en el diseño UUID, lo que lo hace útil solo en entornos heredados donde esos identificadores tienen un significado organizacional. El diseño v2 asume un modelo informático específico (seguridad DCE) que es poco común en los sistemas distribuidos modernos. La mayoría de las organizaciones asocian los UUID con usuarios o grupos en su capa de aplicación a través de uniones de bases de datos o tablas de búsqueda, no codificando el ID de usuario en el identificador mismo. Esta separación de preocupaciones facilita cambiar los modelos de autorización, migrar datos de usuarios y mantener registros de auditoría. Codificar credenciales directamente en UUID crea un estrecho acoplamiento y dificulta la evolución de los sistemas.
v3 y v5: basado en nombre: ID deterministas obtenidos de un espacio de nombres y un nombre con MD5 o SHA-1
Versiones 3 y 5 Los UUID son deterministas: el mismo espacio de nombres y nombre siempre producen el mismo identificador, ideal para representar asignaciones estables a partir de datos externos. La versión 3 usa MD5 y la versión 5 usa SHA-1 como algoritmos hash, lo que refleja sus respectivas edades y adopción. Cuando llega un registro de cliente para importar, una versión 5 UUID derivada de un espacio de nombres fijo será idéntica en varias ejecuciones de importación, lo que evitará registros duplicados. Este determinismo significa que UUID es reproducible y predecible para cualquiera que conozca el espacio de nombres y la entrada. El valor práctico brilla en escenarios de integración de datos: conciliar registros de clientes de múltiples sistemas, evitar duplicados en importaciones recurrentes y asignar identificaciones estables a artículos.
v4: aleatorio: 122 bits de un CSPRNG y la elección predeterminada al realizar el pedido no importa
La versión 4 es la opción predeterminada cuando no es necesario realizar pedidos y desea una generación independiente sin coordinación central. Una versión 4 UUID se compone de 122 bits de una fuente aleatoria criptográficamente segura, con seis bits configurados en valores fijos (versión nibble 4 y RFC 9562 bits variantes 10). La aleatoriedad es el punto central: cada llamada produce un valor diferente, las colisiones siguen siendo extremadamente improbables y no se requiere ningún estado externo o coordinación. Es la versión que ToolAcre genera usando crypto.randomUUID() o crypto.getRandomValues(). Esta versión es adecuada para referencias de objetos, datos no estructurados y la mayoría de roles fuera de claves primarias o contextos de clasificación.
v7 y v8: tiempo Unix y personalizado: la versión moderna ordenada por tiempo para claves de bases de datos y la trampilla de escape para diseños personalizados
La versión 7, estandarizada en RFC 9562, trae propiedades modernas ordenadas por tiempo al formato UUID. Utiliza una marca de tiempo de milisegundos Unix de 48 bits, 12 bits de precisión de submilisegundos y 62 bits aleatorios combinados. La marca de tiempo de milisegundos de Unix es válida hasta el año 10889, lo que la hace adecuada para sistemas. El resultado se ordena correctamente en orden lexicográfico y cabe en una columna estándar de 128 bits UUID sin manejo especial ni conversión de codificación. Si su aplicación necesita identificadores que se ordenen por hora de creación dentro del formato estándar UUID, la versión 7 es la mejor práctica actual. La versión 8 es un comodín estandarizado para formatos definidos por la implementación, útil solo si necesita diseños de bits específicos no cubiertos por v1-v7.
Ejemplo resuelto: una ruta de decisión aplicada a tres escenarios: una referencia de API pública, una clave principal y una ID estable para registros importados
Tres escenarios del mundo real ilustran la selección de versiones: Primero, una referencia de API pública debe ser estable en todas las instancias de API, no debe perder el tiempo de creación y debe ser la misma en todos los reinicios del servidor para que diferentes instancias generen la misma referencia para el mismo documento. Utilice v5 con un espacio de nombres y un nombre de documento estables. En segundo lugar, una clave primaria para una tabla en continuo crecimiento debe ser única, no debe causar fragmentación del índice y debe ser generada por cualquier instancia de aplicación sin coordinación central. Utilice v7 para identificadores ordenables con soporte de ecosistema estándar UUID. En tercer lugar, los registros archivados que requieren una búsqueda estable necesitan identificadores inmutables.
Conclusión: elija por propiedad, no por hábito: el generador ToolAcre produce UUID aleatorios a partir del CSPRNG del navegador para los casos que requieren v4
La selección de la versión se deriva del diseño de su esquema y de los requisitos del sistema, no de convenciones o familiaridad. Los UUID aleatorios (v4) son los predeterminados porque no requieren estado ni coordinación y producen identificadores independientes adecuados para la mayoría de las funciones. Las versiones ordenadas en el tiempo (v6, v7) resuelven problemas de localidad de índice a costa de fugas de información temporal o requisitos de sincronización de reloj. Las versiones deterministas (v3, v5) evitan importaciones duplicadas y permiten asignaciones externas estables a costa de la previsibilidad: cualquiera que conozca su espacio de nombres puede volver a calcularlas. ToolAcre genera UUID v4 aleatorios a partir del generador criptográficamente seguro del navegador. Cuando necesita una versión diferente, la verificación bien formada confirma que los identificadores analizados son válidos.