Codifique en formato Base64

Descripción general

Base64 es un cambio de forma reversible, y esta herramienta es la mitad de ida del viaje: toma todo lo que pueda teclear o cualquier archivo que pueda subir, y lo reescribe en el texto imprimible que sobrevive a correos, URLs y documentos JSON sin perder un solo byte. Pegue unos datos, elija su variante de Base64, y el resultado codificado estará listo para copiar. El decodificador correspondiente vive en el sitio hermano, a un enlace de distancia.

Opciones avanzadas

• Conjunto de caracteres: Su texto siempre llega hasta nosotros como UTF-8, y por defecto se codifica como UTF-8. Cambie la lista cuando el otro extremo espere otros bytes, por ejemplo Windows-1252 para un programa heredado de Windows o una variante de ISO-8859 para software europeo más antiguo: la conversión ocurre antes de la codificación, así que la cadena que recibe lleva exactamente los bytes que pidió. Diga al decodificador qué conjunto eligió, porque Base64 en sí nunca lo dice. En el formulario de carga de archivos, la lista empieza en BINARIO (sin conversión), la elección correcta para todo menos el texto plano.
• Separador de nueva línea: Unix y Windows no coinciden en cómo terminar una línea, y su entrada puede llevar cualquiera de los dos (o ambos). Antes de que empiece la codificación, cada salto de línea del texto se reescribe en el estilo que elija aquí, así que la carga útil codificada es coherente sin importar de dónde vinieron los datos. El mismo separador también une las líneas de salida cuando una de las dos opciones multilínea está activa. En los archivos subidos, los bytes se dejan tal cual; el separador solo decide cómo se parte la salida codificada en líneas.
• Codifique cada línea por separado: Normalmente, la entrada entera se codifica como un bloque único, saltos de línea incluidos, que es lo que esperan la mayoría de las aplicaciones. Actívelo cuando la entrada sea, en su lugar, una lista de entradas independientes: cada línea se codifica por su cuenta, y las líneas codificadas se vuelven a unir con el separador que eligió. (*)
• Divida las líneas en trozos: Una cadena Base64 recién hecha es una sola línea larga, que le va bien a la mayoría de los sistemas pero no a todos: la especificación MIME (RFC 2045) dice que las líneas codificadas no deben tener más de 76 caracteres, y el correo en particular las quiere cortas. Marque esta casilla y la salida se envuelve a 76 caracteres por línea, usando el separador que elija. (*)
• Realice una codificación URL segura: Dos caracteres del alfabeto estándar, + y /, no se sientan bien en URLs, y los rellenos = lo empeoran todo. Esta opción cambia en su lugar a la variante Base64URL de RFC 4648: + pasa a ser -, / pasa a ser _, y los rellenos se eliminan por completo, porque se pueden calcular a partir de la longitud. El resultado es más corto y seguro para poner en URLs, nombres de archivo y JSON Web Tokens sin ningún escapado. Solo recuerde decirle al decodificador qué dialecto eligió.
• Modo en tiempo real: Actívelo y la codificación ocurre en su navegador mientras escribe, volviéndose a ejecutar con cada pulsación de tecla sin enviar nada a nuestros servidores. Respeta las otras opciones, línea por línea, trozos y segura para URLs, mientras las va activando y desactivando, y solo funciona con UTF-8, así que la lista de conjuntos de caracteres se mantiene bloqueada mientras está activo, y el botón de codificación se mantiene deshabilitado hasta que vuelva a cambiarlo.

(*) Estas opciones no se pueden activar a la vez, ya que la salida resultante no sería válida para la mayoría de las aplicaciones. El formulario se encarga de ello: marcar una desactiva la otra.

Seguro y protegido

Todo se ejecuta sobre una conexión HTTPS cifrada, y nada de lo que envía se conserva: los archivos subidos se borran en cuanto se procesan, y el resultado descargable desaparece justo después de su primer intento de descarga o de 15 minutos de inactividad, lo que ocurra primero. El contenido de lo que envía nunca se guarda ni se mira más allá de la propia conversión. Con el modo en tiempo real activo, su texto nunca sale del navegador. Todos los detalles están en nuestra política de privacidad, enlazada en el pie de página de abajo.

Completamente gratis

Todo en esta página es de uso gratuito - la lista completa de conjuntos de caracteres, las subidas de archivos y el modo en tiempo real incluidos. Sin cuenta, sin software que instalar, sin muro de pago: para una tarea tan pequeña, así debería ser.

