Herramientas de desarrollo · UUID generador
GUID vs UUID: Explicación de las llaves, el orden de bytes y la variante de Microsoft
· Antecedentes
uuid criptografía APIS del navegador
GUID es el nombre de Microsoft para UUID, pero las llaves, las mayúsculas y el orden de bytes pueden hacer que el mismo identificador se vea diferente en todas las plataformas. Esta publicación explica cada diferencia y cómo comparar de forma segura.
El mismo ID que no coincide en todos los sistemas: un servicio .NET y un servicio Java que no coinciden en un registro
Un servicio .NET genera un GUID y lo envía a un servicio Java, que intenta hacer coincidir el valor con un UUID de PostgreSQL. La comparación de cadenas falla y los sistemas informan que los identificadores no coinciden, aunque los tres servicios funcionan con los mismos 16 bytes subyacentes. Las diferencias son aparentemente cosméticas (llaves, mayúsculas y minúsculas, orden de bytes), pero hacen que las comparaciones de cadenas fallen y confundan los puntos de integración que no se normalizan en el límite. GUID es la terminología de Microsoft para lo que RFC 9562 llama UUID: un identificador de 128 bits con el mismo diseño de bits. Los dos nombres se refieren a la misma estructura fundamental, pero la representación difiere en formas que toman por sorpresa a los desarrolladores. Comprender dónde se origina la confusión evita errores de integración.
GUID es un UUID: el formato compartido de 128 bits y de donde proviene la diferencia de nombres
GUID significa Identificador único global e Identificador único global y es el nombre que Microsoft usa para lo que los estándares RFC llaman UUID. El diseño de 128 bits y la versión /variant del sistema son idénticos. RFC 4122 y RFC 9562 especifican el formato y significado de UUID; Microsoft los implementa y utiliza el término GUID. La diferencia de nombres es histórica: Microsoft usó GUID antes de que el IETF estandarizara los UUID, y la terminología de Microsoft se ha quedado dentro del ecosistema .NET. A nivel de bits, un GUID y un UUID son completamente intercambiables. A nivel de formato, difieren en la presentación: el código .NET a menudo escribe GUID con llaves y letras mayúsculas, mientras que los UUID canónicos RFC usan minúsculas y sin llaves.
Llaves y mayúsculas: el formato de registro {XXXXXXXX-...} y cómo normalizarlo
Un UUID en formato RFC canónico se escribe como ocho, cuatro, cuatro, cuatro y doce caracteres hexadecimales en minúscula separados por guiones: 550e8400-e29b-41d4-a716-446655440000. Un GUID .NET se muestra convencionalmente entre llaves y mayúsculas: {550E8400-E29B-41D4-A716-446655440000}. Las llaves provienen del formato del Registro de Windows; mayúsculas es una convención de visualización. Ambas formas representan los 128 bits idénticos. Para hacer coincidir un GUID de .NET con un UUID de PostgreSQL, elimine las llaves y normalice la carcasa, luego compare las cadenas. La verificación bien formada de ToolAcre acepta la forma canónica y elimina automáticamente las llaves. La normalización es una transformación menor del texto que preserva todo el significado.
Orden de bytes endian mixto: cómo se almacenan los primeros tres campos en little endian en la estructura GUID y por qué Guid.ToByteArray difiere del orden de bytes RFC
La peligrosa diferencia entre GUID y UUID es el orden de bytes. RFC 9562 especifica que los primeros tres campos (8, 4 y 4 grupos hexadecimales) se almacenan en orden de bytes big-endian (red). La estructura Guid de .NET almacena los primeros tres campos en little-endian: los bytes se invierten antes de escribir en el almacenamiento. Los mismos 16 bytes, cuando se escriben mediante .NET Guid.ToByteArray() y se interpretan mediante código compatible con RFC, producen representaciones de texto completamente diferentes. A UUID 550e8400-e29b-41d4-a716-446655440000 en orden de bytes RFC se almacena como bytes 55 0e 84 00 e2 9b 41 d4 a7 16 44 66 55 44 00 00.
La variante heredada de Microsoft: qué significa c o d en el primer carácter del cuarto grupo
Además del orden de bytes, los identificadores heredados de Microsoft a veces utilizan un campo variante no estándar. Cuando RFC 9562 especifica que el primer carácter del cuarto grupo debe ser 8, 9, aob, los GUID de Microsoft heredados pueden usar c, d, e o f. Estos siguen siendo UUID válidos, pero se ajustan a una variante heredada anterior a la estandarización RFC. Si encuentra un GUID con c o d en el primer carácter del cuarto grupo, tiene un valor de 128 bits válido que no se ajusta a los bits de la variante RFC. El .NET moderno genera GUID compatibles con RFC, por lo que los nuevos identificadores no deberían presentar este problema. Los bits de variantes heredadas son raros pero es importante reconocerlos.
Ejemplo resuelto: los mismos 16 bytes representados en orden RFC y en orden de estructura GUID, mostrando exactamente qué caracteres se intercambian
Tome UUID 550e8400-e29b-41d4-a716-446655440000 y conviértalo al formato de matriz de bytes GUID de .NET usando la convención little-endian. En orden RFC, los bytes son: el primer campo (550e8400) es igual a 55 0e 84 00, el segundo campo (e29b) es igual a e2 9b, el tercer campo (41d4) es igual a 41 d4, el cuarto y quinto son iguales a a7 16 44 66 55 44 00 00. En .NET little-endian: el primer campo se convierte en 00 84 0e 55, el segundo se convierte en 9b e2, el tercero se convierte en d4 41 y el resto permanece en big-endian. La matriz de bytes completa es 00 84 0e 55 9b e2 d4 41 a7 16 44 66 55 44 00 00. Si un sistema Java lee estos bytes esperando el orden RFC, los interpreta como 00840e55-9be2-d441-a716-446655440000.
Lo que esto no cubre: NEWSEQUENTIALID y pedidos de SQL Server, que son un tema de almacenamiento propio
El comportamiento de la función NEWSEQUENTIALID de SQL Server y sus propiedades específicas de ordenamiento de identificadores son temas específicos de la capa de almacenamiento y de la base de datos. Esta publicación se centra en las diferencias de formato y orden de bytes a nivel de aplicación y serialización. Los problemas profundos de orden de bytes y manejo de UUID específicos de la base de datos se abordan mejor en la documentación específica de esa plataforma de base de datos. Los diferentes sistemas de bases de datos tienen diferentes enfoques y enfoques para UUID almacenamiento, indexación, clasificación y soporte nativo. Algunas bases de datos detectan automáticamente los bits de versión y variante, mientras que otras requieren declaraciones de tipo explícitas y manejo del orden de bytes en el límite entre los sistemas y el almacenamiento.
Conclusión: normalizar en el límite: la verificación ToolAcre acepta la forma canónica, que es la forma para estandarizar al intercambiar ID
Normalizar en el límite cuando los identificadores cruzan un límite del sistema .NET/non-.NET. Quite las llaves, normalice las mayúsculas y minúsculas de manera consistente e intercambie bytes en los primeros tres campos si los bytes provienen de .NET Guid.ToByteArray(). La forma canónica RFC es el estándar de referencia: ocho, cuatro, cuatro, cuatro y doce caracteres hexadecimales en minúsculas con guiones, sin llaves, orden de bytes big-endian. Al intercambiar con sistemas .NET, acuerde una forma normalizada y aplique las conversiones explícitamente en el código de integración. Documente el manejo del orden de bytes y pruebe las conversiones minuciosamente. Las similitudes fundamentales entre GUID y UUID significan que la mayoría de los bits 128 son idénticos.