Base32 es un método de codificación basado en el sistema de numeración de base -32 . Utiliza un alfabeto de 32 dígitos , cada uno de los cuales representa una combinación diferente de 5 bits (2 5 ). Dado que base32 no está muy ampliamente adoptado, la cuestión de la notación (qué caracteres utilizar para representar los 32 dígitos) no está tan resuelta como en el caso de los sistemas de numeración más conocidos (como el hexadecimal ), aunque existen RFC y estándares no oficiales y de facto. Una forma de representar números Base32 en forma legible para humanos es utilizando los dígitos 0–9 seguidos de las veintidós letras mayúsculas A–V. Sin embargo, se utilizan muchas otras variaciones en diferentes contextos. Históricamente, el código Baudot podría considerarse un código base32 modificado ( con estado ).
Este artículo se centra en el uso de Base32 para representar cadenas de bytes en lugar de números enteros sin signo, de forma similar a como funciona Base64 .
El estándar de Internet propuesto en octubre de 2006 [1] RFC 4648 documenta las codificaciones base16 , base32 y base64. Incluye dos esquemas para base32, pero recomienda uno sobre el otro. Además, recomienda que, independientemente del precedente, solo el alfabeto que define en su sección 6 se denomine base32, y que el otro alfabeto similar en su sección 7 se denomine base32hex. [a] El acuerdo con esas recomendaciones no es universal. Se debe tener cuidado al usar sistemas que se denominan base32, ya que esos sistemas podrían ser base32 según el RFC 4648 §6, o según el §7 (posiblemente sin tener en cuenta la desaprobación de ese RFC del nombre más simple para este último), o podrían ser otra variante de codificación, consulte más adelante.
El alfabeto base32 más utilizado [ cita requerida ] se define en el RFC 4648 §6 y el anterior RFC 3548 (2003). El esquema fue diseñado originalmente en 2000 por John Myers para SASL / GSSAPI . [2] Utiliza un alfabeto de A – Z , seguido de 2 – 7 . Los dígitos , 1 y 8 se omiten debido a su similitud con las letras O , I y B (por lo tanto, "2" tiene un valor decimal de 26 ).
En algunas circunstancias, no se requiere ni se utiliza el relleno (el relleno se puede inferir de la longitud de la cadena módulo 8). La RFC 4648 establece que se debe utilizar el relleno a menos que la especificación del estándar (que hace referencia a la RFC) indique explícitamente lo contrario. Excluir el relleno es útil cuando se utilizan datos codificados en Base32 en tokens de URL o nombres de archivo donde el carácter de relleno podría plantear un problema.
Este es un ejemplo de una representación Base32 que utiliza el conjunto de 32 caracteres descrito anteriormente ( IPFS CIDv1 en codificación Base32 en mayúsculas):BAFYBEICZSSCDSBS7FFQZ55ASQDF3SMV6KLCW3GOFSZVWLYARCI47BGF354
Base 32 "hexadecimal extendida" o base32hex , [3] otro esquema para la base 32 según RFC 4648 §7, extiende el hexadecimal de una manera más natural: su mitad inferior es idéntica al hexadecimal, y más allá de eso, base32hex simplemente continúa el alfabeto hasta la letra V.
Este esquema fue propuesto por primera vez por Christian Lanctot, un programador que trabajaba en Sage Software , en una carta a la revista Dr. Dobb's en marzo de 1999 [4] como parte de una solución sugerida para el error Y2K . Lanctot se refirió a él como "Double Hex". El mismo alfabeto fue descrito en 2000 en RFC 2938 bajo el nombre "Base-32". RFC 4648, si bien reconoce el uso existente de esta versión en NSEC3 , se refiere a él como base32hex y desaconseja referirse a él solo como "base32".
Dado que esta notación utiliza los dígitos del 0 al 9 seguidos de letras consecutivas del alfabeto, coincide con los dígitos utilizados por la función de JavaScript [5] y el constructor de Python [6] cuando se especifica una base mayor que 10 (como 16 o 32). También conserva la propiedad del hexadecimal de preservar el orden de clasificación bit a bit de los datos representados, a diferencia de la base32 o base64 del §6 de RFC 4648. [3]parseInt() int()
A diferencia de muchos otros sistemas de notación de base 32, los dígitos de base32hex posteriores al 9 son contiguos. Sin embargo, su conjunto de dígitos incluye caracteres que pueden entrar en conflicto visualmente. Con la fuente correcta es posible distinguir visualmente entre 0, O y 1, I, pero otras fuentes pueden no ser adecuadas, ya que esas letras podrían ser difíciles de distinguir para los humanos, especialmente cuando el contexto que el inglés suele proporcionar no está presente en un sistema de notación que solo expresa números. [b] La elección de la fuente no está controlada por la notación o la codificación, pero base32hex no intenta compensar las deficiencias de las fuentes afectadas. [c]
Cambiando el alfabeto Base32, todos los estándares alternativos tienen combinaciones similares de símbolos alfanuméricos.
z-base-32 [7] es una codificación Base32 diseñada por Zooko Wilcox-O'Hearn para que sea más fácil de usar para humanos y más compacta. Incluye 1 , 8 y 9 pero excluye l , v , y 2. También permuta el alfabeto de modo que los caracteres más fáciles sean los que aparecen con más frecuencia. [ aclaración necesaria ] Codifica de forma compacta cadenas de bits cuya longitud en bits no es un múltiplo de 8 [ aclaración necesaria ] y omite los caracteres de relleno finales. z-base-32 se utilizó en el proyecto de código abierto Mnet, y actualmente se utiliza en el protocolo ZRTP de Phil Zimmermann y en el proyecto de código abierto Tahoe-LAFS .
Otro diseño alternativo para Base32 es creado por Douglas Crockford , quien propone usar caracteres adicionales para una suma de comprobación mod-37. [8] Excluye las letras I, L y O para evitar confusiones con dígitos. También excluye la letra U para reducir la probabilidad de obscenidad accidental.
Las bibliotecas para codificar datos binarios en Base32 de Crockford están disponibles en una variedad de idiomas.
Los programadores que trabajaban en la Electrologica X1 utilizaban una forma anterior de notación de base 32 para representar direcciones de máquina. Los "dígitos" se representaban como números decimales del 0 al 31. Por ejemplo, 12-16 representaría la dirección de máquina 400 (= 12 × 32 + 16).
Véase el algoritmo Geohash , utilizado para representar valores de latitud y longitud en un entero positivo (entrelazado por bits). [9] La representación base32 de Geohash utiliza todos los dígitos decimales (0-9) y casi todo el alfabeto en minúsculas, excepto las letras "a", "i", "l", "o", como se muestra en el siguiente mapa de caracteres:
Antes de que la NVRAM se volviera universal, varios videojuegos para las plataformas de Nintendo usaban números de base 31 para las contraseñas . Estos sistemas omiten las vocales (excepto Y) para evitar que el juego proporcione accidentalmente una contraseña profana . Por lo tanto, los caracteres son generalmente alguna variación menor del siguiente conjunto: 0–9, B, C, D, F, G, H, J, K, L, M, N, P, Q, R, S, T, V, W, X, Y, Z y algunos signos de puntuación. Los juegos que se sabe que usan este sistema incluyen Mario Is Missing!, Mario 's Time Machine , Tetris Blast y El Señor de los Anillos (Super NES) .
El alfabeto Base32, que no admite palabras, es una extensión del alfabeto Base20 de Open Location Code . Este alfabeto utiliza 8 dígitos numéricos y 12 dígitos de letras que distinguen entre mayúsculas y minúsculas, elegidos para evitar la formación accidental de palabras. Si se trata el alfabeto como sensible a mayúsculas y minúsculas, se obtiene un conjunto de 32 dígitos (8+12+12).
Base32 tiene una serie de ventajas sobre Base64 :
Base32 tiene ventajas sobre el hexadecimal / Base16 :
En comparación con las codificaciones basadas en 8 bits, los sistemas de 5 bits también pueden tener ventajas cuando se utilizan para la transmisión de caracteres:
La representación en base32 ocupa aproximadamente un 20 % más de espacio que en base64 . Además, dado que codifica cinco bytes de 8 bits (40 bits) en ocho caracteres en base32 de 5 bits en lugar de tres bytes de 8 bits (24 bits) en cuatro caracteres en base64 de 6 bits, el relleno hasta un límite de 8 caracteres supone una carga mayor en los mensajes cortos (lo que puede ser una razón para omitir el relleno, que es una opción en RFC 4648).
Aunque Base32 ocupa aproximadamente un 20% menos de espacio que el hexadecimal , Base32 se utiliza mucho menos. El hexadecimal se puede asignar fácilmente a bytes porque dos dígitos hexadecimales son un byte. Base32 no se asigna a bytes individuales. Sin embargo, dos dígitos Base32 corresponden a diez bits, que pueden codificar (32 × 32 =) 1024 valores, con aplicaciones obvias para órdenes de magnitud de unidades de varios bytes en términos de potencias de 1024.
El sistema hexadecimal es más fácil de aprender y recordar, ya que solo implica memorizar los valores numéricos de seis símbolos adicionales (A–F), e incluso si estos no se recuerdan instantáneamente, es más fácil contar solo un puñado de valores.
Los programas Base32 son adecuados para codificar datos de bytes arbitrarios utilizando un conjunto restringido de símbolos que pueden ser utilizados cómodamente por humanos y procesados por computadoras.
Las implementaciones de Base32 utilizan un conjunto de símbolos compuesto por al menos 32 caracteres diferentes (a veces un 33.º para el relleno), así como un algoritmo para codificar secuencias arbitrarias de bytes de 8 bits en un alfabeto Base32. Debido a que se necesita más de un carácter Base32 de 5 bits para representar cada byte de entrada de 8 bits, si la entrada no es un múltiplo de 5 bytes (40 bits), entonces no cabe exactamente en caracteres Base32 de 5 bits. En ese caso, algunas especificaciones requieren que se agreguen caracteres de relleno, mientras que otras requieren bits cero adicionales para formar un múltiplo de 5 bits. El sistema Base64, estrechamente relacionado, en cambio, utiliza un conjunto de 64 símbolos (o 65 símbolos cuando se utiliza relleno).
Están disponibles implementaciones de Base32 en C/C++, [10] [11] Perl, [12] Java, [13] JavaScript, [14] Python, [15] Go [16] y Ruby [17] . [18]