Base64 explicado

Hay datos que simplemente no pueden viajar por un canal de solo texto: una foto, un archivo, un hash, un trozo de binario que haría que una conexión de correo de 7 bits se atragantara. Base64 es el traductor para momentos como este. Reescribe cualquier secuencia de bytes en texto plano e imprimible, para que los datos puedan estar en el cuerpo de un correo, en un documento JSON, en un archivo XML o en una URL, y lleguen exactamente como salieron. La traducción es completamente reversible: cada byte vuelve, en el mismo orden, sin perder nada por el camino.

El formato entero cabe en una frase: tres bytes de entrada, cuatro caracteres de salida. El precio es un resultado aproximadamente un tercio más grande que el original. La recompensa es una cadena que parece texto, se comporta como texto y sobrevive a canales que destruirían los bytes crudos. Y vale la pena dejar claro desde el principio lo que Base64 no es: no es cifrado, y no es compresión. Es un cambio de forma reversible, y ese es todo su trabajo.

Por qué 64, y por qué esos caracteres

Un byte guarda 8 bits, pero los viejos canales de texto, sobre todo el correo, solo llevaban ASCII de 7 bits con seguridad. El truco es elegir un alfabeto de caracteres imprimibles que sobreviva a cualquier viaje así, y dimensionarlo para que la cuenta salga limpia. Con 64 caracteres, cada carácter codificado lleva exactamente 6 bits, y 24 es divisible tanto por 8 (el byte) como por 6 (el carácter): tres bytes de entrada se convierten en cuatro caracteres de salida sin nada sobrante. El nombre es solo la base de esa matemática de caracteres, como la base 10 para nuestros dígitos.

El alfabeto estándar son los 62 caracteres alfanuméricos, de A a Z, de a a z y de 0 a 9, con + y / como los dos últimos. La especificación añade un 65.º carácter, =, que no está en el alfabeto en absoluto: solo aparece al final, como relleno. La elección fue deliberada. Todo el conjunto es imprimible; es común a todos los sistemas de texto; y la especificación MIME apunta que se escribe idénticamente en todas las versiones de ISO 646, incluida US-ASCII, y en todas las versiones de EBCDIC. Esa última propiedad es la que mantiene los datos intactos mientras cruzan la vieja maquinaria de internet, no apta para 8 bits.

Codificación, paso a paso

El codificador es una cadena de montaje de cuatro pasos. Lee la entrada de tres bytes a la vez y fusiona cada trío en una única cadena de 24 bits. Esa cadena se corta en cuatro trozos de 6 bits. Cada trozo es un número de 0 a 63, y cada número se busca en la tabla de arriba. Cuatro números de entrada, cuatro caracteres de salida.

Mírelo ocurrir con la palabra foo, que llega como los valores de byte 102, 111 y 111 (en hexadecimal: 66, 6F, 6F). Puestos uno tras otro, los 24 bits son 01100110 01101111 01101111. Cortado en grupos de seis, eso da 011001, 100110, 111101 y 101111, que son 25, 38, 61 y 47. La tabla dice que esos son Z, m, 9 y v, así que foo se codifica como Zm9v, y cualquier decodificador Base64 del mundo lo convertirá de nuevo en los tres bytes originales.

El resto de la entrada se procesa de la misma manera, trío tras trío, hasta que no quede nada. Solo el grupo final, cuando contiene menos de tres bytes, necesita un movimiento especial.

Relleno: el = al final

La entrada es siempre un número entero de bytes, pero tres no siempre lo divide exactamente. Cuando sobran uno o dos bytes al final, el codificador aún tiene que terminar un grupo completo de cuatro caracteres. Rellena los bits que faltan con ceros, hace las búsquedas como de costumbre, y sustituye los caracteres que habrían producido los bits de relleno por signos =. Exactamente tres finales son posibles:

Así, fo, dos bytes, se convierte en Zm8=, y la solitaria f se convierte en Zg==, mientras que foo no necesita relleno alguno. El decodificador sabe exactamente qué hacer con los rellenos: cada = significa ocho bits más de cero para descartar. Los rellenos solo se sientan al final absoluto, y son como máximo dos. La especificación MIME incluso usa esto como ventaja: como = no puede aparecer en otro sitio, una carga útil con relleno anuncia su propio final, y el receptor puede saber que los datos no se truncaron en tránsito. Y para el caso más pequeño: la entrada vacía se codifica en la salida vacía. Hasta la nada tiene un viaje de ida y vuelta perfecto.

