El Base64 es una codificación de la transferencia del contenido del MIME base-64 que utiliza los carácteres A– Z, a– z, y 0– 9 en esa orden para los primeros 62 dígitos. Los símbolos elegidos para los dos dígitos pasados varían considerablemente entre diversos sistemas. Varios otros métodos de codificación tales como uuencode y versiones posteriores de Binhex utilizan un diverso sistema de 64 carácteres para representar 6 dígitos binarios, pero éstos nunca son llamados por el nombre Base64.

Esquemas de codificación de la base 64

Privacy Enhanced Mail (PEM)

El uso primero sabido de la codificación de la base 64 para la transferencia de datos electrónicos era el protocolo Aislamiento-realzado del correo electrónico (PEM), propuesto por RFC 989 en el 1987 . El PEM define un " encoding" imprimible; proyectar que las aplicaciones basan la codificación 64 para transformar una secuencia arbitraria de los octetos a un formato que se pueda expresar en las líneas cortas de 7 carácteres del pedacito, según los requisitos de protocolos de la transferencia tales como smtp .

La versión actual del PEM (especificado en RFC 1421) utiliza consistir en el alfabeto de 64 carácteres superior y los carácteres del alfabeto romano de la minúscula (A– Z, a– z), los números (0– 9), y el " +" y " /" símbolos. El " =" el símbolo también se utiliza como código especial del sufijo. La especificación original, RFC 989, utilizó además el " *" símbolo para delimitar datos codificados pero unencrypted dentro de la corriente de salida.

Para convertir datos a la codificación imprimible del PEM, el primer octeto se pone en el la mayoría de los pedacitos significativos de ocho de 24 almacenadores intermediarios del pedacito, el siguiente en los ocho medios, y el tercero en el menos pedacitos significativos de ocho. Si hay menos de tres octetos dejados para codificar (o en total), los pedacitos restantes del almacenador intermediario serán cero. El almacenador intermediario entonces se utiliza, seis pedacitos a la vez, el primer más significativo, como índices en la secuencia: " ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/" se hace salir , y el carácter indicado.

El proceso se repite en los datos restantes hasta que siga habiendo menos de cuatro octetos. Si sigue habiendo tres octetos, los procesan normalmente. Si menos de tres octetos (24 pedacitos) son restantes codificar, los datos de entrada derecho-se rellenan con los pedacitos cero para formar un múltiplo integral de seis pedacitos.

Después de la codificación datos rellenados, si dos octetos eran restantes codificar, un " =" el carácter se añade a la salida; si un octeto era restante, el " dos; =" se añaden los carácteres. Esto señala el decodificador que los pedacitos cero agregaron debido al acolchado se deben excluir de los datos reconstruidos. Esto también garantiza que la longitud codificada de la salida es un múltiplo de 4 octetos.

El PEM requiere que todas las líneas codificadas consistan en exactamente 64 carácteres imprimibles, a excepción de la línea pasada, que puede contener pocos carácteres imprimibles. Las líneas son delimitadas por los carácteres del whitespace según convenciones (platform-specific) locales.

MIME

La especificación del MIME (Multipurpose Internet Mail Extension), definida en RFC 2045, enumera el " base64" como uno de varios la codificación del Binario-a-texto proyecta. La codificación de base64 del MIME se basa en la de la versión 1421 del RFC del PEM: utiliza el mismo mecanismo del alfabeto y de la codificación de 64 carácteres que el PEM, y utiliza el " =" símbolo para el acolchado de la salida de la misma manera.

El MIME no especifica una longitud fija para las líneas de base64-encoded, sino que especifica una longitud máxima de 76 carácteres. Especifica además que cualquier carácter adicional-alfabético se debe no hacer caso por un decodificador obediente, aunque la mayoría de las puestas en práctica utilicen un par del Newline de CR/LF para delimitar líneas codificadas.

Así, la longitud real de los datos binarios MIME-obedientes de base64-encoded es generalmente cerca de 137% de la longitud de datos original, aunque para los mensajes muy cortos que los gastos indirectos pueden ser mucho más altos debido a los gastos indirectos de los jefes. Muy áspero, el tamaño final de los datos binarios de base64-encoded es igual a 1.37 veces el tamaño original de los datos + 814 octetos (para los jefes).

UTF-7

