Base64

Cada secuencia de entrada de 6 bits (que puede codificar 2⁶ ⁼  64  valores) se asigna a una letra del alfabeto Base64. Por lo tanto, la codificación Base64 produce cuatro caracteres por cada tres bytes de entrada. Suponiendo que la entrada sea ASCII o similar, los datos de bytes para los tres primeros caracteres 'M', 'a', 'n' son los valores 77, , 97y , 110que en representación binaria de 8 bits son 01001101, 01100001, y 01101110. Al unir estas representaciones y dividirlas en grupos de 6 bits se obtiene:

010011 010110 000101 101110 

Que codifica la cadena TWFu(según ASCII o similar).

La siguiente tabla muestra cómo se codifica la entrada. Por ejemplo, la letra 'M' tiene el valor 77(según ASCII y similares). Los primeros 6 bits del valor son 010011o 19 decimal que se asigna a la letra 'T' en Base64 que tiene un valor 84(según ASCII y similares).

Si la entrada consta de un número de bytes que es 2 unidades mayor que un múltiplo de 3 (por ejemplo, 'M', 'a'), los últimos 2 bytes (16 bits) se codifican en 3 dígitos Base64 (18 bits). Los dos bits menos significativos del último bloque de 6 bits que contiene el contenido se tratan como cero para la codificación y se descartan para la decodificación (junto con el =carácter de relleno final).

Si la entrada consta de un número de bytes que es 1 más que un múltiplo de 3 (por ejemplo, 'M'), entonces los últimos 8 bits se representan en 2 dígitos Base64 (12 bits). Los cuatro bits menos significativos= del último bloque de 6 bits que contiene contenido se tratan como cero para la codificación y se descartan para la decodificación (junto con los dos caracteres de relleno finales ):

Al decodificar, cada secuencia de cuatro caracteres codificados se convierte en tres bytes de salida, pero con un solo carácter de relleno, los últimos 4 caracteres se decodifican en solo dos bytes, o con dos caracteres de relleno, los últimos 4 caracteres se decodifican en un solo byte. Por ejemplo:

Otra forma de interpretar el carácter de relleno es considerarlo como una instrucción para descartar 2 bits finales de la cadena de bits cada vez que =se encuentra un . Por ejemplo, cuando se decodifica bGlnaHQg dw== , convertimos cada carácter (excepto las ocurrencias finales de ) en su representación correspondiente de 6 bits, y luego descartamos 2 bits finales para el primero y otros 2 bits finales para el otro . En este caso, obtendríamos 6 bits del , y otros 6 bits del para una cadena de bits de longitud 12, pero como eliminamos 2 bits para cada (para un total de 4 bits), el termina produciendo 8 bits (1 byte) cuando se decodifica.===dw=dw==

El uso del carácter de relleno en el texto codificado no es esencial para la decodificación. El número de bytes faltantes se puede inferir a partir de la longitud del texto codificado. En algunas variantes, el carácter de relleno es obligatorio, mientras que en otras no se utiliza. Cabe destacar que, al concatenar cadenas codificadas en Base64, el uso de caracteres de relleno es necesario durante la codificación para evitar ambigüedades durante la decodificación.

Sin relleno, tras decodificar cada secuencia de 4 caracteres codificados, pueden quedar 2 o 3 caracteres codificados sobrantes (como se muestra en la tabla anterior). No es posible que quede un único carácter codificado sobrante, ya que un solo carácter Base64 solo contiene 6 bits, y se requieren 8 bits para crear un byte; por lo tanto, el primer carácter Base64 aporta 6 bits, y el segundo carácter Base64 aporta sus primeros 2 bits para completar el byte (véase más arriba).

La siguiente tabla muestra cómo decodificar cadenas codificadas que tienen 2, 3 o ningún carácter sobrante.

