Base64

De El Museo de los 8 Bits
Ir a la navegación Ir a la búsqueda

Base 64 es un sistema de numeración posicional que usa 64 como base. Es la mayor potencia de dos que puede ser representada usando únicamente los caracteres imprimibles de ASCII. Esto ha propiciado su uso para codificación de correos electrónicos, PGP y otras aplicaciones. Todas las variantes famosas que se conocen con el nombre de Base64 usan el rango de caracteres A-Z, a-z y 0-9 en este orden para los primeros 62 dígitos, pero los símbolos escogidos para los últimos dos dígitos varían considerablemente de unas a otras. Otros métodos de codificación como UUEncode y las últimas versiones de binhex usan un conjunto diferente de 64 caracteres para representar 6 dígitos binarios, pero éstos nunca son llamados Base64.


Esquemas de codificación en Base 64

Protocolo Privacy-Enhanced Electronic Mail (PEM)

La primera aplicación conocida de la codificación Base 64 para transmisiones electrónicas de datos fue el protocolo Privacy-enhanced Electronic Mail (PEM), propuesto por el RFC 989 en 1987. PEM define un esquema de caracteres imprimibles que usa Base 64 para transformar una secuenca arbitraria de octetos en un formato que puede ser expresado en líneas cortas de caracteres de 7 bits, tales como las necesarias en protocolos de transmisión como SMTP.

La versión actual de PEM (especificada en el RFC 1421) usa un alfabeto de 64 caracteres consistente en los caracteres en mayúscula y minúscula del alfabeto latino (A-Z, a-z), los numerales (0-9) y los símbolos '+' y '/'. El símbolo '=' se usa como un sufijo especial. La especificación original (RFC 989) usa además el carácter '*' para delimitar la parte codificada pero no cifrada del flujo de salida.

Para transformar datos en una codificación PEM imprimible, el primer byte se sitúa en los 8 bits más significativos de un búfer de 24 bits, el siguiente en los 8 de en medio y el tercero en los de menor peso. Si hay menos de 3 bytes por codificar, el resto del búfer se rellena con ceros. En este punto, el búfer se usa de forma que se van extrayendo 6 bits desde la parte más significativa para ser usados como índice dentro de la cadena: "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/", de forma que el carácter indicado será la salida.

Este proceso se repite con los datos restantes hasta que queden menos de cuatro octetos. Si quedan tres, se procesan de forma normal, mientras que si quedan menos de 3 bytes (24 bits), la entrada se rellenará con ceros por la derecha para formar un múltiplo de 6 bits.

Después de codificar los datos, si en el paso anterior quedaban 2 octetos por codificar, entonces se añade el carácter '=' al final de la salida; si solo quedaba un octeto, se concatenarán dos caracteres '='. Esto avisa al descodificador de que los bits a 0 que se hayan añadido de relleno no deben formar parte de los datos reconstruídos.

PEM necesita que todas las líneas codificadas estén formadas exactamente por 64 caracteres imprimibles, con la excepción de la última, que puede contener menos. Las líneas estarán delimitadas por caracteres de espacio en blanco de acuerdo con las convenciones específicas de la plataforma.

MIME

La especificación MIME (Multipurpouse Internet Mail Extensions) definida en el RFC 2045, describe base64 como uno de los sistemas de codificación de binario a texto. El base64 de MIME se basa en la versión de PEM que se describe en el RFC 1421: usa el mismo alfabeto de 64 caracteres y el mismo mecanismo de codificación, al igual que usa el símbolo '=' para señalar el relleno final.

MIME no especifica un tamaño fijo para las líneas codificadas en base64, pero sí precisa un tamaño máximo de 76 caracteres. Además, concreta que cualquier carácter que no pertenezca al alfabeto deberá ser ignorado por los descodificadores, aunque muchas implementaciones usan los caracteres CR/LF (retorno de carro y salto de línea) para delimitar las líneas codificadas. De esta manera, el tamaño real de los datos codificados conforme a MIME suele ser de un 140% del tamaño original.

UTF-7

UTF-7, descrito en el RFC 2152, introdujo un sistema llamado Modified Base64 (Base64 Modificado). Este esquema de codificación se usa para codificar UTF-16 como caracteres ASCII para ser usados en transmisiones de 7 bits como en SMTP. Es una variante del base64 usado en MIME.

