Como é a saída octal de 2 bytes calculada a partir de od

4

Estou com dificuldades para descobrir qual é a saída octal de 2 bytes do comando od . Eu entendo a saída octal ( -b flag) mas o octal 2-byte é um mistério para mim ( -o )

Alguém pode esclarecer como o resultado -o é calculado a partir de ASCII?

Aqui está um exemplo:

[root@localhost lpi103-2]# cat text1
1 apple
2 pear
3 banana
[root@localhost lpi103-2]# od -c text1
0000000   1       a   p   p   l   e  \n   2       p   e   a   r  \n   3
0000020       b   a   n   a   n   a  \n
0000030
[root@localhost lpi103-2]# od -bc text1
0000000 061 040 141 160 160 154 145 012 062 040 160 145 141 162 012 063
          1       a   p   p   l   e  \n   2       p   e   a   r  \n   3
0000020 040 142 141 156 141 156 141 012
              b   a   n   a   n   a  \n
0000030
[root@localhost lpi103-2]# od -oc text1
0000000  020061  070141  066160  005145  020062  062560  071141  031412
          1       a   p   p   l   e  \n   2       p   e   a   r  \n   3
0000020  061040  067141  067141  005141
              b   a   n   a   n   a  \n
0000030
    
por zod90 02.03.2011 / 23:50

2 respostas

8

Por razões históricas histéricas , od imprime palavras de dois bytes¹ por padrão.

O número 020061 (octal) corresponde à sequência de dois bytes 1␣ ( é um caractere de espaço). Por quê? É mais claro se você usar hexadecimal: 0o20061 = 0x2031 e é 0x20 (32) em ASCII e 1 é 0x31 (49). Observe que os bits de ordem inferior (0x31) correspondem ao primeiro caractere e os bits de ordem superior correspondem ao segundo caractere: od está montando as palavras em little-endian ordem, porque essa é a condição do seu sistema."

A ordem little-endian não é muito natural aqui porque um dos formatos de saída ( -c ) imprime caracteres, o outro ( -o ) imprime palavras. Cada palavra é impressa como um número na notação usual big-endian (o dígito mais significativo vem primeiro em nossa ordem de leitura da esquerda para a direita). Isso é ainda mais aparente em hexadecimal, onde os limites de bytes são claramente aparentes na saída numérica:

echo '1 text' | od -xc   
0000000 2031 6574 7478 000a
         1    t e  x t \n
echo '1 text' | od -xc   
0000000 2031 6574 7478 000a
         1    t e  x t \n%pre%

Se você preferir ver o arquivo como uma seqüência de bytes, use od -t x1 (ou hd se você tiver).

¹ Era uma vez, os homens eram homens de verdade, os computadores eram computadores reais, os números eram geralmente escritos em octal e as palavras tinham dois bytes de comprimento.

² Todos os PCs (x86, x86-64) são little-endian, assim como o PDP-11 onde o Unix começou. Os processadores ARM podem lidar com o endianness, mas o Linux e o iOS o usam no modo little-endian. Então, a maioria das plataformas que você provavelmente encontrará hoje em dia são little-endian.

    
por 03.03.2011 / 00:51
3

Pergunta interessante. Depois de navegar na página man, descobri que -o imprime a saída octal (od == octal dump), o c que você anexou apenas imprime os caracteres associados também. Você obtém os mesmos números com -o sozinho.

Olhando para a saída, parece que od está lendo dados dois bytes de cada vez. Pegue os dois primeiros caracteres, por exemplo:

CHAR - OCTAL - BINARY
1      061     0011 0001
SPACE  040     0010 0000

A resposta vem quando concatenamos os valores binários (com o '1' à direita, o ESPAÇO à esquerda):

0010 0000 0011 0001

Converter este valor binário para octal nos dá 020061, que é o que od impresso.

Agora, por quê? Eu acho que o ponto é que od está lendo dois bytes de cada vez, e não está preocupado ou ciente de que esses dois bytes são na verdade dois caracteres separados.

    
por 03.03.2011 / 00:18