Codec Base64

Base64 transforma datos binarios arbitrarios en una representación de texto ASCII usando un alfabeto de 64 caracteres (A-Z, a-z, 0-9, +, /) más el carácter de padding (=). El proceso está definido en RFC 4648 y opera de la siguiente manera: • Agrupación en bloques de 3 bytes — Los datos de entrada se dividen en bloques de 24 bits (3 bytes de 8 bits). Cada bloque de 24 bits se subdivide en cuatro grupos de 6 bits. Cada grupo de 6 bits (valores 0-63) se mapea a un carácter del alfabeto Base64. Ejemplo: el texto "Man" (bytes 0x4D, 0x61, 0x6E) produce los índices 19, 22, 5, 46, que corresponden a los caracteres "TWFu". • Padding — Si la entrada no es multiplo de 3 bytes, se añade padding con =. Un byte sobrante produce dos caracteres Base64 + "==" (se añaden dos bytes nulos para completar el bloque). Dos bytes sobrantes producen tres caracteres Base64 + "=". El padding permite al decodificador determinar la longitud exacta de los datos originales. • Overhead de tamaño — La codificación Base64 expande los datos en un factor de 4/3 (aproximadamente 33%). Cada 3 bytes de entrada producen 4 caracteres de salida. Con line breaks (MIME requiere lineas de 76 caracteres), el overhead puede llegar al 37%. Este costo es relevante para datos grandes: un archivo de 1 MB codificado en Base64 ocupara ~1.33 MB. • Base64URL — La variante definida en RFC 4648 sección 5 reemplaza + por - y / por _, y típicamente omite el padding =. Esto produce cadenas seguras para URLs, query parameters, nombres de archivo y fragmentos de URI sin necesidad de percent-encoding adicional. Los JWT usan Base64URL para header y payload.

La interacción entre Base64 y UTF-8 es una fuente frecuente de bugs en aplicaciones web: • El problema — Base64 opera sobre bytes, no sobre caracteres. La función btoa() nativa del navegador solo acepta caracteres Latin-1 (código 0-255) y lanza una excepción con cualquier carácter fuera de ese rango, incluyendo emojis, caracteres CJK y muchos símbolos Unicode. El error típico es: "Failed to execute 'btoa': The string to be encoded contains characters outside of the Latin1 range." • La solución estándar — Primero se codifica el texto en bytes UTF-8 usando TextEncoder, y luego se aplica Base64 sobre esos bytes. En el navegador moderno: new TextEncoder().encode(text) devuelve un Uint8Array con la representación UTF-8. Para la decodificación inversa: se decodifica Base64 a bytes y luego se usa new TextDecoder('utf-8').decode(bytes). Esta herramienta implementa este flujo correcto automáticamente. • Impacto en el tamaño — Un carácter ASCII ocupa 1 byte en UTF-8, un carácter acentuado o griego ocupa 2 bytes, caracteres CJK ocupan 3 bytes, y emojis ocupan 4 bytes. Después de aplicar Base64 (expansión 4/3), un emoji que ocupa 4 bytes UTF-8 se convierte en 8 caracteres Base64. Esto es importante al calcular límites de tamaño en APIs, headers HTTP o campos de base de datos. • Errores comunes — Codificar con btoa() sin pasar por UTF-8 primero (falla con caracteres no Latin-1). Decodificar bytes UTF-8 como Latin-1 en lugar de UTF-8 (produce mojibake: caracteres corruptos). Mezclar Base64 estándar y Base64URL sin conversión (caracteres + y / no coinciden con - y _). Aplicar doble codificación Base64 accidentalmente.

Base64 es ubicuo en la web y en protocolos de comunicación: • Data URIs — Permiten incrustar recursos directamente en HTML o CSS sin peticiones HTTP adicionales. Formato: data:[mediatype];base64,[datos]. Ejemplo: data:image/png;base64,iVBORw0KGgo... para iconos pequeños. Util para iconos SVG inline, favicons y imagenes pequeñas (<2-3 KB), pero contraproducente para imagenes grandes porque el overhead de 33% y la imposibilidad de cache independiente superan el beneficio de ahorrar una petición HTTP. • MIME y correo electrónico — RFC 2045 define Base64 como uno de los Content-Transfer-Encoding para adjuntos de correo. El correo SMTP solo transporta texto ASCII de 7 bits, por lo que archivos binarios (PDF, imagenes, ejecutables) deben codificarse en Base64 con lineas de 76 caracteres. Es por esto que los adjuntos de correo aumentan el tamaño del mensaje en aproximadamente un 33%. • HTTP Basic Authentication — RFC 7617 define el esquema donde las credenciales se envían como Authorization: Basic base64(usuario:contraseña). Base64 no proporciona seguridad alguna (es codificación, no cifrado); la seguridad depende exclusivamente de HTTPS. Enviar Basic Auth sobre HTTP plano expone las credenciales en texto claro. • JWT (JSON Web Tokens) — Header y payload se codifican en Base64URL. La firma se calcula sobre las cadenas Base64URL y se codifica también en Base64URL. Usar Base64 estándar en lugar de Base64URL en un JWT produce tokens invalidos. • APIs y almacenamiento — Campos binarios en JSON (que no soporta datos binarios nativamente) se transmiten como cadenas Base64. Certificados X.509 en formato PEM usan Base64 con cabeceras -----BEGIN CERTIFICATE-----. Claves SSH en formato authorized_keys usan Base64. Variables de entorno en Kubernetes Secrets almacenan valores en Base64. • Cuando NO usar Base64 — Para transmitir archivos grandes: usar multipart/form-data o streams binarios directos. Para cifrar datos: Base64 es codificación reversible, no proporciona confidencialidad. Para comprimir datos: Base64 aumenta el tamaño, no lo reduce. Para almacenar imagenes en base de datos: usar columnas BLOB o almacenamiento de objetos (S3) con referencias.