La decodificación sin relleno no se realiza de forma consistente entre los decodificadores: algunos requieren relleno, mientras que otros infieren la cantidad correcta a partir de la cadena de entrada codificada. ^{[ 10 ]} Además, permitir la decodificación sin relleno, por definición, permite que una lista de cadenas escritas en un orden particular se decodifique en varias cadenas de salida posibles en lugar de una sola, lo que puede suponer un riesgo de seguridad debido a la decodificación impredecible o inesperada. ^{[ 11 ]}

El RFC 4648 describe diversas codificaciones, incluyendo Base64, y aborda el uso de saltos de línea, relleno y caracteres no alfabéticos en los datos codificados, así como el uso de diferentes alfabetos de codificación y codificaciones canónicas. La variante denominada Codificación Base 64 y base64 está destinada a uso general. 

El RFC también especifica una segunda codificación Base64 que denomina Codificación Base64 con Alfabeto Seguro para URL y Nombres de Archivo, destinada a representar información de identificación relativamente larga. Por ejemplo, un marco de persistencia de bases de datos para objetos Java podría usar la codificación Base64 para codificar un identificador único relativamente grande (generalmente UUID de 128 bits ) como una cadena para usarla como parámetro HTTP en un formulario HTTP o una URL HTTP GET . Además, muchas aplicaciones necesitan codificar datos binarios de una manera conveniente para su inclusión en una URL, incluso en campos ocultos de formularios web, y Base64 es una codificación conveniente para representarlos de forma compacta.

Usar Base64 estándar en una URL requiere codificar los caracteres +, /y como secuencias hexadecimales especiales codificadas en porcentaje ( se convierte en , se convierte en y se convierte en ), lo que hace que la cadena sea más larga y difícil de leer. Usar un alfabeto diferente permite codificar como Base64 sin requerir este marcado adicional. Normalmente, y se reemplazan por y , respectivamente, de modo que ya no es necesario usar codificadores/decodificadores de URL y no tiene efecto en la longitud del valor codificado, dejando la misma forma codificada intacta para su uso en bases de datos relacionales, formularios web e identificadores de objetos en general. Un sitio popular que hace uso de esto es YouTube . ^{[ 13 ]} Algunas variantes permiten o requieren omitir los signos de relleno para evitar que se confundan con separadores de campo, o requieren que cualquier relleno de este tipo esté codificado en porcentaje. Algunas bibliotecas codifican como , lo que potencialmente expone las aplicaciones a ataques de ruta relativa cuando un nombre de carpeta se codifica a partir de datos de usuario.=+%2B/%2F=%3D+/-_==.

El RFC 3548 , titulado " Codificaciones de datos Base16, Base32 y Base64" , es un documento informativo (no normativo) que busca unificar las especificaciones RFC 1421 y RFC 2045 sobre codificaciones Base64, codificaciones con alfabetos alternativos y las codificaciones Base32 (de uso poco frecuente) y Base16. El RFC 4648 reemplaza al RFC 3548.   

A menos que un codificador esté escrito según una especificación que haga referencia a RFC 3548 y requiera específicamente lo contrario , RFC 3548 prohíbe que un codificador genere mensajes que contengan caracteres fuera del alfabeto de codificación o sin relleno, y también declara que un decodificador debe rechazar los datos que contengan caracteres distintos del alfabeto de codificación. ^{[ 4 ]} 

La especificación MIME (Multipurpose Internet Mail Extensions) enumera Base64 como uno de los dos esquemas de codificación de binario a texto (el otro es quoted-printable ). ^{[ 3 ]} La codificación Base64 de MIME se basa en la de la versión RFC 1421 de PEM: utiliza el mismo alfabeto de 64 caracteres y mecanismo de codificación que PEM y utiliza el símbolo para el relleno de salida de la misma manera, como se describe en RFC 2045 . = 

MIME no especifica una longitud fija para las líneas codificadas en Base64, pero sí una longitud máxima de 76 caracteres. Además, especifica que cualquier carácter que no pertenezca al conjunto estándar de 64 caracteres de codificación (por ejemplo, secuencias CRLF) debe ser ignorado por un decodificador compatible, aunque la mayoría de las implementaciones utilizan un par de saltos de línea CR/LF para delimitar las líneas codificadas.

