Codificador e descodificador base32

O que é o base32

O base32 representa bytes quaisquer com 32 caracteres imprimíveis, para que dados que não são texto possam viajar por sítios que só aceitam texto. Está definido na RFC 4648, a mesma especificação que define o base64 e o base16, e trabalha em grupos de cinco bytes: quarenta bits repartidos por oito grupos de cinco, e cada grupo passa a ser um carácter.

A pergunta óbvia é porquê usá-lo se existe o base64 e ocupa menos. O base32 gasta oito caracteres por cada cinco bytes contra os quatro por cada três do base64: uma proporção de 8/5 contra 4/3, o que deixa o base32 exactamente em 6/5, ou seja 20 por cento maior. Esses 20 por cento pagam-se por uma única propriedade: o alfabeto não distingue maiúsculas de minúsculas. O base64 precisa das duas caixas para chegar a 64 caracteres, portanto tudo o que uniformize a caixa o destrói. O base32 usa apenas 26 letras e seis algarismos, por isso sobrevive a sistemas de ficheiros que ignoram a caixa, a etiquetas DNS, a nomes de máquina e a ser lido em voz alta ou copiado à mão.

É essa a troca toda, e explica onde o base32 aparece de facto: em registos de DNSSEC, nas ligações magnet das redes de partilha e nos segredos partilhados que as aplicações de duplo factor guardam, onde por vezes é uma pessoa que tem de escrever aquilo.

Como usar

1. Escolha Codificar ou Descodificar e depois um alfabeto. O padrão é o que quer, a não ser que saiba o contrário. O hex estendido é o outro alfabeto que a RFC 4648 define, e a secção abaixo explica quando é o certo.
2. Cole o seu texto ou o seu base32 na caixa. A codificar verá os bytes à entrada, os caracteres à saída e a proporção de expansão. A descodificar a ferramenta é tolerante com espaços e com minúsculas, porque aqui nenhuma das duas coisas significa o que quer que seja.
3. Copie o resultado. A codificar pode desligar o enchimento final de sinais de igual, porque as especificações reais desligam-no. E se colar algo que não seja uma codificação canónica, a ferramenta descodifica na mesma e di-lo, em vez de fingir que a entrada estava bem.

Dois alfabetos, e o que ninguém implementa é o que se ordena

A RFC 4648 define o base32 duas vezes. A secção 6 dá o alfabeto conhecido: de A a Z e depois os algarismos de 2 a 7. A secção 7 dá um segundo alfabeto a que chama hex estendido: os algarismos de 0 a 9 e depois de A a V. Quase todas as implementações oferecem só o primeiro, e a razão de o segundo existir é exacta, não decorativa.

O alfabeto hex estendido está em ordem ASCII ascendente. Os valores vão de 0 a 9 e depois de A a V, que é a ordem pela qual esses caracteres já se ordenam, portanto a cadeia codificada ordena-se exactamente como os bytes por baixo dela. O alfabeto padrão não está em ordem ASCII: atribui o valor 0 à letra A, que é 0x41, e o valor 26 ao algarismo 2, que é 0x32. Os últimos seis valores ordenam-se por isso antes dos primeiros vinte e seis, e a ordem parte-se.

Isto é uma afirmação que convém medir em vez de aceitar, e por isso os testes medem-na. Sobre vinte mil pares gerados de cadeias de bytes do mesmo comprimento, o alfabeto hex estendido preserva a ordem de todos os pares sem excepção. O padrão preserva-a 74 por cento das vezes, o que é o mesmo que dizer que normalmente parece resultar e falha exactamente quando se precisa dele.

A propriedade tem um consumidor real, que é a melhor confirmação que há. Os registos NSEC3 do DNSSEC, especificados na RFC 5155, guardam nomes de proprietário já resumidos em base32 com o alfabeto hex estendido, e a especificação diz porquê por palavras suas: essa ordem é a mesma que a ordem canónica de nomes DNS quando os nomes são codificados assim. O NSEC3 funciona provando que nenhum nome cai no intervalo entre dois vizinhos, portanto ali a ordem não é uma comodidade, é o mecanismo. A RFC 5155 dispensa ainda o enchimento por completo, e é por isso que esta ferramenta o deixa desligar.

O preço é visual, e é mais subtil do que parece à partida. O alfabeto padrão não evita simplesmente os caracteres de aspecto ambíguo: mantém as letras O e I, que são justamente as ambíguas. O que evita são os pares ambíguos, porque não estando os algarismos 0 e 1 no alfabeto, um O só pode ser uma letra e um 1 nunca pode aparecer, de modo que a má leitura não é possível. O hex estendido contém 0, 1, O e I ao mesmo tempo, e essa ambiguidade verdadeira é o que ele paga por se ordenar.

O enchimento, e três comprimentos que não podem existir

