Question Pourquoi y a-t-il une différence entre les fichiers texte et les fichiers binaires dans Windows?


Dans de nombreux langages de programmation différents, il existe des concepts permettant de contourner le fait que Windows différencie les fichiers texte et les fichiers binaires.

Par exemple, dans 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 avec le système de fichiers.

En réalité, je suppose qu’il n’ya littéralement aucune différence entre un texte et un fichier binaire, car les deux sont simplement une collection d’octets. Un fichier texte peut être facilement représentable 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é.

Pourquoi Windows fait-il cette distinction apparemment inutile?


4
2017-11-19 01:55


origine


La compatibilité des bonnes anciennes guerres Motorola / Intel avec Big Endian / Little Endian, MS-DOS et les décisions prises dans un monde 64k issu de CPM avec son besoin d'être extrêmement conservateur en matière de mémoire alors que 640k était tout ce dont on aurait besoin. Les décisions prises depuis longtemps dans un monde qui n'existe plus ont une longue portée. Certaines décisions, une fois prises, ne disparaîtront jamais lorsqu'elles deviendront trop ancrées dans le fonctionnement du système d'exploitation. Oh, et les fins de ligne, les trois grands cr-lf, lf, cr ... - Fiasco Labs
Ce qui signifie que Windows écrit des fichiers texte dans des fichiers little-endian et binaires en big-endian ou vice versa? Pas clair ce que vous voulez dire. - Naftuli Kay
Heh, peu importe ce que Windows écrit maintenant dans des fichiers, mais quoi une fois qu'ils ont été écrits. - Fiasco Labs
Mais comment cela se rapporte-t-il à ma question? - Naftuli Kay
La différence réside dans la mise en mémoire tampon et, dans certains cas, dans le traitement des caractères de contrôle. Vous pouvez lire / écrire un fichier texte en mode binaire, mais si vous lisez / écrivez un fichier binaire en mode texte, vous risquez de corrompre les données. En particulier, il existe un caractère de fin de fichier écrit à la fin des fichiers texte, plus dans certains cas cr/lf se convertit à / de nl. - Daniel R Hicks


Réponses:


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

Réponse courte

Il n'y en a pas.

Longue réponse

En réalité, je suppose qu’il n’ya littéralement aucune différence entre un texte et un fichier binaire, car les deux sont simplement une collection d’octets. Un fichier texte peut être facilement représentable 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 paquet d'octets. C'est tout. Son contenu ne prend sens que lorsqu'il est interprété par un programme. Il est tout à fait possible pour un programme d’interpréter les octets d’un fichier dans un sens et un autre programme de les interpréter. Lorsque vous ouvrez un fichier "binaire" dans un éditeur de texte, il 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 de les interpréter et de les sortir.

Dans de nombreux langages de programmation différents, il existe des concepts permettant de contourner le fait que Windows différencie les fichiers texte et les fichiers binaires.

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

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

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

Pourquoi Windows fait-il cette distinction apparemment inutile?

Windows est un système d'exploitation, il ne distingue rien lui-même. La question que vous devriez poser est la suivante: les pièces de Windows se distinguent. Dans ce cas, c'est l'invite de commande qui traite les fichiers texte et binaires différemment, 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, toutefois 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 Windows veut être utile et interprète les fichiers texte en tant que tels et copie le lignes à la sortie (ajouter une nouvelle ligne entre les fichiers), mais copie les fichiers binaires comme si sans interférence.

Par exemple, dans 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 avec le système de fichiers.

Ce sont tous des langages de script, et donc exécutés à partir de la ligne de commande. Lorsque vous travaillez avec des fichiers d'entrée de texte, il n'y a généralement pas beaucoup de problèmes, mais avec les fichiers binaires, vous utilisez le mode binaire pour éviter que l'invite de commande prétraitera le fichier et le transmettra sous forme d'octets bruts.

Sous Linux, lorsque vous tapez ou dirigez un fichier, le shell transmet tous les octets bruts au lieu de le pré-traiter sous la forme de texte, comme l'invite de commande Windows.