El UTF-7, descrito en RFC 2152, introdujo un sistema llamado Base64 modificado . Este esquema de la codificación de los datos se utiliza para codificar el UTF-16 como carácteres ASCII para el uso en 7 transportes del pedacito tales como smtp . Es una variante de la codificación base64 usada en el MIME.

El " Base64" modificado; el alfabeto consiste en el alfabeto del MIME base64, pero no utiliza el " =" carácter de relleno. UTF-7 se piensa para el uso en los jefes de correo (definidos en RFC 2047), y el " =" el carácter se reserva en ese contexto como el carácter de escape para el " cotizado-printable" codificación. Base64 modificado omite simplemente el acolchado y los extremos inmediatamente después del dígito pasado BASE64 que contiene los pedacitos útiles (que dejan 0-4 pedacitos inusitados en el dígito pasado base64)

OpenPGP

OpenPGP, descrito en RFC 2440, describe la codificación Radix-64, también conocida como " ASCII Armor". Radix-64 es idéntico al " base64" codificación descrita del MIME, con la adición de 24 sumas de comprobación del CRC del pedacito. La suma de comprobación se calcula en los datos de entrada antes de codificar; la suma de comprobación entonces se codifica con el mismo algoritmo base64 y, usar un " adicional; =" símbolo como separador, concatenado a los datos de salida codificados.

RFC 3548

El RFC 3548 (las codificaciones de los datos Base16, Base32, y Base64) es una nota (non-normative) informativa que intenta unificar las especificaciones del RFC 1421 y del RFC 2045 de las codificaciones base64, de las codificaciones del alternativa-alfabeto, y de las codificaciones raramente-usadas de la base 32 y de la base 16.

El RFC 3548 prohíbe puestas en práctica de agregar carácteres no alfabéticos a menos que se escriban a una especificación que refiera a RFC 3548 y lo requiera específicamente de otra manera; también declara que las puestas en práctica del decodificador deben rechazar los datos que contienen carácteres no alfabéticos a menos que se escriban a una especificación que refiera a RFC 3548 y lo requiera específicamente de otra manera.

RFC 4648

Este RFC 3548 de los obsoletes del RFC y focos en la base 64/32/16: el

l este documento describe la base de uso general 64, base 32, y basa 16 esquemas de codificación. También discute el uso de avances de línea en datos codificados, el uso del relleno en datos codificados, el uso de los carácteres del no-alfabeto en datos codificados, el uso de diversos alfabetos de la codificación, y codificaciones canónicas.

Ejemplo

Una cotización Leviathan del de de Thomas Hobbes: el hombre del

l es distinguido, no sólo por su razón, pero por esta pasión singular de otros animales, que es una lujuria de la mente, que por una perseverencia del placer en la generación continua e infatigable de conocimiento, excede la vehemencia corta de cualquier placer carnal.

se codifica en el esquema de base64 del MIME como sigue:

TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZWFzb24sIGJ1dCBieSB0aGlz IHNpbmd1bGFyIHBhc3Npb24gZnJvbSBvdGhlciBhbmltYWxzLCB3aGljaCBpcyBhIGx1c3Qgb2Yg dGhlIG1pbmQsIHRoYXQgYnkgYSBwZXJzZXZlcmFuY2Ugb2YgZGVsaWdodCBpbiB0aGUgY29udGlu dWVkIGFuZCBpbmRlZmF0aWdhYmxlIGdlbmVyYXRpb24gb2Yga25vd2xlZGdlLCBleGNlZWRzIHRo ZSBzaG9ydCB2ZWhlbWVuY2Ugb2YgYW55IGNhcm5hbCBwbGVhc3VyZS4=

En la cotización antedicha el valor codificado del hombre del es TWFu . Codificado en el ASCII, M, un, n se almacena como los octetos 77, 97, 110, que son 01001101, 01100001, 01101110 en la base 2. Estos tres octetos se ensamblan juntos en 24 almacenadores intermediarios del pedacito produciendo 010011010110000101101110. Los paquetes de 6 pedacitos (6 pedacitos tienen un máximo de 64 diversos valores binarios) se convierten en 4 números (24 = 6x4) que entonces se conviertan a sus valores correspondientes en la base 64.

Puesta en práctica

