En programación informática , Base64 es un grupo de esquemas de codificación de binario a texto que transforman datos binarios en una secuencia de caracteres imprimibles , limitada a un conjunto de 64 caracteres únicos. Más específicamente, los datos binarios de origen se toman de a 6 bits por vez, luego este grupo de 6 bits se asigna a uno de los 64 caracteres únicos.
Al igual que todos los esquemas de codificación de binario a texto, Base64 está diseñado para transportar datos almacenados en formatos binarios a través de canales que solo admiten contenido de texto de manera confiable. Base64 es particularmente frecuente en la World Wide Web [1], donde uno de sus usos es la capacidad de incrustar archivos de imagen u otros recursos binarios dentro de recursos textuales como archivos HTML y CSS . [2]
Base64 también se utiliza ampliamente para enviar archivos adjuntos a correos electrónicos , ya que SMTP , en su forma original, fue diseñado para transportar únicamente caracteres ASCII de 7 bits . Codificar un archivo adjunto como Base64 antes de enviarlo y luego decodificarlo al recibirlo garantiza que los servidores SMTP más antiguos no interfieran con el archivo adjunto.
La codificación Base64 genera una sobrecarga del 33 al 37 % en relación con el tamaño de los datos binarios originales (33 % por la codificación en sí; hasta un 4 % más por los saltos de línea insertados).
El conjunto particular de 64 caracteres elegido para representar los valores de 64 dígitos para la base varía entre las implementaciones. La estrategia general es elegir 64 caracteres que sean comunes a la mayoría de las codificaciones y que también sean imprimibles. Esta combinación hace que los datos sean poco probables de modificar en tránsito a través de sistemas de información, como el correo electrónico, que tradicionalmente no eran limpios de 8 bits . [3] Por ejemplo, la implementación Base64 de MIMEA usa – Z, a– zy 0– 9para los primeros 62 valores. Otras variaciones comparten esta propiedad pero difieren en los símbolos elegidos para los dos últimos valores; un ejemplo es UTF-7 .
Los primeros ejemplos de este tipo de codificación se crearon para la comunicación por acceso telefónico entre sistemas que ejecutaban el mismo sistema operativo (por ejemplo, uuencode para UNIX y BinHex para TRS-80 [posteriormente adaptado para Macintosh ]) y, por lo tanto, podían hacer más suposiciones sobre qué caracteres eran seguros de usar. Por ejemplo, uuencode usa letras mayúsculas, dígitos y muchos caracteres de puntuación, pero no minúsculas. [4] [5] [6] [3]
Este es el alfabeto Base64 definido en el RFC 4648 §4. Véase también la tabla de resumen de variantes §.
El ejemplo siguiente utiliza texto ASCII para simplificar, pero no es un caso de uso típico, ya que se puede transferir de forma segura a través de todos los sistemas que pueden manejar Base64. El uso más típico es codificar datos binarios (como una imagen); los datos Base64 resultantes solo contendrán 64 caracteres ASCII diferentes, todos los cuales se pueden transferir de forma confiable a través de sistemas que pueden dañar los bytes de origen sin procesar.
He aquí un modismo muy conocido en el ámbito de la computación distribuida :
Muchas manos hacen el trabajo más liviano.
Cuando la comilla (sin espacios finales) se codifica en Base64, se representa como una secuencia de bytes de caracteres ASCII con relleno de 8 bits codificados en el esquema Base64 de MIME de la siguiente manera (las nuevas líneas y los espacios en blanco pueden estar presentes en cualquier lugar, pero deben ignorarse durante la decodificación):
TWFueSBoYW5kcyBtYWtlIGxpZ2h0IHdvcmsu
En la cita anterior, el valor codificado de Man es TWFu . Codificados en ASCII, los caracteres M , a y n se almacenan como los valores de byte 77, 97y 110, que son los valores binarios de 8 bits 01001101, 01100001y 01101110. Estos tres valores se unen en una cadena de 24 bits, lo que produce 010011010110000101101110. Los grupos de 6 bits (6 bits tienen un máximo de 2 6 = 64 valores binarios diferentes) se convierten en números individuales de principio a fin (en este caso, hay cuatro números en una cadena de 24 bits), que luego se convierten en sus valores de caracteres Base64 correspondientes.
Como ilustra este ejemplo, la codificación Base64 convierte tres octetos en cuatro caracteres codificados.
=Se pueden agregar caracteres de relleno para que el último bloque codificado contenga cuatro caracteres Base64.
La transformación de hexadecimal a octal es útil para convertir entre binario y Base64. Dicha conversión está disponible tanto para calculadoras avanzadas como para lenguajes de programación. Por ejemplo, la representación hexadecimal de los 24 bits anteriores es 4D616E. La representación octal es 23260556. Esos 8 dígitos octales se pueden dividir en pares ( 23 26 05 56 ), y cada par se convierte a decimal para obtener 19 22 05 46 . Al utilizar esos cuatro números decimales como índices para el alfabeto Base64, los caracteres ASCII correspondientes son TWFu .
Si solo hay dos octetos de entrada significativos (por ejemplo, 'Ma'), o cuando el último grupo de entrada contiene solo dos octetos, los 16 bits se capturarán en los primeros tres dígitos Base64 (18 bits); los dos bits menos significativos del último bloque de 6 bits con contenido resultarán ser cero y se descartarán durante la decodificación (junto con el =carácter de relleno siguiente):
Si solo hay un octeto de entrada significativo (por ejemplo, 'M'), o cuando el último grupo de entrada contiene solo un octeto, los 8 bits se capturarán en los primeros dos dígitos Base64 (12 bits); los cuatro bits menos significativos del último bloque de 6 bits con contenido resultarán ser cero y se descartarán durante la decodificación (junto con los dos =caracteres de relleno siguientes):
También existen herramientas interactivas para visualizar la codificación paso a paso desde texto simple a base64. [7]
Debido a que Base64 es una codificación de seis bits y a que los valores decodificados se dividen en octetos de 8 bits, cada cuatro caracteres de texto codificado en Base64 (4 sextetos = 4 × 6 = 24 bits) representan tres octetos de texto o datos sin codificar (3 octetos = 3 × 8 = 24 bits). Esto significa que cuando la longitud de la entrada sin codificar no es un múltiplo de tres, la salida codificada debe tener un relleno agregado para que su longitud sea un múltiplo de cuatro. El carácter de relleno es =, que indica que no se necesitan más bits para codificar completamente la entrada. (Esto es diferente de A, que significa que los bits restantes son todos ceros). El siguiente ejemplo ilustra cómo truncar la entrada de la cita anterior cambia el relleno de la salida:
El carácter de relleno no es esencial para la decodificación, ya que la cantidad de bytes faltantes se puede inferir a partir de la longitud del texto codificado. En algunas implementaciones, el carácter de relleno es obligatorio, mientras que en otras no se utiliza. Una excepción en la que se requieren caracteres de relleno es cuando se han concatenado varios archivos codificados en Base64.
Al decodificar texto Base64, normalmente se convierten cuatro caracteres en tres bytes. Las únicas excepciones son cuando existen caracteres de relleno. Un solo =indica que los cuatro caracteres se decodificarán en solo dos bytes, mientras que ==un solo byte indica que los cuatro caracteres se decodificarán 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 a. Por ejemplo, cuando se decodifica ` bGlnaHQg dw== `, convertimos cada carácter (excepto las ocurrencias finales de ) en su representación de 6 bits correspondiente, y luego descartamos 2 bits finales para el primero y otros 2 bits finales para el otro . En este caso, obtendríamos 6 bits de , y otros 6 bits de para una cadena de bits de longitud 12, pero como eliminamos 2 bits para cada uno (para un total de 4 bits), el termina produciendo 8 bits (1 byte) cuando se decodifica.===dw=dw==
Sin relleno, después de la decodificación normal de cuatro caracteres a tres bytes una y otra vez, pueden quedar menos de cuatro caracteres codificados. En esta situación, solo pueden quedar dos o tres caracteres. No es posible que quede un solo carácter codificado, porque un solo carácter Base64 solo contiene 6 bits y se requieren 8 bits para crear un byte, por lo que se requiere un mínimo de dos caracteres Base64: el primer carácter contribuye con 6 bits y el segundo carácter contribuye con sus primeros 2 bits. Por ejemplo:
La decodificación sin relleno no se realiza de manera uniforme entre los decodificadores. Además, permitir la decodificación sin relleno por definición permite que varias cadenas se decodifiquen en el mismo conjunto de bytes, lo que puede ser un riesgo de seguridad. [8]
Las implementaciones pueden tener algunas restricciones en el alfabeto utilizado para representar algunos patrones de bits. Esto se refiere en particular a los dos últimos caracteres utilizados en el alfabeto en las posiciones 62 y 63, y al carácter utilizado para el relleno (que puede ser obligatorio en algunos protocolos o eliminarse en otros). La siguiente tabla resume estas variantes conocidas y proporciona vínculos a las subsecciones siguientes.
El primer uso estandarizado conocido de la codificación ahora llamada MIME Base64 fue en el protocolo de correo electrónico con privacidad mejorada (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 octetos a un formato que puede expresarse en líneas cortas de caracteres de 6 bits, como lo requieren los protocolos de transferencia como SMTP . [9]
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. [4] La especificación original, RFC 989, utilizó además el símbolo para delimitar datos codificados pero no cifrados dentro del flujo de salida.AZaz09+/=*
Para convertir los 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 bits del medio y el tercero en los ocho bits menos significativos . Si quedan menos de tres bytes para codificar (o en total), los bits restantes del búfer serán cero. Luego, el búfer se utiliza, seis bits a la vez, el más significativo primero, como índices en la cadena: " ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/", y se genera el carácter indicado.
El proceso se repite con los datos restantes hasta que queden menos de cuatro octetos. Si quedan tres octetos, se procesan normalmente. Si quedan menos de tres octetos (24 bits) para codificar, los datos de entrada se rellenan a la derecha con bits cero para formar un múltiplo entero de seis bits.
Después de codificar los datos no rellenados, si dos octetos del búfer de 24 bits están rellenos =con ceros, se añaden dos caracteres a la salida; si un octeto del búfer de 24 bits está lleno de ceros, =se añade un carácter. Esto indica al decodificador que los bits cero añadidos debido al relleno deben excluirse de los datos reconstruidos. Esto también garantiza que la longitud de salida codificada sea un múltiplo de 4 bytes.
PEM requiere que todas las líneas codificadas consten de exactamente 64 caracteres imprimibles, con excepción de la última línea, que puede contener menos caracteres imprimibles. Las líneas están delimitadas por caracteres de espacio en blanco según las convenciones locales (específicas de la plataforma).
La especificación MIME (Multipurpose Internet Mail Extensions) incluye Base64 como uno de los dos esquemas de codificación de binario a texto (el otro es quoted-printable ). [5] 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í especifica una longitud máxima de línea de 76 caracteres. Además, especifica que cualquier carácter que esté fuera del 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 nueva línea CR/LF para delimitar las líneas codificadas.
Por lo tanto, la longitud real de los datos binarios codificados en Base64 que cumplen 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 los encabezados. A grandes rasgos, 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 los encabezados). El tamaño de los datos decodificados se puede aproximar con esta fórmula:
bytes = (longitud_de_cadena(cadena_codificada) − 814) / 1,37
UTF-7 , descrito por primera vez en RFC 1642, que luego fue reemplazado por RFC 2152, introdujo un sistema llamado Base64 modificado . Este esquema de codificación de datos se utiliza para codificar UTF-16 como caracteres ASCII para su uso en transportes de 7 bits como SMTP . Es una variante de la codificación Base64 utilizada en MIME. [10] [11]
El alfabeto "Base64 modificado" consiste en el alfabeto Base64 MIME, pero no utiliza el =carácter de relleno " ". UTF-7 está pensado para usarse en encabezados de correo (definidos en RFC 2047), y el carácter " " está reservado en ese contexto como el carácter de escape para la codificación "entre comillas e imprimible". 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 4880, describe la codificación Radix-64 , también conocida como " armadura ASCII ". Radix-64 es idéntica a la codificación "Base64" descrita por MIME, con la adición de un CRC de 24 bits opcional . La suma de comprobación se calcula sobre los datos de entrada antes de la codificación; luego, la suma de comprobación se codifica con el mismo algoritmo Base64 y, precedida por el símbolo " " como separador, se agrega a los datos de salida codificados. [12]=
El RFC 3548, titulado Las codificaciones de datos Base16, Base32 y Base64 , es un memorando informativo (no normativo) que intenta unificar las especificaciones RFC 1421 y RFC 2045 de las codificaciones Base64, las codificaciones de alfabeto alternativo y las codificaciones Base32 (que rara vez se utiliza) y Base16.
A menos que las implementaciones se escriban según una especificación que haga referencia a RFC 3548 y requiera específicamente lo contrario, RFC 3548 prohíbe que las implementaciones generen mensajes que contengan caracteres fuera del alfabeto de codificación o sin relleno, y también declara que las implementaciones de decodificadores deben rechazar datos que contengan caracteres fuera del alfabeto de codificación. [6]
El RFC 4648 deja obsoleto el RFC 3548 y se centra en Base64/32/16:
La codificación Base64 puede ser útil cuando se utiliza información de identificación bastante extensa en un entorno HTTP. Por ejemplo, un marco de persistencia de base de datos para objetos Java podría utilizar la codificación Base64 para codificar un identificador único relativamente grande (generalmente UUID de 128 bits ) en una cadena para su uso como parámetro HTTP en formularios HTTP o URL GET HTTP . Además, muchas aplicaciones necesitan codificar datos binarios de una manera que sea conveniente para su inclusión en URL, incluso en campos de formularios web ocultos, y Base64 es una codificación conveniente para representarlos de una manera compacta.
El uso de Base64 estándar en una URL requiere la codificación de los caracteres ' +', ' /' y ' =' en secuencias hexadecimales especiales codificadas en porcentaje (' +' se convierte en ' %2B', ' /' se convierte en ' %2F' y ' =' se convierte en ' %3D'), lo que hace que la cadena sea innecesariamente más larga.
Por esta razón, existen variantes modificadas de Base64 para URL (como base64url en RFC 4648), donde los caracteres ' ' y ' ' del Base64 estándar se reemplazan respectivamente por ' ' y ' ', de modo que el uso de codificadores/descodificadores de URL ya no es necesario 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 para hacer 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 dicho relleno esté codificado en porcentaje. Algunas bibliotecas [ which? ] codificarán ' ' a ' ', lo que potencialmente expondrá las aplicaciones a ataques de ruta relativa cuando se codifique un nombre de carpeta a partir de datos de usuario. [ cita requerida ]+/-_==.
Los métodos atob()y btoa()JavaScript, definidos en la especificación preliminar de HTML5 [14] , 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.
Base64 se puede utilizar en una variedad de contextos:
<data encoding="base64">…</data>de los faviconos exportados de Firefoxbookmarks.html .data:URI, en lugar de proporcionarse en archivos separados.Algunas aplicaciones utilizan un alfabeto Base64 que es significativamente diferente de los alfabetos utilizados en las variantes Base64 más comunes (consulte la tabla de resumen de variantes más arriba).
no incluye caracteres en minúscula, sino que utiliza códigos ASCII del 32 (" " (espacio)) al 95 (" _"), de forma consecutiva. Uuencoding utiliza el alfabeto " !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_" . Evitar todas las letras en minúscula fue útil, porque muchas impresoras antiguas solo imprimían mayúsculas. El uso de caracteres ASCII consecutivos ahorró potencia de procesamiento, porque solo fue necesario sumar 32, sin necesidad de una tabla de búsqueda. Su uso de la mayoría de los caracteres de puntuación y el carácter de espacio puede limitar su utilidad en algunas aplicaciones, como las que utilizan estos caracteres como sintaxis. [ cita requerida ]7', 'O', 'g' y 'o'. Su alfabeto incluye caracteres de puntuación adicionales. Utiliza el alfabeto " !"#$%&'()*+,-012345689@ABCDEFGHIJKLMNPQRSTUVXYZ[`abcdefhijklmpqr" .0b10xxxxxx/etc/passwdarchivo utilizando una codificación llamada B64 . El alfabeto de crypt coloca la puntuación .y /antes de los caracteres alfanuméricos. crypt utiliza el alfabeto " ./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz" sin relleno. Una ventaja sobre RFC 4648 es que la clasificación de datos ASCII codificados da como resultado el mismo orden que la clasificación de datos ASCII simples../0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz" . [18]./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789" . [19]+and"-en lugar de."and/. Xxencoding utiliza el alfabeto " +-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz" .0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ@_" . [21]JPEG contents encoded in Base64" ... />De lo contrario, los números toman la forma [base#]n, donde la base opcional es un número decimal entre 2 y 64 que representa la base aritmética, y n es un número en esa base.