Codificador base85: tres variantes, una al lado de otra

¿Qué es base85?

Base85 mete datos binarios en texto imprimible usando 85 caracteres distintos. Cada cuatro bytes se convierten en cinco caracteres, y ahí está su razón de ser: base64 convierte tres bytes en cuatro, un 33% de expansión, mientras que base85 se queda en un 25%. Ese ahorro es lo que llevó a PostScript y al PDF a adoptarlo, y por lo que sigue apareciendo allí donde un binario tiene que sobrevivir a un canal de texto.

El problema es que base85 no es un solo formato. Al menos tres cosas usan ese nombre y ninguna sabe leer la salida de las otras. Ascii85 usa los 85 caracteres que empiezan en el signo de exclamación, y es lo que producen PostScript, el PDF y el btoa original. Z85, especificado por ZeroMQ, usa un alfabeto deliberadamente distinto, elegido para que la salida se pueda pegar en código fuente sin problemas. Y una tercera variante, la que entienden casi todas las bibliotecas de programación, usa el alfabeto del RFC 1924.

Esta página codifica tus bytes con las tres a la vez, para que las diferencias se vean en lugar de quedarse en la teoría, y también funciona en la otra dirección: le das una cadena y te enseña qué cree cada variante que significa.

Cómo usarla

1. Dale unos bytes. En hexadecimal o como texto, lo que te venga mejor. Los ejemplos cubren el propio vector de prueba de la especificación de ZeroMQ, una tanda de bytes a cero y un único byte, y cada uno se comporta de forma distinta en las tres variantes.
2. Compara las tres salidas. Aparecen juntas, con una nota sobre qué es cada variante. Ascii85 tiene dos opciones que merece la pena probar: los delimitadores de Adobe y la abreviatura que escribe cuatro bytes a cero como una sola z.
3. O cambia a leer una cadena. Pega texto base85 y todas las variantes capaces de descodificarlo lo harán, con los bytes que produce cada una. Cuando dos discrepan, la propia cadena no puede decirte cuál acierta.

Por qué cambiar de variante es peligroso

Una cadena base85 no lleva ninguna marca que diga qué variante la produjo. Dásela al descodificador equivocado y pasará una de dos cosas: la rechaza, o la acepta y te devuelve otros bytes sin quejarse lo más mínimo.

Medido sobre cinco mil entradas aleatorias, descodificar una salida de Ascii85 con el alfabeto del RFC 1924 devuelve bytes erróneos sin error alrededor del 16% de las veces, y falla el resto. La dirección contraria se comporta igual, con un 16,6%. Así que aproximadamente una vez de cada seis obtienes basura verosímil en lugar de un aviso de que algo ha ido mal.

Es justo lo contrario de lo que este sitio encontró con base58, donde los dos alfabetos en competencia contienen los mismos 58 caracteres en otro orden. Allí un cambio siempre descodifica en silencio, porque todo carácter válido en un alfabeto lo es también en el otro. Las variantes de base85 usan conjuntos de caracteres realmente distintos, así que la mayoría de las veces el desajuste produce un error. Esas cinco veces de cada seis en que falla ruidosamente son el formato protegiéndote; la que queda es la razón por la que la variante hay que anotarla en algún sitio que no sea la propia cadena.

Z85 es la más estricta de las tres y la que menos probable es que acepte algo que no debería. Su especificación exige que la longitud binaria sea divisible entre cuatro y la del texto entre cinco, y no define relleno alguno: se lo deja a quien la llama. Así que rechaza sin más entradas que las otras dos rellenarían, y por eso uno de los ejemplos de aquí se codifica con Ascii85 y con el alfabeto del RFC 1924 y Z85 lo devuelve.

La variante que no es lo que su nombre dice

A la tercera variante se la suele llamar base85 del RFC 1924, y el nombre engaña. El RFC 1924 trata de direcciones IPv6. Su sección de codificación dice que hay que tratar una dirección como un único entero de 128 bits, escribir ese entero en base 85 y representarlo con 85 caracteres ASCII, lo que da exactamente veinte dígitos. No describe ninguna forma de codificar un flujo de bytes, y en todo el documento no se menciona en ningún momento procesar cuatro bytes de golpe.

Lo que las bibliotecas implementan bajo ese nombre es el alfabeto del RFC con la agrupación de cuatro bytes de Ascii85 aplicada encima. Es algo perfectamente razonable de construir, y no es lo que el RFC especifica. El tercer modo de esta página implementa el algoritmo de verdad del RFC, así que puedes codificar una dirección real y obtener los veinte dígitos que describe el documento.

El RFC merece una lectura por sí mismo. Está fechado el 1 de abril de 1996, está clasificado como Informational y afirma en sus primeras líneas que no especifica ningún estándar de internet. Su apartado sobre por qué 85 repasa la base 84 y la base 94 antes de decidirse, y explica que el conjunto de caracteres se eligió con considerable cuidado para dejar libre la puntuación con la que delimitar direcciones. Saca tus propias conclusiones sobre la fecha.

Lo que esto no puede decirte

No puede decirte qué variante produjo una cadena que te han dado. Ese es justo el problema: nada en la codificación lo registra. Si una cadena se descodifica limpiamente con dos variantes, se muestran ambas respuestas y la elección es tuya, guiada por de dónde salió la cadena y no por nada que haya dentro de ella.

Las tres variantes de aquí son las de uso extendido, no todas las que existen. Ascii85 en particular tiene dialectos: el programa btoa tenía una abreviatura para cuatro espacios además de la de cuatro bytes a cero, y algunas herramientas parten la salida en una columna fija y otras no. Son variaciones dentro de Ascii85 más que formatos aparte, pero bastan para que dos implementaciones de Ascii85 no coincidan en el texto exacto.

Y base85 encaja mal allí donde la salida tiene que sobrevivir a una URL, a un nombre de archivo o a una orden de shell. Todas las variantes usan puntuación a manos llenas, y los caracteres cambian de una a otra, así que un texto seguro en un contexto puede necesitar escaparse en otro. Ese es el problema que Z85 vino a resolver, y por eso su alfabeto deja fuera las comillas y la barra invertida que si no habría que escapar dentro de una cadena de código.

¿Por qué es gratis?

Un cambio de base es aritmética, y se ejecuta en tu navegador. No hay servidor de por medio, así que no hay nada que facturar ni cuenta que crear.

No se sube nada. Los bytes que pegas no salen de la pestaña.