Исторически сложилось так, что разные ОС используют разные последовательности для обозначения концов строк в текстовых файлах:
- Unix и сопутствующие файлы
\n (перевод строки) - DOS и Windows
\r\n (возврат каретки, перевод строки) - Mac OS (до Mac OS X)
\r (возврат каретки) (Mac OS X (получившая ядро BSD Unix) может поддерживать оба: разрыв строкиЯвляется ли разрыв строки ).
Это все беспорядок, например:
- Иногда текстовые файлы Windows выглядят немного странно в Xemacs со всеми строками, украшенными
^M в конце строки. - Блокнот Windows (включенный текстовый редактор) отображает текстовые файлы Linux только в одну строку.
Однажды вы периодически переключаетесь между различными ОС,Вы начинаете привыкать, что окончания строк должны быть исправлены время от времени.Для этого существует множество вспомогательных инструментов, например, unix2dos и dos2unix в cygwin, специальные команды в Notepad ++, приглашения в VisualStudio и т. Д.
В C конец строки всегда отмечается \n, дажев DOS и Windows.(У меня нет опыта работы с Mac OS, но я хотел бы спросить, не там ли это по-другому.) Чтобы сделать эту работу безошибочной, MS решила «исправить» содержимое файла при чтении и записи «под капотом».При чтении файла все вхождения \r\n автоматически заменяются на \n, в то время как при записи файла вставляется \r перед каждым записанным \n.
. Это имеет некоторые раздражающие недостатки:
Если файл определенного размера читается, «полученное» содержимое может быть на несколько байтов меньше.(Однажды я наткнулся на это, когда попытался зарезервировать место перед загрузкой файла и одновременным чтением всего содержимого. Я удивился, почему некоторые байты, похоже, отсутствуют после загрузки.)
Это можетпрервать загрузку двоичных файлов, где \n просто представляет двоичное значение 10 с любым значением (за пределами переноса строки).
Чтобы исправить это, C API предоставляет дополнительные режимы для файла I/ OEg fopen() поддерживает за пределами r, w и a, дополнительный символ для обозначения типа файла
b обозначает двоичный ввод / вывод (не трогайте содержимое) t обозначает текстовый ввод / вывод (исправление концов строк).
Без них по умолчанию используется текстовый ввод / вывод.
В Windows, а также для переносимых файловых операций ввода-вывода это всегда должно быть указано.(В Linux это просто не имеет никакого эффекта, особенно без ущерба.)
Однажды я написал ответ на SO: Копирование bmp в c , где дамп поврежденного файла BMPхорошо иллюстрирует эффект неправильного вывода файла.
После этого длинного рассказа о вводе / выводе текстовых и двоичных файлов может быть очевидно, что это всегда потенциальная проблема для разработчиков, работающих с данными изображений (которые обычнозакодированный двоичный файл).
Следовательно, я могу представить, что последовательность \r\n\032\n является просто тестовым шаблоном для этого.Если эти 4 байта не имеют точно этих значений, есть вероятность, что файл
- будет открыт в неправильном режиме (на платформе, где это актуально) или
- поврежден предыдущий инструментсодержимое файла.
Цитировать PeteBlackerThe3rd :
Это позволит декодеру выдавать полезные сообщения об ошибках в этом случае, в отличие от сбоятаинственно.