As regras de enchimento do base32 são mais estritas do que as do base64 e erram-se com mais frequência. Como oito caracteres levam cinco bytes, um grupo final incompleto deixa um corpo de 2, 4, 5 ou 7 caracteres, enchido até oito com 6, 4, 3 ou 1 sinais de igual respectivamente. Esses quatro números não são uma convenção, são aritmética, e um descodificador que aceite qualquer outra quantidade está a aceitar algo que nenhum codificador produziu.

A consequência mais afiada é que há três comprimentos impossíveis. O corpo de um base32 nunca pode ter 1, 3 ou 6 caracteres acima de um múltiplo de oito, porque não existe número de bytes de entrada que os produza. Compare-se com o base64, onde só um comprimento em quatro é impossível. Portanto um base32 com o comprimento errado não está meramente curto ou truncado: é a prova de que alguma coisa a montante está partida, e esta ferramenta di-lo em vez de adivinhar o que se quereria dizer.

O enchimento em si é opcional na prática. Os exemplos da própria RFC incluem-no, o DNSSEC omite-o expressamente e os segredos dos autenticadores escrevem-se normalmente sem ele. Esta ferramenta aceita a entrada das duas maneiras e deixa escolher ao codificar, porque ambas são legítimas e uma ferramenta que insistisse numa só estaria errada acerca de metade do mundo.

Quando os mesmos bytes têm várias grafias

A secção 3.5 da RFC 4648 chama-se Codificação canónica e descreve um problema que quase todas as ferramentas ignoram. Quando o grupo final está incompleto, o último carácter leva alguns bits de dados verdadeiros e alguns bits sobrantes. A especificação diz que um codificador conforme tem de pôr esses bits sobrantes a zero, e avisa que, se não o fizer, não existe representação canónica e várias cadeias diferentes descodificam para os mesmos dados binários.

O número de grafias é fixado pela aritmética. Um corpo que acaba em 2 caracteres tem 2 bits livres, portanto quatro cadeias diferentes descodificam para o mesmo byte; um corpo de 4 caracteres tem 4 bits livres e dezasseis grafias; um de 5 tem 1 bit livre e duas; um de 7 tem 3 bits livres e oito. Em concreto, a letra solta f codifica-se como MY, e MZ, M2 e M3 também descodificam para f.

A especificação apenas diz que um descodificador pode rejeitar essa entrada, e como é um pode, praticamente nada o faz. A biblioteca padrão do Python é um exemplo razoável de implementação cuidada, e aceitou duas mil de duas mil cadeias mutadas de propósito, devolvendo os bytes originais em todas elas sem dizer nada. Isso é comportamento conforme e é também a maneira como uns mesmos dados acabam com várias representações dentro de sistemas que partiam do princípio de que tinham uma.

Esta ferramenta escolhe a terceira via. Descodifica a entrada não canónica, porque recusar seria pouco útil e contaria menos, e a seguir diz que a codificação não era canónica e mostra o que um codificador conforme teria escrito. Se anda a comparar cadeias base32 por igualdade nalgum sítio, como chaves de cache, como identificadores ou para eliminar duplicados, essa diferença é precisamente o erro que procura.

Limites honestos

Isto codifica e descodifica texto, não ficheiros. A entrada é tratada como texto e convertida em bytes UTF-8 antes de codificar, e à volta os bytes têm de ser UTF-8 válido ou a ferramenta di-lo em vez de lhe entregar caracteres de substituição. Essa última verificação significa que não pode usar esta página para fazer passar binário qualquer pela direcção de descodificação, e é deliberado: estragar bytes em silêncio é pior do que recusá-los.

O base32 é uma codificação, não uma cifra. Não esconde nada. Qualquer pessoa que reconheça o conjunto de caracteres o descodifica em segundos, e o facto de uma cadeia parecer opaca não é protecção nenhuma. Se o que quer é um texto que os outros não consigam ler, o que quer é cifra, que é outra página deste sítio.

Por fim, os dois alfabetos daqui são os dois que a RFC 4648 define. Por aí existem outras variantes de base32, como a de Crockford, que elimina várias letras e funde outras, ou o z-base-32, que reordena o alfabeto a pensar nas pessoas, e não são interoperáveis nem com estas nem entre si. Se uma cadeia não descodificar aqui, a variante é a primeira coisa a verificar.

Porque é grátis

Porque não custa nada manter. A codificação e a descodificação acontecem no seu navegador à medida que escreve; nada é enviado, nada é registado e nenhum servidor vê o seu texto porque não há servidor nenhum pelo meio.

Portanto não há conta, nem registo, nem nada guardado atrás de um. Os alfabetos e as regras de enchimento saem da própria RFC 4648, os vectores de teste da bateria são os que a especificação publica, e os resultados são confrontados com a biblioteca padrão do Python como implementação independente.