Base64

Grupo de esquemas de codificación de binario a texto que utilizan 64 símbolos (más relleno)

En programación , Base64 es un grupo de esquemas de codificación de binario a texto que representan datos binarios (más específicamente, una secuencia de bytes de 8 bits) en un formato de cadena ASCII al traducir los datos en una representación de base 64. El término Base64 se origina en una codificación de transferencia de contenido MIME específica . Cada dígito de Base64 no final representa exactamente 6 bits de datos. Por lo tanto, tres bytes de 8 bits (es decir, un total de 24 bits) pueden representarse mediante cuatro dígitos Base64 de 6 bits.

Común a 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 sus usos incluyen la capacidad de incrustar archivos de imagen u otros activos binarios dentro de activos textuales como archivos HTML y CSS . ^[2]

Base64 también se usa ampliamente para enviar archivos adjuntos de correo electrónico. Esto es necesario porque SMTP , en su forma original, fue diseñado para transportar solo caracteres ASCII de 7 bits. Esta codificación provoca una sobrecarga del 33-36% (33% por la propia codificación; hasta un 3% más por los saltos de línea insertados).

Diseño

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 son comunes a la mayoría de las codificaciones y que también se pueden imprimir . 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 MIME usa A- 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 de acceso telefónico entre sistemas que ejecutan el mismo sistema operativo  , por ejemplo, uuencode para UNIX , BinHex para TRS-80 (más tarde adaptado para Macintosh ), y por lo tanto podría hacer más suposiciones sobre qué los personajes 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]}

Tabla Base64

La tabla de índice Base64 :

Índice	Binario	Carbonizarse		Índice	Binario	Carbonizarse		Índice	Binario	Carbonizarse		Índice	Binario	Carbonizarse
0	000000	A		dieciséis	010000	Q		32	100000	g		48	110000	w
1	000001	B		17	010001	R		33	100001	h		49	110001	x
2	000010	C		18	010010	S		34	100010	i		50	110010	y
3	000011	D		19	010011	T		35	100011	j		51	110011	z
4	000100	E		20	010100	U		36	100100	k		52	110100	0
5	000101	F		21	010101	V		37	100101	l		53	110101	1
6	000110	G		22	010110	W		38	100110	m		54	110110	2
7	000111	H		23	010111	X		39	100111	n		55	110111	3
8	001000	I		24	011000	Y		40	101000	o		56	111000	4
9	001001	J		25	011001	Z		41	101001	p		57	111001	5
10	001010	K		26	011010	a		42	101010	q		58	111010	6
11	001011	L		27	011011	b		43	101011	r		59	111011	7
12	001100	M		28	011100	c		44	101100	s		60	111100	8
13	001101	N		29	011101	d		45	101101	t		61	111101	9
14	001110	O		30	011110	e		46	101110	u		62	111110	+
15	001111	P		31	011111	f		47	101111	v		63	111111	/
Relleno		=

Ejemplos

El siguiente ejemplo usa texto ASCII para simplificar, pero este no es un caso de uso típico, ya que ya se puede transferir de forma segura a todos los sistemas que pueden manejar Base64. El uso más típico es codificar datos binarios (como una imagen); los datos de Base64 resultantes solo contendrán 64 caracteres ASCII diferentes, todos los cuales se pueden transferir de manera confiable a través de sistemas que pueden dañar los bytes de origen sin procesar.

Aquí es una cita de Thomas Hobbes 's Leviatán :

El hombre se distingue, no sólo por su razón, sino por esta singular pasión de otros animales, que es un deseo de la mente, que por una perseverancia de deleite en la continua e infatigable generación de conocimientos, supera la breve vehemencia de cualquier placer carnal. .

(Tenga en cuenta que todas las codificaciones de ejemplo a continuación utilizan solo los bytes que se muestran arriba; no es una cadena terminada en nulo y no tiene caracteres de nueva línea ).

Cuando esa cita está codificada 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 líneas nuevas y los espacios en blanco pueden estar presentes en cualquier lugar, pero deben ignorarse en la decodificación):

TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZWFzb24sIGJ1dCBieSB0aGlzIHNpbmd1bGFyIHBhc3Npb24gZnJvbSBvdGhlciBhbmltYWxzLCB3aGljaCBpcyBhIGx1c3Qgb2YgdGhlIG1pbmQsIHRoYXQgYnkgYSBwZXJzZXZlcmFuY2Ugb2YgZGVsaWdodCBpbiB0aGUgY29udGlu dWVkIGFuZCBpbmRlZmF0aWdhYmxlIGdlbmVyYXRpb24gb2Yga25vd2xlZGdlLCBleGNlZWRzIHRoZSBzaG9ydCB2ZWhlbWVuY2Ugb2YgYW55IGNhcm5hbCBwbGVhc3VyZS4 =

En la cita anterior, el valor codificado de Man es TWFu . Codificada en ASCII, los caracteres M , una , 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, produciendo 010011010110000101101110. Los grupos de 6 bits (6 bits tienen un máximo de 2 ⁶  = 64 valores binarios diferentes) se convierten en números individuales de izquierda a derecha (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.

Fuente	Texto (ASCII)	METRO								a								norte
	Octetos	77 (0x4d)								97 (0x61)								110 (0x6e)
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
Base 64 codificado	Sextetos	19						22						5						46
	Personaje	T						W						F						tu
	Octetos	84 (0x54)						87 (0 x 57)						70 (0x46)						117 (0 x 75)

= Es posible que se agreguen caracteres de relleno para que el último bloque codificado contenga cuatro caracteres Base64.

La transformación hexadecimal a octal es útil para convertir entre binario y Base64. Tanto para calculadoras avanzadas como para lenguajes de programación, dicha conversión está disponible. Por ejemplo, los 24 bits anteriores, cuando se convierten a hexadecimal, son 4D616E. Esos 24 bits, cuando se convierten a octales, son 23260556. Esos 8 dígitos octales, cuando se dividen en cuatro grupos, son 23 26 05 56. Cada grupo de 2 dígitos, cuando se convierten a decimales, es 19 22 05 46. Usando esos cuatro decimales números como índices para la tabla de índice 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 serán cero y se descartarán en la decodificación (junto con el siguiente =carácter de relleno):

Fuente	Texto (ASCII)	METRO								a
	Octetos	77 (0x4d)								97 (0x61)
Bits		0	1	0	0	1	1	0	1	0	1	1	0	0	0	0	1	0	0
Base 64 codificado	Sextetos	19						22						4						Relleno
	Personaje	T						W						mi						=
	Octetos	84 (0x54)						87 (0 x 57)						69 (0x45)						61 (0x3D)

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 dos primeros dígitos Base64 (12 bits); los cuatro bits menos significativos del último bloque de 6 bits con contenido serán cero y se descartarán en la decodificación (junto con los dos =caracteres de relleno siguientes):

Fuente	Texto (ASCII)	METRO
	Octetos	77 (0x4d)
Bits		0	1	0	0	1	1	0	1	0	0	0	0
Base 64 codificado	Sextetos	19						dieciséis						Relleno						Relleno
	Personaje	T						Q						=						=
	Octetos	84 (0x54)						81 (0x51)						61 (0x3D)						61 (0x3D)

Relleno de salida

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 en una computadora moderna, cada cuatro caracteres de texto codificado en Base64 (4 sextetos = 4 × 6 = 24 bits) representa tres octetos de texto no codificado texto o datos (3 octetos = 3 × 8 = 24 bits). Esto significa que cuando la longitud de la entrada no codificada 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, 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:

Aporte		Producción		Relleno
Largo	Texto	Largo	Texto
20	cualquier súplica carnal sur e.	28	YW55IGNhcm5hbCBwbGVh c3Vy ZS4 =	1
19	cualquier súplica carnal sur e	28	YW55IGNhcm5hbCBwbGVh c3Vy ZQ ==	2
18	cualquier súplica carnal sur	24	YW55IGNhcm5hbCBwbGVh c3Vy	0
17	cualquier súplica carnal su	24	YW55IGNhcm5hbCBwbGVh c3U =	1
dieciséis	ningún motivo carnal s	24	YW55IGNhcm5hbCBwbGVh cw ==	2

El carácter de relleno no es esencial para la decodificación, ya que el número de bytes que faltan 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.

Otra consecuencia de la codificación de octetos por sexteto es que el mismo octeto se codificará de manera diferente dependiendo de su posición dentro de un grupo de tres octetos de la entrada, y dependiendo de qué octeto particular lo precede dentro del grupo. Por ejemplo:

Aporte	Producción
un placer seguro.	cGxlY XN1cmUu
estar seguro.	bGVh c3VyZS4 =
ea seguro.	ZWF zdXJlLg ==
un seguro.	Y XN1cmUu
Por supuesto.	c3VyZS4 =

Dado que los ocho bits de un octeto se distribuyen en varios sextetos dentro de la salida, esto es una consecuencia obvia, ya que ningún octeto puede rellenarse en un solo sexteto; en cambio, deben compartir.

Sin embargo, dado que los sextetos o caracteres de la salida deben guardarse y manipularse en el mismo sistema informático, que solo comprende octetos, deben representarse como octetos, con los dos bits superiores puestos a cero. (En otras palabras, la salida codificada YW55ocupa 4 × 8 = 32 bits, aunque solo 24 bits se derivan de manera significativa de la entrada, ' cualquiera' ). De hecho, estos bits supuestamente desperdiciados son exactamente la razón de la codificación Base64 . La relación entre bytes de salida y bytes de entrada es 4∶3 (33% de sobrecarga). Específicamente, dada una entrada de n bytes, la salida será${\textstyle 4\left\lceil {\frac {n}{3}}\right\rceil }$ bytes de longitud, incluidos los caracteres de relleno.

Decodificación de Base64 con relleno

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 solo un byte. Por ejemplo:

Codificado	Relleno	Largo	Descifrado
YW55IGNhcm5hbCBwbGVh cw ==	==	1	ningún motivo carnal s
YW55IGNhcm5hbCBwbGVh c3U =	=	2	cualquier súplica carnal su
YW55IGNhcm5hbCBwbGVh c3Vy	Ninguno	3	cualquier súplica carnal sur
YW55IGNhcm5hbCBwbGVhc3Vy ZQ ==	==	1	cualquier placer carnal e

Decodificación de Base64 sin relleno

Sin relleno, después de la descodificació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 personajes. No es posible 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 aporta 6 bits y el segundo carácter aporta sus 2 primeros bits.) Por ejemplo:

