Ascii85

Ascii85 , también llamado Base85 , es una forma de codificación de binario a texto desarrollada por Paul E. Rutter para la utilidad btoa . Al usar cinco caracteres ASCII para representar cuatro bytes de datos binarios (haciendo que el tamaño codificado sea 1 ⁄ 4 más grande que el original, asumiendo ocho bits por carácter ASCII), es más eficiente que uuencode o Base64 , que usan cuatro caracteres para representar tres bytes. de datos ( aumento de 1 ⁄ 3 , asumiendo ocho bits por carácter ASCII).

Sus principales usos modernos están en Adobe 's PostScript y Portable Document Format formatos de archivo, así como en el parche de codificación de archivos binarios utilizados por Git . ^[1]

Visión general

La necesidad básica de una codificación de binario a texto proviene de la necesidad de comunicar datos binarios arbitrarios a través de protocolos de comunicación preexistentes que fueron diseñados para transportar solo texto en inglés legible por humanos . Esos protocolos de comunicación solo pueden ser seguros de 7 bits (y dentro de eso evitar ciertos códigos de control ASCII), y pueden requerir saltos de línea en ciertos intervalos máximos y es posible que no mantengan espacios en blanco . Por lo tanto, solo los 94 caracteres ASCII imprimibles son "seguros" de usar para transmitir datos.

Cuatro bytes pueden representar 2 ³² = 4.294.967.296 valores posibles. Cinco dígitos de base -85 proporcionan 85 ⁵ = 4,437,053,125 valores posibles, suficiente para proporcionar una representación única para cada posible valor de 32 bits. Debido a que cinco dígitos de la base 84 solo proporcionan 84 ⁵ = 4,182,119,424 valores representables, 85 es la base integral mínima posible que representará cuatro bytes en cinco caracteres, de ahí su elección.

Al codificar, cada grupo de 4 bytes se toma como un número binario de 32 bits, el byte más significativo primero (Ascii85 usa una convención big-endian ). Esto se convierte, dividiendo repetidamente por 85 y tomando el resto, en 5 dígitos de 85 radix. Luego, cada dígito (nuevamente, el más significativo primero) se codifica como un carácter imprimible ASCII agregando 33, dando los caracteres ASCII 33 (" !") a 117 (" u").

Debido a que los datos de todo cero son bastante comunes, se hace una excepción por el bien de la compresión de datos y un grupo de todo cero se codifica como un solo carácter " z" en lugar de " !!!!!".

Los grupos de caracteres que decodifican a un valor mayor que 2 ³² - 1 (codificados como " s8W-!") causarán un error de decodificación, al igual que los zcaracteres " " en el medio de un grupo. Los espacios en blanco entre los caracteres se ignoran y pueden aparecer en cualquier lugar para adaptarse a las limitaciones de longitud de línea.

Una desventaja de Ascii85 es que los datos codificados pueden contener caracteres de escape como barra invertida y comillas, que tienen un significado especial en muchos lenguajes de programación y en algunos protocolos basados en texto. Otras codificaciones en base 85 como Z85 y RFC 1924 están diseñadas para ser seguras en el código fuente. ^[2]

Historia

versión btoa

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 32 -sumas de comprobación de bits . El decodificador necesita usar la longitud del archivo para ver cuánto del grupo estaba rellenando. La propuesta inicial para la codificación btoa usaba un alfabeto de codificación que comenzaba en el carácter de espacio ASCII hasta la "t" inclusive, pero esto fue reemplazado por un alfabeto de codificación de "!" a "u" para evitar "problemas con algunos anuncios publicitarios (eliminar los espacios en blanco finales)". ^[3] Este programa también introdujo la zforma abreviada especial " " para un grupo todo cero. La versión 4.2 agregó un "y"excepción para un grupo de todos los ASCIIcaracteres de espacio (0x20202020).

Versión ZMODEM

La "codificación ZMODEM Pack-7" codifica grupos de 4 octetos en grupos de 5 caracteres ASCII imprimibles de una manera similar, o posiblemente de la misma manera que lo hace Ascii85. Cuando los programas ZMODEM envían 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]

Versión de Adobe

