Lexander
Если бы не IIS, то конечно.
Система, которая пишет символ конца файла в средине файла.
Как это еще назвать?

Да, если учесть, что логи предназначены для анализа человеком, то точно бинарных данных не должно
быть

Lexander
Если бы не IIS, то конечно.

ИСС тут не при чём, логи наш сервак пишет, там хоть ИСС, хоть апач, всё равно так же будет

В каком случае текстовый режим чтения файла предпочтительнее, чем бинарный?

Budulianin
В каком случае текстовый режим чтения файла предпочтительнее, чем бинарный?

Я там выше отписался, когда нужна независимость от платформы (\r, \n, \r\n).

Lexander
Я там выше отписался, когда нужна независимость от платформы (\r, \n, \r\n).

Спасибо, не заметил

Разве бинарный режим не будет одинаково работать на разных платформах ?

Budulianin
Разве бинарный режим не будет одинаково работать на разных платформах ?

текстовый режим приводит содержимое файла к одному и тому же виду при чтении
перевод строки превращается в \n, какой бы он там ни был в файле
при записи выполняется то же преобразование
это из C пошло

py.user.next
текстовый режим приводит содержимое файла к одному и тому же виду при чтении
перевод строки превращается в \n, какой бы он там ни был в файле
при записи выполняется то же преобразование
это из C пошло

Т.е. при чтении в текстовом режиме, все символы конца строки будут заменены на \n
При чтении в бинарном режиме, символы конца строки остаются нетронутыми

Попробовал читать файлы созданные в винде, в разных режимах

При чтении файла из винды \r\n в конце каждой строки, хоть бинарный режим, хоть текстовый, замены на \n не происходит при чтении в текстовом режиме

Budulianin
Т.е. при чтении в текстовом режиме, все символы конца строки будут заменены на \n

Не заменены, а распознаны именно как символ окончания строки.
Если бы этого не было, то, например, читая на Маке лог, записанный под Вин, у вас 2-я и дальше строки начинались бы с символа \n

Lexander
Не заменены, а распознаны именно как символ окончания строки.

заменены
то есть,
если у тебя в файле \r\n, то при чтении такой строки эти два символа заменятся на \n (если дело под виндой происходит)
если у тебя в файле \r, то при чтении такой строки этот один символ заменится на \n (если дело под маком происходит)
а при записи - обратно: \n -> \r\n (под виндой), \n -> \r (под маком)

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

а в C даже \r\n не распознает в лине и не заменит, потому что в лине перевод строки - \n
то есть это фишка питона, что он может виндовые переводы под линем распознавать

Budulianin
При чтении файла из винды \r\n в конце каждой строки, хоть бинарный режим, хоть текстовый, замены на \n не происходит при чтении в текстовом режиме

всё проверил

Эти файлы ты записал на винде, правильно?

Сначала ты сохранил в текстовом режиме, он перевёл \n -> \r\n т.к. винда

Потом ты считал этот текст в режиме чтения и показал, как Python видит у себя эту строку, т.е. он изменил \r\n -> \n

Потом ты считал этот файл в бинарном режиме и показал, что в строке \r\n , т.к. режим бинарный и Python считал т.к. есть без преобразований

Budulianin
Попробовал читать файлы созданные в винде, в разных режимах
При чтении файла из винды \r\n в конце каждой строки, хоть бинарный режим, хоть текстовый, замены на \n не происходит при чтении в текстовом режиме

Это я на Linux читал файл сохранённый в винде. Поэтому он и не преобразовал \r\n -> \n т.к. такое только в винде работает. Но Python распознаёт в Linux \r\n как символ окончания строки, поэтому нормально работает с таким файлом из винды.

Всё правильно понял?

Budulianin
Эти файлы ты записал на винде, правильно?

ну, да

Budulianin
Потом ты считал этот текст в режиме чтения

в текстовом режиме
есть два режима: текстовый и бинарный
текстовый может проводить изменения над данными (неважные для чтения человеком, типа пробелы в конце строк удалять и так далее), бинарный не может проводить изменения над данными

Budulianin
режим бинарный и Python считал т.к. есть без преобразований

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

“ т.к. режим бинарный и Python считал так, как есть, - без преобразований”

Budulianin
Это я на Linux читал файл сохранённый в винде. Поэтому он и не преобразовал \r\n -> \n т.к. такое только в винде работает.

в питоне они просто распознаются все (в файловом объекте, по-моему, сохраняются все виды встретившихся переводов в кортеже)
в то время как в линукс, в редакторах возвраты каретки не удаляются, а считаются частью строки
поэтому скрипт для bash, созданный в винде, в лине выдаёт ошибку с символом ^M
и, наоборот, текстовый файл, созданный в лине, в виндовом блокноте открывается в виде одной строки с квадратиками

py.user.next

Ну теперь всё стало ясно, спасибо.