Largo	Codificado	Largo	Descifrado
2	YW55IGNhcm5hbCBwbGVh cw	1	ningún motivo carnal s
3	YW55IGNhcm5hbCBwbGVh c3U	2	cualquier súplica carnal su
4	YW55IGNhcm5hbCBwbGVh c3Vy	3	cualquier súplica carnal sur

Implementaciones e historia

Tabla resumen de variantes

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 la tabla de índice para los índices 62 y 63, y al carácter utilizado para el relleno (que puede ser obligatorio en algunos protocolos o eliminado en otros). La siguiente tabla resume estas variantes conocidas y proporciona enlaces a las subsecciones siguientes.

Codificación	Codificación de caracteres			Codificación separada de líneas			Decodificación de caracteres no codificados
	62º	63º	almohadilla	Separadores	Largo	Suma de comprobación
RFC 1421 : Base64 para correo con privacidad mejorada (obsoleto)	+	/	= obligatorio	CR + LF	64 o menos para la última línea	No	No
RFC 2045 : codificación de transferencia Base64 para MIME	+	/	= obligatorio	CR + LF	Como máximo 76	No	Descartado
RFC 2152 : Base64 para UTF-7	+	/	No	No			No
RFC 3501 : codificación Base64 para nombres de buzones de correo IMAP	+	,	No	No			No
RFC 4648 §4 : base64 (estándar) [a]	+	/	= Opcional	No			No
RFC 4648 §5 : base64url (estándar seguro para URL y nombre de archivo) [a]	-	_	= Opcional	No			No
RFC 4880 : Radix-64 para OpenPGP	+	/	= obligatorio	CR + LF	Como máximo 76	CRC de 24 bits con codificación Radix-64	No

