Herramientas de desarrollo · UUID generador
Lectura manual de un UUID: dónde residen la versión y los bits variantes
· Cómo funciona
uuid criptografía APIS del navegador
Dos caracteres hexadecimales en cada UUID le indican qué versión lo produjo y qué variante de diseño sigue. Aprende a leerlos de un vistazo y a saber lo que no te pueden decir.
¿Qué sistema creó esta identificación? — la pregunta de log-forense que la versión nibble puede responder
Una cadena UUID tiene 36 caracteres: treinta y dos dígitos hexadecimales y cuatro guiones en las posiciones 8-4-4-4-12. Dos caracteres en cada UUID, que aparecen en las posiciones 14 y 19, codifican metadatos: el campo de versión le indica qué algoritmo generó la identificación, y el campo de variante le indica qué diseño estándar sigue. Leer estos dos caracteres sin herramientas es la habilidad forense de registros: detecta un UUID en un volcado de base de datos o en un mensaje de error e inmediatamente sabe si es una marca de tiempo v1 (que filtra el tiempo de creación), un valor aleatorio v4 (que se generó a partir de un CSPRNG) o algo más. El número de versión ocupa los bits 48–51 de UUID, que se asigna al primer carácter hexadecimal del tercer grupo.
El diseño de 128 bits en cinco grupos: cómo 8-4-4-4-12 se asigna a bytes y por qué los grupos son históricos, no funcionales
Para la cadena xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx, el carácter en la posición 14 es la versión. RFC 9562 define las versiones 1 a 8: v1 se basa en el tiempo gregoriano y filtra el tiempo de creación; v4 es aleatorio; v7 está basado en tiempo Unix y se puede ordenar. Las versiones 0, 9 y superiores están reservadas o no se utilizan. Si ve una v1 UUID, sabrá que la hora y la dirección de hardware estaban mezcladas; si ve v4, el ID son bytes aleatorios con bits de versión configurados; si ve la v7, se ordena por hora de creación. La versión no es opcional; cada UUID formado correctamente tiene uno. El campo variante ocupa los bits 64–65 del UUID, los dos bits más significativos del octeto 8.
La versión nibble: el primer carácter del tercer grupo, lo que significan de 1 a 8 y lo que indica un 0 o 9 allí.
En la representación de texto xxxxxxxx-xxxx-xxxx-Nxxx-xxxxxxxxxxxx, el primer carácter del cuarto grupo (posición 19) codifica la variante. Para la variante RFC 9562 (el estándar en el uso moderno), este carácter debe ser 8, 9, a o b: las representaciones hexadecimales de 1000, 1001, 1010 y 1011 en binario. Cualquier otro carácter (0–7, c–f) indica una variante diferente: 0–7 son compatibilidad con versiones anteriores de NCS; c – d son GUID heredados de Microsoft con orden de bytes little-endian; e – f están reservados. Cuando lees la posición 19 y ves 8, 9, a o b, estás viendo un RFC 9562 UUID. Cualquier otro valor significa que los bytes siguen una interpretación diferente. El diseño de 128 bits se divide en octetos 0–15, pero el formato de texto los separa en grupos para facilitar la lectura, no para funcionar.
El campo variante: por qué el primer carácter del cuarto grupo es 8, 9, aob para UUID RFC y qué señal c/d (heredado de Microsoft) o 0–7 (NCS)
Los cinco grupos representan límites históricos de campos: los primeros tres campos contienen la marca de tiempo y la versión en UUID v1, el cuarto campo contiene la secuencia de reloj y la variante, el quinto campo contiene el identificador de nodo. La versión 4 y las versiones posteriores UUID no usan estos nombres de campo, pero las mismas posiciones de bits aún llevan la versión y la variante. Leer un UUID v4 significa aceptar que la mayoría de los bits 128 son carga útil aleatoria, pero dos de ellos, en las posiciones 14 y 19 en el texto, están fijos por estándar. Esos bits fijos prueban que el ID es una variante v4 y RFC. El UUID nulo es 00000000-0000-0000-0000-000000000000, todo ceros y no lleva ninguna versión. El máximo UUID es ffffffff-ffff-ffff-ffff-ffffffffffff, todos los caracteres f, y también está reservado y sin versión.
Ejemplo resuelto: decodificar tres identificadores de muestra carácter por carácter, incluidos un v4 y un v7
Todos los demás UUID bien formados tienen una versión en el tercer grupo y una variante en el cuarto. Ponte a prueba con tres ID de muestra: 123e4567-e89b-12d3-a456-426614174000 (v1, variante RFC porque la posición 19 es a); 9b2e4f1a-4f3e-4c1a-8a7d-1b2c3d4e5f60 (v4, variante RFC porque la posición 19 es 8); 018f0c2e-1b5a-7c3d-9e4f-5a6b7c8d9e0f (v7, variante RFC porque la posición 19 es 9). El inspector de ToolAcre confirma su lectura. Una verificación de formato no puede indicarle si una identificación es única, existe en su base de datos o se generó de forma segura. La versión v1 utiliza la hora y el hardware como entradas, por lo que UUID v1 idénticos de diferentes máquinas significan un desfase del reloj o problemas de sincronización. La versión v4 es aleatoria, por lo que un duplicado v4 UUID significa aleatoriedad rota o una colisión astronómicamente improbable (aproximadamente uno por cada 2. 7 billones de UUID con aleatoriedad sólida).
Nil y Max: los dos valores completamente cero y completamente F que no tienen ninguna versión
Una versión 0 o 9 significa que la cadena no es una UUID válida en absoluto. Leer la versión y variante es el primer paso para comprender qué es una identificación; comprobar si existe o es único es el segundo y tercer paso, realizado por su base de datos y su lógica empresarial. Comprender las posiciones de los bits ayuda a depurar las migraciones de datos. Al importar UUID de sistemas heredados, algunas herramientas exportan campos variantes que no coinciden con el estándar RFC 9562. Un campo variante de c o d indica un GUID de Microsoft en orden de bytes little-endian. Estos GUID son identificadores válidos dentro de los sistemas Microsoft, pero no interoperan con los UUID RFC 9562 sin conversión de orden de bytes. La posición de lectura 19 le indica inmediatamente qué sistema generó la identificación. Si ve 8, 9, aob, tiene un estándar RFC UUID.
Lo que una verificación de formato no puede decirle: que el ID existe en su base de datos, que se generó de forma segura o que es único.
Si ve c o d, tiene un GUID de Microsoft. Si ve cualquier otro carácter, el identificador está mal formado o proviene de un sistema oscuro. El generador ToolAcre siempre produce UUID RFC 9562 con la posición 19 como una de 8, 9, a o b. El campo de versión de tres bits codifica siete valores posibles (1–7; las versiones 0 y 8 tienen significados especiales). La versión 1 es una marca de tiempo gregoriana, la versión 3 es un espacio de nombres basado en MD5, la versión 4 es aleatoria, la versión 5 es un espacio de nombres basado en SHA-1, la versión 6 está basada en una marca de tiempo Unix (propuesta), versión 7 es ordenable según marca de tiempo Unix (estandarizado en RFC 9562), la versión 8 está reservada para formatos personalizados. La lectura del carácter position-14 le indica inmediatamente qué algoritmo se utilizó. Si está depurando UUID colisiones u tipos inesperados, el número de versión es su primera pista. ToolAcre genera UUID v4 exclusivamente a partir de criptomonedas.
Conclusión: dos caracteres, mucho contexto: use la verificación bien formada de ToolAcre para confirmar el análisis de una cadena y luego lea la versión mordisquear usted mismo
getRandomValues; cada UUID que produce tiene un 4 en la posición 14. Analizar la estructura UUID a mano es una habilidad útil para depurar sistemas complejos donde las herramientas no están disponibles. En un incidente de producción, es posible que necesite leer los UUID de un volcado de base de datos, un registro de errores o un caché sin ejecutar una herramienta especial. Busca la posición 14 para identificar la versión (¿se pierde tiempo? ¿Es aleatoria? ¿Se puede ordenar?). Buscas la posición 19 para identificar la variante (¿es estándar RFC? ¿es un GUID de Microsoft? ¿está reservado?). Estos dos caracteres, de un total de 36, llevan los metadatos. Los caracteres 34 restantes son carga útil: marca de tiempo o bytes aleatorios u otros datos específicos del algoritmo. Saber qué representa la carga útil le ayuda a comprender el papel del ID en su sistema.