Adobe adoptó la codificación básica btoa, pero con ligeros cambios, y le dio el nombre Ascii85. Los caracteres utilizados son los caracteres ASCII 33 (!) A 117 (u) inclusive (para representar los dígitos de base 85 del 0 al 84), junto con la letra z (como caso especial para representar un valor 0 de 32 bits), y se ignoran los espacios en blanco. Adobe usa el delimitador " ~>" para marcar el final de una cadena codificada en Ascii85 y representa la longitud truncando el grupo final: si el último bloque de bytes de origen contiene menos de 4 bytes, el bloque se rellena con hasta tres bytes nulos. antes de codificar. Después de la codificación, se eliminan del final de la salida tantos bytes como se agregaron como relleno.

Se aplica lo contrario al decodificar: el último bloque se rellena a 5 bytes con el carácter Ascii85 " u", y se omiten tantos bytes como se añadieron como relleno al final de la salida (ver ejemplo).

NOTA: El relleno no es arbitrario. La conversión de binario a base 64 solo reagrupa los bits y no los cambia ni su orden (un bit alto en binario no afecta los bits bajos en la representación de base64). Al convertir un número binario a base85 (85 no es una potencia de dos), los bits altos afectan los dígitos base85 de orden inferior y viceversa. Rellenar el binario bajo (con cero bits) mientras se codifica y rellenar el valor base85 alto (con 'u's) en la decodificación asegura que los bits de orden superior se conservan (el relleno de cero en el binario da suficiente espacio para que una pequeña adición quede atrapada y no hay "acarreo" a los bits altos).

En bloques codificados en Ascii85, los espacios en blanco y los caracteres de salto de línea pueden estar presentes en cualquier lugar, incluso en el medio de un bloque de 5 caracteres, pero deben ignorarse en silencio.

La especificación de Adobe no admite la " y" excepción.

Ejemplo para Ascii85

Una cita del Leviatán de Thomas Hobbes :

El hombre se distingue, no sólo por su razón, sino por esta singular pasión de otros animales, que es un deseo de la mente, que por una perseverancia de deleite en la continua e infatigable generación de conocimientos, supera la breve vehemencia de cualquier placer carnal. .

Si se codifica inicialmente con US-ASCII, se puede volver a codificar en Ascii85 de la siguiente manera:

