Bonjour,
Ont dit toujours que les fichiers binaires sont des fichiers composé de 0 et de 1 uniquement. Mais pourquoi quand je l'ouvre avec vim, je ne vois pas de 0 et de 1 ?
[fichier binaire] (en cours)
-
AchilleFraisse
- Elfe
- Messages : 618
- Inscription : dim. 27 avr. 2014, 09:32
-
oktoberfest
- Maître du Kyudo
- Messages : 1855
- Inscription : mer. 06 janv. 2010, 13:51
- Localisation : Ried - Alsace - France
Re: [fichier binaire] (en cours)
Salut,
c'est un abus de langage car on désigne par 'fichier binaire' un fichier qui n'est pas un fichier texte (i.e. un fichier 'lisible' par un humain normal). Mais tout fichier n'est qu'une suite d'octets (une valeur valant entre 0 et 255). Via des tables de conversion (table ASCII par exemple) on a défini que 65 = A, 66 = B etc... et un éditeur (comme vim) utilise cette table de conversion pour t'afficher le contenu du fichier.
c'est un abus de langage car on désigne par 'fichier binaire' un fichier qui n'est pas un fichier texte (i.e. un fichier 'lisible' par un humain normal). Mais tout fichier n'est qu'une suite d'octets (une valeur valant entre 0 et 255). Via des tables de conversion (table ASCII par exemple) on a défini que 65 = A, 66 = B etc... et un éditeur (comme vim) utilise cette table de conversion pour t'afficher le contenu du fichier.
La majorité des bugs se situe entre la chaise et le clavier...
Arrêtez de vous prendre la tête avec les partitions... passez au LVM
Arrêtez de vous prendre la tête avec les partitions... passez au LVM
Re: [fichier binaire] (en cours)
Normalement, si tu ouvres un fichier binaire avec un éditeur hexadécimal,
Tu peux voir chaque octet sous sa forme hexadécimal.
Tu peux voir chaque octet sous sa forme hexadécimal.
-
Xorg
- Maître du Kyudo
- Messages : 1933
- Inscription : dim. 22 janv. 2012, 19:25
- Localisation : Entre le clavier et la chaise.
Re: [fichier binaire] (en cours)
Ça ne présente pas vraiment d'intérêt d'essayer de lire un fichier binaire. On peut voir les instructions machines, mais ça ne sert quand dans certains cas spécifiques.
Après, le fait d'afficher ça sous forme hexadécimal, c'est que c'est plus facile à lire. En binaire, il faut huit bits pour faire un octet, ce qui est représenté avec huit caractères (par exemple, 00000000), alors qu'en hexadécimal, un caractère représente quatre bits. C'est pour cela qu'il y a deux caractères hexadécimal par colonnes, pour former un octet.
C'est assez aisé de passer du binaire à l’hexadécimal et vice versa. 0000 en binaire équivaut à 0 en hexadécimal, 0001 à 1, 0010 à 2, 0011 à 3, [...], 1001 à 9, 1010 à A, [...] et 1111 à F.
Donc avec les commandes que j'ai mis, tu n'as pas des 0 et des 1, mais c'est tout comme, le contenu est là, mais c'est affiché en base 16 et non en base 2.
hexdump -C permet d'afficher la totalité du fichier en hexadécimal.objdump -s -j .rodata est plus spécifique, ça affiche en hexadécimal la section qui contient en quelques sortes le cœur du programme.Après, le fait d'afficher ça sous forme hexadécimal, c'est que c'est plus facile à lire. En binaire, il faut huit bits pour faire un octet, ce qui est représenté avec huit caractères (par exemple, 00000000), alors qu'en hexadécimal, un caractère représente quatre bits. C'est pour cela qu'il y a deux caractères hexadécimal par colonnes, pour former un octet.
C'est assez aisé de passer du binaire à l’hexadécimal et vice versa. 0000 en binaire équivaut à 0 en hexadécimal, 0001 à 1, 0010 à 2, 0011 à 3, [...], 1001 à 9, 1010 à A, [...] et 1111 à F.
Donc avec les commandes que j'ai mis, tu n'as pas des 0 et des 1, mais c'est tout comme, le contenu est là, mais c'est affiché en base 16 et non en base 2.
AUR