Why is there a difference between text and binary files in Windows?

Réponse courte

Il n'y en a pas.

Réponse longue

En réalité, je suppose qu'il n'y a littéralement aucune différence entre un fichier texte et un fichier binaire, puisqu'il s'agit dans les deux cas d'une simple collection d'octets. Un fichier texte peut être facilement représentable [sic] dans un éditeur en fonction de l'encodage, alors qu'un fichier binaire ne le sera généralement pas, mais la représentation sous-jacente est la même : une séquence d'octets dans un ordre donné.

Comme vous l'avez dit, un fichier n'est qu'un ensemble d'octets. C'est tout. Son contenu n'a de sens que lorsqu'il est interprété par un programme . Il est tout à fait possible qu'un programme interprète les octets d'un fichier d'une certaine manière et qu'un autre programme les interprète d'une autre manière. Lorsque vous ouvrez un fichier "binaire" dans un éditeur de texte, celui-ci interprète les octets comme du texte et les affiche. Si le fichier n'est pas du "texte brut", les résultats seront probablement du charabia, mais le programme continue à faire son travail d'interprétation et de sortie.

Dans de nombreux langages de programmation, il existe des constructions permettant de contourner le fait que Windows fait la différence entre les fichiers texte et les fichiers binaires.

Ce n'est pas le cas de Windows. Ce qui se passe, c'est que la plupart de ces langages de programmation ont évolué sur d'autres systèmes d'exploitation tels qu'Unix, Linux, etc. et utilisent donc des fins de ligne différentes pour les fichiers de texte brut natifs. Il est possible qu'ils utilisent également un encodage différent, mais ce sont généralement les fins de ligne qui varient d'une plate-forme à l'autre.

Voici une liste des plates-formes et des fins de ligne les plus courantes :

