Genera UUID v4 y v7 reproducibles a partir de una semilla, o valida un UUID o GUID y decodifica su versión, variante y marca de tiempo integrada.
Por AdminRedactado con herramientas de redacción con IAActualizado Ejemplos verificados: 8
017f22e2-79b0-7cc3-98c4-dc0c0c07398f es un UUID de versión 7 (Basado en el tiempo Unix) con la variante RFC 9562; se creó con la marca de tiempo 2022-02-22 19:22:22.000 UTC.
Hexadecimal en minúsculas con grupos de 8-4-4-4-12 cifras: 017f22e2-79b0-7cc3-98c4-dc0c0c07398f.
Los bits iniciales 10 indican el formato RFC 9562; 0, 110 y 111 se reservan para esquemas anteriores o futuros.
Esta disposición deja 74 bits para datos aleatorios.
Un UUID es un identificador de 128 bits escrito con 32 cifras hexadecimales en grupos de 8-4-4-4-12. RFC 9562 fija dos campos en cada UUID estándar: los bits de variante 10 al principio de la 17.ª cifra hexadecimal y una versión de 4 bits en la 13.ª. El decodificador lee ambos y extrae lo que contiene esa versión: una marca de tiempo Unix de 48 bits en milisegundos para v7, un contador de 60 bits de intervalos de 100 nanosegundos desde el 15 de octubre de 1582 para v1 y v6, o 122 bits aleatorios para v4.
El valor inicial es el ejemplo v7 de RFC 9562, 017f22e2-79b0-7cc3-98c4-dc0c0c07398f. Sus primeros 48 bits cuentan 1 645 557 742 000 ms, correspondientes al 22 de febrero de 2022 a las 19:22:22 UTC. Se suele elegir v7 para claves de base de datos porque sus valores se ordenan por fecha de creación.
Los UUID generados proceden de xoshiro256** con semilla, por lo que la misma semilla produce siempre la misma lista. Para identificadores que deban ser impredecibles, usa una fuente criptográfica como crypto.randomUUID().
La herramienta identifica formato, variante, versión y campos temporales admitidos de un UUID existente. También genera ejemplos reproducibles de versiones 4 y 7 a partir de una semilla. Elige el modo según necesites inspeccionar un identificador o construir datos de prueba. La interpretación de campos y la generación de ejemplos son operaciones distintas.
El UUID inicial es 017f22e2-79b0-7cc3-98c4-dc0c0c07398f. Se identifica como versión siete, con variante RFC 9562, y contiene 2022-02-22 19:22:22.000 UTC. Su marca Unix es 1645557742000 milisegundos. Ese tiempo es información almacenada, sin demostrar cuándo se creó realmente un registro o se produjo un evento.
Un identificador puede copiarse, construirse manualmente o generarse con un tiempo arbitrario. Utiliza los registros de la aplicación cuando necesites evidencia temporal de un suceso. El formulario interpreta los bits presentes; no consulta una base de datos ni verifica el historial del objeto que tenga asociado ese UUID.
Un UUID contiene 128 bits. La forma textual habitual tiene 32 dígitos hexadecimales en grupos 8-4-4-4-12, separados por guiones. Se admiten letras hexadecimales mayúsculas o minúsculas, entrada compacta sin guiones, llaves exteriores y el prefijo urn:uuid:. La salida normalizada utiliza minúsculas.
Si hay guiones, deben ocupar las posiciones correctas. Un dígito ausente, un carácter no hexadecimal o un guion dentro de otro grupo produce un error. Normalizar la representación conserva los mismos 128 bits; no crea un identificador nuevo ni cambia la variante que esos bits contienen.
La variante determina cómo interpretar la disposición. Un UUID RFC moderno tiene bits iniciales de variante 10. Otros patrones se reservan para NCS, compatibilidad Microsoft o definiciones futuras. La herramienta identifica esos patrones sin tratar automáticamente su aparente nibble de versión como una versión RFC moderna.
RFC 9562 define los formatos actuales y sustituye RFC 4122. Revisa variante y versión juntas. El valor de todos ceros es Nil UUID y el de todos unos, Max UUID. Se identifican como valores especiales; que su sintaxis sea válida no implica que sean adecuados para cualquier campo de identificador de registro.
La versión siete comienza con una marca Unix de 48 bits en milisegundos. En el UUID inicial, los dos primeros grupos forman el hexadecimal 017f22e279b0. Su valor entero es 1645557742000 milisegundos y corresponde al tiempo UTC mostrado. La posición de esos bits permite localizar el campo temporal en el dibujo.
Las versiones uno y seis contienen una marca gregoriana en intervalos de cien nanosegundos desde 1582-10-15, con distinto orden de campos. El decodificador reconstruye el valor y lo convierte a tiempo Unix. Presenta siete dígitos fraccionarios de segundo para conservar la resolución almacenada de cien nanosegundos.
Para esas versiones también se muestran secuencia de reloj y campo de nodo. Son datos decodificados; no se establece que pertenezcan a un dispositivo concreto ni que procedan de un reloj correctamente mantenido. Conserva esa distinción al interpretar identificadores obtenidos de fuentes externas o de ejemplos construidos manualmente.
La versión cuatro no tiene un campo estándar de creación y sus salidas temporales quedan ausentes. Las versiones tres y cinco se reconocen como formatos basados en nombres, sin recuperar esos nombres originales. La versión ocho permite formatos personalizados; el decodificador general no asigna un tiempo universal a sus bits personalizados.
En generación, elige versión cuatro o siete, introduce una semilla y selecciona una cantidad de uno a cincuenta. La semilla debe ser un entero decimal desde 0 hasta 18446744073709551615, el intervalo completo sin signo de 64 bits. Pueden utilizarse espacios, comas y guiones bajos para agrupar sus dígitos.
La generación usa xoshiro256** con inicialización SplitMix64, según los generadores de referencia de sus autores. Repetir semilla, versión y ajustes temporales pertinentes devuelve la misma lista. Esa propiedad permite reproducir pruebas y demostraciones, sin depender de un estado aleatorio nuevo en cada ejecución.
Estos ejemplos no deben utilizarse como tokens de acceso impredecibles ni sustituir un generador de producción que gestione adecuadamente aleatoriedad y unicidad. La versión cuatro puede contener 122 posiciones de datos aleatorios, pero eso no transforma una semilla de 64 bits de esta herramienta en 122 bits de entropía independiente.
Para versión cuatro, los campos temporales no intervienen. Para versión siete, introduce fecha y hora UTC. Con semilla 42, fecha 2026-01-15 y hora 12:00, el primer valor es 019bc186-de00-7716-a104-d9866d113a7e. Contiene la marca Unix 1768478400000 milisegundos. Guarda esos ajustes completos cuando quieras repetir una lista más adelante.
Todos los UUID de versión siete de una lista utilizan el mismo milisegundo proporcionado. Los datos restantes proceden de extracciones seudoaleatorias sucesivas. Por eso no se garantiza que el orden de filas coincida con el orden lexicográfico dentro de ese milisegundo. La herramienta no impone un contador creciente entre sus ejemplos.
Con tiempos diferentes, la versión siete sitúa primero la parte temporal. Si una prueba necesita identificadores estrictamente crecientes, comprueba esa condición por separado. Cambiar solo el tiempo modifica el campo temporal y conserva la secuencia generada por la semilla para los demás campos; cambiar la semilla modifica esa secuencia.
| Escenario | Versión | Tiempo UTC incorporado |
|---|---|---|
| Predeterminado | 7 | 2022-02-22 19:22:22.000 UTC |
| RFC v1 | 1 | 2022-02-22 19:22:22.0000000 UTC |
| RFC v4 | 4 | — |
| RFC v6 | 6 | 2022-02-22 19:22:22.0000000 UTC |
| Semilla v7 | 7 | 2026-01-15 12:00:00.000 UTC |
Los ejemplos RFC proceden de su apéndice A. La tabla generada y el CSV contienen número de fila y UUID completo. Conserva las cadenas sin alterar al trasladarlas. La calculadora de bits permite revisar campos enteros pequeños y el conversor de bases, representar una marca temporal en otra base.
Fuente de comprobación: Comprobación del ejemplo: RFC 9562, apéndice A.6 (martes 22 de febrero de 2022, 14:22:22.00 GMT−05:00)
Fuente de comprobación: Comprobación del ejemplo: RFC 9562, apéndice A.3
Fuente de comprobación: Comprobación del ejemplo: RFC 9562, apéndice A.1;.clock_seq = 13256;.node = 0x9f6bdeced846
Fuente de comprobación: Comprobación del ejemplo: RFC 9562, apéndice A.5 (el mismo instante que el ejemplo v1)
La versión 4 rellena 122 de los 128 bits con datos aleatorios: sus valores se distribuyen uniformemente y no incorporan una fecha. La versión 7, definida en RFC 9562 (mayo de 2024), coloca primero una marca Unix de 48 bits en milisegundos y después 74 bits aleatorios, para ordenar los identificadores nuevos por creación. RFC 9562 señala que v4 tiene poca localidad en índices de bases de datos; por eso v7 resulta útil como clave primaria, a costa de revelar cuándo se creó cada ID.
Sí, aunque es extremadamente improbable con una fuente aleatoria adecuada. Un UUID v4 tiene 122 bits aleatorios; por la cota del cumpleaños harían falta unos 2,7 × 10^18 para alcanzar un 50 % de probabilidad de un duplicado, o unos 103 billones para una probabilidad de uno entre mil millones. En la práctica, las colisiones pueden deberse a generadores defectuosos o semillas repetidas; no uses los UUID con semilla de esta herramienta cuando sea importante la unicidad entre sistemas.
Es el mismo formato de 128 bits; GUID es el nombre que usa Microsoft. Sus herramientas suelen mostrarlo en mayúsculas y entre llaves, como {017F22E2-79B0-7CC3-98C4-DC0C0C07398F}. RFC 9562 admite mayúsculas, minúsculas o ambas, así que los analizadores deben aceptarlas. La diferencia relevante está en el orden binario de bytes: Windows almacena los tres primeros grupos en little-endian, algo que importa al leer bytes sin procesar.
Toma las primeras 12 cifras hexadecimales, que contienen un contador de 48 bits de milisegundos desde 1970-01-01 00:00 UTC, y conviértelas a decimal. En 017f22e2-79b0-7cc3-98c4-dc0c0c07398f, 017f22e279b0 equivale a 1 645 557 742 000 ms: 2022-02-22 19:22:22.000 UTC. El campo de 48 bits se agota en el año 10889, por lo que su desbordamiento no es un problema práctico actual.
Puede suponerlo. La versión 1 almacena una marca de tiempo de 60 bits y un campo de nodo de 48 bits que tradicionalmente es la dirección MAC de la máquina. Por tanto, el ID puede revelar cuándo y en qué tarjeta de red se creó. El ejemplo v1 de RFC 9562 se decodifica como 2022-02-22 19:22:22 UTC con nodo 9f:6b:de:ce:d8:46. RFC 9562 permite un nodo aleatorio y recomienda usar v7 en lugar de v1 o v6 cuando sea posible.
Esta calculadora incluye 8 ejemplos resueltos con respuestas de fuentes independientes. Forman parte del conjunto de pruebas y también puedes ejecutarlos aquí.