Ascii85 - Ascii85

Ascii85 , também chamado de Base85 , é uma forma de codificação binário para texto desenvolvida por Paul E. Rutter para o utilitário btoa . Ao usar cinco caracteres ASCII para representar quatro bytes de dados binários (tornando o tamanho codificado 14 maior que o original, assumindo oito bits por caractere ASCII), é mais eficiente do que uuencode ou Base64 , que usam quatro caracteres para representar três bytes de dados ( aumento de 13 , assumindo oito bits por caractere ASCII).

Seus principais usos modernos estão em Adobe 's PostScript e Portable Document Format formatos de arquivo, bem como no patch de codificação para arquivos binários usados por Git .

Visão geral

A necessidade básica de uma codificação binário para texto vem da necessidade de comunicar dados binários arbitrários em protocolos de comunicação preexistentes que foram projetados para transportar apenas texto legível em inglês. Esses protocolos de comunicação podem ser seguros apenas de 7 bits (e dentro deles evitar certos códigos de controle ASCII) e podem exigir quebras de linha em determinados intervalos máximos e podem não manter espaços em branco . Assim, apenas os 94 caracteres ASCII imprimíveis são "seguros" para usar para transmitir dados.

Quatro bytes podem representar 2 32  = 4.294.967.296 valores possíveis. Cinco radix -85 dígitos fornecem 85 5  = 4.437.053.125 valores possíveis, o suficiente para fornecer uma representação única para cada valor possível de 32 bits. Como cinco dígitos radix-84 fornecem apenas 84 5  = 4.182.119.424 valores representáveis, 85 é a base integral mínima possível que representará quatro bytes em cinco caracteres, daí sua escolha.

Ao codificar, cada grupo de 4 bytes é considerado um número binário de 32 bits, o byte mais significativo primeiro (o Ascii85 usa uma convenção big-endian ). Isso é convertido, dividindo repetidamente por 85 e tomando o resto, em 5 dígitos de raiz-85. Em seguida, cada dígito (novamente, o mais significativo primeiro) é codificado como um caractere ASCII imprimível adicionando 33 a ele, dando aos caracteres ASCII 33 (" !") a 117 (" u").

Como os dados totalmente zero são bastante comuns, uma exceção é feita para fins de compactação de dados e um grupo totalmente zero é codificado como um único caractere " z" em vez de " !!!!!".

Grupos de caracteres que decodificam para um valor maior que 2 32 - 1 (codificados como " s8W-!") causarão um erro de decodificação, assim como " z" caracteres no meio de um grupo. O espaço em branco entre os caracteres é ignorado e pode ocorrer em qualquer lugar para acomodar as limitações de comprimento de linha.

Uma desvantagem do Ascii85 é que os dados codificados podem conter caracteres de escape , como barra invertida e aspas, que têm um significado especial em muitas linguagens de programação e em alguns protocolos baseados em texto. Outras codificações base 85, como Z85 e RFC 1924, são projetadas para serem seguras no código-fonte.

História

versão btoa

O programa btoa original sempre codificou grupos completos (preenchendo a fonte conforme necessário), com uma linha de prefixo "xbtoa Begin" e linha de sufixo "xbtoa End", seguido pelo comprimento do arquivo original (em decimal e hexadecimal ) e três 32 -bit checksums . O decodificador precisa usar o comprimento do arquivo para ver quanto do grupo foi preenchido. A proposta inicial para a codificação btoa usava um alfabeto de codificação começando no caractere de espaço ASCII até "t" inclusive, mas foi substituído por um alfabeto de codificação de "!" para "u" para evitar "problemas com alguns mailers (removendo espaços em branco)". Este programa também introduziu a zforma abreviada " " especial para um grupo totalmente zero. A versão 4.2 adicionou uma yexceção " " para um grupo de todos os caracteres de espaço ASCII (0x20202020).

Versão ZMODEM

A "codificação ZMODEM Pack-7" codifica grupos de 4 octetos em grupos de 5 caracteres ASCII imprimíveis de maneira semelhante ou possivelmente da mesma forma que o Ascii85. Quando os programas ZMODEM enviam arquivos de dados pré-compactados de 8 bits em canais de dados de 7 bits , ele usa a "codificação ZMODEM Pack-7".

Versão Adobe

A Adobe adotou a codificação btoa básica, mas com pequenas alterações, e deu a ela o nome de Ascii85. Os caracteres usados ​​são os caracteres ASCII 33 ( !) a 117 ( u) inclusive (para representar os dígitos de base 85 de 0 a 84), junto com a letra z(como um caso especial para representar um valor 0 de 32 bits) e o espaço em branco é ignorado. A Adobe usa o delimitador " ~>" para marcar o final de uma string codificada por Ascii85 e representa o comprimento truncando o grupo final: Se o último bloco de bytes de origem contiver menos de 4 bytes, o bloco será preenchido com até 3 bytes nulos antes codificação. Após a codificação, tantos bytes quantos forem adicionados como preenchimento são removidos do final da saída.

