FreeToGenerate.com

Três coisas diferentes se chamam base85 e não são compatíveis entre si. Esta página codifica as três de uma vez e mostra o que uma string significa em cada uma. Nada é enviado.

Interpretar a entrada como

Codificada nas três variantes ao mesmo tempo, para você ver o quanto elas divergem.

Experimente:

Os mesmos bytes, de três formas

VarianteSaída
Ascii85A forma do btoa e da Adobe. Os dígitos começam no ponto de exclamação.

L/669[9<6.

Z85ZeroMQ RFC 32. Recusa qualquer entrada cujo comprimento não seja múltiplo de quatro, porque a especificação não define preenchimento e deixa isso para quem chama.

HelloWorld

Alfabeto da RFC 1924O alfabeto da RFC 1924, aplicado a um fluxo de bytes em grupos de quatro. É o que quase toda biblioteca chama de base85, e não é o que a RFC 1924 de fato especifica.

hELLOwORLD

Tudo roda no seu navegador. Nada é enviado, e recarregar a página apaga o que você digitou.

Também disponível em: English · Español · Français · العربية

Codificador base85: três variantes, lado a lado

Codifique bytes como Ascii85, Z85 e com o alfabeto da RFC 1924 ao mesmo tempo, ou cole uma string e veja todas as leituras.

O que é base85?

Base85 empacota dados binários em texto imprimível usando 85 caracteres diferentes. Cada quatro bytes viram cinco caracteres, e é aí que está a razão de ser: base64 transforma três bytes em quatro, uma expansão de 33%, enquanto base85 fica em 25%. Essa economia é o que levou PostScript e PDF a adotá-lo, e por isso ele ainda aparece onde um binário precisa sobreviver a um canal de texto.

O problema é que base85 não é um formato só. Pelo menos três coisas usam esse nome e nenhuma consegue ler a saída da outra. Ascii85 usa os 85 caracteres que começam no ponto de exclamação, e é o que PostScript, PDF e o btoa original produzem. Z85, especificado pelo ZeroMQ, usa um alfabeto deliberadamente diferente, escolhido para que a saída possa ser colada em código-fonte sem problemas. E uma terceira variante, a que quase toda biblioteca de programação entende, usa o alfabeto da RFC 1924.

Esta página codifica seus bytes nas três ao mesmo tempo, para que as diferenças fiquem visíveis em vez de teóricas, e também funciona no sentido inverso: você dá uma string e ela mostra o que cada variante acha que aquilo significa.

Como usar

  1. Dê alguns bytes a ela. Em hexadecimal ou como texto, o que for melhor. Os exemplos cobrem o próprio vetor de teste da especificação do ZeroMQ, uma sequência de bytes zerados e um único byte, e cada um se comporta de forma diferente nas três variantes.
  2. Compare as três saídas. Elas aparecem juntas, com uma nota sobre o que é cada variante. Ascii85 tem duas opções que vale experimentar: os delimitadores da Adobe e a abreviação que escreve quatro bytes zerados como um único z.
  3. Ou mude para ler uma string. Cole texto base85 e todas as variantes capazes de decodificá-lo o farão, com os bytes que cada uma produz. Quando duas discordam, a própria string não diz qual está certa.

Por que trocar de variante é perigoso

Uma string base85 não carrega marca alguma dizendo qual variante a produziu. Entregue-a ao decodificador errado e acontece uma de duas coisas: ele recusa, ou aceita e devolve outros bytes sem reclamar nada.

Medido sobre cinco mil entradas aleatórias, decodificar uma saída de Ascii85 com o alfabeto da RFC 1924 devolve bytes errados sem erro cerca de 16% das vezes, e falha no resto. O sentido inverso se comporta igual, com 16,6%. Ou seja, aproximadamente uma vez a cada seis você recebe lixo plausível em vez de um aviso de que algo deu errado.

É exatamente o oposto do que este site encontrou no base58, onde os dois alfabetos concorrentes contêm os mesmos 58 caracteres em outra ordem. Ali uma troca sempre decodifica em silêncio, porque todo caractere válido num alfabeto também é válido no outro. As variantes do base85 usam conjuntos de caracteres realmente diferentes, então na maior parte das vezes a incompatibilidade gera erro. Essas cinco vezes em seis em que falha ruidosamente são o formato protegendo você; a que sobra é a razão pela qual a variante precisa ser anotada em algum lugar que não seja a própria string.

Z85 é a mais rígida das três e a menos propensa a aceitar o que não deveria. Sua especificação exige que o comprimento binário seja divisível por quatro e o do texto por cinco, e não define preenchimento algum, deixando isso para quem chama. Então ela simplesmente recusa entradas que as outras duas preencheriam, e é por isso que um dos exemplos aqui codifica em Ascii85 e no alfabeto da RFC 1924 e é recusado pelo Z85.

A variante que não é o que o nome diz

A terceira variante costuma ser chamada de base85 da RFC 1924, e esse nome engana. A RFC 1924 trata de endereços IPv6. Sua seção de codificação diz para tratar um endereço como um único inteiro de 128 bits, escrever esse inteiro em base 85 e representá-lo com 85 caracteres ASCII, o que dá exatamente vinte dígitos. Ela não descreve nenhuma forma de codificar um fluxo de bytes, e em nenhum ponto do documento se menciona processar quatro bytes por vez.

O que as bibliotecas implementam sob esse nome é o alfabeto da RFC com o agrupamento de quatro bytes do Ascii85 aplicado por cima. É uma coisa perfeitamente razoável de construir, e não é o que a RFC especifica. O terceiro modo desta página implementa o algoritmo de verdade da RFC, então você pode codificar um endereço real e obter os vinte dígitos que o documento descreve.

A RFC também vale a leitura por si só. É datada de 1º de abril de 1996, classificada como Informational, e afirma nas primeiras linhas que não especifica padrão algum da internet. Sua seção sobre por que 85 percorre a base 84 e a base 94 antes de decidir, e explica que o conjunto de caracteres foi escolhido com considerável cuidado para deixar livre a pontuação com que delimitar endereços. Tire suas próprias conclusões sobre a data.

O que isto não diz

Não diz qual variante produziu uma string que te entregaram. É justamente esse o problema: nada na codificação registra isso. Se uma string decodifica limpa em duas variantes, as duas respostas aparecem e a escolha é sua, guiada por de onde a string veio e não por qualquer coisa dentro dela.

As três variantes aqui são as de uso amplo, não todas as que existem. Ascii85 em particular tem dialetos: o programa btoa tinha uma abreviação para quatro espaços além da de quatro bytes zerados, e algumas ferramentas quebram a saída numa coluna fixa enquanto outras não. São variações dentro do Ascii85 e não formatos separados, mas bastam para duas implementações de Ascii85 discordarem sobre o texto exato.

E base85 se encaixa mal onde a saída precisa sobreviver a uma URL, a um nome de arquivo ou a um comando de shell. Todas as variantes usam pontuação com fartura, e os caracteres mudam de uma para a outra, então um texto seguro num contexto pode precisar de escape em outro. Esse é o problema que o Z85 veio resolver, e é por isso que seu alfabeto deixa de fora as aspas e a barra invertida que de outro modo precisariam de escape dentro de uma string de código.

Por que é grátis?

Mudança de base é aritmética, e roda no seu navegador. Não há servidor no meio, então não há o que cobrar nem conta a criar.

Nada é enviado. Os bytes que você cola não saem da aba.