El alfabeto de Base64 Modificado consiste en el alfabeto de base64 usado en MIME, pero no usa el carácter '='. UTF-7 se pretendió usar para las cabeceras de los correos (definido en RFC 2047), y el carácter '=' se reserva en este contexto como carácter de escape para codificación Quoted-Printable. Base 64 Modificado simplemente omite el relleno y termina inmediatamente tras el último dígito BASE64 que contiene bits útiles (dejando los 0-4 bits no usados del último dígito base64).

OpenPGP

OpenPGP, descrito en el RFC 2440, usa la codificación Radix-64, también conocida como ASCII Armor. Radix-64 es idéntico a base64 de MIME, salvo en que añade una suma de verificación CRC de 24 bits. Esta suma se calcula sobre los datos de entrada, antes de codificar, y posteriormente se codifica con el mismo base64 para ser concatenada a la codificación resultante.

IRCu

En el protocolo P10 de servidor-servidor usado por el demonio IRC IRCu y software compatible, se usa una versión de Base 64 para codificar los datos numéricos de cliente/servidor y de las direcciones IP binarias. Estos datos numéricos de la comunicación entre el cliente y el servidor tienen tamaños fijos, con un número exacto de dígitos base64, por lo que no se necesita rellenar. Las direcciones IP binarias tienen bits a 0 por el comienzo para hacerlas encajar. El símbolo usado es algo diferente al usado en el alfabeto de MIME, utilizando "[]" en lugar de "+/" para evitar conflictos con otras partes del protocolo que usan el carácter '+' internamente como indicador de establecimiento de modos.

RFC 3548

RFC 3548 (Las codificaciones Base16, Base32 y Base64) es un documento informal (no-normativo) que trata de unificar las especificaciones RFC 1421 y RFC 2045 de base64, codificaciones con alfabetos alternativos y las codificaciones raramente usadas Base32 y Base16.

RFC 3548 prohíbe a las implementaciones añadir caracteres no alfabéticos y establece que los descodificadores deben rechazar datos que contengan caracteres no alfabéticos; todo esto si no están contemplados en una especificación que se refiera a ésta o que, en todo caso, la requiera.

RFC 4648

Este RFC hace obsoleto al RFC 3548 y se refiere al mismo tema:

Este documento describe las codificaciones base 64, base 32 y base 16 usadas comúnmente y trata cuestiones como el uso de saltos de línea, rellenos, uso de caracteres no alfabéticos en los datos codificados y la utilización de otros alfabetos y codificaciones canónicas.

Ejemplo

Una cita de Thomas Hobbes perteneciente a la obra Leviathan:

Man is distinguished, not only by his reason, but by this singular passion from other animals, which is a lust of the mind, that by a perseverance of delight in the continued and indefatigable generation of knowledge, exceeds the short vehemence of any carnal pleasure.

se codifica en base64 como sigue:

TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZWFzb24sIGJ1dCBieSB0aGlz
IHNpbmd1bGFyIHBhc3Npb24gZnJvbSBvdGhlciBhbmltYWxzLCB3aGljaCBpcyBhIGx1c3Qgb2Yg
dGhlIG1pbmQsIHRoYXQgYnkgYSBwZXJzZXZlcmFuY2Ugb2YgZGVsaWdodCBpbiB0aGUgY29udGlu
dWVkIGFuZCBpbmRlZmF0aWdhYmxlIGdlbmVyYXRpb24gb2Yga25vd2xlZGdlLCBleGNlZWRzIHRo
ZSBzaG9ydCB2ZWhlbWVuY2Ugb2YgYW55IGNhcm5hbCBwbGVhc3VyZS4=

En la cita de arriba el valor codificado de Man es TWFu. Codificadas en ASCII, las letras: M, a y n son almacenadas como los bytes 77, 97 y 110, es decir, 01001101, 01100001, 01101110 en base 2.

Ahora esos tres bytes se unen y tenemos el búfer de 24 bits, que será 010011010110000101101110. Este número se convertirá a su valor Base 64, que puede hacerse tomando bloques de 6 bits a la vez (6 bits forman como máximo 64 valores diferentes en binario: 26). A continuación, cogiendo cada vez 6 bits del búfer, tenemos 4 números (24 = 6 x 4), que entonces son convertidos a su correspondiente valor en Base 64.

Texto de entrada M a n
ASCII 77 97 110
Bits 0 1 0 0 1 1 0 1 0 1 1 0 0 0 0 1 0 1 1 0 1 1 1 0
Índice 19 22 5 46
Resultado en Base64 T W F u