<~ 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 / AKY
i (DIb: @FD, *) + C] U = @ 3BN # EcYf8ATD3s @ q? d $ AftVqCh [NqF <G: 8 + EV:. + Cf> -FD5W8ARlolDIa
l (DId <j @ <? 3r @: F% a + D58'ATD4 $ Bl @ l3De:, - DJs`8ARoFb / 0JMK @ qB4 ^ F!, R <AKZ & -DfTqBG% G
> uD.RTpAKYo '+ CT / 5 + Cei # DII? (E, 9) oF * 2M7 / c ~>

Contenido del texto	METRO								a								norte																...	s								tu								r								mi
ASCII	77								97								110								32								...	115								117								114								101
Patrón de bits	0	1	0	0	1	1	0	1	0	1	1	0	0	0	0	1	0	1	1	0	1	1	1	0	0	0	1	0	0	0	0	0	...	0	1	1	1	0	0	1	1	0	1	1	1	0	1	0	1	0	1	1	1	0	0	1	0	0	1	1	0	0	1	0	1
Valor de 32 bits	1.298.230.816 = 24 × 85 ⁴ + 73 × 85 ³ + 80 × 85 ² + 78 × 85 + 61																																...	1.937.076.837 = 37 × 85 ⁴ + 9 × 85 ³ + 17 × 85 ² + 44 × 85 + 22
Base 85 (+33)	24 (57)						73 (106)							80 (113)						78 (111)							61 (94)						...	37 (70)						9 (42)							17 (50)						44 (77)							22 (55)
ASCII	9						j							q						o							^						...	F						*							2						METRO							7

Dado que la última tupla de 4 está incompleta, debe rellenarse con tres bytes cero:

Contenido del texto	.								\ 0								\ 0								\ 0
ASCII	46								0								0								0
Patrón de bits	0	0	1	0	1	1	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0
Valor de 32 bits	771.751.936 = 14 × 85 ⁴ + 66 × 85 ³ + 56 × 85 ² + 74 × 85 + 46
Base 85 (+33)	14 (47)						66 (99)							56 (89)						74 (107)							46 (79)
ASCII	/						C							Y						k							O

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

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

ASCII	/						C							tu						tu							tu
Base 85 (+33)	14 (47)						66 (99)							84 (117)						84 (117)							84 (117)
Valor de 32 bits	771.955.124 = 14 × 85 ⁴ + 66 × 85 ³ + 84 × 85 ² + 84 × 85 + 84
Patrón de bits	0	0	1	0	1	1	1	0	0	0	0	0	0	0	1	1	0	0	0	1	1	0	0	1	1	0	1	1	0	1	0	0
ASCII	46								3								25								180
Contenido del texto	.								[ ETX ]								[EM]								´ ( ASCII extendido )

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

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

Compatibilidad

La codificación Ascii85 es compatible con MIME de 7 y 8 bits , mientras que tiene menos gastos generales que Base64 .

Un problema de compatibilidad potencial de Ascii85 es que las comillas "simples" y "dobles", los corchetes <angle> y los símbolos de unión (&) no se pueden usar sin escape en lenguajes de marcado como XML o SGML.

Versión RFC 1924

Publicado el 1 de abril de 1996 , RFC 1924 informativo : "Una representación compacta de direcciones IPv6" por Robert Elz sugiere una codificación base-85 de direcciones IPv6 . Esto difiere del esquema utilizado anteriormente en que propone un conjunto diferente de 85 caracteres ASCII y propone hacer toda la aritmética en el número de 128 bits, convirtiéndolo en un solo número base 85 de 20 dígitos (no se permiten espacios en blanco internos). , en lugar de dividirlo en cuatro grupos de 32 bits.

El juego de caracteres propuesto es, en orden, 0- 9, A- Z, a- z, y luego los 23 caracteres !#$%&()*+-;<=>?@^_`{|}~. La dirección representable más alta posible, 2 ¹²⁸ −1 = 74 × 85 ¹⁹ + 53 × 85 ¹⁸ + 5 × 85 ¹⁷ + ..., se codificaría como =r54lj&NUUO~Hi%c2ym0.

Este conjunto de caracteres excluye los caracteres "',./:[\] , lo que lo hace adecuado para su uso en cadenas JSON (donde "y \requeriría escapar). Sin embargo, para SGML -basado protocolos, incluyendo en particular XML , puede ser necesaria escapa de cuerda (para acomodar <, >y &).

Ver también

Base32
Base36
Base64
Codificación de binario a texto para una comparación de varios algoritmos de codificación
Codificación estándar PostScript

Referencias

^ Junio Hamano (5 de mayo de 2006). "parche binario" .
^ "Z85 - Algoritmo de codificación ZeroMQ Base-85"
^ Orost, Joe. "Re: COMPRESIÓN de datos binarios en ASCII que se puede enviar por correo. Re: Codificación de datos binarios en ASCII que se puede enviar por correo" . Grupos de Google . Consultado el 11 de abril de 2015 .
^ Chuck Forsberg. "Desarrollos recientes en ZMODEM" . Archivado desde el original el 24 de septiembre de 2015 . Consultado el 14 de mayo de 2013 .. "ZMODEM Pack-7 empaqueta 4 bytes en 5 caracteres de impresión".

enlaces externos

BasE91
Referencia del lenguaje PostScript (Adobe): consulte Filtro de codificación ASCII85

[1] Junio Hamano (5 de mayo de 2006). "parche binario" .

[2] "Z85 - Algoritmo de codificación ZeroMQ Base-85"

[3] Orost, Joe. "Re: COMPRESIÓN de datos binarios en ASCII que se puede enviar por correo. Re: Codificación de datos binarios en ASCII que se puede enviar por correo" . Grupos de Google . Consultado el 11 de abril de 2015 .

[4] Chuck Forsberg. "Desarrollos recientes en ZMODEM" . Archivado desde el original el 24 de septiembre de 2015 . Consultado el 14 de mayo de 2013 .. "ZMODEM Pack-7 empaqueta 4 bytes en 5 caracteres de impresión".

[1]