Decodificación: la cadena de montaje a la inversa

Decodificar es la misma máquina funcionando hacia atrás, y es igual de mecánica. Tome cuatro caracteres, busque los reales (un relleno hace las veces de seis ceros), escriba los 24 bits, y devuelva los primeros 16 bits si hay un relleno, o los 24 completos si no hay ninguno. Cuatro caracteres de entrada, tres bytes de salida; dos bytes de salida con un relleno; un byte de salida con dos. Los bits de cero que añadió el codificador son lo único que se descarta, y cada otro bit es exactamente lo que entró. Eso es lo que reversible significa de verdad aquí: el formato en sí mismo no pierde nada, y las únicas cosas que pueden dañar sus datos son un canal que corrompe la cadena, o un decodificador que se rinde en silencio.

Por eso la norma es estricta en una cosa: los caracteres que no están en el alfabeto. RFC 4648 dice que un decodificador debe rechazar una carga útil que lleve cualquier carácter fuera de los 64, a menos que la especificación circundante lo permita explícitamente. La razón es práctica, no pedante. Un decodificador que traga en silencio caracteres extraños puede ser engañado: los caracteres colados se convierten en un canal lateral oculto, y ese truco se ha usado para ocultar datos a los filtros y para provocar errores del decodificador. La excepción famosa es el propio MIME, anterior a la norma y que dice lo contrario: ignora todo carácter fuera del alfabeto, y así es como los saltos de línea pasan por un adjunto de correo. Cuando valida la entrada usted mismo, la regla moderna es la correcta: si su cadena lleva una @, un espacio o cualquier otra cosa que no está en la tabla, no es Base64 limpio.

Saltos de línea y la regla de los 76 caracteres

A menudo se encontrará con Base64 envuelto en líneas, y la costumbre viene del correo. La vieja maquinaria de SMTP tenía límites de longitud de línea, así que MIME envuelve la carga útil a 76 caracteres por línea con un salto CRLF, y el formato PEM más antiguo, el que transporta certificados y claves, envuelve a 64. La regla de RFC 4648 para el código nuevo es la contraria: no añada saltos de línea en absoluto a menos que el formato que esté implementando lo diga. En la práctica, al decodificador no le importa. Un salto de línea es solo un carácter fuera del alfabeto, así que una carga útil envuelta en MIME, un bloque PEM y una sola cadena larga e ininterrumpida se decodifican todas a los mismos bytes. Si pega Base64 de cualquier sitio, elimine primero los saltos de línea y asunto zanjado.

El envoltorio tiene un pequeño coste, y se nota en los cálculos de tamaño. Sin saltos de línea, Base64 es exactamente cuatro tercios del original, aproximadamente un 33 % mayor. Envuelto a 76 caracteres con saltos CRLF, es aproximadamente un 37 % mayor, por eso un archivo que debería ser de 100 KB suele llegar como unos 137 KB de texto. La cuenta siempre cuadra.

Base64URL: el gemelo seguro para URLs

El alfabeto estándar tiene dos caracteres que no se llevan bien con las URLs. Un + en una cadena de consulta se lee tradicionalmente como espacio, y / es un separador de rutas, así que una cadena Base64 cruda en una URL necesita escapado por porcentaje para ambos, más los rellenos =. La sección 5 de RFC 4648 define la solución: el alfabeto seguro para URLs y nombres de archivo, donde + pasa a ser - y / pasa a ser _. Los rellenos también suelen irse, porque un relleno que falta se puede calcular a partir de la longitud. El RFC lo dice sin rodeos: esto no debe llamarse Base64 normal: es una codificación distinta, normalmente escrita base64url.

En la práctica, los dos están a un intercambio de distancia, en la dirección peligrosa. Si le da a un decodificador estándar una cadena base64url, saldrá mal, porque - y _ no están en el alfabeto estándar: un decodificador permisivo los descarta y devuelve una cadena de bytes más corta e incorrecta - o, cuando el resto es demasiado corto para valer por sí solo, un error - mientras que uno estricto rechaza la carga útil entera. El baile correcto es cambiar - de vuelta a + y _ de vuelta a /, añadir los rellenos que faltan, y solo entonces decodificar. Este es el dialecto que se encuentra en los JSON Web Tokens (JWT), en las cadenas de estado de OAuth y en los identificadores de un cierto sitio de vídeo muy grande.

Una guía rápida de campo

