Pourquoi un fichier binaire n'est-il pas représenté par des 0 et des 1 ?

Presque tous les ordinateurs modernes traitent des octets, et non des bits individuels. Un seul octet, comme vous le savez peut-être, peut stocker 256 valeurs différentes, de huit zéros à huit uns.

Lorsque vous ouvrez le fichier binaire dans un éditeur de texte, celui-ci vous montre ces morceaux de la taille d'un octet au lieu de chaque bit individuel. Les symboles qu'il choisit sont déterminés par l'encodage par défaut de votre éditeur. Souvent, un caractère dans votre éditeur correspond à un octet dans le fichier réel, mais il existe des cas particuliers.

Si vous voyez une chaîne de texte lisible, telle que __stub_helper cela signifie qu'un texte particulier est stocké tel quel dans le fichier binaire.

Les cas particuliers que j'ai mentionnés précédemment sont des caractères dits de contrôle qui sont affichés avec un code d'échappement. Les codes d'échappement, comme on le voit ici, commencent par ^ et sont suivis d'un seul caractère supplémentaire. Cette paire, telle que ^@ sont regroupés pour représenter un seul octet. En fait, le symbole ^@ est la valeur zéro, ce qui signifie que les bits à cet emplacement seraient huit zéros.

La raison pour laquelle votre éditeur de texte affiche le fichier binaire de cette manière est qu'il affiche simplement tous les fichiers de cette manière. Si vous utilisiez un éditeur hexadécimal, il afficherait tous les fichiers en hexadécimal. En fait, il n'y a pas de différence fondamentale entre le contenu d'un fichier binaire et celui d'un fichier texte - ce sont les métadonnées et les en-têtes de fichier qui permettent à votre ordinateur de savoir lequel est lequel.

Début vi en mode binaire - alors vous pouvez exécuter xxd pour obtenir une vue hexagonale, une vue binaire et éditer le fichier comme vous le feriez. (Bien sûr, la plupart de ces fichiers sont en lecture seule, mais il ne s'agit pas de l'éditeur mais plutôt des permissions/SIP).

vi -b /bin/ps

Ensuite pour convertir le tampon en bits de 1 et 0

:%!xxd -b

Vous pouvez alors voir toutes les qualités binaires de l'exécutable Mach-0, directement dans l'éditeur. Si vous laissez tomber le b, vous obtenez la représentation hexadécimale plus typique qui est un encodage plus efficace en termes d'espace et vous ne voyez pas les valeurs mappées comme des caractères dérivés de l'ASCII où tant de valeurs se terminent par ^@^@^@ lorsque vous partez d'un défaut centré sur le texte brut.

La réponse la plus simple à votre question est : Pour l'efficacité. Comme d'autres l'ont dit dans leurs réponses, les fichiers sont affichés en utilisant une notation plus compacte que le code binaire brut, car le code binaire brut est insondable inefficace comme moyen de communication des données.

Prenez le ps le programme que vous avez affiché en utilisant vi . Je ne suis pas sûr de la version MacOS de la commande, mais sur mon système Fedora 30 /bin/ps est un exécutable à liaison dynamique (ce qui signifie qu'une partie de son code est chargée à partir d'autres fichiers situés ailleurs sur le disque) qui a néanmoins une taille de fichier d'environ 158k, ou pour être précis une taille de fichier de 157224 octets.

Puisque chaque octet de mémoire contient 8 bits, il faudrait une chaîne de huit 1 ou 0 chiffres à afficher chaque octet individuel de l /bin/ps dossier. Ce qui signifie que, si vous affichez le contenu entier du fichier sous la forme d'une chaîne de caractères de juste 1 ou 0 cette chaîne serait 1257792 (c'est un et un quart million ) chiffres.

Et il s'agit d'un fichier relativement petit ! Pensez au contenu d'un disque Blu-Ray, qui peut facilement atteindre plusieurs dizaines de gigaoctets. Un film de 80 gigaoctets aurait une représentation binaire pure nécessitant 640 milliards d'euros 1 / 0 les chiffres.