Ascii85

El programa btoa original siempre codificaba grupos completos (rellenando la fuente según fuera necesario), con una línea de prefijo de "xbtoa Begin" y una línea de sufijo de "xbtoa End", seguida de la longitud del archivo original (en decimal y hexadecimal ) y tres sumas de verificación de 32 bits . El decodificador necesita usar la longitud del archivo para ver cuánto del grupo se rellenó. La propuesta inicial para la codificación btoa usaba un alfabeto de codificación que comenzaba en el carácter de espacio ASCII hasta "t" inclusive, pero esto fue reemplazado por un alfabeto de codificación de "!" a "u" para evitar "problemas con algunos programas de correo (eliminando los espacios en blanco finales)". ^{[ 3 ]} Este programa también introdujo la zforma corta especial " " para un grupo de todos los ceros. La versión 4.2 agregó una excepción " " para un grupo de todos los caracteres de espacioy ASCII (0x20202020).

La codificación "ZMODEM Pack-7" codifica grupos de 4 octetos en grupos de 5 caracteres ASCII imprimibles de forma similar, o posiblemente idéntica, a como lo hace Ascii85. Cuando un programa ZMODEM envía archivos de datos de 8 bits precomprimidos a través de canales de datos de 7 bits , utiliza la codificación "ZMODEM Pack-7". ^{[ 4 ]}

Adobe adoptó la codificación básica btoa, pero con ligeros cambios, y la denominó Ascii85. Los caracteres utilizados son los caracteres ASCII del 33 ( !) al 117 ( u) inclusive (para representar los dígitos base-85 del 0 al 84), junto con la letra z(como caso especial para representar un valor 0 de 32 bits  ), y se ignora el espacio en blanco. Adobe utiliza el delimitador " ~>" para marcar el final de una cadena codificada en Ascii85, y la cadena puede ir precedida de " <~". ^{[ 5 ]} Adobe representa la longitud truncando el último grupo: si el último bloque de bytes de origen contiene menos de 4 bytes, el bloque se rellena con hasta 3 bytes nulos antes de la codificación. Después de la codificación, se eliminan del final de la salida tantos bytes como se añadieron como relleno.

Se aplica el proceso inverso al decodificar: el último bloque se rellena con 5 bytes con el carácter Ascii85 u, y se omiten del final de la salida tantos bytes como se agregaron como relleno (ver ejemplo).

El relleno no es arbitrario. La conversión de binario a base 64 solo reagrupa los bits y no los modifica ni cambia su orden (un bit alto en binario no afecta a los bits bajos en la representación base64). Al convertir un número binario a base 85 (85 no es una potencia de dos), los bits altos sí afectan a los dígitos de orden inferior en base 85 y viceversa. El relleno bajo del binario (con bits cero) durante la codificación y el relleno alto del valor base 85 (con us) durante la decodificación garantizan que los bits de orden superior se conserven (el relleno de ceros en binario proporciona suficiente espacio para que una pequeña suma quede atrapada y no haya acarreo a los bits altos).

En los bloques codificados en Ascii85, los espacios en blanco y los caracteres de salto de línea pueden aparecer en cualquier parte, incluso en medio de un bloque de 5 caracteres, pero deben ignorarse silenciosamente.

La especificación de Adobe no admite la excepción de btoay .

Toma esta cita del Leviatán de Thomas Hobbes :

Man is distinguished, not only by his reason, but by this singular passion from other animals, which is a lust of the mind, that by a perseverance of delight in the continued and indefatigable generation of knowledge, exceeds the short vehemence of any carnal pleasure.

Suponiendo que la cita de 269 caracteres se proporciona en US-ASCII o una codificación 100% compatible para empezar, se puede volver a codificar en Ascii85 como los siguientes 337 caracteres (el recuento y la salida se muestran sin los prefijos/posfijos " " <~y " ~>"): ^{[ a ]}

9jqo^BlbD-BleB1DJ+*+F(f,q/0JhKF<GL>Cj@.4Gp$d7F!,L7@<6@)/0JDEF<G%<+EV:2F!,O< DJ+*.@<*K0@<6L(Df-\0Ec5e;DffZ(EZee.Bl.9pF"AGXBPCsi+DGm>@3BB/F*&OCAfu2/AKYi( DIb:@FD,*)+C]U=@3BN#EcYf8ATD3s@q?d$AftVqCh[NqF<G:8+EV:.+Cf>-FD5W8ARlolDIal( DId<j@<?3r@:F%a+D58'ATD4$Bl@l3De:,-DJs`8ARoFb/0JMK@qB4^F!,R<AKZ&-DfTqBG%G>u D.RTpAKYo'+CT/5+Cei#DII?(E,9)oF*2M7/c 

Para un análisis detallado de la recodificación, este es el comienzo de la cita de Hobbes:

...y lo siguiente es el final de la cita (penúltima cuádrupla):

Sin embargo, como la última cuádrupla está incompleta después del punto, debe rellenarse con tres bytes cero:

Dado que fue necesario agregar tres bytes de relleno, los tres caracteres finales 'YkO' se omiten en la salida.

La decodificación se realiza de forma inversa, excepto que la última tupla de 5 elementos se rellena con caracteres 'u':

Dado que la entrada tuvo que rellenarse con tres bytes 'u', los últimos tres bytes de la salida se ignoran y terminamos con el punto original.

La frase de entrada no contiene 4 bytes cero consecutivos, por lo que el ejemplo no muestra el uso de la abreviatura 'z'.

La codificación Ascii85 es compatible con MIME de 7 y 8 bits , a la vez que tiene una sobrecarga menor que Base64 .

Un posible problema de compatibilidad de Ascii85 es que algunos de los caracteres que utiliza son significativos en lenguajes de marcado como XML o SGML . Para incluir datos Ascii85 en estos documentos, puede ser necesario escapar las comillas , los corchetes angulares y las ampersands .