Codificador y decodificador Base64

Base64 existe porque gran parte de la infraestructura construida alrededor del texto — correo, JSON, XML, URL — no puede llevar de forma fiable bytes binarios arbitrarios, que podrían contener caracteres de control, bytes nulos, o secuencias de bytes que terminan una cadena antes de tiempo o rompen un analizador directamente. Base64 asigna cada tres bytes de datos binarios arbitrarios a cuatro caracteres extraídos de un conjunto fijo de 64 que cualquier sistema basado en texto maneja de forma segura — letras, dígitos y dos símbolos — así que el resultado codificado puede incrustarse en JSON, enviarse como adjunto de correo, o incluirse en un documento sin que nada río abajo lo malinterprete como algo distinto de texto plano.

El sobrecoste de esa seguridad es fijo e inevitable: cuatro caracteres de salida por cada tres bytes de entrada, una expansión de aproximadamente un 33%, sin importar cuáles sean los datos subyacentes. Ese es el precio pagado por un paso seguro garantizado a través de canales de solo texto, no un defecto específico de ninguna implementación particular.

La función `btoa` incorporada del navegador, a la que recurren directamente muchas implementaciones rápidas de Base64, arroja un error en el momento en que encuentra cualquier carácter por encima del punto de código U+00FF — lo que incluye esencialmente todos los emojis, el chino, japonés, coreano, cirílico, griego y árabe, además de bastantes caracteres latinos acentuados usados en francés, alemán, español y otros idiomas. Este no es un caso extremo oscuro que afecte a entradas raras; afecta a una fracción muy grande de texto del mundo real, y es la razón por la que tantas herramientas Base64 hechas a mano funcionan perfectamente en pruebas con entrada en inglés plano y luego fallan la primera vez que un usuario pega algo con un emoji o un nombre no latino.

El arreglo es codificar el texto como bytes UTF-8 primero, luego codificar en Base64 esos bytes — que es lo que hacen los codificadores correctamente construidos y lo que hace esta herramienta — en lugar de intentar introducir puntos de código Unicode directamente en una codificación diseñada para secuencias de bytes por debajo de 256.

El conjunto de caracteres del Base64 estándar incluye `+` y `/`, ambos con significado en una URL — `+` a veces se interpreta como un espacio, y `/` es un separador de ruta — así que una cadena Base64 estándar pegada directamente en una cadena de consulta o un nombre de archivo puede corromperse o truncarse silenciosamente al pasar por lo que sea que analice esa URL. Base64URL reemplaza esos dos caracteres por `-` y `_`, ninguno de los cuales lleva un significado especial en una URL, y típicamente también elimina los caracteres de relleno `=` finales, que existen puramente para señalar la longitud y son innecesarios una vez que el decodificador ya sabe que debe esperarlos.

Los JSON Web Tokens usan Base64URL exactamente por esta razón: un JWT está diseñado para viajar dentro de una cabecera HTTP Authorization y a veces una URL, y los caracteres reservados del Base64 estándar harían eso poco fiable.

Vale la pena decirlo con claridad porque la suposición aparece a menudo: Base64 proporciona cero confidencialidad. No hay ninguna clave secreta involucrada en ningún punto del proceso, así que cualquiera que obtenga una cadena Base64 puede decodificarla de vuelta a los datos originales al instante usando nada más que una llamada de biblioteca estándar o una herramienta exactamente como esta. Codificar una contraseña o una clave de API en Base64 antes de almacenarla o transmitirla no proporciona ninguna protección en absoluto — solo oculta el valor de un vistazo casual, que es una propiedad muy distinta a la seguridad real.