Por tanto, 3 bytes sin codificar (en este caso, caracteres ASCII) entran y 4 caracteres ASCII codificados surgen como resultado.

Ilustración del marcado de relleno conforme acortamos la entrada:

La entrada termina con carnal pleasure.  La salida termina con: c3VyZS4=
La entrada termina con carnal pleasure   La salida termina con: c3VyZQ==
La entrada termina con carnal pleasur    La salida termina con: c3Vy
La entrada termina con carnal pleasu     La salida termina con: c3U=

Aplicaciones en URL

La codificación Base64 puede ser útil cuando el tamaño de la información de identificación usada en un entorno HTTP es bastante grande. El framework de base de datos para objetos persistentes llamado Hibernate para el lenguaje de programación Java usa Base64 para codificar una ID única relativamente grande (generalmente UUIDs de 128 bits) dentro de una cadena de texto para ser usada como parámetro HTTP en los formularios o en el modo de transmisión GET. También, gran cantidad de aplicaciones necesitan codificar datos binarios de forma que puedan ser introducidos en las URL, así como en los campos ocultos de los formularios. Base64 resulta adecuado para estos propósitos ya que además de transformarlos en una cadena compacta, oculta la naturaleza de los datos ante posibles observadores.

El uso de un codificador de URL sobre Base64 estándar, sin embargo, no resulta adecuado ya que traducirá los caracteres '+' y '/' en las secuencias especiales en hexadecimal %XX ('+' = '%2B' y '/' = '%2F'). Si posteriormente se usa para almacenamiento en base de datos o entre sistemas heterogéneos, producirán un conflicto en el carácter '%' generado por el codificador de URL (debido a que este carácter es usado en ANSI SQL como comodín).

Por esta razón existe un Base64 Modificado para URL, donde no se usa el carácter '=' de marcado de relleno, y los caracteres '+' y '/' del Base64 estándar son sustituidos por '*' y '-' respectivamente, de manera que ya no se necesita usar codificadores de URL. Además, no tiene impacto en el tamaño de la codificación, dejándola intacta para uso en base de datos relacionales, formularios web e identificadores de objetos en general.

Otra variante, llamada Base64 Modificado para expresiones regulares, usa "!-" en lugar de "*-" para sustituir el "+/" del Base64 estándar, debido a que, tanto '+' como '*' son caracteres reservados para las expresiones regulares (cabe resaltar que el "[]" usado en la variante IRCu explicada arriba no funcionará en este contexto).

También hay otras variantes que usan "_-" o "._" cuando la cadena codificada va a ser usada como identificador válido para programas, o ".-" cuando se usa para los tokens de XML (Nmtoken), o incluso "_:" para ser usada en un los identificadores más restrictivos de XML (Name).

Otras aplicaciones

Base64 se usa también para otras aplicaciones, como:

  • Thunderbird y Evolution usan Base64 para ofuscar las contraseñas de correo electrónico.
  • Ofuscación insegura pero rápida de información privada sin la necesidad de la gestión de claves de la criptografía.
  • Los spammers usan Base64 para evitar algunas protecciones anti-spam, que no suelen descodificar Base64 y, por tanto, no pueden detectar palabras prohibidas en los mensajes codificados.
  • Codificación de cadenas de caracteres en archivos LDIF.
  • Incorporación de datos binarios en archivos XML, usando una sintaxis similar a ....... Por ejemplo, los marcadores de Firefox almacenados en bookmarks.html.

Un ejemplo programático

A continuación se muestra un ejemplo de como codificar y decodificar un texto usando Base64. El ejemplo que se muestra está escrito en el lenguaje de programación Python


>>> import base64
>>> texto = "Prueba de codificación BASE64!"
>>> textoCodificado = base64.encodestring(texto)
>>> textoCodificado
'UHJ1ZWJhIGRlIGNvZGlmaWNhY2nDs24gQkFTRTY0IQ==\n'
>>> base64.decodestring(textoCodificado)
'Prueba de codificación BASE64!'

Véase también

Enlaces externos

Atribución

Este artículo proviene originalmente de Wikipedia
que lo licencia simultáneamente bajo las licencias

Creative Commons Reconocimiento - CompartirIgual 3.0
y la licencia de documentación libre GNU v.1.2 y posteriores
El Museo de los 8 Bits lo integra en su wiki bajo cc-by-sa-3.0

Creative Commons License
GNU head