Padding e comprimento

O comprimento da saída Base64 é previsível quando você entende agrupamento em seis bits. Caracteres de padding (=, às vezes ==) dizem “este sexteto final foi sintetizado com menos de três bytes finais” — não é mágica, só contabilidade.

Quando aparece padding

O resto da divisão do comprimento de entrada por três governa tudo:

Bytes de entrada % 3	Padding necessário
0	nenhum
1	==
2	=

Por quê? Cada quantum de saída codifica três bytes ⇒ quatro símbolos Base64. Quantum parcial ainda emite quatro símbolos, mas sextetos finais além dos bits reais são marcados com padding para o decoder truncar corretamente.

Pular padding às vezes parece funcionar porque alguma ferramenta infere automaticamente — APIs entre linguagens quebram quando um lado remove = agressivamente e outro exige forma canônica.

O que = não é

= não faz parte do alfabeto de 64 símbolos no Base64 clássico — é metacaractere de preenchimento. Decoders descartam ou interpretam como sinal de comprimento; editar = por engano (concatenação de URL, truncar ao colar) corrompe checagens de comprimento em silêncio.

Bibliotecas devem rejeitar padrões inválidos (= fora do lugar, lixo após equals) em vez de adivinhar.

Modelo mental rápido

• Cada três octetos ⇒ quatro símbolos do alfabeto.
• Byte extra? Ainda emite quatro símbolos; dois carregam semântica de padding.
• Dois bytes extras geram um =; byte sobrando gera ==.

A tabela de módulo costuma bastar para depuração, sem decorar tabelas de bits.

Quebra de linha e MIME

Encoders de e-mail antigos inseriam quebras a cada ~76 caracteres para terminais antigos. APIs Base64 simples muitas vezes omitem quebras; blocos PEM envolvem largura fixa de propósito.

Se você concatenar linhas sem remover \n/\r antes do decode, muitos decoders rígidos falham. Outros parsers ignoram espaço em qualquer lugar — saiba a postura da sua stack.

Forma de exemplo (só conceitual)

Imagine codificar a letra ASCII a (0x61). Você emite quatro caracteres imprimíveis terminando em == no padrão — vale verificar com a primitiva da sua linguagem uma vez.

Nunca edite padding na mão para “otimizar” URL — dialetos URL-safe só omitem = quando padronizados explicitamente (próxima lição).

Checagens de comprimento em código sensível

Comparando ciphertext ou assinaturas em Base64? Diferenças de comprimento normalizado expõem:

• bugs de truncamento
• double-encoding
• truncamento de query string no cliente

Trate payloads Base64 como strings opacas com validação rígida.

Resumo

Padding existe porque Base64 insiste em emitir quatro símbolos de saída por bloco de processamento, mesmo quando restam menos de vinte e quatro bits reais de entrada. Respeite padding canônico quando a API exige — e normalize/remova espaços conforme regras documentadas, não folclore.