O inverso é aplicado durante a decodificação: o último bloco é preenchido com 5 bytes com o caractere Ascii85 u, e tantos bytes quantos foram adicionados como preenchimento são omitidos no final da saída (veja o exemplo).

NOTA: O preenchimento não é arbitrário. A conversão de binário para base 64 apenas reagrupa os bits e não os altera ou sua ordem (um bit alto em binário não afeta os bits baixos na representação de base64). Ao converter um número binário em base85 (85 não é uma potência de dois), os bits altos afetam os dígitos de base85 de ordem inferior e vice-versa. O preenchimento do binário baixo (com bits zero) enquanto codifica e o preenchimento do valor base85 alto (com us) na decodificação garante que os bits de ordem alta sejam preservados (o preenchimento de zero no binário dá espaço suficiente para que uma pequena adição seja capturada e não é "transportar" para os bits altos).

Em blocos codificados por Ascii85, os caracteres de espaço em branco e de quebra de linha podem estar presentes em qualquer lugar, inclusive no meio de um bloco de 5 caracteres, mas devem ser ignorados silenciosamente.

A especificação da Adobe não oferece suporte à yexceção.

Exemplo para Ascii85

Uma citação do Leviatã de Thomas Hobbes :

O homem se distingue, não apenas por sua razão, mas por esta paixão singular de outros animais, que é uma concupiscência da mente, que por uma perseverança de deleite na contínua e infatigável geração de conhecimento, excede a curta veemência de qualquer prazer carnal .

Se isso for inicialmente codificado usando US-ASCII, pode ser recodificado em Ascii85 da seguinte maneira:

<~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~>
Conteúdo de texto M uma n ... s você r e
ASCII 77 97 110 32 ... 115 117 114 101
Padrão 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 4 + 73 × 85 3 + 80 × 85 2 + 78 × 85 + 61 ... 1.937.076.837 = 37 × 85 4 + 9 × 85 3 + 17 × 85 2 + 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 M 7

Como a última 4 tupla está incompleta, ela deve ser preenchida com três bytes zero:

Conteúdo de texto . \ 0 \ 0 \ 0
ASCII 46 0 0 0
Padrão 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 4 + 66 × 85 3 + 56 × 85 2 + 74 × 85 + 46
Base 85 (+33) 14 (47) 66 (99) 56 (89) 74 (107) 46 (79)
ASCII / c Y k O

Visto que três bytes de preenchimento tiveram que ser adicionados, os três caracteres finais 'YkO' são omitidos da saída.

A decodificação é feita inversamente, exceto que as últimas 5 tuplas são preenchidas com caracteres 'u':

ASCII / c você você você
Base 85 (+33) 14 (47) 66 (99) 84 (117) 84 (117) 84 (117)
Valor de 32 bits 771.955.124 = 14 × 85 4 + 66 × 85 3 + 84 × 85 2 + 84 × 85 + 84
Padrão 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
Conteúdo de texto . [ ETX ] [EM] ´ ( ASCII estendido )

Uma vez que a entrada teve que ser preenchida com três bytes 'u', os últimos três bytes da saída são ignorados e terminamos com o ponto original.

A frase de entrada não contém 4 bytes zero consecutivos, portanto, o exemplo não mostra o uso da abreviatura 'z'.

Compatibilidade

A codificação Ascii85 é compatível com MIME de 7 e 8 bits , embora tenha menos sobrecarga do que Base64 .

Um possível problema de compatibilidade do Ascii85 é que aspas 'simples' e "duplas", colchetes <angle> e e comercial (&) não podem ser usados ​​sem escape em linguagens de marcação como XML ou SGML.

Versão RFC 1924

Publicado em 1 ° de abril de 1996 , informativo RFC  1924 : "A Compact Representation of IPv6 Addresses" por Robert Elz sugere uma codificação base 85 de endereços IPv6 . Isso difere do esquema usado acima porque ele propõe um conjunto diferente de 85 caracteres ASCII e propõe fazer toda a aritmética no número de 128 bits, convertendo-o em um único número de base 85 de 20 dígitos (espaços em branco internos não permitidos) , em vez de dividi-lo em quatro grupos de 32 bits.

O conjunto de caracteres proposto é, na ordem, 0- 9, A- Z, a- ze, em seguida, os 23 caracteres !#$%&()*+-;<=>?@^_`{|}~. O endereço representável mais alto possível, 2 128 −1 = 74 × 85 19  + 53 × 85 18  + 5 × 85 17  + ..., seria codificado como =r54lj&NUUO~Hi%c2ym0.

Este conjunto de caracteres exclui os caracteres "',./:[\] , tornando-o adequado para uso em strings JSON (onde "e \exigiria escape). No entanto, para SGML baseados em protocolos, nomeadamente incluindo XML , escapes de corda ainda pode ser necessária (para acomodar <, >e &).

Veja também

Referências

links externos