Codificador/Decodificador Base64

Base64 é um método que utiliza 64 caracteres imprimíveis para representar dados binários. Esses 64 caracteres incluem letras maiúsculas A-Z, minúsculas a-z, dígitos 0-9, e os dois símbolos + e /. Como usa apenas caracteres imprimíveis, os dados codificados em Base64 podem ser transmitidos com segurança em ambientes que suportam apenas texto, como emails, páginas web e JSON. Os dados codificados aumentam aproximadamente 33% em relação aos dados originais. Base64 apareceu pela primeira vez em 1987 no protocolo PEM para transmitir dados binários com segurança em emails. Hoje é um dos padrões da Internet, amplamente utilizado em diversos cenários, de anexos de email a tokens JWT, de imagens embarcadas a transmissão de dados. Quase todas as linguagens de programação têm funções de codificação e decodificação Base64 integradas.

Base64 é uma das várias codificações binário-para-texto especificadas na RFC 4648 (S. Josefsson, outubro de 2006), juntamente com Base16 (hex) e Base32. O nome 'Base64' e o alfabeto foram originalmente definidos para Privacy-Enhanced Mail (RFC 989, 1987), onde o PEM encapsulava material binário S/MIME e X.509 dentro de um envelope ASCII imprimível para que pudesse sobreviver a transportes limpos de 7 bits. O mesmo alfabeto tornou-se depois o padrão de facto para MIME (RFC 2045), assinaturas JWT (RFC 7519), URIs data: em HTML (RFC 2397), blobs de chave pública SSH (RFC 4253 §6.6) e arquivos de ponteiro Git LFS (que armazenam hashes SHA-256 como Base64). Os próprios packfiles do Git NÃO são Base64 — usam codificação delta com compressão zlib, e os IDs de objetos Git são strings hex SHA-1 de 40 caracteres, não Base64. O custo: cada 3 bytes de entrada se tornam 4 caracteres de saída, então a saída codificada é exatamente 4/3 do tamanho (33,3% de sobrecarga). Para um blob binário de 10 MB, a forma codificada é ~13,3 MB.

O mecanismo: divide-se a entrada em grupos de 3 bytes (24 bits); cada grupo é dividido em quatro valores de 6 bits; cada valor de 6 bits seleciona um caractere de um alfabeto de 64 caracteres. O alfabeto canônico é A-Z (índices 0-25), a-z (26-51), 0-9 (52-61), '+' (62), '/' (63), com '=' como caractere de preenchimento. O exemplo clássico da RFC 4648: 'Man' (0x4d 0x61 0x6e) é compactado no valor de 24 bits 0x4d616e; dividido em pedaços de 6 bits dá 0x0d 0x16 0x0e 0x0a, mapeado para 'TWFu'. Quando o comprimento da entrada não é múltiplo de 3, o grupo final é preenchido com zeros à direita: 1 byte restante → 2 pedaços significativos de 6 bits + '==' (2 caracteres de preenchimento); 2 bytes restantes → 3 pedaços significativos + '=' (1 preenchimento). Os caracteres de preenchimento não carregam informação, mas tornam o comprimento da codificação uma função determinística do comprimento da entrada e permitem que decodificadores rejeitem entrada truncada.

No navegador, Base64 tem duas armadilhas notórias. Primeiro, `btoa` e `atob` (as variantes DOMString) operam em unidades de código Latin-1, não bytes — passar uma string contendo U+00E9 (é) ou U+4E2D (中) lança InvalidCharacterError. A página contorna isso passando por `TextEncoder().encode(str)` (sempre UTF-8) antes de chamar `btoa`, e `TextDecoder().decode(bytes)` após `atob`. Caracteres multibyte UTF-8 se expandem: '你' são 3 bytes (0xe4 0xbd 0xa0) → 4 caracteres base64 (8 caracteres base64 para '你好'). Segundo, Base64URL (RFC 4648 §5) substitui '+' e '/' por '-' e '_' e remove o preenchimento, porque '+' e '/' são significativos para URLs e '=' termina strings de consulta. JWT (RFC 7519) e JWS (RFC 7515) exigem Base64URL exatamente por essa razão.