Por lo tanto, la longitud real de los datos binarios codificados en Base64 compatibles con MIME suele ser aproximadamente el 137 % de la longitud de los datos originales ( 4/3 × 78/76 ) , aunque para mensajes muy cortos la sobrecarga puede ser mucho mayor debido a la sobrecarga de las cabeceras. Aproximadamente, el tamaño final de los datos binarios codificados en Base64 es igual a 1,37 veces el tamaño de los datos originales + 814 bytes (para las cabeceras). El tamaño de los datos decodificados se puede aproximar con esta fórmula:

bytes = (longitud_cadena(cadena_codificada) − 814) / 1,37 

El primer uso estandarizado conocido de la codificación ahora llamada MIME Base64 fue en el protocolo Privacy-Enhanced Mail (PEM), propuesto por RFC 989 en 1987. PEM define un esquema de "codificación imprimible" que utiliza la codificación Base64 para transformar una secuencia arbitraria de bytes a un formato que se puede expresar en líneas cortas de caracteres de 6 bits, como lo requieren los protocolos de transferencia como SMTP . ^{[ 14 ]} 

La versión actual de PEM (especificada en RFC 1421 ) utiliza un alfabeto de 64 caracteres que consta de letras romanas mayúsculas y minúsculas ( – , – ), los números ( – ) y los símbolos y . El símbolo también se utiliza como sufijo de relleno. ^{[ 2 ]} La especificación original, RFC 989 , utilizaba además el símbolo para delimitar datos codificados pero no cifrados dentro del flujo de salida. AZaz09+/= *

Para convertir datos a codificación imprimible PEM, el primer byte se coloca en los ocho bits más significativos de un búfer de 24 bits , el siguiente en los ocho intermedios y el tercero en los ocho menos significativos . Si quedan menos de tres bytes por codificar (o en total), los bits restantes del búfer serán cero. A continuación, el búfer se utiliza, de seis bits en seis bits, comenzando por los más significativos, como índices de la cadena: " ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/", y se imprime el carácter indicado.

El proceso se repite con los datos restantes hasta que queden menos de cuatro bytes. Si quedan tres bytes, se procesan normalmente. Si quedan menos de tres bytes (24 bits) para codificar, los datos de entrada se rellenan a la derecha con ceros para formar un múltiplo entero de seis bits.

Tras codificar los datos sin relleno, si dos bytes del búfer de 24 bits contienen ceros de relleno, =se añaden dos caracteres a la salida; si un byte contiene ceros de relleno, =se añade un carácter. Esto indica al decodificador que los bits cero añadidos por el relleno deben excluirse de los datos reconstruidos. Asimismo, garantiza que la longitud de la salida codificada sea un múltiplo de 4 bytes.

PEM requiere que todas las líneas codificadas consten de exactamente 64 caracteres imprimibles, con la excepción de la última línea, que puede contener menos. Las líneas están delimitadas por espacios en blanco según las convenciones locales (específicas de la plataforma).

UTF-7 , descrito por primera vez en el RFC 1642 , posteriormente reemplazado por el RFC 2152 , introdujo un sistema denominado Base64 modificado . Este esquema de codificación de datos se utiliza para codificar UTF-16 como caracteres ASCII para su uso en protocolos de transporte de 7 bits como SMTP . Es una variante de la codificación Base64 utilizada en MIME. ^{[ 15 ] [ 16 ]}  

El alfabeto "Base64 modificado" consiste en el alfabeto Base64 MIME, pero no utiliza el =carácter de relleno " ". UTF-7 está diseñado para usarse en encabezados de correo (definido en RFC 2047 ), y el carácter " " está reservado en ese contexto como carácter de escape para la codificación "quoted-printable". El Base64 modificado simplemente omite el relleno y termina inmediatamente después del último dígito Base64 que contiene bits útiles, dejando hasta tres bits sin usar en el último dígito Base64. =