• Unix, Linux - saut de ligne
• Windows - retour chariot, saut de ligne
• Mac (historiquement) - retour de chariot
• (Quelques anciens systèmes d'exploitation (par exemple, Acorn BBC) - saut de ligne, retour chariot)

Pourquoi Windows fait-il cette distinction qui n'est apparemment pas nécessaire ?

Windows est un système d'exploitation, il ne distingue rien en soi. La question que vous devez vous poser est de savoir quel pièces de Windows se distinguent. Dans ce cas, c'est la fenêtre de commande qui traite différemment les fichiers texte et les fichiers binaires, et même dans ce cas, cela dépend de la commande utilisée. Par exemple, la commande del foobar.txt n'est pas différent de del foobar.bin Cependant copy a.txt + b.txt c.txt est différent de copy /b a.bin + b.bin c.bin Pourquoi ? Parce que l'invite de commande de Windows veut être utile et interprète les fichiers texte comme tels et copie le fichier lignes à la sortie (en ajoutant une nouvelle ligne entre les fichiers), mais copie les fichiers binaires en l'état sans interférence.

Par exemple, en Ruby :
f = File.open('filename.bin', 'rb') # read a file in binary mode
f = File.open('filename.txt', 'r') # read a file in text mode
En Python :
f = open("filename.bin", "rb") # read a file in binary mode
f = open("filename.txt", "r") # read a file in text mode
Sur d'autres systèmes d'exploitation, il semble qu'il n'y ait pas de différence entre un fichier texte et un fichier binaire dans le système de fichiers.

Il s'agit de langages de script, qui s'exécutent donc à partir de la ligne de commande. Lorsque vous travaillez avec des fichiers texte, il n'y a généralement pas de problème, mais avec des fichiers binaires, vous utilisez le mode binaire pour éviter que l'invite de commande ne prétraite le fichier et ne le transmette sous forme d'octets bruts.

Sous Linux, lorsque vous tapez ou pipetez un fichier, le Shell transmet tous les octets bruts au lieu de les prétraiter en tant que texte comme le fait l'invite de commande de Windows.

Cela dit, en fonction du programme et de la manière dont le fichier d'entrée est transmis, il est possible d'éviter complètement le prétraitement. Par exemple C:\>pyhton foobar.py baz.bin passerait l'étape de la nom du fichier d'entrée au script qui l'ouvrirait alors à sa guise alors que C:\>type baz.bin | python foobar.py entraînerait la lecture du fichier par l'invite de commande, puis le passage de la commande chaque ligne au script, ce qui pour un fichier binaire n'est pas bon.

Les différents modes permettent simplement flexibilité et vous permettent de jouer la carte de la sécurité et de traiter les fichiers comme vous l'entendez.

CP/M (Control Program for Microcomputers) a été créé par Digital Research dans les années 1970. La taille des fichiers dans CP/M était exprimée sous la forme d'un décompte de secteurs de disque de 128 octets -- en d'autres termes, un décompte exact de la taille du fichier par octet n'était pas disponible. Ce n'était pas (autant) un problème pour les fichiers binaires, puisque 127 octets supplémentaires de NULL (ou autre) n'avaient généralement pas d'impact négatif sur le chargement du programme. En revanche, c'était problématique pour les fichiers texte, qui pouvaient être de longueur arbitraire.

Ainsi, le système CP/M fait la distinction entre les fichiers binaires et les fichiers texte. Par convention, le dernier octet d'un fichier texte était un caractère Control-Z dans la bande -- vous lisiez le fichier jusqu'à ce que vous voyiez ^Z, puis vous vous arrêtiez. (Les fichiers binaires ne nécessitaient pas ce traitement ; il suffisait de charger le nombre brut de secteurs).

CP/M était très populaire et a été piraté par de nombreuses personnes. L'un d'entre eux s'appelait Tim Paterson et travaillait pour une petite entreprise appelée Seattle Computer Products. Il a créé un clone de CP/M pour le matériel de classe x86 appelé QDOS (Quick and Dirty Operating System), qui imitait une bonne partie de la conception fonctionnelle de CP/M. QDOS a ensuite été racheté par un étudiant à l'esprit douteux du nom de Bill Gates, qui l'a encore amélioré, en reprenant sans réfléchir tous ses défauts de conception et ses limitations, et a créé MS-DOS. Et Windows lui-même a commencé sa vie comme un kluge au sommet de MS-DOS.

Bien que Microsoft ait depuis appris - probablement par pur hasard - à créer un système de fichiers qui conserve le nombre exact d'octets pour les fichiers, la distinction entre les fichiers texte et les fichiers binaires subsiste, même si elle n'a plus aucune utilité.

Vous réalisez que Python fonctionne aussi sous *nix et mac, n'est-ce pas ? et que la fonction est la même sur ces systèmes d'exploitation ? Ce n'est pas seulement une affaire de Windows. Regardez l'article de Wikipedia sur les fichiers binaires - la première ligne résume assez bien la situation :

Un fichier binaire est un fichier informatique qui n'est pas un fichier texte. contenir n'importe quel type de données, codées sous forme binaire pour le stockage informatique à des fins de stockage et de traitement informatique.

Il poursuit en déclarant

Les fichiers binaires sont généralement considérés comme une séquence d'octets, ce qui signifie que les chiffres binaires (bits) sont groupés par huit. Les fichiers contiennent généralement des octets destinés à être interprétés en tant que autre chose que des caractères de texte.

Alors que les fichiers texte sont beaucoup plus simples :

Un fichier texte... est un type de fichier informatique structuré comme une séquence de lignes de caractères électroniques. séquence de lignes de texte électronique. Un fichier texte existe au sein d'un système de fichiers informatiques. La fin d'un fichier texte est souvent signalée par en plaçant un ou plusieurs caractères spéciaux, connus sous le nom de marqueur de fin de fichier après la dernière ligne d'un fichier texte

La réponse est donc oui : il s'agit dans les deux cas d'une séquence d'octets, mais la méthode de codage des données est très différente. Un éditeur de texte est programmé pour lire le codage d'un fichier texte et un lecteur binaire est programmé pour lire le codage d'un fichier binaire. Lorsque vous appelez ces fonctions en Python ou en Ruby, vous leur indiquez le codage à attendre du fichier afin qu'elles le décodent correctement. Il en va de même quel que soit le système d'exploitation utilisé.