En programación de computadoras , Base64 es un grupo de esquemas de codificación de binario a texto que transforma 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 6 bits a la vez, luego este grupo de 6 bits se asigna a uno de los 64 caracteres únicos.
Como ocurre con 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 de manera confiable contenido de texto. Base64 es particularmente frecuente en la World Wide Web [1] , donde uno de sus usos es la capacidad de incrustar archivos de imágenes u otros activos binarios dentro de activos textuales como archivos HTML y CSS . [2]
Base64 también se utiliza ampliamente para enviar archivos adjuntos de correo electrónico , porque SMTP (en su forma original) fue diseñado para transportar caracteres ASCII de 7 bits únicamente. Codificar un archivo adjunto como Base64 antes de enviarlo y luego decodificarlo cuando se recibe garantiza que los servidores SMTP más antiguos no interfieran con el archivo adjunto.
La codificación Base64 provoca 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 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 sea poco probable que los datos se modifiquen 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 utiliza – 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 .
Las primeras instancias 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 (luego adaptado para Macintosh )) y, por lo tanto, podrí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 RFC 4648 §4. Véase también Resumen de variantes (abajo).
El siguiente ejemplo utiliza texto ASCII para simplificar, pero este no es un caso de uso típico, ya que ya se puede transferir de forma segura entre 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 pueden transferirse de manera confiable entre sistemas que pueden dañar los bytes de origen sin procesar.
A continuación se muestra un modismo muy conocido de la informática distribuida :
Muchas manos hacen trabajo liviano.
Cuando la cita (sin espacios en blanco al final) se codifica en Base64, se representa como una secuencia de bytes de caracteres ASCII rellenos 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 estar ignorado en 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 valores de bytes 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 correspondientes valores de caracteres Base64.
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. Esta 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 producir 19 22 05 46 . Usando esos cuatro números decimales como índices para el alfabeto Base64, los caracteres ASCII correspondientes son TWFu .
Si sólo hay dos octetos de entrada significativos (por ejemplo, 'Ma'), o cuando el último grupo de entrada contiene sólo 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 sólo hay un octeto de entrada significativo (por ejemplo, 'M'), o cuando el último grupo de entrada contiene sólo un octeto, los 8 bits se capturarán en los dos primeros 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 plano hasta base64. [7]
Debido a que Base64 es una codificación de seis bits y debido 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) representa tres octetos de texto o datos no codificados ( 3 octetos = 3 × 8 = 24 bits). Esto significa que cuando la longitud de la entrada no codificada no es múltiplo de tres, se debe agregar relleno a la salida codificada para que su longitud sea múltiplo de cuatro. El carácter de relleno es =, lo que indica que no se necesitan más bits para codificar completamente la entrada. (Esto es diferente de A, lo 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 salida:
El carácter de relleno no es esencial para la decodificación, ya que el número de bytes faltantes se puede inferir 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 cuatro caracteres se vuelven a convertir 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 ==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 apariciones 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 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), 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, sólo pueden quedar dos o tres personajes. No es posible dejar un solo carácter codificado restante, porque un solo carácter Base64 solo contiene 6 bits y se requieren 8 bits para crear un byte, por lo que se requieren un mínimo de dos caracteres Base64: el primer carácter contribuye con 6 bits y el segundo carácter. aporta sus primeros 2 bits. Por ejemplo:
La decodificación sin relleno no se realiza de manera consistente entre los decodificadores. Además, permitir la decodificación sin almohadilla por definición permite decodificar varias cadenas en el mismo conjunto de bytes, lo que puede suponer un riesgo para la 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 enlaces 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 pueda 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 ( – , – ), números ( – ) y símbolos y . El símbolo también se utiliza como sufijo de relleno. [4] La especificación original, RFC 989, utilizó adicionalmente 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 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 se utiliza el búfer, 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 cero bits para formar un múltiplo integral de seis bits.
Después de codificar los datos no rellenados, si dos octetos del búfer de 24 bits se rellenan con ceros, =se añaden dos caracteres a la salida; si un octeto del búfer de 24 bits se rellena con ceros, =se añade un carácter. Esto indica al decodificador que los bits cero agregados debido al relleno deben excluirse de los datos reconstruidos. Esto también garantiza que la longitud de salida codificada sea 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 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 (Extensiones multipropósito de correo de Internet) enumera Base64 como uno de los dos esquemas de codificación de binario a texto (el otro es imprimible con comillas ). [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 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 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 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 los encabezados. De manera muy aproximada, 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_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" consta del alfabeto MIME Base64, 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 "imprimible entre comillas". Base64 modificado simplemente omite el relleno y termina inmediatamente después del último dígito de Base64 que contiene bits útiles, dejando hasta tres bits no utilizados en el último dígito de Base64.=
OpenPGP , descrito en RFC 4880, describe la codificación Radix-64 , también conocida como " armadura ASCII ". Radix-64 es idéntico a la codificación "Base64" descrita por MIME, con la adición de un CRC de 24 bits opcional . 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, con el prefijo " " como separador, se agrega a los datos de salida codificados. [12]=
RFC 3548, titulado Codificaciones de datos Base16, Base32 y Base64 , es un memorando informativo (no normativo) que intenta unificar las especificaciones RFC 1421 y RFC 2045 de codificaciones Base64, codificaciones de alfabeto alternativo y Base32 (que rara vez se utiliza). utilizados) y codificaciones Base16.
A menos que las implementaciones estén escritas 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 de la codificación. alfabeto. [6]
Este RFC deja obsoleto el RFC 3548 y se centra en Base64/32/16:
La codificación Base64 puede resultar ú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 usar codificación Base64 para codificar una identificación única relativamente grande (generalmente UUID de 128 bits ) en una cadena para usar 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 ocultos de formularios web, y Base64 es una codificación conveniente para representarlos de manera compacta.
El uso de Base64 estándar en URL requiere la codificación de los caracteres ' +', ' /' y ' ' en secuencias hexadecimales especiales codificadas por porcentaje (' ' se convierte en ' ', ' ' se convierte en ' ' y ' ' se convierte en ' '), lo que hace que la cadena sea innecesariamente más larga .=+%2B/%2F=%3D
Por esta razón, existe Base64 modificado para variantes de URL (como base64url en RFC 4648), donde los caracteres ' ' y ' ' de Base64 estándar se reemplazan respectivamente por ' ' y ' ', de modo que ya no es necesario usar codificadores/decodificadores de URL. necesario y no tiene ningún efecto sobre la longitud del valor codificado, dejando intacto el mismo formulario codificado para su uso en bases de datos relacionales, formularios web e identificadores de objetos en general. Un sitio popular para utilizarlos 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 [ ¿cuáles? ] codificará de ' ' a ' ', exponiendo potencialmente las aplicaciones a ataques de ruta relativa cuando el nombre de una carpeta se codifica a partir de datos de usuario. [ cita necesaria ]+/-_==.
Los métodos JavaScript atob()y btoa(), definidos en el borrador de la especificación HTML5, [14] proporcionan funcionalidad de codificación y decodificación Base64 a 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>por ejemplo, los favicons en los archivosbookmarks.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 de Base64 más comunes (consulte la tabla de resumen de variantes más arriba).
" (espacio)) al 95 (" _"), consecutivamente. Uuencoding utiliza el alfabeto " !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_" . Evitar todas las letras minúsculas fue útil, porque muchas impresoras antiguas solo imprimían mayúsculas. El uso de caracteres ASCII consecutivos ahorró potencia de cálculo, porque sólo era 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 aquellas que utilizan estos caracteres como sintaxis. [ cita necesaria ]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 pone la puntuación .y /antes de los caracteres alfanuméricos. La cripta utiliza el alfabeto " ./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz". No se utiliza relleno../0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz" . [17]./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789" . [18]+y-en lugar de.y/. Xxencoding usa el alfabeto " +-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz" .0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ@_" . [20]Un problema con el alfabeto RFC 4648 es que, cuando una lista ordenada de cadenas codificadas en ASCII se transforma en Base64 y se ordena nuevamente, el orden de los elementos cambia. Esto se debe a que el carácter de relleno y los caracteres del alfabeto de sustitución no están ordenados por el valor del carácter ASCII (que se puede ver usando los botones de clasificación de la siguiente tabla de ejemplo). Alfabetos como B64 (sin relleno) abordan esto.
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.