Codificador/Decodificador Base64

Base64 es un método que utiliza 64 caracteres imprimibles para representar datos binarios. Estos 64 caracteres incluyen mayúsculas A-Z, minúsculas a-z, dígitos 0-9, y los dos símbolos + y /. Como solo usa caracteres imprimibles, los datos codificados en Base64 pueden transmitirse de forma segura en entornos que solo soportan texto, como correos electrónicos, páginas web y JSON. Los datos codificados aumentan aproximadamente un 33% respecto a los originales. Base64 apareció por primera vez en 1987 en el protocolo PEM para transmitir datos binarios de forma segura en correos. Hoy es uno de los estándares de Internet, ampliamente utilizado en diversos escenarios, desde archivos adjuntos hasta tokens JWT, desde imágenes embebidas hasta transmisión de datos. Casi todos los lenguajes de programación tienen funciones de codificación y decodificación Base64 integradas.

Base64 es una de varias codificaciones binario-a-texto especificadas en RFC 4648 (S. Josefsson, octubre 2006), junto con Base16 (hex) y Base32. El nombre 'Base64' y su alfabeto se definieron originalmente para Privacy-Enhanced Mail (RFC 989, 1987), donde PEM envolvía material binario S/MIME y X.509 dentro de una envoltura ASCII imprimible para que pudiera sobrevivir a transportes limpios de 7 bits. El mismo alfabeto se convirtió después en el estándar de facto para MIME (RFC 2045), firmas JWT (RFC 7519), URIs data: en HTML (RFC 2397), blobs de clave pública SSH (RFC 4253 §6.6) y archivos puntero de Git LFS (que almacenan hashes SHA-256 como Base64). Los packfiles de Git NO son Base64 — usan codificación delta con compresión zlib, y los IDs de objetos Git son cadenas hexadecimales SHA-1 de 40 caracteres, no Base64. El coste: cada 3 bytes de entrada se convierten en 4 caracteres de salida, así que la salida codificada es exactamente 4/3 del tamaño (33,3% de sobrecarga). Para un blob binario de 10 MB la forma codificada es ~13,3 MB. El mecanismo: dividir la entrada en grupos de 3 bytes (24 bits); cada grupo se descompone en cuatro valores de 6 bits; cada valor de 6 bits selecciona un carácter de un alfabeto de 64 caracteres. El alfabeto canónico es A-Z (índices 0-25), a-z (26-51), 0-9 (52-61), '+' (62), '/' (63), con '=' como carácter de relleno. El ejemplo clásico de RFC 4648: 'Man' (0x4d 0x61 0x6e) se empaqueta en el valor de 24 bits 0x4d616e; dividido en fragmentos de 6 bits da 0x0d 0x16 0x0e 0x0a, mapeado a 'TWFu'. Cuando la longitud de entrada no es múltiplo de 3, el grupo final se rellena con ceros a la derecha: 1 byte restante → 2 fragmentos de 6 bits significativos + '==' (2 caracteres de relleno); 2 bytes restantes → 3 fragmentos significativos + '=' (1 relleno). Los caracteres de relleno no contienen información, pero hacen que la longitud de codificación sea una función determinista de la longitud de entrada y permiten a los decodificadores rechazar entrada truncada. En el navegador, Base64 tiene dos trampas notorias. Primero, `btoa` y `atob` (las variantes DOMString) operan sobre unidades de código Latin-1, no bytes — pasar una cadena que contenga U+00E9 (é) o U+4E2D (中) lanza InvalidCharacterError. La página lo resuelve pasando por `TextEncoder().encode(str)` (siempre UTF-8) antes de llamar a `btoa`, y `TextDecoder().decode(bytes)` después de `atob`. Los caracteres multi-byte UTF-8 se expanden: '你' son 3 bytes (0xe4 0xbd 0xa0) → 4 caracteres base64 (8 caracteres base64 para '你好'). Segundo, Base64URL (RFC 4648 §5) reemplaza '+' y '/' por '-' y '_' y elimina el relleno, porque '+' y '/' son significativos para URLs y '=' termina cadenas de consulta. JWT (RFC 7519) y JWS (RFC 7515) requieren Base64URL precisamente por esta razón. Base64 es codificación, no cifrado — la forma codificada tiene cero secrecía, y el alfabeto es tan corto que cualquier observador lee el resultado trivialmente. Confundir Base64 con un mecanismo de seguridad es un patrón CVE: CVE-2004-2761 documentó la colisión de prefijo elegido MD5 en X.509 que permitía a atacantes forjar certificados con firmas MD5 en colisión, mientras que CVE-2005-4900 y otros involucraban la vieja práctica de hashes de contraseña md5crypt `$1$` siendo recodificados o re-hasheados por una capa de autenticación que confundía los bytes decodificados de Base64 con credenciales frescas. El patrón que se repite es el mismo: un sistema trata la codificación como si añadiera una capa de secrecía que no tiene, y el resultado es explotable. Para secretos reales usa AES-GCM (RFC 5288) o ChaCha20-Poly1305 (RFC 8439). Para compresión seguida de Base64 (lo que hace `gzip -b64`), ten en cuenta que la forma codificada es aproximadamente 1,37× el tamaño comprimido, y cualquier cambio de byte en el flujo comprimido rompe la decodificación — así que Base64 es una mala capa de integridad; HMAC-SHA256 sobre los bytes antes de codificar es el enfoque correcto.

