4

Во многих различных языках программирования существуют конструкции, специально предназначенные для обхода того факта, что Windows различает текстовые и двоичные файлы.

Например, в 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

В Python:

f = open("filename.bin", "rb")  # read a file in binary mode
f = open("filename.txt", "r")   # read a file in text mode

В других операционных системах кажется, что нет разницы между текстовым файлом и двоичным файлом с файловой системой.

На самом деле, я бы предположил, что в действительности нет разницы между текстом и двоичным файлом, поскольку оба являются просто набором байтов. Текстовый файл может быть легко представлен в редакторе в зависимости от кодировки, тогда как двоичный файл обычно не будет, но базовое представление такое же: последовательность байтов в заданном порядке.

Почему Windows делает это различие, которое кажется ненужным?

3 ответа3

10

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

Короткий ответ

Нет

Длинный ответ

На самом деле, я бы предположил, что в действительности нет разницы между текстом и двоичным файлом, поскольку оба являются просто набором байтов. Текстовый файл может быть легко представлен в редакторе [sic] в зависимости от кодировки, тогда как двоичный файл обычно не будет, но базовое представление такое же: последовательность байтов в заданном порядке.

Как вы сказали, файл - это просто набор байтов. Вот и все. Его содержание имеет смысл только тогда, когда интерпретируется программой. Одна программа может полностью интерпретировать байты в файле одним способом, а другая - другим. Когда вы открываете «двоичный» файл в текстовом редакторе, он будет интерпретировать байты как текст и отображать их. Если файл не является «простым текстом», то результаты, скорее всего, будут бессмысленными, но программа все еще выполняет свою работу по их интерпретации и выводу.

Во многих различных языках программирования существуют конструкции, специально предназначенные для обхода того факта, что Windows различает текстовые и двоичные файлы.

Windows не имеет. Происходит то, что большинство таких языков программирования развивались в других операционных системах, таких как Unix, Linux и т.д., И поэтому используют разные окончания строк для собственных текстовых файлов. Возможно, что они также используют другую кодировку, но, как правило, конечные строки будут варьироваться от платформы к платформе.

Вот список общих платформ и окончаний строк:

  • Unix, Linux - перевод строки
  • Окна - возврат каретки, перевод строки
  • Mac (исторически) - возврат каретки
  • (Несколько старых ОС (например, Acorn BBC) - перевод строки, возврат каретки)

Почему Windows делает это различие, которое кажется ненужным?

Windows - операционная система, она сама по себе ничего не различает. Вопрос, который вы должны задать, состоит в том, какие части Windows отличаются. В этом случае это командная строка, которая обрабатывает текстовые и двоичные файлы по-разному, и даже в этом случае это зависит от используемой команды. Например, команда del foobar.txt ничем не отличается от del foobar.bin , однако copy a.txt + b.txt c.txt отличается от copy /b a.bin + b.bin c.bin Почему? Поскольку командная строка Windows , хочет быть полезными и интерпретирует текстовые файлы как таковые и копию линий на выход ( при добавлении новой строки между файлами), но копирует бинарные файлы , как это без каких - либо помех.

Например, в 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
В Python:
f = open("filename.bin", "rb") # read a file in binary mode
f = open("filename.txt", "r") # read a file in text mode
В других операционных системах кажется, что нет разницы между текстовым файлом и двоичным файлом с файловой системой.

Все это языки сценариев, и поэтому запускаются из командной строки. При работе с файлами ввода текста, как правило, проблем не так много, но с двоичными файлами вы используете двоичный режим, чтобы избежать командной строки от предварительной обработки файла и передачи его в виде необработанных байтов.

В Linux, когда вы вводите или передаете файл по каналу, оболочка передает все необработанные байты вместо предварительной обработки его в виде текста, как в командной строке Windows.

Тем не менее, в зависимости от программы и способа передачи входного файла, можно легко избежать предварительной обработки. Например, C:\>pyhton foobar.py baz.bin передает имя входного файла скрипту, который затем открывает его по своему усмотрению, тогда как C:\>type baz.bin | python foobar.py заставит командную строку прочитать файл, а затем передать каждую строку скрипту, что для двоичного файла не годится.

Различные режимы просто обеспечивают гибкость и позволяют вам играть безопасно и обрабатывать файлы так, как вы ожидаете.

1

CP/M (управляющая программа для микрокомпьютеров) была создана Digital Research в 1970-х годах. Размеры файлов в CP/M выражались в виде подсчета 128-байтовых секторов диска - другими словами, точное количество байтов в размере файла было недоступно. Это не являлось (в значительной степени) проблемой для двоичных файлов, поскольку дополнительные 127 байтов NULL (или чего-либо другого) обычно не оказывали негативного влияния на загрузку программы. Однако это было проблематично для текстовых файлов, которые могут иметь произвольную длину.

Таким образом, CP/M различает двоичные файлы и текстовые файлы. По соглашению, последний байт текстового файла был внутриполосным символом Control-Z - вы читали файл, пока не увидели ^ Z, а затем остановились. (Двоичные файлы не требуют этой обработки; вы только что загрузили счетчик сырых секторов.)

CP/M был очень популярен, и его взломали многие. Одного из парней, взломавших его, звали Тим Патерсон, который работал в небольшой компании Seattle Computer Products. Он собрал вместе клон CP/M для аппаратного обеспечения класса x86 под названием QDOS (Быстрая и грязная операционная система), который имитировал изрядное количество функционального дизайна CP/M. Затем QDOS был куплен пятнистым выпускником колледжа по имени Билл Гейтс, который еще больше ударил его, бездумно перенеся все его недостатки и ограничения в дизайне, и создал MS-DOS. И сама Windows начала свою жизнь как кладезь поверх MS-DOS.

Хотя Microsoft с тех пор научилась - возможно, совершенно случайно - как создать файловую систему, которая поддерживает точное количество байтов для файлов, различие между текстовыми и двоичными файлами сохраняется, даже если оно больше не служит какой-либо полезной цели.

-1

Вы понимаете, что python работает на * nix и mac тоже, верно? и эта функция одинакова на этих операционных системах? Это не просто вещь для Windows. Посмотрите на статью в Википедии о бинарных файлах - первая строка достаточно хорошо подводит итог:

Бинарный файл - это компьютерный файл, который не является текстовым файлом; он может содержать данные любого типа, закодированные в двоичной форме для хранения и обработки на компьютере.

Далее говорится:

Двоичные файлы обычно рассматриваются как последовательность байтов, что означает, что двоичные цифры (биты) сгруппированы в восьмерки. Двоичные файлы обычно содержат байты, которые должны интерпретироваться как нечто отличное от текстовых символов.

В то время как текстовые файлы намного проще:

Текстовый файл ... это разновидность компьютерного файла, который структурирован как последовательность строк электронного текста. Текстовый файл существует в файловой системе компьютера. Конец текстового файла часто обозначается путем размещения одного или нескольких специальных символов, известных как маркер конца файла, после последней строки в текстовом файле.

Так что да, ответ заключается в том, что оба они представляют собой последовательность байтов, но метод, с помощью которого они кодируют данные, сильно отличается. Текстовый редактор запрограммирован для чтения кодировки текстового файла, а двоичный считыватель запрограммирован для чтения кодировки двоичного файла. Когда вы вызываете эти функции в python или ruby, вы сообщаете ему, какую кодировку ожидать от файла, чтобы он правильно декодировал его. Это будет то же самое, независимо от того, в какой операционной системе вы находитесь.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .