Codificador e decodificador quoted-printable

O que é quoted-printable

Quoted-printable é uma das duas formas pelas quais o e-mail carrega texto que não sobreviveria a um canal de sete bits. Está definido na RFC 2045, o mesmo documento que define o base64, e os dois são alternativas para exatamente o mesmo trabalho. O truque dele é deixar intacto tudo que já é seguro e escapar só o que não é, escrevendo cada byte problemático como um sinal de igual e dois dígitos hexadecimais — assim uma letra acentuada vira algo como =C3=A9 e tudo em volta continua legível.

Essa legibilidade é justamente o objetivo. Uma mensagem em base64 é um bloco opaco; uma em quoted-printable é o texto original salpicado de escapes, e é por isso que normalmente dá para abrir o código-fonte de um e-mail e entender o que ele diz. Se você já viu =E2=80=99 onde deveria haver um apóstrofo, viu quoted-printable exibido sem ter sido decodificado.

Esta ferramenta vai nos dois sentidos. Codifica texto para quoted-printable e decodifica de volta, e ao lado do resultado diz se o base64 teria ficado menor para o que você deu, porque para alguns textos ficaria — e a especificação deixa essa escolha com você.

Como usar

1. Escolha o sentido. Codificar transforma texto comum em quoted-printable; Decodificar pega quoted-printable e devolve o texto. A saída se atualiza enquanto você digita.
2. Cole seu texto. Vale qualquer coisa: uma frase, o corpo inteiro de uma mensagem ou o trecho estragado de um e-mail que você está depurando. As quebras de linha são tratadas como a especificação exige.
3. Leia a comparação. Abaixo da saída ficam o tamanho do seu texto nas duas codificações e qual delas vence. Ao decodificar, também aparece ali tudo que na entrada fuja das regras.

Quoted-printable ou base64, e onde fica a fronteira

As duas codificações têm modelos de custo completamente diferentes, então a resposta depende do texto e não da preferência. O quoted-printable gasta um caractere por byte que pode deixar como está e três por byte que não pode, de modo que um texto em que uma fração p dos bytes precisa de escape custa 1 + 2p por byte. O base64 gasta quatro caracteres a cada três bytes, sejam quais forem, ou seja 4/3. Igualando as duas expressões sai p = 1/6: por volta de 16,7% de bytes não ASCII os dois empatam, e acima disso o base64 vence.

Esse número ignora as quebras de linha, e contá-las o desloca — menos de um ponto, mas num sentido fácil de inverter. As duas codificações precisam manter as linhas dentro de 76 caracteres. Uma quebra suave do quoted-printable custa três caracteres, porque o sinal de igual que a marca é um deles; uma quebra do base64 custa dois. Os custos não se anulam, e carregando os dois o ponto de virada real fica mais perto de 15,8%. A aritmética parece simétrica exatamente até você contar o sinal de igual.

Na prática isso se divide pelo sistema de escrita. Uma mensagem em português, espanhol, inglês ou francês é quase toda ASCII com alguns acentos, então o quoted-printable sai por cerca de três quartos do tamanho do base64 e ainda por cima continua legível. Uma mensagem em árabe ou japonês é não-ASCII do começo ao fim, e o quoted-printable mais que dobra o tamanho: essas vão de base64, e preferência nenhuma muda isso.

Vale saber porque muito software escolhe um e nunca revisita. Se o seu e-mail é sobretudo em alfabeto latino, o quoted-printable é ao mesmo tempo menor e legível. Se não é, você está pagando três caracteres por byte em troca de nada.

Limitações honestas

Há uma regra que surpreende e é o motivo de aparecer =20 no fim das linhas. Um espaço normalmente fica como está, mas um espaço ou tabulação que caia no fim de uma linha precisa ser codificado. A RFC 2045 é incomumente franca sobre o porquê: sabe-se que há servidores de e-mail que preenchem linhas com espaços e outros que removem o espaço final, então um espaço visível no fim da linha pode simplesmente não chegar. Codificá-lo é a única forma de garantir que ele sobreviva.

Ao decodificar, esta ferramenta informa em vez de consertar. A especificação fecha sua definição com uma lista de coisas que um codificador correto nunca consegue produzir — dígitos hexadecimais minúsculos, um sinal de igual seguido de algo que não é hexadecimal, um sinal de igual bem no fim, bytes crus acima de 126, linhas com mais de 76 caracteres — e sugere como um decodificador deve lidar com cada uma. Aqui essas sugestões são seguidas e depois se diz o que foi encontrado, porque se você está decodificando uma mensagem quebrada provavelmente quer saber que ela estava quebrada.

Os codificadores também podem discordar entre si. A especificação diz que caracteres imprimíveis podem ser deixados como estão, não que devam, então duas implementações corretas podem produzir saídas diferentes para a mesma entrada e as duas estarem certas. Por isso esta ferramenta foi conferida verificando que a saída dela e a de uma implementação de referência decodificam para os mesmos bytes nos dois sentidos, em vez de exigir que as duas strings coincidam.

Uma diferença real que vale sinalizar: os finais de linha. Esta ferramenta normaliza as quebras para CRLF, que é a forma que a especificação chama de canônica para texto. Algumas implementações deixam o que receberam. As duas coisas são permitidas, e isso significa que uma comparação byte a byte entre duas ferramentas pode divergir só nos finais de linha sem que nenhuma esteja errada.

Por que é grátis?

Tudo acontece no seu navegador. Trocar bytes por sequências de escape não é trabalho que precise de servidor, então não há nada para manter, nada para cobrar e nenhuma conta para criar.

Nada do que você cola é enviado, guardado ou registrado. O corpo de um e-mail está entre as coisas mais privadas que alguém colocaria numa caixa de texto, e a única forma confiável de lidar com isso é nunca recebê-lo.