Base64
De Wikipedia, la enciclopedia libre
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.
Tabla de contenidos |
[editar] Esquemas de codificación en Base 64
[editar] 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 (o en total), 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.
[editar] 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.
[editar] 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).
[editar] 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.
[editar] 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.
[editar] 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.
[editar] 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.
[editar] 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).
[editar] 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 <data encoding="base64">......</data>. Por ejemplo, los marcadores de Firefox almacenados en bookmarks.html.
[editar] Véase también
[editar] Enlaces externos
- RFC 989 (Privacy Enhancement for Electronic Internet Mail) (obsoleto)
- RFC 1421 (Privacy Enhancement for Electronic Internet Mail)
- RFC 2045 (Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies)
- RFC 3548 (The Base16, Base32, and Base64 Data Encodings)
- RFC 4648 (The Base16, Base32, and Base64 Data Encodings)
- Codificador de Radix64 en JavaScript
