paulo1205
(usa Ubuntu)
Enviado em 28/06/2019 - 08:38h
E costumo usar o
bvi .
Quanto a diferença de forma, você se refere ao efeito de
endianness ?
Veja duas saídas diferentes do próprio
hexdump , a primeira orientada a palavra de 16 bits (default), e a segunda orientada a
bytes (e com os caracteres ASCII correspondentes, se imprimíveis).
$ head -c 16 /bin/bash | hexdump
0000000 457f 464c 0102 0001 0000 0000 0000 0000
0000010
$ head -c 16 /bin/bash | hexdump -C
00000000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|
00000010
A aparente troca de ordem entre os pares de bytes
0x7f e
0x45 ,
0x4c e
0x46 ,
0x02 e
0x01 , e assim por diante se deve ao fato de que nossos PCs com Intel utilizam representação
little-endian para números compostos por mais de um byte, o que quer dizer que o byte menos significativo fica na posição mais baixa de memória, seguido pelo segundo byte menos significativo, e assim sucessivamente até o byte mais significativo, que vem por último, na posição de memória mais alta. Assim, se você tratar o par de bytes
0x7f e
0x45 como compondo um único número de 16 bits, de acordo com a representação nativa do processador, esse número será o número
0x457f .
Num processador diferente, que usasse representação
big-endian (bytes mais significativos primeiro e menos significativos por último), o mesmo par de bytes poderia indicar algo diferente. O exemplo seguinte mostra como uma máquina com processador Sparc, que usa
big-endian , mostraria a os mesmos dados (o Solaris não tem
hexdump nativo, então eu usei o
od com a opção
-x , que produz saída parecida com a do formato padrão do
hexdump ). Note que ele mostra
0x7f45 , em vez de
0x457f , como nossos PCs fazem.
$ head -c 16 /bin/bash | ssh maquina-com-solaris-sparc od -x
0000000 7f45 4c46 0201 0100 0000 0000 0000 0000
0000020
... “Principium sapientiae timor Domini, et scientia sanctorum prudentia.” (Proverbia 9:10)