Validador de Base32hex

Validação Base32hex: o primo ordenável do Base32

Base32hex é a variante "extended hex" do Base32, padronizada na RFC 4648 seção 7. Codifica dados binários como texto de 32 caracteres, mas com um detalhe crítico: o alfabeto usa dígitos 0–9 seguidos das letras A–V, ordenados pelos seus codepoints ASCII. Essa ordenação faz com que a ordem de bytes da string codificada coincida com a ordem de bytes do binário original — uma propriedade que o Base32 padrão (que coloca A–Z primeiro e 2–7 depois) não tem.

O alfabeto completo:

0 1 2 3 4 5 6 7 8 9 A B C D E F G H I J K L M N O P Q R S T U V

Note que os primeiros 16 caracteres (0-9 A-F) coincidem exatamente com o alfabeto hexadecimal — daí o "hex" no nome. Codificar a sequência de bytes [0x14, 0xfb] resulta em CO====== em base32hex (compare com CT7Q==== no Base32 padrão).

Base32hex vs Base32 padrão vs Crockford

• Base32 padrão (RFC 4648 §6) — alfabeto A-Z 2-7. Letras primeiro, sem propriedade de ordenação. Usado em segredos TOTP, S/MIME e codificação segura para email.
• Base32hex (RFC 4648 §7) — alfabeto 0-9 A-V. Dígitos primeiro, ordenável. Usado em registros DNSSEC NSEC3.
• Crockford Base32 — alfabeto 0-9 A-Z menos I L O U. Amigável para humanos (pula letras visualmente ambíguas), case-insensitive na entrada. Usado em ULID.

As três variantes são incompatíveis — uma string codificada em Base32hex passada para um decoder Base32 padrão dá erro ou produz lixo. Sempre verifique qual variante a sua lib usa por padrão: o Buffer do Node não tem Base32 nativo, base64.b32encode do Python é o padrão e base64.b32hexencode é a variante hex, e o pacote encoding/base32 do Go expõe HexEncoding ao lado de StdEncoding.

Regras de padding e tamanho

Base32 (ambas variantes) empacota 5 bits por caractere. Como bytes de 8 bits não dividem certo em pedaços de 5 bits, o tamanho da saída é múltiplo de 8 e é completado com = no fim. O número de caracteres de padding depende do tamanho da entrada módulo 5:

• 1 byte → 2 chars + 6 de padding (==‍====)
• 2 bytes → 4 chars + 4 de padding
• 3 bytes → 5 chars + 3 de padding
• 4 bytes → 7 chars + 1 de padding
• 5 bytes → 8 chars, sem padding

A RFC exige o padding, mas muitos parsers são tolerantes — aceitam strings sem padding e inferem o tamanho pela contagem de caracteres. Validadores devem aceitar ambas as formas, a menos que estejam interoperando com um consumer estrito.

Onde base32hex é usado

O caso de uso de referência é em registros DNSSEC NSEC3 (RFC 5155): os labels dos owner-names com hash são emitidos em base32hex minúsculo especificamente porque a ordem lexicográfica sobre os labels codificados precisa bater com a ordem dos hashes originais, para que os resolvers consigam encontrar registros NSEC3 cobertores por comparação de string. Outras aplicações escolhem base32hex quando precisam de uma string case-insensitive, ordenável e URL-safe — por exemplo IDs em estilo slug em sistemas content-addressed, ou tokens compactos que viajam em headers HTTP sem problemas de normalização de caixa.

Note que base32hex não tem checksum embutido. Se você precisa de integridade, anexe um HMAC ou CRC32 aos bytes de origem antes de codificar.

Perguntas frequentes

Qual a diferença para o Base32 padrão? A mecânica de codificação é a mesma (5 bits por char, padding para múltiplos de 8), só o alfabeto muda. Base32hex põe dígitos primeiro, então a string codificada ordena na mesma ordem dos bytes de origem.

Strings base32hex são ordenáveis? Sim — esse é o ponto inteiro. Comparação lexicográfica da forma codificada dá o mesmo resultado que um memcmp dos bytes originais. O Base32 padrão não tem essa propriedade porque A < 2 em ASCII.

O padding = é obrigatório? A RFC diz que sim; na prática, muitas libs aceitam entrada sem padding. Em owner-names DNSSEC, o padding é omitido por convenção. Para interoperar com parsers estritos, sempre padding.

Base32hex é case-sensitive? O alfabeto só contém maiúsculas A–V, mas pela RFC 4648 a decodificação é case-insensitive — letras minúsculas a-v são aceitas na entrada e produzem os mesmos bytes.