Cela dit, en fonction du programme et de la manière dont le fichier d'entrée est transmis, il est alors facile d'éviter le prétraitement. Par exemple C:\>pyhton foobar.py baz.bin passerait le prénom du fichier d'entrée au script qui l'ouvrirait alors comme il le souhaite alors que C:\>type baz.bin | python foobar.py provoquerait l'invite de commande pour lire le fichier, puis passer chaque ligne au script, qui pour un fichier binaire n'est pas bon.

Les différents modes permettent simplement la flexibilité et vous permettre de le jouer en toute sécurité et de traiter les fichiers comme vous le souhaitez.


9
2017-11-19 02:21





CP / M (programme de contrôle pour micro-ordinateurs) a été créé par Digital Research dans les années 1970. Les tailles de fichier dans CP / M étaient exprimées en tant que nombre de secteurs de disque de 128 octets - en d'autres termes, un nombre d'octets exact de la taille du fichier n'était pas disponible. Ce n'était pas (autant) un problème pour les fichiers binaires, car 127 octets supplémentaires de NULL (ou autre) n'ont généralement pas d'impact négatif sur le chargement du programme. Cependant, il était problématique pour les fichiers texte, qui pouvaient être de longueur arbitraire.

Ainsi, CP / M distinguait les fichiers binaires et les fichiers texte. Par convention, l'octet final d'un fichier texte était un caractère Control-Z dans la bande - vous lisez le fichier jusqu'à ce que vous ayez vu ^ Z, puis vous vous êtes arrêté. (Les fichiers binaires ne nécessitaient pas ce traitement; vous venez de charger le nombre de secteurs bruts.)

CP / M était très populaire et a été piraté par de nombreuses personnes. L'un des gars qui l'a piraté s'appelait Tim Paterson, qui travaillait pour une petite société appelée Seattle Computer Products. Il a assemblé un clone CP / M pour un matériel de classe x86 appelé QDOS (Quick and Dirty Operating System), qui imitait une bonne partie de la conception fonctionnelle de CP / M. Ensuite, QDOS a été acheté par Bill Gates, un décrocheur du collège, qui l'a poursuivi encore plus loin, réalisant inconsciemment toutes ses faiblesses et limites de conception, et a créé MS-DOS. Et Windows lui-même a démarré en tant que kluge par-dessus MS-DOS.

Bien que Microsoft ait depuis appris - probablement par accident - comment créer un système de fichiers qui gère des compteurs d'octets exacts pour les fichiers, la distinction entre les fichiers texte et les fichiers binaires demeure, même si elle ne sert plus à rien.


1
2017-11-19 02:35





Vous vous rendez compte que python fonctionne sur * nix et mac aussi, non? et cette fonction est la même sur ces systèmes d'exploitation? Ce n'est pas juste un truc Windows. Regardez l'article de Wikipedia pour les fichiers binaires - la première ligne le résume assez bien:

Un fichier binaire est un fichier informatique qui n’est pas un fichier texte; cela pourrait   contient tout type de données, encodé sous forme binaire pour le stockage informatique   et fins de traitement.

Il continue en disant:

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 regroupés en huit. Binaire   les fichiers contiennent généralement des octets destinés à être interprétés comme   quelque chose d'autre que des caractères de texte.

Alors que les fichiers texte sont beaucoup plus simples:

Un fichier texte ... est une sorte de fichier informatique structuré   séquence de lignes de texte électronique. Un fichier texte existe dans un   système de fichiers informatique. La fin d'un fichier texte est souvent désignée par   placer un ou plusieurs caractères spéciaux, connus sous le nom de fin de fichier   marqueur, après la dernière ligne dans un fichier texte

Donc oui, la réponse est qu'ils sont tous deux une séquence d'octets, mais la méthode par laquelle ils encodent les données est très différente. Un éditeur de texte est programmé pour lire l'encodage 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 lui indiquez quel encodage attendre du fichier pour le décoder correctement. Ce serait la même quel que soit le système d'exploitation utilisé.


-1
2017-11-19 02:16



Bien sûr, je me rends compte que cela fonctionne sur * nix, je l'exécute sur ma boîte Linux ici. La raison pour laquelle je pose cette question est que sur la plupart des systèmes d’exploitation non Windows, sinon tous, il n’ya pas de différence open('a', 'rb') et open('a', 'r'). Windows est le exception, alors pourquoi est-ce différent? - Naftuli Kay