Я знаю, что я должен открыть двоичный файл, используя "rb" вместо "r", потому что Windows ведет себя по-разному для двоичных и не двоичных файлов.
Но я не понимаю, что именно происходит, если я открываю файл неправильным образом и почему это различие даже необходимо. Другие операционные системы, похоже, преуспевают, обрабатывая оба файла одинаковыми.
Этот режим относится к преобразованию окончаний строки.
При чтении в текстовом режиме окончание собственных строк платформы (\r\n в Windows) преобразуется в конец строки \n в стиле Python Unix. При записи в текстовом режиме происходит обратное.
В двоичном режиме такое преобразование не выполняется.
Другие платформы, как правило, отлично работают без преобразования, потому что они хранят окончание строк изначально \n. (Исключение составляет Mac OS, которая использовала \r в старые времена.) Однако код, основанный на этом, не переносится.
Ну, это для исторических (или, как мне хочется сказать, истеричных) причин. Режимы открытия файла наследуются из библиотеки C stdio и, следовательно, мы следуем за ним.
Для Windows нет разницы между текстовыми и двоичными файлами, как и в любом из клонов Unix. Нет, я имею в виду! - существуют (были) файловые системы/ОС, в которых текстовый файл является совершенно другим зверем из объектного файла и т.д. В некоторых случаях вам приходилось указывать максимальную длину строк заранее, а записи фиксированного размера использовались... ископаемые из времен 80-колоночных бумажных перфокарт и т.д. К счастью, это не так в Unices, Windows и Mac.
Однако - все остальные вещи равны - Unix, Windows и Mac исторически отличаются тем, какие символы они используют в потоке вывода, чтобы отметить конец одной строки (или, что то же самое, что и разделитель между строками). В Unix используется \x0A (\n). В Windows используется последовательность из двух символов \x0D\x0A (\ r\n); на Mac - просто \xOD (\ r). Вот некоторые подсказки о происхождении использования этих двух символов: ASCII-код 10 называется Line Feed (LF), и когда он отправляется в телетайп, он будет перемещаться по одной строке (Y ++), не изменяя его горизонтальную (X) позицию, Возврат каретки (CR) - ASCII 13 - с другой стороны приведет к тому, что печатная каретка вернется к началу строки (X = 0) без прокрутки одной строки вниз. Поэтому при отправке вывода на принтер нужно было отправить как \r, так и \n, чтобы каретка переместилась в начало новой строки. Теперь, когда вы печатаете на терминальной клавиатуре, операторы, естественно, должны нажать один ключ, а не два на конец строки. Это на Apple] [был ключом "Return" (\ r).
Во всяком случае, так обстоят дела. Создатели C были обеспокоены переносимостью - большая часть Unix была написана на C, в отличие от предыдущих, когда ОС были написаны на ассемблере. Поэтому они не хотели иметь дело с каждой платформой причуды о текстовом представлении, поэтому они добавили этот злой хак в свою библиотеку ввода-вывода в зависимости от платформы, вход и выход в этот файл будут "исправлены" на лету, чтобы программа увидит новые строки праведными, Unix-way - как "\n" - независимо от того, было ли это "\ r\n" из Windows или "\ r" с Mac. Поэтому разработчику не нужно беспокоиться о том, на какой ОС была запущена программа, он все равно мог читать и писать текстовые файлы в собственном формате.
Однако возникла проблема - не все файлы - это текст, есть другие форматы, и они очень чувствительны к замене одного символа другим. Поэтому, хотя мы будем называть эти "двоичные файлы" и указывать на fopen() путем включения "b" в режим - и это будет означать, что библиотека не выполняет никакого за кадром преобразования. И как это получилось так:)
Таким образом, если файл открыт с 'b' в двоичном режиме, конверсии не будут. Если он был открыт в текстовом режиме, в зависимости от платформы, могут произойти некоторые преобразования нового символа линии (линий) - к точке зрения Unix. Естественно, на платформе Unix нет разницы между чтением/записью в "текст" или "двоичный" файл.
В Windows текстовый режим преобразует новую строку \n в возврат каретки, за которой следует новая строка \r\n.
Если вы читаете текст в двоичном режиме, проблем нет. Если вы читаете двоичные данные в текстовом режиме, это скорее всего будет повреждено.
Для чтения файлов не должно быть разницы. При записи в текстовые файлы Windows автоматически испортит ваши разрывы строк (он добавит \r до \n). Вот почему вы должны использовать "wb".