• RFC 4648 (octubre 2006) define Base64, Base32 y Base16 con un alfabeto canónico (A-Z, a-z, 0-9, +, /) y '=' como carácter de relleno. La variante MIME (RFC 2045) inserta saltos de línea cada 76 caracteres para el transporte; la variante URL-safe (Base64URL, RFC 4648 §5) reemplaza + y / por - y _ y elimina el relleno — usada por JWT (RFC 7519), JWS (RFC 7515) y JWK (RFC 7517).
• Mecanismo: 3 bytes de entrada (24 bits) → 4 caracteres de salida (cada uno de 6 bits). La sobrecarga es del 33,3% — cada 1 MB de entrada binaria se convierte en 1,33 MB de Base64. Para ASCII la proporción puede ser aún peor cuando la entrada contiene '=' u otros caracteres que son escapados por protocolos circundantes.
• Regla de relleno: longitud de entrada módulo 3 = 0 → sin relleno; módulo 3 = 1 → '==' (dos caracteres de relleno, un byte codificado); módulo 3 = 2 → '=' (un carácter de relleno, dos bytes codificados). '=' no contiene información; solo permite al decodificador saber cuántos bytes se descartaron.
• Trampa de UTF-8 + btoa: `btoa('é')` lanza InvalidCharacterError porque btoa trata la entrada como unidades de código Latin-1. La página lo resuelve codificando a través de `TextEncoder` (UTF-8) antes de btoa, y decodificando a través de `TextDecoder` después de atob. Sin este paso, cualquier cosa fuera de U+0000..U+00FF se convierte en '0 bytes codificados' en lugar de un error.
• Base64URL es requerido para JWT, JWS y JWK (RFC 7519/7515/7517). Usa '-' y '_' en lugar de '+' y '/' (caracteres significativos para URLs) y elimina el relleno '=' (que termina cadenas de consulta). Pasar un segmento de cabecera JWT a un decodificador Base64 en lugar de Base64URL devuelve basura; la página no auto-detecta — elige la variante correcta para el payload.
• Rendimiento: la codificación es aproximadamente 400-700 MB/s en V8 en un portátil moderno (un bucle ajustado con búsquedas en tabla y desplazamientos de bits). La decodificación tiene velocidad similar. Para blobs grandes (10+ MB) el cuello de botella es la asignación, no el cálculo — el búfer de salida es un 33% mayor y `TextEncoder/TextDecoder` hace una copia.
• Base64 es codificación, no cifrado — cualquiera con la cadena puede leerla. CVE-2004-2761 (colisión de prefijo elegido MD5 en firmas de certificados X.509) y muchos writeups de CTF usan esta concepción errónea como primer peldaño. Para secretos usa AES-GCM (RFC 5288) o ChaCha20-Poly1305 (RFC 8439). Para data URIs, vigila el tamaño codificado: una imagen de 10 MB se convierte en una URL de 13,3 MB, que excede la mayoría de límites de longitud de URL del navegador y la mayoría de límites de tamaño de correo.
• Nota de migración: Base16 (hex) es preferido en protocolos de bajo nivel y salida de hashes porque cada byte se mapea exactamente a 2 caracteres y la longitud es predecible (sin cálculos de relleno). Base32 es preferido para transcripción humana (sin caracteres confundibles). Base64 es el valor por defecto universal para transporte binario en protocolos de texto, pero está siendo gradualmente reemplazado por bytes crudos sobre HTTP/2 y WebTransport donde el framing lo permite.