J'ai un fichier .log qui est un fichier binaire (BSC0000.log). Donc, visualisé dans un visualiseur HEX (OKteta) et exporté directement dans une chaîne (split_space.txt). Avec des espaces au milieu, comme 00 DF 00 45
.
Le fait est que lorsque j'ai compté les caractères dans les deux fichiers, la différence était énorme.
laksith@laksithPC:~/Desktop/test$ cat split_space.txt | wc -c
31617470
laksith@laksithPC:~/Desktop/test$ cat BSC0000.log | wc -c
10539157
On peut supposer que cela pourrait être dû aux espaces entre les deux. Mais alors cela devrait ressembler à peu près à 10539157 + 10539157/2 mais comment se fait-il que cette valeur soit 31617470.
mais 10539157 * 3 = 31617471, valeur de la ligne de commande +1
Un octet a 8 bits. Comme hex utilise 16 caractères, 0-9a-f, il ne peut afficher que quatre bits par caractère. Il faut deux caractères hexadécimaux pour afficher un octet. Ajoutez à cela que la plupart des caractères de l'affichage hexadécimal ont un espace après eux et vous voyez pourquoi l'affichage hexadécimal prend jusqu'à trois fois plus d'octets que le nombre binaire. fichier.
Créons un fichier contenant un seul octet:
$ printf 'a' >afile
$ wc afile
0 1 1 afile
Maintenant, affichons-le avec, par exemple, hexdump -C
:
$ hexdump -C afile
00000000 61 |a|
00000001
Le caractère a
est ASCII caractère 61
(hex). Un seul octet dans le fichier prend deux caractères à afficher en hexadécimal (et trois si l'hexagone a un espace après celui-ci).