OpenPGP , descrito en RFC 9580 , especifica " ASCII armor ", que es idéntico a la codificación "Base64" descrita por MIME, con la adición de un CRC opcional de 24 bits . La suma de verificación se calcula sobre los datos de entrada antes de la codificación; luego, la suma de verificación se codifica con el mismo algoritmo Base64 y, precedida por el símbolo " " como separador, se agrega a los datos de salida codificados. ^{[ 17 ]} =

Los métodos atob()y btoa()JavaScript, definidos en la especificación preliminar de HTML5, ^{[ 18 ] [ 19 ]} proporcionan funcionalidad de codificación y decodificación Base64 a las páginas web. El btoa()método genera caracteres de relleno, pero estos son opcionales en la entrada del atob()método. Ejemplo: Codificación del inicio de un archivo GIF: btoa("GIF89a")↦ "R0lGODlh".

Varias variantes utilizan alfabetos similares a los de las variantes comunes, pero en un orden diferente.

Contraseña de Unix

Unix almacena los hashes de contraseñas calculados con crypt en el /etc/passwdarchivo usando una codificación llamada B64 . El alfabeto de crypt coloca la puntuación .y /antes de los caracteres alfanuméricos. crypt usa el alfabeto " ./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz" sin relleno. Una ventaja sobre RFC 4648 es que ordenar los datos ASCII codificados da como resultado el mismo orden que ordenar los datos ASCII sin formato.

GEDCOM

El estándar GEDCOM 5.5 para el intercambio de datos genealógicos codifica archivos multimedia en su formato de archivo jerárquico de línea de texto. GEDCOM utiliza el mismo alfabeto que crypt, que es " ./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz" . ^{[ 20 ]}

bcrypt

Los hashes bcrypt están diseñados para usarse de la misma manera que los hashes crypt(3) tradicionales, pero el alfabeto de bcrypt está en un orden diferente al de crypt. bcrypt usa el alfabeto " ./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789" . ^{[ 21 ]}

Xxencoding

Xxencoding utiliza un conjunto de caracteres mayoritariamente alfanumérico similar a crypt, pero usando+y-en lugar de.y/. Xxencoding utiliza el alfabeto " +-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz" .

Paquete de 6

Utilizado con algunos controladores de nodos terminales , utiliza un alfabeto de 0x00 a 0x3f. ^{[ 22 ]}

Intento

Bash admite literales numéricos en Base64. Bash utiliza el alfabeto " 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ@_" . ^{[ 23 ]}

Algunas variantes utilizan un alfabeto Base64 que es significativamente diferente de los alfabetos utilizados en las variantes Base64 más comunes (como RFC 4648).

Uuencoding

El alfabeto Uuencoding no incluye caracteres en minúscula, sino que utiliza los códigos ASCII del 32 ("  " (espacio)) al 95 (" _"), de forma consecutiva. Uuencoding utiliza el alfabeto "  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_" . Evitar todas las letras minúsculas fue útil, ya que muchas impresoras antiguas solo imprimían en mayúsculas. El uso de caracteres ASCII consecutivos ahorró potencia de cálculo, puesto que solo era necesario sumar 32, sin necesidad de una tabla de búsqueda. El uso de la mayoría de los caracteres de puntuación y el espacio puede limitar su utilidad en algunas aplicaciones, como aquellas que utilizan estos caracteres como sintaxis.

BinHex

BinHex 4 (HQX), que se usaba en el Mac OS clásico , excluye algunos caracteres visualmente confusos como '7', 'O', 'g' y 'o'. Su alfabeto incluye caracteres de puntuación adicionales. Utiliza el alfabeto " !"#$%&'()*+,-012345689@ABCDEFGHIJKLMNPQRSTUVXYZ[`abcdefhijklmpqr" .

UTF-8

Un entorno UTF-8 puede usar bytes de continuación no sincronizados como base64: . Consulte UTF-8#Autosincronización .0b10xxxxxx