Antes de recurrir a una herramienta, puede leer gran parte de la cadena por su cuenta. Unas pocas comprobaciones le dicen si una carga útil es Base64 o no, y qué esconde:

• Mire los caracteres. El Base64 estándar solo usa de A a Z, de a a z, de 0 a 9, + y /; el gemelo seguro para URLs usa - y _ en lugar de esos dos. Cualquier otro símbolo, o un espacio suelto, significa que no es Base64 limpio.
• Revise los rellenos. Los signos =, si están, se sientan solo al final absoluto, y son como máximo dos. Un relleno a mitad de la cadena es una señal de alarma.
• Cuenta la longitud. Con rellenos, la longitud es siempre un múltiplo de 4. Sin rellenos, al dividir la longitud entre 4 el resto es 0, 2 o 3. Un resto de 1 es imposible, porque un solo carácter solo lleva 6 bits y un byte necesita 8.
• Estime el tamaño. Cada grupo de 4 caracteres guarda 3 bytes, menos un byte por cada signo =. Así, Zm9vYmFy, ocho caracteres sin rellenos, son 6 bytes, y Zm9vYg==, ocho caracteres con dos rellenos, son 4.

Un último truco de campo, y el más útil. El codificador debe poner a cero los bits de relleno, pero un decodificador permisivo no los comprueba. La carga útil Zg== se decodifica al único byte f, y lo mismo Zh==: los bits bajos del último carácter son relleno en ambos casos, así que ambos forman el mismo byte. La norma llama a la versión de bits a cero la forma canónica, y permite a los decodificadores estrictos rechazar la otra. Dos cadenas, una carga útil. Si dos sistemas no coinciden en un valor Base64, los bits de relleno son un buen sitio para empezar a mirar.

Lo que Base64 no es

• No es cifrado. No hay clave ni secreto; cualquiera puede convertir una cadena Base64 de nuevo en bytes en un segundo. El RFC incluso menciona incidentes reales en los que la gente reportó intercambios de protocolo que incluían una contraseña "codificada", convencida de que la codificación la estaba ocultando. Si los datos son sensibles, protéjalos con criptografía de verdad antes de codificarlos, no después.
• No es compresión. Va en la dirección contraria: el resultado es aproximadamente un 33 % mayor que la entrada, y aún mayor cuando se añaden saltos de línea. Base64 le compra seguridad de texto, y le cobra por ella en tamaño.
• No es un conjunto de caracteres. Base64 mueve bytes, no letras. No sabe ni le importa si esos bytes son texto UTF-8, una codificación heredada de un byte, o un JPEG. La pregunta "¿de qué conjunto de caracteres es esto?" vive antes de la codificación y después de la decodificación, nunca dentro de ella.
• No es una sola codificación. El nombre cubre una familia: el alfabeto estándar, el gemelo seguro para URLs, cargas útiles envueltas en 76 o 64 caracteres, variantes que omiten los rellenos, y un puñado de raros (IMAP, por ejemplo, usa una coma en lugar de la / del alfabeto al codificar nombres de buzón internacionales). Cuando dos sistemas no coinciden en una carga útil, una diferencia de dialecto suele ser el culpable.

La letra pequeña

Las fuentes primarias son cortas y legibles. RFC 4648, Las codificaciones de datos Base16, Base32 y Base64 (2006), es la norma actual: los dos alfabetos, las reglas de relleno y de saltos de línea, las reglas de estrictez, y un conjunto de vectores de prueba oficiales, como foo convertido en Zm9v, contra los que las implementaciones se comprueban a sí mismas. Detrás de ella se alza RFC 2045, la especificación MIME de 1996, de donde salen la regla de líneas de 76 caracteres y la permisividad de ignorar caracteres sueltos, y RFC 1421, la especificación Privacy Enhanced Mail en desuso, que inició la familia con líneas de 64 caracteres. Un intento de unificación anterior, RFC 3548, fue sustituido por RFC 4648.

Esa es la historia completa: 64 caracteres, tres bytes de entrada y cuatro caracteres de salida, = para rematar el final, y un viaje de ida y vuelta perfecto. Cada herramienta, librería y conversor en línea con el que se encuentre es solo una puerta de entrada a esto. Cuando puede mirar una cadena Base64 y ver los bytes que se mantienen detrás de ella, nada del formato le sorprenderá más. Y cuando esté listo para escribir el codificador por su cuenta, los artículos de lenguajes de programación justo debajo de esta sección le entregan los mismos 64 caracteres como código que funciona: una guía completa por lenguaje.