Validador de Base32

Base32: codificação case-insensitive para segredos TOTP, Tor v3 e identificadores legíveis

Base32 é a prima do Base64 desenhada para ambientes onde humanos precisam ler, digitar ou ditar a string codificada. Padronizada na RFC 4648 junto com o Base64, a Base32 usa um alfabeto pequeno o suficiente para ser case-insensitive e visualmente sem ambiguidade, sacrificando densidade em troca de legibilidade.

A cada 5 bytes de entrada correspondem 8 caracteres de saída, com 60% de overhead — pior que os 33% do Base64, mas o custo se paga ao ditar: tente ler uma string Base64 ao telefone e depois uma Base32, e a diferença fica evidente.

Alfabeto da RFC 4648 e os dígitos ausentes

O alfabeto padrão da Base32 é A-Z mais 2-7 — excluindo deliberadamente 0, 1, 8 e 9. O motivo é a transcrição humana: 0 parece O, 1 parece I ou l, e 8 e 9 visualmente lembram B e q. A regex de validação é ^[A-Z2-7]+=*$ e o tamanho deve ser múltiplo de 8.

O padding usa = exatamente como em Base64 — mas a Base32 permite até 6 caracteres de padding no fim (Base64 permite no máximo 2), porque o alinhamento de bits entre grupos de 5 bytes e blocos de 8 caracteres é menos elegante.

Crockford Base32: a alternativa humano-amigável

Douglas Crockford propôs um alfabeto Base32 alternativo otimizado para manipulação humana. Usa 0-9 e A-Z mas exclui I, L, O e U — os três primeiros porque se parecem com dígitos, o último para evitar gerar obscenidades acidentais. A Crockford Base32 é case-insensitive (minúsculas viram maiúsculas no decode), tolera hífens para legibilidade e oferece um caractere opcional de checksum. É a base dos identificadores ULID e de vários esquemas de short URL.

Onde a Base32 aparece em produção

• Segredos TOTP (Google Authenticator, Authy, 1Password): o segredo compartilhado em URIs otpauth:// é codificado em Base32. Um segredo típico tem 160 bits = 32 caracteres, geralmente exibido com espaços a cada 4 chars para facilitar a leitura.
• Endereços .onion v3 do Tor: 56 caracteres Base32 representando 35 bytes (chave pública de 256 bits + checksum + versão). A v2 tinha 16 chars; a v3 foi implantada em 2020 para resistir a colisões de hash.
• Identificadores ULID: strings de 26 caracteres em Crockford Base32 combinando timestamp de 48 bits e 80 bits de aleatoriedade, ordenáveis lexicograficamente.
• Backups de seed Bitcoin BIP-32: alguns dispositivos de armazenamento de seed usam Crockford Base32 para tornar a transcrição manual menos arriscada.
• Identificadores baseados em DNS: hostnames precisam ser case-insensitive, então Base32 encaixa naturalmente.

Base32 vs Base64 vs Base58 vs Hex

• Hex (Base16): o mais simples, 100% de overhead, só 16 chars (0-9 A-F). Fácil de ler mas verboso.
• Base32: 60% de overhead, case-insensitive, sem caracteres ambíguos. Melhor para humanos.
• Base58: 36% de overhead. Usada em endereços Bitcoin; evita 0, O, I, l. Não está na RFC 4648.
• Base64: 33% de overhead, case-sensitive, mais densa. Melhor para máquinas e largura de banda.

Bibliotecas e ferramentas

O Node não traz Base32 nativo (só Base64), então a opção é base32 ou thirty-two no npm. A biblioteca padrão do Python tem base64.b32encode / base64.b32decode (apesar do nome do módulo). Go oferece encoding/base32 com variante standard e Hex. Para Crockford Base32 especificamente, use base32-encode ou implemente a troca de alfabeto manualmente — é uma função de 10 linhas.

FAQ

Como Base32 se compara ao Base64?

Base32 é case-insensitive e usa um alfabeto sem ambiguidade visual, então é mais fácil de ler, ditar e digitar. Base64 é mais densa (33% vs 60% de overhead) mas case-sensitive. Escolha Base32 quando humanos tocam na string, Base64 quando só máquinas tocam.

O padding é obrigatório?

Na RFC 4648 estrita, sim — o tamanho codificado deve ser múltiplo de 8 com = preenchendo o vazio. Na prática, muitas bibliotecas aceitam entrada sem padding e inferem a contagem de bytes pelo número de caracteres. A Crockford Base32 dispensa padding por completo.

O Google Authenticator usa Base32?

Sim. O segredo TOTP compartilhado em URIs otpauth://totp/...?secret=... é sempre Base32. Um segredo de 160 bits produz uma string Base32 de 32 caracteres, geralmente agrupados em blocos de 4 chars para facilitar a digitação manual.

Por que excluir 0, 1, 8 e 9?

Para evitar confusão visual quando um humano lê ou transcreve a string. 0 se mistura com O, 1 com I/l, e os outros dígitos não estão excluídos por si — o alfabeto só precisa de 32 símbolos e 2-7 foi a faixa limpa escolhida.

Base32 é case-sensitive?

Não. A RFC 4648 define o alfabeto só em maiúsculas, mas a codificação é canonicamente case-insensitive: a maioria dos decoders aceita maiúsculas e minúsculas indistintamente. Por isso a Base32 cai bem em hostnames DNS e cenários de ditado.