Когда вы печатаете \n в файл, используя библиотеки Windows C stdio, библиотека интерпретирует это как логическую новую строку, а не буквальный символ 0x0A.Выходными данными в файл будет версия новой строки для Windows: 0x0D0A (\r\n).
Запись
Пример кода:
#include <stdio.h>
int main() {
FILE *f = fopen("foo.txt","w");
fprintf(f,"foo\nbar");
return 0;
}
Быстрый cl /EHsc foo.c позже, и вы получите
0x666F6F 0x0D0A 0x626172 (separated for convenience)
в файле foo.txt в шестнадцатеричном редакторе.
Важно отметить, что этот перевод НЕ происходит, еслиВы пишете в файл в «двоичном режиме».
Чтение
Если вы читаете файл обратно, используя те же инструменты, также в Windows, "Windows EOL "будет интерпретироваться правильно, если вы попытаетесь сравнить с \n.
При чтении обратно
#include <stdio.h>
int main() {
FILE *f = fopen("foo.txt", "r");
char c;
while (EOF != fscanf(f, "%c", &c))
printf("%x-", c);
}
Вы получаете
66-6f-6f-a-62-61-72-
Следовательно, единственный раз, когда это должно относиться к вам, это если вы
- Перемещение файлов назад и вперед между Mac / Unix и Windows.Unix здесь не нуждается в реальном объяснении, поскольку
\n прямо переводится как 0x0A на этих платформах.(pre-OSX \n было 0x0D на Mac iirc) - Помещая текст в двоичные файлы, только делайте это осторожно, пожалуйста
- Пытаясь выяснить, почему ваши двоичные данные испорченыкогда вы открываете файл "w" вместо "wb"
- Оценивая что-то важное на основе размера файла, в Windows у вас будет дополнительный байт на новую строку.