Lição 5
Base64 vs hex
Quando escolher Base64 em vez de codificação hexadecimal.
Hexadecimal (“hex”) expande cada nibble (4 bits) em um dos dezesseis símbolos ASCII 0–9A–F. Base64 empacota mais bits por caractere de saída — seis em vez de quatro — então payloads ficam menores em contagem de caracteres, embora nem sempre menores em bytes após camadas de compressão.
Fatores de expansão (intuição)
| Codificação | Bits por símbolo de saída | Tamanho do alfabeto |
|---|---|---|
| Hex | 4 | 16 |
| Base64 | 6 | 64 |
Ignorando enquadramento, Base64 usa em geral ~4 caracteres tipados por 3 bytes brutos. Hex gasta 2 caracteres tipados por byte. A sobrecarga ~33% do Base64 parece ruim até você perceber que hex dobra o comprimento visível incondicionalmente.
Sensação concreta: dezesseis bytes brutos ⇒ trinta e dois dígitos hex vs cerca de vinte e dois caracteres Base64 (depende de alinhamento e cauda de padding).
Quando hex brilha
Prefira hex quando:
- Humanos precisam comparar visualmente fingerprints (hashes costumam sair em hex)
- Você só emite charset estreito imprimível mas quer mapeamento trivial (“cada par de hex = um byte”)
- Scripts de debug rápidos onde Base64 traz carga mental de padding
- Restrições exigem ordenação lexical case-insensitive uniforme (às vezes hex em maiúsculas padroniza comparações)
Hashes no Git, digestos SHA-256 em páginas de download — domínio do hex é ergonomia, não necessidade criptográfica.
Quando Base64 brilha
Prefira Base64 quando:
- Precisa embutir binário em envelopes de texto MIME / JSON-ish históricos rapidamente
- O canal proíbe ambiguidade de parsers insensíveis a newline com larguras estranhas (ainda observe quebras)
- Quer menos caracteres delimitadores no total versus blobs hex longos em logs (legibilidade é trade-off subjetivo)
- O ecossistema de bibliotecas já padronizou wrappers Base64 (JWT, blocos internos PEM)
Nenhum formato comprime entropia; a escolha é ergonomia de transporte.
Pipelines mistos
Padrão perigoso: SHA-256 mostrado em hex na UI → desenvolvedor Base64 codifica a string ASCII hex, não os bytes brutos do digest → inferno de mismatch de checksum. Mantenha clareza: objeto digest vs representação imprimível vs camadas de codificação no fio.
Da mesma forma, dupla aplicação (hex depois Base64) raramente ajuda — cada camada expande ou transforma sem segurança extra, salvo passos de protocolo intencionais.
Confusão de exemplo (conceitual)
digest_bytes = saída criptográfica (32 bytes opacos típicos para SHA-256)
hex_string = visão humana de digest_bytes ('a3f...')
base64_digest = outra visão dos MESMOS bytes (alfabeto diferente)
Converter formatos deve desembalar para octetos idênticos.
Nota de desempenho
Custo computacional é desprezível para tamanhos típicos (< poucos MB) em CPUs modernas. A escolha de serialização deve seguir interop + clareza, não folclore de micro-benchmark.
Resumo
Hex é maravilhosamente regular (2 chars / byte); Base64 é mais denso em pilhas ASCII imprimíveis. Codifique os bytes brutos que o protocolo pretende — não um intermediário textual acidental — e documente qual forma canônica de string os validadores esperam.
Use o Codificador / Decodificador Base64 para comparar a mesma amostra em Base64 e inspecionar saída em hex quando o decode não for texto UTF-8.