(MIME) los procesos tradicionales de la codificación base64 y el descifrar son bastante simples ejecutar. Aquí un ejemplo usar Javascript se da, incluyendo la línea requerida MIME/etc roturas en la línea longitudes particular. Vale el observar sin embargo, ese muchas secuencias codificadas de vuelta de las funciones base64 (e. en PHP ) base64 sin la línea se rompen, pues la línea roturas puede ser insertada fácilmente después de codificar, y muchas veces la codificación base64 se desea solamente para los datos con seguridad de transferencia vía el XML o inserción en una base de datos, &mdash del etc.; épocas en que la línea roturas se sabe para ser innecesaria y por lo tanto undesirable. El newline que inserta y que quita en estas funciones aquí puede ser comentado fácilmente hacia fuera (son cada uno solamente una línea en las funciones respectivas) si no son necesaria.

Un arsenal de los carácteres de la base 64 es necesario para la codificación, por ejemplo: lang=" del var base64chars = “ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/” .split (" "); Y el descifrar requerirá la lista inversa (intercambiar los índices por los valores), por ejemplo: lang=" del var base64inv = {}; para (var i = 0; i < base64chars.length; i++) {base64inv] = i; }

Observar que en puestas en práctica verdaderas, es mejor enumerar explícitamente el arsenal/el picadillo enteros para cada lista sobre — los chistes aquí se dan para demostrar el concepto tan directo como sea posible, algo que siendo el ideal en la práctica.

La función de la codificación base64: lang=" del función base64_encode (s) { // el resultado/la secuencia cifrada, la secuencia del acolchado, y la cuenta del cojín var r = " " ; var p = " " ; var c = s.length % 3; // agrega un cojín cero derecho para hacer esta secuencia un múltiplo de 3 carácteres si (c > 0) {para (; c < 3; c++) {p += “=”; " de s +=; \ 0" ; }} incremento sobre la longitud de la secuencia, tres carácteres de // a la vez para (c = 0; c < s.length; c += 3) { // agregamos newlines después de cada 76 carácteres hechos salir, según espec. del MIME si (c > 0 && (c/3 * 4) % 76 del == 0) {" de r+=; \ r \ n" ; } // estos tres carácteres de 8 bits (ASCII) se convierte en un 24 números de pedacito var n = (s.charCodeAt (c) << 16) + (s.charCodeAt (c+1) << 8) + s.charCodeAt (c+2); // que este 24 números de pedacito consiguen separados en cuatro 6 números de pedacito n = >>> 18) y 63, (>>> 12 de n) y 63, (>>> de n 6) y 63, n y 63; // esos cuatro 6 números de pedacito se utiliza como índices en la lista del carácter base64 r+= base64chars] + base64chars] + base64chars] + base64chars]; // agrega la secuencia real del acolchado, después de quitar el cojín cero } r.substring de vuelta (0, r.length) + p; }

La función el descifrar base64: lang=" del función base64_decode (s) { // substituye cualquier acolchado entrante por un cojín cero (el carácter de “A” es cero) ¿var p = == (de s.length-1) “=”? == (de s.length-2) “=” ¿? “AA”: “A "): " "); var r = " " ; s = s.length) + p; // quita/no hace caso de cualquier carácter no en la lista de los carácteres base64 -- particularmente newlines s = s.replace (nuevo RegExp ('', “g "), " "); incremento sobre la longitud de esta secuencia cifrada, cuatro carácteres de // a la vez para (var c = 0; c < s.length; c += 4) { // cada uno de estos cuatro carácteres representa un índice de 6 pedacitos en la lista de los carácteres base64 // que, cuando está concatenada, darán los 24 números de pedacito para los carácteres de la original 3 var n = (base64inv << 18) + base64inv + (base64inv << 12) + (base64inv << 6); // partió los 24 números de pedacito en los tres carácteres de 8 bits originales (ASCII) r+= String.fromCharCode ((>>> 16 de n) y 255, (>>> de n 8) y 255, n y 255); // quita cualquier cojín cero que fuera agregado para hacer esto un múltiplo de 24 pedacitos } r.substring de vuelta (0, r.length); } La puesta en práctica antedicha es la mejor con una lengua como el Javascript que maneja el encadenamiento de la secuencia de las secuencias arbitrarias de la longitud muy eficientemente. C) trabajará mucho más eficientemente asignando la memoria para una nuevos secuencia/arsenal del tamaño apropiado (la longitud de la secuencia de la salida se calcula fácilmente de la secuencia de la entrada al principio) y después simplemente fijando cada índice del carácter, en comparación con el encadenamiento.

