C: Как реализован бинарный режим по сравнению с текстовым режимом для fopen?
В качестве учебного упражнения я пытаюсь написать уровень платформы на C для операционных систем Windows и GNU/Linux.
В настоящее время меня интересует реализация функции, которая открывает файл на хост-платформе в предоставленном режиме, аналогично fopen из <stdio.h>. Я знаю, что есть функция Windows API CreateFile из <fileapi.h> и функция GNU open из <fcntl.h>; Я думаю, что смогу использовать их, чтобы открыть файл с диска для чтения или записи. Однако fopen также обеспечивает выбор режима открытия файла: в двоичном или текстовом режиме. Я не совсем понимаю, в чем разница между этими работами под капотом; как мне реализовать эту функциональность в моей версии?
Под окнами с помощью O_BINARY вы увидите \r\n. Без него (т. е. O_TEXT) \r\n массируется до \n на лету. Повторяю, на Linux et. ал. b и O_BINARY не используются и предусмотрены для совместимости с Win32.
Ответы 2
В Microsoft Windows текстовые файлы обычно используют символы \r\n (возврат каретки с последующим переводом строки) в качестве окончания строки. При чтении файлов, открытых в текстовом режиме, окончания строк \r\n преобразуются в \n, так что приложению кажется, что окончания строк состоят из \n вместо \r\n. Кроме того, при записи файлов в текстовом режиме окончания строк \n преобразуются в \r\n. Эти переводы не происходят в двоичном режиме. Кроме того, значение байта 0x1A интерпретируется как конец файла в текстовом режиме, а не в двоичном.
Однако в GNU/Linux (и на всех других платформах POSIX) нет разницы между текстовым и двоичным режимом. В обоих режимах перевод не осуществляется. Это связано с тем, что на этой платформе окончания строк текстовых файлов изначально состоят только из \n, поэтому перевод не требуется.
На самом деле, «окончание строк» предполагает очень многое. Это двухбайтовая последовательность CRLF, преобразованная в LF при чтении, и LF, преобразованная в CRLF при записи... Бедный человек, который пренебрег указанием «b» при открытии файла (двоичных данных или текста), может рассчитывать на сверхурочную работу, чтобы найти Устраните проблему, которая может выглядеть как «поврежденные данные».
В оригинальной Mac OS (когда она называлась «Система») и некоторых других малоизвестных ОС, таких как OS/9, конец строки равен \r.
не совсем понимаю, в чем разница между этими работами под капотом;
Когда код использует "b" для открытия файла, перевод отсутствует. Что бы ни было в файле, это то, что читается. Все, что записано в файл, записывается.
Если код не использует "b" для открытия файла, существует потенциальный перевод. Исходящий "\n" может быть переведен в "\r\n", "\r", "\n" или что-то еще. В последней записи может быть добавлен Ctrl z или нет. Начало файла может включать Спецификацию. Возможны и другие переводы. Чтение таких файлов может потребовать упомянутого выше и предоставить код с меньшим количеством информации. Существует множество аспектов реализации чтения и записи такого текстового файла.
При чтении/записи текстового файла не используйте "b". В противном случае не открывайте с помощью "b".
как мне реализовать эту функциональность в моей версии?
При чтении текстового файла не используйте "b", в противном случае используйте "b".
В posix/linux/*BSD разницы нет. Это просто то, как
fgetsинтерпретирует строку текста. В Linux терминатор строки —\n(новая строка/0x0A). В Windows терминатор строки —\r\n(crlf, cr/newline, 0x0D/0x0A). Если вы передадитеb(для двоичного кода) вfopen, он добавитO_BINARYк флагам, данным [базовому] вызовуopen(или эквиваленту Win32). В Linux уровень приложения (например,fgets) обрабатывает признак конца строки. Я не могу вспомнить точный механизм, но Windows обрабатывает это в ядре. Чтение низкого уровня будет работать по-разному в зависимости от режима.