Base32

El alfabeto base32 más utilizado se define en RFC 4648 §6 y en 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 0 y 1 se omiten debido a su similitud con las letras O e I (por lo tanto, "2" tiene un valor decimal de 26 ). 

En algunos casos, el relleno no es necesario ni se utiliza (puede inferirse a partir de la longitud de la cadena módulo 8). El RFC 4648 establece que el relleno debe utilizarse a menos que la especificación del estándar (que hace referencia al RFC) indique explícitamente lo contrario. Excluir el relleno resulta útil al utilizar datos codificados en Base32 en tokens de URL o nombres de archivo, donde el carácter de relleno podría generar problemas.

Este es un ejemplo de una representación Base32 utilizando el conjunto de 32 caracteres descrito anteriormente ( IPFS CIDv1 en codificación Base32 en mayúsculas):BAFYBEICZSSCDSBS7FFQZ55ASQDF3SMV6KLCW3GOFSZVWLYARCI47BGF354

"Hexadecimal extendido" base 32 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 el RFC 2938 bajo el nombre de "Base-32". El RFC 4648, si bien reconoce el uso existente de esta versión en NSEC3 , se refiere a ella como base32hex y desaconseja referirse a ella simplemente como "base32". 

Dado que esta notación utiliza 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 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 la RFC 4648. ^{[ 3 ]}parseInt()int()

A diferencia de muchos otros sistemas de notación de base 32, los dígitos de base32hex más allá del 9 son contiguos. Sin embargo, su conjunto de dígitos incluye caracteres que pueden generar conflictos visuales. Con muchas fuentes es posible distinguir visualmente entre caracteres de aspecto similar como (0, O) y (1, I), pero en otras fuentes esto puede ser difícil y, por lo tanto, pueden no ser adecuadas para representar secuencias de caracteres base32. Esto es especialmente cierto en un sistema de notación que solo expresa números, cuando el contexto que suele proporcionar el inglés no está presente. ^{[ b ]} La elección de la fuente no está controlada ni por la notación ni por la codificación, pero base32hex no intenta compensar las deficiencias de las fuentes afectadas. ^{[ c ]}

z-base-32 ^{[ 7 ]} es una codificación Base32 diseñada por Zooko Wilcox-O'Hearn para facilitar su uso y hacerla más compacta. Incluye 1 , 8 y 9 , pero excluye l , v , 0 y 2. Además, permuta el alfabeto de manera que los caracteres más fáciles sean los que aparecen con mayor frecuencia. Codifica de forma compacta cadenas de bits cuya longitud en bits no es múltiplo de 8 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 verificación módulo 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.

Existen bibliotecas para codificar datos binarios en Base32 de Crockford, disponibles en varios lenguajes de programación.

Los programadores que trabajaban en la Electrologica X1 utilizaban una forma anterior de notación en base 32 para representar las direcciones de las máquinas. 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).

En el algoritmo Geohash , se utiliza una representación base32 modificada para representar los valores de latitud y longitud en un entero positivo (entrelazado por bits). ^{[ 9 ]} Esta representación 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:

Aproximadamente en 1950, ^{[ 10 ]} Alan Turing escribió los requisitos de software para el sistema informático Manchester Mark I. ^{[ 11 ]} Una transcripción del manual de Turing para el Mark I está disponible en archive.org. ^{[ 12 ]}

El sitio de archivo de la Universidad de Manchester que conmemora los 60 años de la informática ^{[ 13 ]} contiene una tabla con la codificación en base 32 que utilizó Turing. La tabla y la explicación que la acompaña también aparecen en el manual.

Otro relato de este período en la vida de Turing aparece en su página biográfica bajo el título " Primeras computadoras y la prueba de Turing" .

Antes de que la NVRAM se generalizara, varios videojuegos para plataformas de Nintendo utilizaban números en base 31 para las contraseñas . Estos sistemas omiten las vocales (excepto la Y) para evitar que el juego introduzca accidentalmente una contraseña inapropiada . Por lo tanto, los caracteres suelen ser 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. Algunos juegos que utilizan este sistema son Mario Is Missing!, Mario's Time Machine , Tetris Blast y El Señor de los Anillos (Super NES) .

El alfabeto Base32, que permite la escritura segura de 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. Al tratar el alfabeto como sensible a mayúsculas y minúsculas, se obtiene un conjunto de 32 (8+12+12) dígitos.

Base32 tiene varias ventajas sobre Base64:

1. El conjunto de caracteres resultante utiliza una sola mayúscula o minúscula, lo que a menudo puede ser beneficioso al usar un sistema de archivos que no distingue entre mayúsculas y minúsculas , nombres DNS , lenguaje hablado o memoria humana.
2. El resultado se puede utilizar como nombre de archivo porque no puede contener el símbolo '/', que es el separador de rutas de Unix .
3. Se puede seleccionar el alfabeto para evitar pares de símbolos diferentes de aspecto similar, de modo que las cadenas se puedan transcribir con precisión a mano. (Por ejemplo, el conjunto de símbolos RFC 4648 §6 omite los dígitos uno, ocho y cero, ya que podrían confundirse con las letras 'I', 'B' y 'O'). 
4. Un resultado sin relleno puede incluirse en una URL sin codificar ningún carácter.

Base32 tiene ventajas sobre hexadecimal / Base16 :

1. La representación en Base32 ocupa un 20 % menos de espacio. (1000 bits ocupan 200 caracteres, en comparación con los 250 de Base16).

En comparación con las codificaciones basadas en 8 bits, los sistemas de 5 bits también podrían tener ventajas cuando se utilizan para la transmisión de caracteres:

1. El esquema Base32 de la sección 6 de la RFC 4648, que incluye el alfabeto completo, y otros similares permiten codificar dos caracteres más por cada entero de 32 bits (para un total de 6 en lugar de 4, con 2 bits de sobra), lo que ahorra ancho de banda en dominios con recursos limitados, como las redes de radio.

La representación Base32 ocupa aproximadamente un 20 % más de espacio que Base64 . Además, debido a que codifica cinco bytes de 8 bits (40 bits) en ocho caracteres Base32 de 5 bits en lugar de tres bytes de 8 bits (24 bits) en cuatro caracteres Base64 de 6 bits, el relleno hasta un límite de 8 caracteres supone una mayor carga para los mensajes cortos (lo que podría ser un motivo para omitir el relleno, una opción contemplada en la RFC 4648 ). 

Aunque Base32 ocupa aproximadamente un 20 % menos de espacio que el hexadecimal , su uso es mucho menor. El hexadecimal se puede convertir fácilmente a bytes, ya que dos dígitos hexadecimales constituyen un byte. Base32 no se convierte a bytes individuales. Sin embargo, dos dígitos Base32 corresponden a diez bits, que pueden codificar (32 × 32 =) 1024 valores, con aplicaciones evidentes 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 no se recuerdan al instante, es más fácil contar a través de un puñado de valores.