1. Es importante tener en cuenta que esta variante está destinada a proporcionar características comunes donde no se desea que se especialicen mediante implementaciones, lo que garantiza una ingeniería sólida. Esto es particularmente a la luz de codificaciones y restricciones de línea separadas, que no se han considerado cuando se han adoptado normas anteriores para su uso en otros lugares. Por lo tanto, las funciones indicadas aquí pueden anularse.

Correo con privacidad mejorada

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 usa codificación Base64 para transformar una secuencia arbitraria de octetos a un formato que se puede expresar en líneas cortas de caracteres de 6 bits, como lo requieren los protocolos de transferencia como SMTP . ^[7]

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 , usó adicionalmente el símbolo para delimitar datos codificados pero no encriptados 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 entre 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 de búfer restantes serán cero. A continuación, se utiliza el búfer, seis bits a la vez, los más significativos primero, como índices en la cadena: " ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/", y se emite el carácter indicado.

El proceso se repite en 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 de la memoria intermedia de 24 bits son ceros rellenados, =se añaden dos caracteres a la salida; si un octeto de la memoria intermedia de 24 bits se llena con ceros rellenados, =se agrega 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 un múltiplo de 4 bytes.

PEM requiere que todas las líneas codificadas tengan 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 de acuerdo con las convenciones locales (específicas de la plataforma).

MIME

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 entre comillas ). ^[5] La codificación Base64 de MIME se basa en la de la versión RFC 1421 de PEM: usa el mismo alfabeto de 64 caracteres y mecanismo de codificación que PEM, y usa 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 especifica una longitud máxima de línea de 76 caracteres. Además, especifica que cualquier carácter extra-alfabético debe ser ignorado por un decodificador compatible, aunque la mayoría de las implementaciones usan 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, 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 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

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. ^{[8] [9]}  

El alfabeto "Modified Base64" consiste en el 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 el carácter de escape para la codificación "entre comillas imprimibles". Base64 modificada simplemente omite el relleno y finaliza inmediatamente después del último dígito Base64 que contiene bits útiles, dejando hasta tres bits no utilizados en el último dígito Base64. =

OpenPGP

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 en MIME, con la adición de un CRC opcional de 24 bits . La suma de comprobación se calcula sobre los datos de entrada antes de la codificación; la suma de comprobación se codifica con el mismo algoritmo Base64 y, con el prefijo " " como separador, se agrega a los datos de salida codificados. ^[10] =

RFC 3548

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 codificaciones Base64, codificaciones alfabéticas alternativas y Base32 (que rara vez es utilizado) y codificaciones Base16.  

A menos que las implementaciones estén escritas en una especificación que se refiera a RFC 3548 y específicamente requiera 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 los datos que contienen caracteres fuera de la codificación. alfabeto. ^[6] 

RFC 4648

Este RFC deja obsoleto el RFC 3548 y se centra en Base64 / 32/16:

Este documento describe los esquemas de codificación Base64, Base32 y Base16 de uso común. También analiza el uso de avances de línea en datos codificados, el uso de relleno en datos codificados, el uso de caracteres no alfabéticos en datos codificados, el uso de diferentes alfabetos de codificación y codificaciones canónicas.

Las aplicaciones de URL

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 puede usar codificación Base64 para codificar un ID único relativamente grande (generalmente UUID de 128 bits ) en una cadena para usar como parámetro HTTP en formularios HTTP o URL GET de 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 forma compacta.

El uso de Base64 estándar en URL requiere la codificación de ' +', ' /' y ' =' caracteres 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, existe Base64 modificada para variantes de URL (como base64url en RFC 4648 ), donde los caracteres ' ' y ' ' de Base64 estándar se reemplazan respectivamente por ' ' y ' ', por lo que el uso de codificadores / decodificadores de URL ya no es posible. necesario y no tiene ningún impacto 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. Algunas variantes permiten o requieren que se omitan los signos de relleno " " para evitar que se confundan con los separadores de campo, o requieren que dicho relleno esté codificado en porcentaje.Algunas bibliotecas ^{[ ¿cuáles? ]} codificará ' +/-_=='a' .', lo que potencialmente expone a las aplicaciones a ataques de ruta relativa cuando el nombre de una carpeta se codifica a partir de los datos del usuario.

HTML

Los métodos atob()y btoa()JavaScript, definidos en el borrador de la especificación HTML5, ^[11] 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.

Otras aplicaciones

Ejemplo de un SVG que contiene imágenes JPEG incrustadas codificadas en Base64 ^[12]

Base64 se puede utilizar en una variedad de contextos:

• Base64 se puede usar para transmitir y almacenar texto que de otra manera podría causar una colisión de delimitadores
• Los spammers utilizan Base64 para evadir las herramientas básicas anti-spam , que a menudo no decodifican Base64 y, por lo tanto, no pueden detectar palabras clave en mensajes codificados.
• Base64 se utiliza para codificar cadenas de caracteres en archivos LDIF
• Base64 se usa a menudo para incrustar datos binarios en un archivo XML , usando una sintaxis similar a, <data encoding="base64">…</data>por ejemplo, favicons en Firefox exportado bookmarks.html.
• Base64 se utiliza para codificar archivos binarios como imágenes dentro de scripts, para evitar depender de archivos externos.
• El esquema de URI de datos puede usar Base64 para representar el contenido del archivo. Por ejemplo, las imágenes de fondo y las fuentes se pueden especificar en un archivo de hoja de estilo CSS como data:URI, en lugar de proporcionarse en archivos separados.
• La implementación de FreeSWAN IPSec precede a las cadenas de Base64 con 0s, por lo que se pueden distinguir de las cadenas de texto o hexadecimales. ^{[ cita requerida ]}
• Aunque no forma parte de la especificación oficial de SVG , algunos espectadores pueden interpretar Base64 cuando se usa para elementos incrustados, como imágenes dentro de SVG. ^[13]

Las aplicaciones Radix-64 no son compatibles con Base64

• Uuencoding , usado tradicionalmente en UNIX , usa ASCII 32 ("  " (espacio)) a 95 (" _"), consecutivamente, lo que hace que su conjunto de 64 caracteres sea "  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_". Evitar todas las letras minúsculas fue útil porque muchas impresoras antiguas solo imprimían en mayúsculas. El uso de caracteres ASCII consecutivos ahorró potencia de cálculo porque solo era necesario sumar 32, no hacer una búsqueda. El uso de la mayoría de los caracteres de puntuación y el carácter de espacio limita su utilidad. ^{[ cita requerida ]}
• BinHex 4 (HQX), que se usó en el Mac OS clásico , usa un conjunto diferente de 64 caracteres. Utiliza letras mayúsculas y minúsculas, dígitos y caracteres de puntuación, pero no utiliza algunos caracteres visualmente confusos como ' 7', ' O', ' g' y ' o'. Su juego de 64 caracteres es " !"#$%&'()*+,-012345689@ABCDEFGHIJKLMNPQRSTUVXYZ[`abcdefhijklmpqr".
• Varias otras aplicaciones usan conjuntos de radix-64 más similares pero en un orden diferente al formato Base64, comenzando con dos símbolos, luego números, luego mayúsculas y luego minúsculas:
  • Unix almacena los hashes de contraseña calculados con crypt en el /etc/passwdarchivo usando la codificación radix-64 llamada B64 . Utiliza un conjunto de caracteres en su mayoría alfanuméricos, más .y /. Su juego de 64 caracteres es " ./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz". No se utiliza relleno.
  • El estándar GEDCOM 5.5 para el intercambio de datos genealógicos codifica archivos multimedia en su formato de archivo jerárquico de línea de texto utilizando radix-64. Su conjunto de 64 caracteres también es " ./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz". ^[14]
  • Los hashes de bcrypt están diseñados para usarse de la misma forma que los hashes de crypt (3) tradicionales, y el algoritmo usa un alfabeto similar pero permutado. Su juego de 64 caracteres es " ./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789". ^[15]
  • Xxencoding usa un juego de caracteres alfanumérico mayormente similar a crypt y GEDCOM, pero usando +y en -lugar de .y /. Su juego de 64 caracteres es " +-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz".
  • 6PACK, usado con algunos controladores de nodo terminal , usa un conjunto diferente de 64 caracteres de 0x00 a 0x3f. ^[dieciséis]
  • Bash admite literales numéricos en base 2-64, extendiéndose a un conjunto de caracteres de 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ@_. ^[17]

Ver también

• 8BITMIME
• Ascii85 (también llamado Base85)
• Base16
• Base32
• Base36
• Base62
• Codificación de binario a texto para una comparación de varios algoritmos de codificación
• Número binario
• URL

Referencias

1. "Codificación y decodificación Base64 - API web | MDN" .
2. "Cuándo codificar imágenes en base64 (y cuándo no)" .
3. Las codificaciones de datos Base16, Base32 y Base64 . IETF . Octubre de 2006. doi : 10.17487 / RFC4648 . RFC 4648 . Consultado el 18 de marzo de 2010 .
4. Mejora de la privacidad para el correo electrónico de Internet: Parte I: Procedimientos de autenticación y cifrado de mensajes . IETF . Febrero de 1993. doi : 10.17487 / RFC1421 . RFC 1421 . Consultado el 18 de marzo de 2010 .
5. Extensiones de correo de Internet multipropósito: (MIME) Primera parte: Formato de los cuerpos de los mensajes de Internet . IETF . Noviembre de 1996. doi : 10.17487 / RFC2045 . RFC 2045 . Consultado el 18 de marzo de 2010 .
6. Las codificaciones de datos Base16, Base32 y Base64 . IETF . Julio de 2003. doi : 10.17487 / RFC3548 . RFC 3548 . Consultado el 18 de marzo de 2010 .
7. Mejora de la privacidad para correo electrónico de Internet . IETF . Febrero de 1987. doi : 10.17487 / RFC0989 . RFC 989 . Consultado el 18 de marzo de 2010 .
8. UTF-7 Un formato de transformación seguro para correo de Unicode . IETF . Julio de 1994. doi : 10.17487 / RFC1642 . RFC 1642 . Consultado el 18 de marzo de 2010 .
9. UTF-7 Un formato de transformación seguro para correo de Unicode . IETF . Mayo de 1997. doi : 10.17487 / RFC2152 . RFC 2152 . Consultado el 18 de marzo de 2010 .
10. Formato de mensaje OpenPGP . IETF . Noviembre de 2007. doi : 10.17487 / RFC4880 . RFC 4880 . Consultado el 18 de marzo de 2010 .
11. "7.3. Métodos de utilidad Base64" . Borrador del editor de HTML 5.2 . Consorcio World Wide Web . Consultado el 2 de enero de 2018 .Introducido por el conjunto de cambios 5814 , 2021-02-01.
12. <image xlink: href = "data: image / jpeg; base64,JPEG contents encoded in Base64" ... />
13. "Editar violín" . jsfiddle.net .
14. "La versión 5.5 estándar de GEDCOM" . Homepages.rootsweb.ancestry.com . Consultado el 21 de junio de 2012 .
15. Provos, Niels (13 de febrero de 1997). "src / lib / libc / crypt / bcrypt.c r1.1" . Consultado el 18 de mayo de 2018 .
16. "6PACK un PC" en tiempo real "a protocolo TNC" . Consultado el 19 de mayo de 2013 .
17. "Aritmética de Shell" . Manual de referencia de Bash . Consultado el 8 de abril de 2020 . 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.