Herramientas en línea

Hay una variedad de herramientas en línea Base64 por ejemplo:
Descifrar el texto codificado Base64
Decodificador Base64
Codificador Base64 y decodificador en línea
Texto y archivos en línea que descifran y de codificaciones
Base64 en línea codifican/descifran
Herramienta transferible de la fuente abierta para codificar o para descifrar Base64 encendido [[Unix] o el Win32] * StUU - Open Source UUDecoder rápido para Macintosh por el Estuardo Cheshire

Usos del URL

La codificación Base64 puede ser provechosa cuando la información de identificación bastante muy larga se utiliza en un ambiente del HTTP. El Hibernate, un marco de la persistencia de la base de datos para el Java se opone, utiliza la codificación Base64 para codificar una identificación única relativamente grande (el UUIDs de generalmente 128 pedacitos en una secuencia para que el uso como un parámetro del HTTP en formas del HTTP o el HTTP CONSIGUE los URL también, la necesidad de muchos usos codifiquen datos binarios de una manera que sea conveniente para la inclusión en URL, incluyendo en campos ocultados de la forma de la tela, y Base64 es una codificación conveniente para rendirlos no sólo de una manera compacta, pero en relativamente ilegible al intentar obscurecer la naturaleza de datos de un observador humano ocasional.

Usar un URL-codificador en Base64 estándar, sin embargo, es incómodo pues traducirá “+” y “/” los carácteres a secuencias hexadecimales por ciento-codificadas especial de (“+” = “%2B” y “/” = “%2F "). Cuando esto se utiliza más adelante con almacenaje de la base de datos o a través de sistemas heterogéneos, ellos mismos estrangularán en “los %” del carácter generado por los URL-codificadores (porque “el %” del carácter también se utiliza en ANSI SQL como comodín).

Por esta razón, un Base64 modificado para la variante del URL existe, donde el ningún acolchado de “=” será utilizado, y “+” y “/” los carácteres de Base64 estándar se substituye respectivamente por “*” y “-”, de modo que usar codificadores/los decodificadores del URL sea no más necesario y no tenga ningún impacto en la longitud del valor codificado, dejando la misma forma codificada intactos para el uso en bases de datis relacionales, formas de la tela, e identificadores del objeto en general.

¡Otro llamado variable modificó Base64 para las aplicaciones de los regexps “! -” en vez de “*” substituir el Base64 estándar “+”, porque “+” y “*” puede ser reservado para las expresiones regulares (la nota que '' utilizó en el antedicho variable de IRCu no trabajaría en ese contexto).

Hay otras variantes que utilizan el “_-” o “. _” cuando la secuencia variable Base64 se debe utilizar dentro de los identificadores válidos para los programas, o “. -” para el uso en los símbolos conocidos XML ( Nmtoken ), o aún “el _: ” para el uso en identificadores más restrictos de XML ( conocido).

Otros usos

Base64 se puede utilizar en una variedad de contextos:
Thunderbird del

y evolución amba uso Base64 de obscurecer las contraseñas del email
Base64 se puede utilizar para transmitir y para almacenar el texto que pudo causar de otra manera la colisión del delimitador
Base64 es de uso frecuente como atajo rápido pero inseguro obscurecer secretos sin incurrir en los gastos indirectos de la gerencia dominante criptográfico
El uso Base64 de los spammeres de evadir las herramientas anti- básicas del Spam, que no descifran Base64 y por lo tanto no pueden a menudo detectar palabras claves en mensajes codificados.
Base64 se utiliza para codificar conjuntos de caracteres en archivos LDIF
Base64 se utiliza a veces para encajar datos binarios en un archivo XML, usar un sintaxis similar al encoding=" del . Firefox 's bookmarks.html de e.
Base64 también se utiliza al comunicar con los dispositivos fiscales de la firma/de impresión (generalmente, sobre puertos seriales o paralelos) para reducir al mínimo el retardo al transferir los carácteres del recibo para firmar.

Ver también

Base32
Ascii85
Cotizar-imprimible
Uuencode
YEnc
8BITMIME
URL

.

Zenithic

Base64

Random links:

Beso de la mujer de la araña (película) | Yu Suzuki | Cazador de Jeffrey | Sverre Petterssen | Sutton y Cheam (distrito electoral BRITÁNICO del parlamento)