Вопросик по текстовым файлам - разделители строк

[lightmaker]

Имеется такой текстовый файл:

Строка_однин_самый_первый
Строка_два_самый_второй

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

[Алексей++]

а покажи дамп файла или прикрепи к посту

[Вад]

А заодно назови платформу Не Unix часом?

[lightmaker]

Ага, Unix, она самая.
Создал в Linux файлик и Win аналогичный по содержанию, далее посмотрел оба в hex в Win
Каждая строка "винфовского" файла заканчивается 0D, 0A. А "линуксовского" только 0A.

В тему вспомнил, на 1курсе рассказывали про printf, что если надо начать вывод с новой строки, то следует добавить перед нужным куском текста \r\n, но почему хватает только \n?

[lightmaker]

а покажи дамп файла или прикрепи к посту

глупый вопрос: что есть дамп файла?

[Алексей++]

в хекс виде

а насчёт отсутствия \r - про другие системы не знаю , а в винде - кому то просто руки надо оторвать за несоблюдение правил Надо быть и \r и \n и при этом именно в таком порядке

[Антон (LogRus)]

на винде разделитель \r\n
на линухе \n
на маке \r\n

принимаем как должное, впрочем нам, ничто, не мешает явно задать разделитель строк. как при записи так и при чтении.

[lightmaker]

на винде разделитель \r\n

В VS 2003 написал: printf("ффффф\nуууууу");
получил:
ффффф
уууууу

короче действительно придется принять как должное

[Артем]

В VS 2003 написал: printf("ффффф\nуууууу");
получил:
ффффф
уууууу

Это потому, что файл изначально пустой



кстати, в Вики написано, что на маке \r

http://ru.wikipedia.org/wiki/%D0%A3%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D1%8F%D1%8E%D1%89%D0%B8%D0%B5_%D1%81%D0%B8%D0%BC%D0%B2%D0%BE%D0%BB%D1%8B

[Алексей++]

а эт пАтАмушта они думают иначе

[RXL]

Если файл открыт как двоичный, то винда не обрабатывает символы \n без предществующего \r. В противном случае - заменяет его на \r\n. Это надо знать!
В Unix-подобных системах, где принято завершать строку только \n, указание типа файла (текстовы или двоичный) при открытии игнорируется.

[lightmaker]

Если файл открыт как двоичный, то винда не обрабатывает символы \n без предществующего \r. В противном случае - заменяет его на \r\n. Это надо знать!
В Unix-подобных системах, где принято завершать строку только \n, указание типа файла (текстовы или двоичный) при открытии игнорируется.

1. Что значит не обрабатывает \n без предществующего \r? Т.е. если у меня в файле (открытом как бинарный) присутствует одиночный \n, то при считывании я его не получу?

2. В противном случае - заменяет его на \r\n. Т.е. если файл открыт как текстовый и в нем присутствует одиночный \n, то при считывании я получу на этом месте \r\n?

[RXL]

1. В режиме текстового файла: \r\n - пропускается как есть, \n - заменяется на \r\n. В бинарном режиме файл читается как есть - побайтово без изменений.

2. При считывании - затрудняюсь сказать - надо доки глянуть. При записи - да, заменяет.

Вот как обстоят дела в POSIX (стандарт для Unix-систем):
http://www.opennet.ru/man.shtml?topic=fopen&category=3&russian=5

The character 'b' shall have no effect, but is allowed for ISO C standard conformance. Opening a file with read mode (r as the first character in the mode argument) shall fail if the file does not exist or cannot be read.

Вот как дела обстоят у майкрософт:
http://msdn2.microsoft.com/en-us/library/yeby3zcb(vs.71).aspx

In addition to the above values, the following characters can be included in mode to specify the translation mode for newline characters:

t
    Open in text (translated) mode. In this mode, CTRL+Z is interpreted as an end-of-file character on input. In files opened for reading/writing with "a+", fopen checks for a CTRL+Z at the end of the file and removes it, if possible. This is done because using fseek and ftell to move within a file that ends with a CTRL+Z, may cause fseek to behave improperly near the end of the file.

Also, in text mode, carriage return–linefeed combinations are translated into single linefeeds on input, and linefeed characters are translated to carriage return–linefeed combinations on output. When a Unicode stream-I/O function operates in text mode (the default), the source or destination stream is assumed to be a sequence of multibyte characters. Therefore, the Unicode stream-input functions convert multibyte characters to wide characters (as if by a call to the mbtowc function). For the same reason, the Unicode stream-output functions convert wide characters to multibyte characters (as if by a call to the wctomb function).

b
    Open in binary (untranslated) mode; translations involving carriage-return and linefeed characters are suppressed.

If t or b is not given in mode, the default translation mode is defined by the global variable _fmode. If t or b is prefixed to the argument, the function fails and returns NULL.

The c, n, and t mode options are Microsoft extensions for fopen and _fdopen and should not be used where ANSI portability is desired.