Herramientas de desarrollo · UUID generador
De 128 Bits a 36 Caracteres: Cómo funciona la codificación de texto UUID
· Cómo funciona
uuid criptografía APIS del navegador
Un UUID tiene 16 bytes, pero su forma familiar es 36 caracteres. Esta publicación explica la duplicación hexadecimal, los guiones, las reglas de mayúsculas y minúsculas y las codificaciones más cortas que la gente usa cuando el formulario estándar es demasiado largo.
Por qué la columna es más ancha que el valor: el valor de 16 bytes que cuesta 36 caracteres en el texto y lo que eso significa para las URL y el almacenamiento
El ancho de la columna de almacenamiento aumenta cuando elige un formato UUID. Un valor de 128 bits es 16 bytes, pero su representación de texto depende de la codificación: hexadecimal (36 caracteres con guiones, 32 sin), base64url (22 caracteres), base58 (22–23 caracteres), Crockford base32 (26 caracteres). Si su esquema almacena UUID como VARCHAR(36), está gastando 36 caracteres en cada fila. En una tabla con 1 mil millones de filas y ninguna otra columna, eso significa 36 gigabytes de texto en comparación con 16 gigabytes de binario. La elección no es sólo cosmética; afecta el tamaño de la consulta, los viajes de ida y vuelta de la red y la presión de la caché. El formato canónico es 36 caracteres: ocho dígitos hexadecimales, guión, cuatro dígitos hexadecimales, guión, cuatro dígitos hexadecimales, guión, cuatro dígitos hexadecimales, guión, doce dígitos hexadecimales.
Hex lo duplica todo: cada byte se convierte en dos caracteres y cuatro guiones completan el 36
Cada byte se convierte en exactamente dos caracteres hexadecimales (0–9, a–f). Los guiones están ahí por motivos de legibilidad y legado desde que se especificaron por primera vez los UUID. La codificación hexadecimal duplica el recuento de bytes: 16 bytes se convierten en 32 dígitos hexadecimales más 4 guiones. Es la codificación más lenta y más larga, pero legible por humanos y compatible en todas partes. Reglas de casos: RFC 9562 exige minúsculas para la salida canónica, pero la entrada no distingue entre mayúsculas y minúsculas. Almacenar mayúsculas desperdicia la oportunidad de normalizar, por lo tanto, almacene minúsculas y compare sin distinguir entre mayúsculas y minúsculas en la entrada. La codificación Base64url representa tres bytes como cuatro caracteres utilizando un alfabeto de 64 caracteres (A–Z, a–z, 0–9, menos, guión bajo). Dieciséis bytes se convierten en 21 caracteres más un carácter de relleno, con un total de 22 caracteres. Base64url elimina el relleno y los caracteres estándar (más y barra) que están reservados en las URL.
Reglas de casos: minúsculas en la salida, no distingue entre mayúsculas y minúsculas en la entrada y por qué las comparaciones de mayúsculas y minúsculas causan discrepancias silenciosas
Un UUID en formato base64url guarda 14 caracteres en comparación con hexadecimal y es válido en URL sin codificación porcentual. La desventaja: es menos legible (las letras minúsculas parecen dígitos; b, 8, B y 8 son fáciles de confundir). Base58 es utilizado por Bitcoin y otras cadenas de bloques y elimina los caracteres ambiguos (0, O, I, l), lo que hace que el resultado tenga 22–23 caracteres sin dejar de ser legible. Crockford base32 (diseñado para formatos similares a ISBN con suma de verificación) utiliza caracteres 26 y prioriza la corrección sobre la brevedad. La captura de orden de bytes del GUID de Microsoft se aplica al almacenamiento UUID en algunas bases de datos. RFC 9562 especifica el orden de bytes de la red (big-endian) para todos los bytes. Algunas configuraciones de Microsoft SQL Server almacenan GUID con orden de bytes little-endian en los primeros tres campos.
Codificaciones más cortas: base64url en 22 caracteres, base58 y Crockford base32, con sus ventajas y desventajas en cuanto a legibilidad y seguridad al copiar y pegar.
El mismo valor de 128 bits almacenado en big-endian y little-endian produce diferentes cadenas hexadecimales. Un UUID 550e8400-e29b-41d4-a716-446655440000 almacenado como GUID de Microsoft se puede recuperar como 00840e55-9be2-d441-a716-446655440000 (bytes 0–3 y 4–5 y 6–7 invertidas). Si su sistema sirve de puente entre los sistemas compatibles con RFC y Microsoft, debe tenerlo en cuenta y normalizar en el límite o documentar qué formato está utilizando en cada columna. Ejemplo resuelto: la v4 UUID 9b2e4f1a-4f3e-4c1a-8a7d-1b2c3d4e5f60 en hexadecimal ocupa 36 caracteres. Como 16 bytes, es 9b 2e 4f 1a 4f 3e 4c 1a 8a 7d 1b 2c 3d 4e 5f 60. En base64url: dividir en fragmentos de tres bytes, convertir a base64, quitar el relleno: my5PGk8-TBqKfRssPTRPX2A. En hexadecimal sin guiones: 9b2e4f1a4f3e4c1a8a7d1b2c3d4e5f60 (32 caracteres).
La trampa del orden de bytes de Microsoft: cómo los primeros tres campos de un GUID se almacenan en little endian, de modo que los mismos bytes se puedan imprimir como dos cadenas diferentes
Base64url guarda 14 caracteres; base58 ahorraría aproximadamente lo mismo; hexadecimal es el estándar. Elija según su caso de uso: si el identificador aparece en las URL y cada carácter es importante, utilice base64url; si aparece en registros e interfaces de usuario donde los humanos lo leen, use la forma canónica hexadecimal; Si está construyendo un sistema blockchain o un sistema distribuido donde la suma de verificación es importante, use base58 o Crockford base32. Al elegir un tipo de columna, almacene el valor que optimice su patrón de acceso real. Si consulta los UUID con frecuencia y necesita una coincidencia que no distinga entre mayúsculas y minúsculas, almacene el binario (16) y deje que la base de datos maneje la representación. Si consulta por subcadena (busca UUID que comienzan con un prefijo), el hexadecimal es más legible en la salida de depuración.
Ejemplo resuelto: un identificador escrito como bytes, hexadecimal canónico y una forma abreviada, que muestra cada paso de conversión
Si exporta a CSV y envía un correo electrónico a usuarios no técnicos, el hexadecimal es más reconocible. Si tiene limitaciones de espacio (aplicación móvil con caché local), base64url o base58 ahorra ancho de banda. El generador ToolAcre genera formato hexadecimal de caracteres canónicos 36; Si necesita una codificación diferente, la verificación bien formada aún funciona porque normaliza cualquier representación válida antes de verificar el formato. Las consideraciones de rendimiento son importantes al codificar o decodificar millones de UUID. La codificación hexadecimal es simple: convierta cada byte en dos caracteres en O(1) tiempo por byte. La decodificación es igualmente sencilla. La codificación y decodificación Base64 utiliza tablas de búsqueda y son ligeramente más lentas (aproximadamente 2–3 veces más lentas que hexadecimal por byte, según el hardware y la implementación). Base58 es significativamente más lento porque es esencialmente una conversión de bases y requiere aritmética modular.
Lo que esto no cubre: opciones de columnas de la base de datos, como tipos de uuid nativos versus binarios (16), se tratan por separado
Si su sistema codifica o decodifica UUID en un bucle activo (generación de identificadores de alta frecuencia, exportación masiva), el hexadecimal es más rápido. Si la codificación ocurre con poca frecuencia y el ahorro de 14 caracteres es importante, base64url es una compensación razonable. El generador ToolAcre genera hexadecimal, por lo que obtiene la ventaja de rendimiento sin sacrificar la compatibilidad. La semántica de comparación de cadenas difiere según la codificación. Los UUID hexadecimales se pueden comparar como cadenas: 550e8400-e29b-41d4-a716-446655440000 < 550e8400-e29b-41d4-a716-446655440001 (la comparación lexicográfica funciona). Los UUID binarios se pueden comparar como bytes: la comparación byte por byte es lo mismo que la comparación numérica. Sin embargo, los UUID codificados en base64url y base58 no conservan el orden numérico en la comparación de cadenas lexicográficas. Si su sistema se basa en la clasificación lexicográfica de UUID (un patrón sorprendentemente común para crear índices o claves de bases de datos), debe usar una variante hexadecimal, binaria o ordenable UUID (v6 o v7).
Conclusión: mantenga la forma canónica en los límites: el generador ToolAcre genera UUID de caracteres estándar 36 y su verificación acepta cadenas en esa forma
El generador ToolAcre actualmente produce UUID v4, que no se pueden ordenar por orden de codificación. La interoperabilidad requiere estandarización en una única codificación. Un sistema que acepta UUID en hexadecimal, base64 y base58 simultáneamente debe normalizar todas las entradas a una forma canónica antes de procesarlas. Esto es posible pero añade complejidad. Las API o bases de datos externas pueden requerir una codificación específica: algunas API esperan urn:uuid: hexadecimal con prefijo, otras esperan hexadecimal sin guiones y otras esperan base64url. Documente claramente las expectativas de codificación UUID de su sistema en los contratos API. El generador ToolAcre siempre genera hexadecimal canónico; Si necesita otras codificaciones, realice la conversión explícitamente y documente las compensaciones (espacio, rendimiento, legibilidad, ordenabilidad) para el equipo.