Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Вопросик по текстовым файлам - разделители строк  (Прочитано 7619 раз)
0 Пользователей и 1 Гость смотрят эту тему.
lightmaker
Участник

ru
Offline Offline

« : 28-02-2008 09:40 » 

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

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

По логике весчей между этими двумя строками должно быть два специальных символа Новой строки и Возврата каретки.
Почему же на практике там отсутствует символ Возврата каретки? Поясните пожалуйста!
« Последнее редактирование: 09-04-2008 20:10 от Вад » Записан
Алексей++
кот глобальный и пушистый
Глобальный модератор

ru
Offline Offline
Сообщений: 13


« Ответ #1 : 28-02-2008 09:47 » 

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

Вад
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #2 : 28-02-2008 09:48 » 

А заодно назови платформу Улыбаюсь Не Unix часом?
Записан
lightmaker
Участник

ru
Offline Offline

« Ответ #3 : 28-02-2008 10:31 » 

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

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

ru
Offline Offline

« Ответ #4 : 28-02-2008 12:30 » 

а покажи дамп файла или прикрепи к посту
глупый вопрос: что есть дамп файла?
Записан
Алексей++
кот глобальный и пушистый
Глобальный модератор

ru
Offline Offline
Сообщений: 13


« Ответ #5 : 28-02-2008 12:44 » 

в хекс виде

а насчёт отсутствия \r - про другие системы не знаю , а в винде - кому то просто руки надо оторвать за несоблюдение правил Улыбаюсь Надо быть и \r и \n и при этом именно в таком порядке
« Последнее редактирование: 28-02-2008 12:46 от Алексей1153++ » Записан

Антон (LogRus)
Глобальный модератор

ru
Offline Offline
Пол: Мужской
Внимание! Люблю сахар в кубиках!


WWW
« Ответ #6 : 28-02-2008 12:55 » 

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

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

Странно всё это....
lightmaker
Участник

ru
Offline Offline

« Ответ #7 : 28-02-2008 13:01 » 

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

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

Улыбаюсь короче действительно придется принять как должное
Записан
Артем
Опытный

nz
Offline Offline
Пол: Мужской
Beware the wolf in sheep's clothing.


« Ответ #8 : 28-02-2008 13:03 » 

В 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

« Последнее редактирование: 28-02-2008 13:12 от Артем » Записан
Алексей++
кот глобальный и пушистый
Глобальный модератор

ru
Offline Offline
Сообщений: 13


« Ответ #9 : 28-02-2008 13:04 » 

а эт пАтАмушта они думают иначе Отлично
Записан

RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #10 : 28-02-2008 19:12 » 

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
lightmaker
Участник

ru
Offline Offline

« Ответ #11 : 28-02-2008 22:33 » 

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

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

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #12 : 29-02-2008 00:05 » 

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.
« Последнее редактирование: 29-02-2008 00:07 от RXL » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines