¿Qué es Base64?
Base64 reescribe los bytes usando sesenta y cuatro caracteres legibles para que los datos sobrevivan a un canal diseñado para texto: el cuerpo de un correo, una cadena JSON, un atributo XML, una URL. Cada tres bytes se convierten en cuatro caracteres, de ahí su nombre: el alfabeto tiene sesenta y cuatro símbolos y cada uno transporta exactamente seis bits.
Es una codificación de transporte, no una medida de seguridad ni un paso de compresión. La salida es aproximadamente un tercio más grande que la entrada, y cualquiera que tenga la cadena puede revertirla directamente. Si quiere saber si los datos se alteraron, eso es un hash (Generador de hash); si quiere que permanezcan en secreto, eso es cifrado. Base64 no hace ninguna de las dos cosas.
El único número que conviene recordar: tres bytes de entrada se convierten en cuatro caracteres de salida. Todo lo demás de esta página se deriva de él. Cuatro caracteres transportan veinticuatro bits, y veinticuatro bits son exactamente tres bytes, así que nunca se pierden ni se inventan datos — salvo al final, donde la entrada puede no llenar el último grupo de tres.
Los cinco alfabetos que puede usar esta página
Las dos primeras filas son estándares y las últimas tres son convenciones que surgieron alrededor de Unix. Las cinco transportan los mismos seis bits por carácter y solo difieren en qué sesenta y cuatro caracteres hacen ese trabajo, así que los mismos bytes se convierten en cinco cadenas distintas. Nada dentro de una cadena indica qué alfabeto la produjo, por eso el selector de alfabeto usa el estándar por defecto y la casilla de seguro para URL es un atajo para la segunda fila.
Cómo la página elige un candidato: el selector es el predeterminado para ambas direcciones. Al decodificar, el panel de la derecha también lee la propia cadena — - y _ solo pueden venir del alfabeto seguro para URL, + o / solo pueden venir del estándar, y una / o un . cerca del inicio apunta a los dos alfabetos de Unix. Todos los alfabetos que pueden leer la entrada actual aparecen en ese panel, con el motivo por el que cada uno es o no es un candidato.
Ajuste de línea: 76 y 64 caracteres
MIME pedía un Base64 que cupiera en un correo sin que ninguna línea se alargara sin medida, y se fijó en 76 caracteres por línea separados por CRLF. Los archivos PEM, que envuelven certificados y claves, usan 64. Los saltos de línea no forman parte de los datos: un decodificador los elimina y une las líneas antes de hacer cualquier otra cosa, así que una cadena envuelta y una sin envolver se decodifican exactamente a los mismos bytes. Cada línea salvo la última contiene un número entero de grupos de cuatro caracteres, que es lo que hace seguro volver a unirlas.
Esta página deja la salida en una sola línea salvo que elija un ancho, y el decodificador acepta entradas con o sin saltos de línea. Los saltos que escribe esta página son saltos de línea simples, que es lo que cabe en un cuadro de texto; los cuerpos de correos MIME tradicionalmente usan un retorno de carro antes de cada salto de línea, y todos los decodificadores en uso aceptan ambos.
El relleno, y por qué puede omitirse
Cuando la entrada no es múltiplo de tres bytes, el último grupo de cuatro caracteres queda incompleto, y uno o dos caracteres = lo completan. No transportan ningún dato: solo indican cuántos de los cuatro caracteres son reales. Un decodificador puede deducirlo a partir de la longitud, por eso Base64 seguro para URL tradicionalmente omite el relleno — un = resulta incómodo en una URL o en un nombre de archivo, y algunos sistemas lo codifican en porcentaje.
La casilla de la fila de opciones conserva el relleno cuando se selecciona el alfabeto seguro para URL. Nada más cambia; los caracteres que transportan datos son idénticos en ambos casos.
Malentendidos habituales
- "Base64 oculta los datos." No. Es una sustitución sin clave, y el objetivo es que cualquier lector pueda deshacerla. Envolver una contraseña o un token en Base64 no cambia quién puede leerlo.
- "Base64 comprime." Lo contrario: cada tres bytes de entrada se convierten en cuatro caracteres de salida, así que el texto es un tercio más grande que los datos que transporta.
- "Los saltos de línea forman parte del valor." Son presentación. Añadirlos o quitarlos nunca cambia los bytes que salen de vuelta.
- "Seguro para URL significa una codificación distinta." Es la misma codificación con dos caracteres intercambiados:
+ pasa a - y / pasa a _, así que la cadena puede ir en una ruta de URL o en un valor de consulta sin escapar. - "Una cadena que se decodifica tiene que ser Base64 válido." Cualquier cadena de caracteres del alfabeto es Base64 válido, porque toda combinación de valores de seis bits es una secuencia válida de bytes. Una cadena solo resulta errónea en el paso siguiente, cuando esos bytes se comprueban contra el formato que se suponía que debían tener.
- "El relleno indica qué alfabeto se usó." No lo indica, y en la mayoría de los casos tampoco lo indican los caracteres: los alfabetos estándar y seguro para URL coinciden en sesenta y dos de sus sesenta y cuatro símbolos, así que una cadena corta suele leerse igual en ambos.
Preguntas habituales
¿Por qué una cadena Base64 a veces termina en un = y a veces en dos? Uno significa que el último grupo transporta tres caracteres reales, es decir, dos bytes de entrada; dos significa que transporta dos, es decir, un byte de entrada. Sin = significa que la longitud de la entrada era múltiplo de tres.
¿Puede Base64 representar archivos binarios arbitrarios? Sí, y ese es su uso principal. Esta página trata la entrada como texto UTF-8; la herramienta específica Archivo a Base64 lee bytes en bruto cuando quiera codificar algo que no es texto.
¿Qué alfabeto debo usar en una API? El que documente el extremo receptor. Si dice seguro para URL, use eso; si no dice nada y el valor viaja dentro de una URL, el seguro para URL sin relleno es la opción segura.
¿La salida distingue mayúsculas? Totalmente. a y A son valores distintos, y por eso Base64 tolera mucho peor un carácter mal escrito que Base32 o Base32 de Crockford.
