Codificador y decodificador quoted-printable

Qué es quoted-printable

Quoted-printable es una de las dos formas en que el correo transporta texto que no sobreviviría a un canal de siete bits. Está definido en el RFC 2045, el mismo documento que define base64, y ambos son alternativas para exactamente el mismo trabajo. Su truco consiste en dejar intacto todo lo que ya es seguro y escapar solo lo que no lo es, escribiendo cada byte problemático como un signo igual y dos dígitos hexadecimales: así una letra acentuada se convierte en algo como =C3=A9 y todo lo que la rodea sigue siendo legible.

Esa legibilidad es justamente el objetivo. Un mensaje en base64 es un bloque opaco; uno en quoted-printable es el texto original salpicado de escapes, y por eso normalmente puedes abrir el código fuente de un correo y entender lo que dice. Si alguna vez has visto =E2=80=99 donde debería haber un apóstrofo, has visto quoted-printable mostrado sin decodificar.

Esta herramienta va en las dos direcciones. Codifica texto a quoted-printable y lo decodifica de vuelta, y junto al resultado te dice si base64 habría ocupado menos con lo que le has dado, porque para algunos textos así sería y la especificación deja esa elección en tus manos.

Cómo se usa

1. Elige la dirección. Codificar convierte texto normal en quoted-printable; Decodificar toma quoted-printable y te devuelve el texto. La salida se actualiza mientras escribes.
2. Pega tu texto. Vale cualquier cosa: una frase, el cuerpo entero de un mensaje o el fragmento estropeado de un correo que estés depurando. Los saltos de línea se tratan como exige la especificación.
3. Lee la comparación. Debajo de la salida tienes el tamaño de tu texto en las dos codificaciones y cuál gana. Al decodificar, ahí aparece también todo lo que en la entrada se aparte de las reglas.

Quoted-printable o base64, y dónde está la frontera

Las dos codificaciones tienen modelos de coste completamente distintos, así que la respuesta depende del texto y no de la preferencia. Quoted-printable gasta un carácter por cada byte que puede dejar tal cual y tres por cada uno que no, de modo que un texto en el que hay que escapar una fracción p de los bytes cuesta 1 + 2p por byte. Base64 gasta cuatro caracteres por cada tres bytes, sean los que sean, es decir 4/3. Igualando las dos expresiones sale p = 1/6: en torno al 16,7 % de bytes no ASCII las dos empatan, y por encima gana base64.

Esa cifra no cuenta los saltos de línea, y contarlos la mueve: menos de un punto, pero en un sentido fácil de equivocar. Las dos codificaciones tienen que mantener las líneas dentro de 76 caracteres. Un salto suave de quoted-printable cuesta tres caracteres, porque el signo igual que lo marca es uno de ellos; un salto de base64 cuesta dos. Los costes no se anulan, y arrastrando los dos el punto de cruce real queda más cerca del 15,8 %. La aritmética parece simétrica justo hasta que cuentas el signo igual.

En la práctica esto se reparte según el sistema de escritura. Un mensaje en español, francés, inglés o portugués es casi todo ASCII con unos pocos acentos, así que quoted-printable sale por aproximadamente tres cuartas partes del tamaño de base64 y encima sigue siendo legible. Un mensaje en árabe o japonés es no-ASCII de principio a fin, y quoted-printable lo duplica con creces: esos van en base64, y ninguna preferencia cambia eso.

Merece la pena saberlo porque mucho software elige una y no vuelve a revisarlo. Si tu correo es sobre todo de alfabeto latino, quoted-printable es a la vez más pequeño y legible. Si no lo es, estás pagando tres caracteres por byte a cambio de nada.

Limitaciones honestas

Hay una regla que sorprende y es el motivo de que aparezca =20 al final de las líneas. Un espacio normalmente se deja tal cual, pero un espacio o un tabulador que caiga al final de una línea tiene que codificarse. El RFC 2045 es inusualmente franco sobre el porqué: se sabe que hay servidores de correo que rellenan las líneas con espacios y otros que eliminan el espacio final, así que un espacio visible al final de línea puede sencillamente no llegar. Codificarlo es la única forma de garantizar que sobreviva.

Al decodificar, esta herramienta informa en lugar de reparar. La especificación cierra su definición con una lista de cosas que un codificador correcto nunca puede producir —dígitos hexadecimales en minúscula, un signo igual seguido de algo que no es hexadecimal, un signo igual al final del todo, bytes crudos por encima de 126, líneas de más de 76 caracteres— y sugiere cómo debería reaccionar un decodificador ante cada una. Aquí se siguen esas sugerencias y después se te dice qué se ha encontrado, porque si estás decodificando un mensaje roto seguramente quieras saber que estaba roto.

Los codificadores también pueden discrepar entre sí. La especificación dice que los caracteres imprimibles pueden dejarse tal cual, no que deban, así que dos implementaciones correctas pueden producir salidas distintas para la misma entrada y las dos tener razón. Por eso esta herramienta se comprobó verificando que su salida y la de una implementación de referencia se decodifican a los mismos bytes en las dos direcciones, en vez de exigir que las dos cadenas coincidan.

Una diferencia real que conviene señalar: los finales de línea. Esta herramienta normaliza los saltos a CRLF, que es la forma que la especificación llama canónica para el texto. Algunas implementaciones dejan lo que se les dio. Las dos cosas están permitidas, y significa que una comparación byte a byte entre dos herramientas puede diferir solo en los finales de línea sin que ninguna se equivoque.

¿Por qué es gratis?

Todo ocurre en tu navegador. Cambiar bytes por secuencias de escape no es trabajo que necesite un servidor, así que no hay nada que mantener, nada que facturar y ninguna cuenta que crear.

Nada de lo que pegas se sube, se guarda ni se registra. El cuerpo de un correo está entre las cosas más privadas que alguien pondría en un cuadro de texto, y la única forma fiable de tratar eso es no recibirlo nunca.