Base64 é codificação, não criptografia — a forma codificada tem zero sigilo, e o alfabeto é tão curto que qualquer observador lê o resultado trivialmente. Confundir Base64 com um mecanismo de segurança é um padrão de CVE: CVE-2004-2761 documentou a colisão de prefixo escolhido MD5 em X.509 que permitia a falsificação de certificados com assinaturas MD5 em colisão, enquanto CVE-2005-4900 e outros envolviam a prática antiga de hashes de senha md5crypt `$1$` sendo recodificados ou re-hasheados por uma camada de autenticação que confundia bytes decodificados de Base64 com credenciais novas. O padrão que se repete é o mesmo: um sistema trata a codificação como se adicionasse uma camada de sigilo que ela não adiciona, e o resultado é explorável. Para segredos reais, use AES-GCM (RFC 5288) ou ChaCha20-Poly1305 (RFC 8439). Para compressão seguida de Base64 (que `gzip -b64` faz), observe que a forma codificada é aproximadamente 1,37x o tamanho comprimido, e qualquer mudança de byte no fluxo comprimido quebra a decodificação — então Base64 é uma camada de integridade pobre; HMAC-SHA256 sobre os bytes antes da codificação é a abordagem correta.

• RFC 4648 (outubro de 2006) define Base64, Base32 e Base16 com um alfabeto canônico (A-Z, a-z, 0-9, +, /) e '=' como caractere de preenchimento. A variante MIME (RFC 2045) insere quebras de linha a cada 76 caracteres para transporte; a variante segura para URL (Base64URL, RFC 4648 §5) substitui + e / por - e _ e remove o preenchimento — usada por JWT (RFC 7519), JWS (RFC 7515) e JWK (RFC 7517).
• Mecanismo: 3 bytes de entrada (24 bits) → 4 caracteres de saída (cada 6 bits). A sobrecarga é de 33,3% — cada 1 MB de entrada binária se torna 1,33 MB de Base64. Para ASCII, a proporção pode ser ainda pior quando a entrada contém '=' ou outros caracteres que são escapados por protocolos adjacentes.
• Regra de preenchimento: comprimento da entrada mod 3 = 0 → sem preenchimento; mod 3 = 1 → '==' (dois caracteres de preenchimento, um byte codificado); mod 3 = 2 → '=' (um caractere de preenchimento, dois bytes codificados). '=' não carrega informação; apenas permite que o decodificador saiba quantos bytes foram descartados.
• Armadilha UTF-8 + btoa: `btoa('é')` lança InvalidCharacterError porque btoa trata a entrada como unidades de código Latin-1. A página contorna isso codificando através de `TextEncoder` (UTF-8) antes de btoa, e decodificando através de `TextDecoder` após atob. Sem essa etapa, qualquer coisa fora de U+0000..U+00FF se torna '0 bytes codificados' em vez de um erro.
• Base64URL é exigido para JWT, JWS e JWK (RFC 7519/7515/7517). Usa '-' e '_' em vez de '+' e '/' (caracteres significativos para URLs) e remove o preenchimento '=' (que termina strings de consulta). Passar um segmento de cabeçalho JWT para um decodificador Base64 em vez de Base64URL retorna lixo; a página não auto-detecta — escolha a variante correta para o payload.
• Desempenho: a codificação é aproximadamente 400-700 MB/s no V8 em um laptop moderno (um loop apertado fazendo buscas em tabela e deslocamentos de bits). A decodificação tem velocidade semelhante. Para blobs grandes (10+ MB), o gargalo é a alocação, não o cálculo — o buffer de saída é 33% maior e `TextEncoder/TextDecoder` faz uma cópia.
• Base64 é codificação, não criptografia — qualquer pessoa com a string pode lê-la. CVE-2004-2761 (colisão de prefixo escolhido MD5 em X.509 em assinaturas de certificado) e muitos writeups de MISC-CTF usam esse equívoco como primeiro degrau. Para segredos, use AES-GCM (RFC 5288) ou ChaCha20-Poly1305 (RFC 8439). Para URIs de dados, observe o tamanho codificado: uma imagem de 10 MB se torna uma URL de 13,3 MB, que excede a maioria dos limites de comprimento de URL dos navegadores e a maioria dos limites de tamanho de email.
• Nota de migração: Base16 (hex) é preferida em protocolos de baixo nível e saída de hash porque cada byte mapeia para exatamente 2 caracteres e o comprimento é previsível (sem matemática de preenchimento). Base32 é preferida para transcrição humana (sem caracteres visualmente semelhantes). Base64 é o padrão universal para transporte binário em protocolos de texto, mas está sendo gradualmente substituído por bytes crus sobre HTTP/2 e WebTransport onde o framing permite.