Herramientas de desarrollo · Codificador y decodificador Base64
Base64 vs hexadecimal vs base32: comparando tres formas de escribir bytes como texto
· Antecedentes
base64 codificación
Hex, base32 y Base64 resuelven el mismo problema con diferentes compensaciones en tamaño, legibilidad y seguridad. Esta publicación los compara en cuanto a densidad, distinción entre mayúsculas y minúsculas, seguridad de URL y error humano.
La clave API que se escribió mal debido a l, 1, I y O: una falla concreta de legibilidad que hexadecimal no habría tenido
Tres formas comunes de representar bytes como texto son hexadecimal, base32 y base64. Todos resuelven el mismo problema (expresar bytes arbitrarios en ASCII imprimible) pero con diferentes compensaciones en tamaño, legibilidad y resistencia a errores. Hexadecimal es 2 caracteres por byte (F3 A2 B1...), por lo que 16 bytes se convierten en 32 caracteres. Base32 tiene 1.6 caracteres por byte (aproximadamente 5 caracteres por 3 bytes), por lo que 16 bytes se convierten en 26 caracteres.
Base64 tiene 1.33 caracteres por byte (exactamente 4 caracteres por 3 bytes), por lo que 16 bytes se convierten en 24 caracteres o menos. Si el tamaño del archivo importa, base64 es el más compacto. Si la transcripción humana es importante, hex y base32 son más seguros. La diferencia de legibilidad es fundamental cuando un valor se escribe, se copia o se habla. Hex utiliza 0-9 y a-f (no distingue entre mayúsculas y minúsculas en la mayoría de los contextos). Un canal de transcripción cambia la decisión porque una representación optimizada para máquinas puede resultar incómoda para las personas. Base64 distingue entre mayúsculas y minúsculas y utiliza dos símbolos de puntuación; hexadecimal utiliza un vocabulario visual más reducido. La implementación aquí prueba cadenas exactas, no una tasa de error humano, por lo que no se adjunta ninguna probabilidad inventada.
Densidad: 2×, 1.6× y 1.33×: cuántos caracteres necesita cada codificación por byte y por qué
Base32 usa A-Z y 2-7, evitando 0, 1, O e I, que se confunden fácilmente en el papel. Base64 usa A-Z, a-z, 0-9, + y /,, incluidas mayúsculas y minúsculas, lo que distingue entre mayúsculas y minúsculas y mezcla dígitos que parecen similares (0 versus O, 1 versus I versus l minúscula). Una clave API en hexadecimal podría ser f3a2b1e4; los mismos bytes en base64 pueden ser 86KrvE== (con relleno), o en base32 6VEV7FI= (con relleno).
Si un usuario debe escribir el valor a mano, hexadecimal o base32 es más seguro que base64. Los caracteres reservados en las URL son importantes. Hex y base32 son seguros para las URL; ambos usan solo caracteres alfanuméricos (hexadecimal también usa 0-9, base32 también usa 2-7). Base64 usa más y barra que están reservadas para URL (más representa un espacio en datos codificados en formato, la barra es un separador de ruta). La densidad Base64 se deriva directamente de seis bits útiles por símbolo de salida y del relleno a bloques de cuatro caracteres. Hex lleva cuatro bits por símbolo, lo que hace dos caracteres por byte. Base32 se analiza como contexto de comparación solo porque este repositorio no proporciona ni su alfabeto ni un codificador para verificar los resultados.
Densidad a partir del ancho de bits: Base64 exacta y aritmética hexadecimal, con Base32 tratado como contexto de comparación
Una cadena base64 en un parámetro de URL debe estar codificada en porcentaje (el signo más se convierte en %2B, la barra diagonal se convierte en %2F), agregando 4 caracteres adicionales para cada aparición. Base64url (RFC 4648 sección 5) reemplaza el signo más con un guión y la barra con guión bajo, lo que lo hace URL seguro sin codificación porcentual. La mayoría de las API que usan base64 en las URL en realidad usan base64url, pero la distinción a menudo no es explícita en la documentación.
Los secretos TOTP (los códigos utilizados por las aplicaciones de autenticación) generalmente se distribuyen como base32. Una pantalla de inscripción TOTP muestra un secreto base32 porque es más fácil de escribir y transcribir que los mismos bytes en base64 o hexadecimal. Los resúmenes de hash SHA a menudo se muestran en hexadecimal porque es el formato tradicional y porque el hexadecimal no distingue entre mayúsculas y minúsculas, lo que hace que los errores tipográficos sean menos probables. La distinción entre mayúsculas y minúsculas es importante cuando alguien lee un valor en voz alta o lo vuelve a escribir, ya que cambiar el caso de una letra cambia su índice. ToolAcre conserva las mayúsculas y minúsculas exactamente y decodificará los diferentes bytes resultantes sin saber que un humano cometió un error de transcripción. La representación en sí no tiene suma de control.
Caracteres reservados y seguridad de URL: dónde + y / muerden, y cómo base32 y hexadecimal evitan el problema
Los JWT utilizan base64url. Las sumas de comprobación de archivos pueden ser hexadecimales o base64; ambos son comunes. La elección es una convención histórica, no una necesidad técnica. La resiliencia al error es una diferencia sutil pero importante. Base32 evita los dígitos 0, 1, 8 y 9 (que parecen letras), lo que reduce los errores de transcripción. Base64 incluye todos los dígitos, lo que hace que 1 sea ambiguo (¿es una letra I, l minúscula o el dígito 1?).
Hex es aún más propenso a errores: 0 parece O, l parece 1. Una suma de comprobación que debe escribirse o leerse de una copia impresa es más segura en base32. Una clave API que se pega directamente desde una computadora es segura en cualquier formato; la legibilidad sólo importa cuando se trata de ojos humanos. Bytes iguales, pero codificación diferente: la secuencia de bytes 16 [0xf3, 0xa2, 0xb1, ...] se convierte en f3a2b1... El signo más y barra del estándar Base64 necesitan un manejo que tenga en cuenta el canal; El modo seguro para URL los reemplaza con guiones y guiones bajos. Hex evita esos separadores utilizando solo dígitos y letras. Las convenciones de Base32 varían, por lo que este artículo evita propiedades de seguridad prometedoras que el repositorio no implementa ni prueba.
Ejemplo resuelto: los mismos 16 bytes en las tres codificaciones: longitudes comparadas e inspección visual
en hexadecimal, 6VEV7FI=... en base32 y 86KrvE== en base64. Ninguna de estas cadenas es intercambiable. Una aplicación que recibe f3a2b1... espera hexadecimal e intentará analizarlo como hexadecimal. La recepción de 86KrvE== fallará si la aplicación espera hexadecimal. El formato de codificación es parte del contrato de los datos: el remitente y el receptor deben acordar qué codificación se utiliza. El acolchado es otra diferencia.
Hex no utiliza relleno (4 bytes son siempre 8 caracteres hexadecimales, sin excepciones). Base32 y base64 usan relleno igual para alinear la salida con varios caracteres (8 para base32, 4 para base64). El relleno es necesario matemáticamente; garantiza que cada entrada de n bytes produzca un recuento de caracteres determinista. Las reglas de relleno varían: algunas aplicaciones requieren relleno, otras permiten omitirlo. La comparación trabajada utiliza una secuencia de bytes fija y calcula Base64 y hexadecimal mecánicamente. Su longitud Base32 se puede analizar a partir de una agrupación de cinco bits, pero se omite un valor de texto Base32 exacto porque ninguna implementación revisada lo generó. La aritmética de longitud y la verificación de salida se mantienen separadas.
Donde cada uno es convencional: hashes en hexadecimal, secretos TOTP en base32, JWT y datos: URI en Base64
Al pegar un valor base32 o base64 sin relleno, los decodificadores pueden aceptarlo o rechazarlo según la implementación. Las claves y tokens criptográficos muestran la diferencia de codificación.
Una clave HMAC tiene 32 bytes, que se convierten en 64 caracteres hexadecimales, 52 caracteres base32 (con relleno) o 44 caracteres base64 (con relleno). Al distribuir una clave, se debe documentar la codificación. Si la documentación dice que la clave es 44 caracteres base64 pero recibe 52 caracteres, algo anda mal. La convención puede guiar a los lectores pero no prueba su idoneidad. Los resúmenes de hash se muestran comúnmente como hexadecimal, mientras que los segmentos JWT usan Base64url. La elección correcta aún depende de las reglas del canal, de si las personas copian el valor y de si otro protocolo ya ha arreglado la representación.
Lo que esto no cubre: codificaciones base58, base85 y suma de verificación
La codificación base64 más corta hace que sea un poco más fácil colocar tokens en sistemas con límites de caracteres (como códigos QR o URL). La elección de la codificación de un valor la establece el ecosistema del que procede. Las API web suelen utilizar base64url. La documentación criptográfica suele utilizar hexadecimal. Las aplicaciones de autenticación utilizan base32. Al crear un sistema, elija una codificación, documéntela claramente y cúmplala.
Mezclar codificaciones (por ejemplo, base64 o base32) introduce confusión. Al depurar, el primer paso es identificar qué codificación utiliza el valor; La herramienta codificadora y decodificadora Base64 puede ayudar al intentar decodificarla de varias maneras y ver cuál produce una salida sensata. Ninguna codificación es universalmente mejor. Base64 es el más compacto para almacenamiento sin formato. Hex es más familiar para los criptógrafos y más legible para secuencias pequeñas. Base58, Base85 y las codificaciones de suma de verificación hacen concesiones diferentes y están ausentes en el panel Base64 de ToolAcre. Sus alfabetos, reglas de ambigüedad y sumas de verificación deben evaluarse con fuentes e implementaciones dedicadas en lugar de extrapolarse a partir del comportamiento probado de esta herramienta.
Conclusión: elija la codificación para el canal y el lector: cómo el codificador y descodificador Base64 cubre la carcasa Base64 en el navegador, junto con la calculadora de hash SHA en el mismo producto
Base32 es más resistente a los errores de transcripción. La elección depende del contexto: dónde reside el valor, cómo se comparte y qué sistemas lo consumirán.
Comprender las compensaciones le ayuda a elegir sabiamente al diseñar una API o un sistema. La herramienta de codificación y decodificación Base64 demuestra la codificación base64; usarlo junto con una herramienta hexadecimal o base32 le permite ver los mismos bytes en los tres formatos y comprender sus diferencias de tamaño y legibilidad. Para el caso de Base64, codifique una muestra, anote los recuentos exactos de UTF-8 bytes y caracteres de salida, y pruebe la puntuación estándar frente a la segura para URL. Para el trabajo de resumen, utilice el panel SHA independiente. Mantener esas operaciones distintas evita que una elección de codificación se confunda con hash o protección de integridad.