чем в текстовом файле заканчивается каждая строка
Текстовые файлы
Текстовые файлы состоят из символьных строк переменной длины.
Каждая строка завершается специальной комбинацией «конец строки», которая состоит из двух символов: «перевод каретки» (ASCII-код #13 ) и «перевод строки» ( #10 ).
Завершается текстовый файл символом «конец файла» ( #26 ).
Чтобы прочитать данные из файла, в качестве первого параметра указывают имя файловой переменной, далее через запятую перечисляются переменные, в которые осуществляется чтение данных из файла.
Если элемент данных может быть преобразован в число, это преобразование осуществляется автоматически при вводе в числовые переменные. Элементы числовых данных в строках текстового файла разделяются пробелами или символами табуляции.
Если строка файла закончилась, а состоящий из числовых или символьных переменных список параметров в read не исчерпался, то начинает считываться следующая строка.
При вводе данных из текстового файла в символьные переменные элементы данных не разделяются.
Если в списке данных после числовой переменной идет строковая, то пробел, который следует после числового значения в файле, считывается в строку (это же справедливо и при считывании в символьную переменную).
Рассмотрим пример. В текстовом файле f.txt через пробел и Enter записаны целые числа. Переписать в файл f1.txt из файла f.txt все числа, за исключением максимальных (предполагается, что их может быть несколько).
В примере файл f.txt прочитывается два раза. Первый раз для определения максимального числа, второй раз — для считывания чисел и их записи во второй файл.
Особенностью текстовых файлов является то, что они являются файлами последовательного доступа: нельзя прочитать какой-либо элемент текстового файла, не прочитав все предшествующие элементы. Аналогично нельзя записывать информацию в текстовый файл произвольным образом, писать в него можно только последовательно.
Pascal: Занятие № 12 Часть1. Работа с файлами в паскале (текстовые файлы)
Работа с файлами в паскале
Виды файлов в зависимости от их описания и режимом работы
Описание файловых переменных:
Для связи файла в коде программы и действительного файла на внешнем носителе используется процедура ASSIGN :
где myfile — имя переменной (объявленной ранее в области var ), ассоциированной с файлом
c:\text.txt — путь к реальному файлу
Первый аргумент процедуры assign в паскаль — переменная, второй – путь к файлу на диске.
Текстовые файлы в паскале: процедуры работы
Текстовый файл в Паскале — это совокупность строк произвольной длины, которые разделены между собой метками конца строки, а весь файл заканчивается меткой конца файла.
Возможные расширения файлов:
*.txt, *.log,
*.htm, *.html
Метод работы с текстовым файлом в Паскале предусматривает лишь последовательный доступ к каждой строке файла. Это означает, что начинать всегда возможно только с первой строки, затем проходя по каждой строке, дойти постепенно до необходимой. Т.е. можно сказать, что чтение (или запись) из файла (в файл) ведутся байт за байтом от начала к концу.
Предусмотрены два режима работы: режим для записи в файл информации и для чтения ее из файла. Одновременная запись и чтение запрещены.
Открытие файла
Допустим, мы в программе описали переменную для работы с текстовым файлом:
Рассмотрим дальнейшую последовательность работы с ним, и рассмотрим процедуры, необходимые для работы с текстовым файлом в Паскале:
процедура открытия существующего файла для чтения при последовательном доступе:
процедура открытия создаваемого файла для записи в него информации; если файл с таким именем уже существует, то информация в нем стирается:
Почему важно всегда ставить символ переноса строки в конце текстовых файлов?
Иногда при просмотре диффов коммитов через git log или git diff можно заметить следующий вывод:
Или на GitHub в интерфейсе для просмотра диффов:
Почему это так важно, что Git и GitHub предупреждают нас об этом? Давайте разберемся.
Что такое символ переноса строки?
Что может быть проще, чем текстовый файл? Просто текстовые данные — как хранятся на диске, так и отображаются. На самом деле правительство нам врёт всё немного сложнее.
Оффтопик про управляющие символы ASCII
Не все символы, которые содержатся в текстовых файлах, имеют визуальное представление. Такие символы ещё называют «управляющими», и к ним относятся, например:
Многие эти символы пришли к нам из эпохи печатных машинок, поэтому у них такие странные названия. И действительно, в контексте печатной машинки или принтера такие операции, как перевод строки (сместить лист бумаги вверх так, чтобы печатающая головка попала на следующую строку), возврат каретки (переместить печатающую головку в крайнее левое положение) и возврат на один символ назад, обретают смысл. При помощи возврата на один символ назад создавались жирные символы (печатаешь символ, возвращаешься назад и печатаешь его ещё раз) и буквы с диакритическими знаками, такие как à или ã (печатаешь символ, возвращаешься назад и печатаешь апостроф или тильду). Но зачем печатной машинке бибикалка?
Сегодня многие из этих символов потеряли смысл, но некоторые до сих пор выполняют функцию, схожую с исходной.
Текстовые редакторы отображают текстовые файлы в некоем адаптированном виде, преобразуя непечатаемые символы, например, переносы строк и табуляции преобразуются в настоящие отдельные строки или выравнивающие отступы.
Для набора символа переноса строки достаточно нажать клавишу «Enter», но на разных платформах этот символ закодируется по-разному:
Как видите, Windows точнее всего эмулирует поведение печатной машинки.
Почему перенос строки в конце файла важен?
Согласно определению из стандарта POSIX, который тоже пришёл к нам из эпохи печатных машинок:
Строка — это последовательность из нуля или более символов, не являющихся символом новой строки, и терминирующего символа новой строки.
Почему важен этот стандарт? Возможен миллиард способов реализовать одно и то же, и только благодаря стандартам, таким как POSIX, мы имеем сейчас огромное количество качественного ПО, которое не конфликтует друг с другом.
Т.е. если вы не ставите символ переноса строки в конце строки, то формально по стандарту такая строка не является валидной. Множество утилит из Unix, которыми я пользуюсь каждый день, написано в согласии с этим стандартом, и они просто не могут правильно обрабатывать такие «сломанные» строки.
Давайте, например, через Python создадим такой файл со сломанными строками:
Упс! wc нашла только 2 строки!
Давайте создадим еще один файл:
И попробуем теперь склеить два созданных файла при помощи утилиты cat :
Название cat — это сокращение от «конкатенация», и никак не связано с котиками. А жаль.
И опять какой-то странный результат! В большинстве случаев это не то, чего вы бы ожидали, но вполне возможны ситуации, когда вам нужен именно такой результат. Именно поэтому утилита cat не может самостоятельно вставлять отсутствующие символы переноса строки, иначе это сделало бы её поведение неконсистентным.
Ещё доводы:
Настраиваем редактор
Самый простой способ перестать думать о пустых строках и начать жить — это настроить свой текстовый редактор или IDE на автоматическое добавление символа переноса строки в конец файлов:
Для других редакторов смотрите настройку здесь.
Заключение
Возможно, такая маленькая деталь, как перенос строки в конце файла и не кажется очень важной, а тема вообще кажется спорной, но боюсь, что у нас нет другого выбора, кроме как принять это правило за данность и просто выработать привычку (или настроить инструментарий) всегда ставить символ новой строки в любых текстовых файлах, даже если этого не требуется явно. Это считается распространённой хорошей практикой, и как минимум убережёт вас и ваших коллег от всяких неожиданных эффектов при работе с утилитами Unix.
В текстовом редакторе это выглядит как лишняя пустая строка в конце файла:
Почему текстовые файлы должны заканчиваться новой строкой?
18 ответов
Каждая строка должна заканчиваться символом новой строки, включая последнюю. У некоторых программ возникают проблемы с обработкой последней строки файла, если она не завершена новой строкой.
GCC предупреждает об этом не потому, что он не может обработать файл, а потому, что он должен как часть стандарта.
Стандарт языка C говорит, что исходный файл, который не является пустым, должен заканчиваться символом новой строки, которому не должен непосредственно предшествовать символ обратной косой черты.
Поскольку это предложение «должно», мы должны выдать диагностическое сообщение о нарушении этого правила.
Это в разделе 2.1.1.2 стандарта ANSI C 1989. Раздел 5.1.1.2 стандарта ISO C 1999 (и, вероятно, также стандарт ISO C 1990).
Этот ответ представляет собой попытку дать технический ответ, а не мнение.
Если мы хотим быть сторонниками POSIX, мы определяем строку как:
Неполная строка как:
Текстовый файл как:
Непрерывная последовательность байтов, которая заканчивается первым нулевым байтом и включает его.
Из руководства wc мы читаем:
Каковы последствия того, что файлы JavaScript, HTML и CSS являются текстовыми файлами?
В браузерах, современных IDE и других интерфейсных приложениях нет проблем с пропуском EOL при EOF. Приложения правильно проанализируют файлы. Это необходимо, поскольку не все операционные системы соответствуют стандарту POSIX, поэтому для инструментов, не относящихся к ОС (например, браузеров), было бы непрактично обрабатывать файлы в соответствии со стандартом POSIX (или любым стандартом уровня ОС).
Мы можем сделать еще один шаг и сказать, что что касается NodeJS, он тоже не может придерживаться стандарта POSIX, так как он может работать в средах, несовместимых с POSIX.
С чем мы тогда остались? Инструменты системного уровня.
Это означает, что единственные проблемы, которые могут возникнуть, связаны с инструментами, которые пытаются придерживаться своей функциональности в соответствии с семантикой POSIX (например, определение строки, как показано в wc ).
Оставаясь на пути к инструментарию, для всех практических намерений и целей давайте рассмотрим следующее:
Давайте работать с файлом без EOL. На момент написания файл в этом примере представляет собой миниатюрный JavaScript без EOL.
Как кто-то еще упомянул в этой ветке: что, если вы хотите cat два файла, вывод которых становится одной строкой вместо двух? Другими словами, cat делает то, что должен делать.
-n Нумеровать выходные строки, начиная с 1.
Заключение
Мораль истории: инструменты инженера, которые не имеют недостатков, связанных с EOL в EOF.
Не стесняйтесь публиковать варианты использования, поскольку они применяются к JS, HTML и CSS, где мы можем изучить, как пропуск EOL имеет неблагоприятный эффект.
Это может быть связано с разницей между:
Если каждая строка действительно заканчивается концом строки, это позволяет избежать, например, того, что объединение двух текстовых файлов приведет к тому, что последняя строка первого попадет в первую строку второго.
Кроме того, редактор может проверять при загрузке, заканчивается ли файл концом строки, сохраняет его в своем локальном параметре «eol» и использует его при записи файла.
Некоторые инструменты этого ожидают. Например, wc ожидает этого:
Почему текстовые файлы заканчиваются символом новой строки?
ОТВЕТЫ
Ответ 1
Поэтому строки, не заканчивающиеся символом новой строки, не считаются фактическими. Поэтому в некоторых программах возникают проблемы с обработкой последней строки файла, если он не завершен новой строкой.
При работе с эмулятором терминала есть, по крайней мере, одно серьезное преимущество: все инструменты Unix ожидают этого соглашения и работают с ним. Например, при объединении файлов с помощью cat файл, оканчивающийся символом новой строки, будет иметь другой эффект, чем файл без:
И, как показано в предыдущем примере, при отображении файла в командной строке (например, через more ) файл с новой строкой в конце приводит к правильному отображению. Неправильно завершенный файл может быть искажен (вторая строка).
Подумайте об этом по-другому: если строки не заканчиваются символом новой строки, сделать такие команды, как cat полезными, гораздо сложнее: как создать команду для объединения файлов таким образом, чтобы
. Или вам нужно ввести специальный символ стража, чтобы пометить строку, которая должна быть продолжена, а не завершена. Что ж, теперь вы застряли в той же ситуации, что и в POSIX, за исключением перевернутого (продолжение строки, а не символ завершения строки).
Ответ 2
Каждая строка должна быть прервана символом новой строки, включая последнюю. Некоторые программы имеют проблемы с обработкой последней строки файла, если она не завершена новой строкой.
GCC предупреждает об этом не потому, что не может обработать файл, а потому, что он должен быть частью стандарта.
В стандарте C-языка Исходный файл, который не является пустым, должен заканчиваться символом новой строки, которому не следует сразу же следовать символ обратной косой черты.
Так как это предложение «должно», мы должны исправить диагностическое сообщение для нарушения этого правила.
Это в разделе 2.1.1.2 стандарта ANSI C 1989. Раздел 5.1.1.2 стандарта ISO C 1999 (и, возможно, также стандарта ISO C 1990).
Ответ 3
Этот ответ является попыткой технического ответа, а не мнения.
Если мы хотим быть пуристами POSIX, мы определяем строку как:
Неполная строка как:
Последовательность из одного или нескольких символов non- в конце файла.
Текстовый файл как:
Непрерывная последовательность байтов, оканчивающаяся первым нулевым байтом и включающая его.
Из этого мы можем сделать вывод, что единственное время, когда мы потенциально можем столкнуться с проблемами любого типа, это если мы имеем дело с концепцией строки файла или файла как текстового файла (поскольку текстовый файл является организацией с нулевым или больше строк, и известная нам строка должна заканчиваться символом ).
С wc руководства мы читаем:
Каковы последствия для файлов JavaScript, HTML и CSS в том, что они являются текстовыми файлами?
Мы можем сделать еще один шаг вперед и сказать, что в отношении NodeJS он также не может придерживаться стандарта POSIX, поскольку он может работать в non- POSIX-совместимых средах.
Что же нам тогда осталось? Инструменты системного уровня.
Это означает, что единственные проблемы, которые могут возникнуть, связаны с инструментами, которые прилагают усилия, чтобы привязать их функциональность к семантике POSIX (например, определение строки, как показано в wc ).
Пищу для размышлений о ценности EOL, являющейся : https://www.rfc-editor.org/old/EOLstory.txt
Оставаясь на пути к инструменту, для всех практических целей и задач, давайте рассмотрим это:
Пусть работает с файлом, который не имеет EOL. На момент написания статьи файл в этом примере представлял собой минимизированный JavaScript без EOL.
Обратите внимание, что размер файла cat является суммой отдельных его частей. Если конкатенация файлов JavaScript представляет собой проблему для файлов JS, более уместным было бы начинать каждый файл JavaScript с точки с запятой.
Как кто-то еще упомянул в этой теме: что если вы хотите cat два файла, вывод которых становится одной строкой вместо двух? Другими словами, cat делает то, что должна делать.
-n Нумерация выходных строк, начиная с 1.
Теперь, когда мы понимаем, как POSIX определяет линию, это поведение становится неоднозначным или действительно совместимым с non-.
Заключение
Мораль истории: Инженерные инструменты, у которых нет слабости полагаться на EOL в EOF.
Не стесняйтесь публиковать варианты использования, так как они относятся к JS, HTML и CSS, где мы можем изучить, как пропуск EOL отрицательно сказывается.
Ответ 4
Это может быть связано с разница между:
Если каждая строка заканчивается в конце строки, это позволяет избежать, например, того, что объединение двух текстовых файлов сделает последнюю строку первого запуска в первой строке второй.
Кроме того, редактор может проверить при загрузке, заканчивается ли файл в конце строки, сохраняет его в своей локальной опции «eol» и использует это при записи файла.
Несколько лет назад (2005) многие редакторы (ZDE, Eclipse, Scite. ) «забыли», что окончательный EOL, который не был очень ценится.
Не только это, но они неправильно интерпретировали этот окончательный EOL, так как «начали новую строку» и фактически начали отображать другую строку, как если бы она уже существовала.
Это было прекрасно видно с помощью «правильного» текстового файла с хорошо подобранным текстовым редактором, например, vim, по сравнению с открытием его в одном из вышеупомянутых редакторов. Он отобразил дополнительную строку под реальной последней строкой файла. Вы видите что-то вроде этого:
Ответ 5
Некоторые инструменты ожидают этого. Например, wc ожидает следующее:
Ответ 6
В основном существует много программ, которые не будут обрабатывать файлы правильно, если они не получат окончательный EOL EOF.
GCC предупреждает вас об этом, поскольку он ожидается как часть стандарта C. (см. раздел 5.1.1.2)
Ответ 7
Это происходит с самых первых дней использования простых терминалов. Новая строка char использовалась для запуска «сброса» переданных данных.
Сегодня новая строка char больше не требуется. Конечно, во многих приложениях все еще есть проблемы, если новая строка не существует, но я считаю, что ошибка в этих приложениях.
Если у вас есть формат текстового файла, где требуется новая строка, вы получите простую проверку данных очень дешево: если файл заканчивается строкой, в которой нет новой строки в конце, вы знаете, файл сломан. Имея только один дополнительный байт для каждой строки, вы можете обнаруживать разбитые файлы с высокой точностью и почти без процессорного времени.
Ответ 8
В дополнение к приведенным выше практическим соображениям меня не удивило бы, если бы создатели Unix (Thompson, Ritchie и др.) или их предшественники Multics поняли, что существует теоретическая причина использовать ограничители строк, а не разделители строк: С терминаторами строк вы можете кодировать все возможные файлы строк. С разделителями строк нет никакой разницы между файлом нулевых строк и файлом, содержащим одну пустую строку; оба они закодированы как файл, содержащий нулевые символы.
Итак, причины таковы:
Ответ 9
Также существует проблема с программированием с файлами, в которых нет новых строк: встроенный read Bash (я не знаю о других реализациях read ) работает не так, как ожидалось:
Ответ 10
Отдельный прецедент: когда ваш текстовый файл контролируется версией (в данном случае специально под git, хотя это относится и к другим). Если содержимое добавлено в конец файла, тогда строка, которая была ранее последней строкой, будет отредактирована, чтобы включить символ новой строки. Это означает, что blame файл, чтобы узнать, когда эта строка была отредактирована последним, покажет добавление текста, а не фиксацию до того, что вы действительно хотели увидеть.
Ответ 11
Предположительно просто, чтобы какой-то код синтаксического анализа ожидал, что он будет там.
Я не уверен, что считаю это «правилом», и это, безусловно, не то, что я придерживаюсь религиозно. Наиболее разумный код будет знать, как разбор текста (включая кодировки) по очереди (любой выбор окончаний строк), с или без новой строки в последней строке.
В самом деле, если вы закончите с новой строкой: существует ли (теоретически) пустая конечная строка между EOL и EOF? Один, чтобы обдумать.
Ответ 12
Почему текстовые файлы заканчиваются символом новой строки?
Также выражается многими, потому что:
Многие программы не ведут себя хорошо, или без них.
Программы редко запрещают окончательный ‘\n’ (я ничего не знаю).
Но это вызывает следующий вопрос:
Что должен делать код с текстовыми файлами без новой строки?
Ответ 13
Я сам это задавался годами. Но сегодня я столкнулся с серьезной причиной.
Представьте файл с записью на каждой строке (например: файл CSV). И что компьютер записывал записи в конце файла. Но он внезапно упал. Джи была последней строкой? (не хорошая ситуация)
Но если мы всегда завершаем последнюю строку, тогда мы бы знали (просто проверьте, завершена ли последняя строка). В противном случае нам, вероятно, придется каждый раз отбрасывать последнюю строку, чтобы быть в безопасности.
Ответ 14
У меня всегда было впечатление, что правило исходило из тех дней, когда синтаксический анализ файла без окончания новой строки был затруднен. То есть, вы закончите писать код, где конец строки был задан символом EOL или EOF. Просто было проще предположить, что линия закончилась EOL.
Ответ 15
Здесь очень поздно, но я столкнулся с одной ошибкой в обработке файлов, которая произошла из-за того, что файлы не заканчивались пустым переводом строки. Мы обрабатывали текстовые файлы с помощью sed и sed опускал последнюю строку в выводе, что приводило к неправильной структуре json и отправляло остальную часть процесса в состояние сбоя.
Все, что мы делали, было:
Есть один пример файла: foo.txt с некоторым содержанием json внутри.
Файл был создан на машине вдов, и оконные скрипты обрабатывали этот файл с помощью команд powershall. Все хорошо.
Когда мы обработали тот же файл, используя sed в командной sed ‘s|value|newValue|g’ foo.txt > foo.txt.tmp в sed ‘s|value|newValue|g’ foo.txt > foo.txt.tmp Вновь созданный файл был
и бум, он отказал остальным процессам из-за недопустимого JSON.
Поэтому всегда полезно заканчивать свой файл пустой новой строкой.
Ответ 16
Представьте, что файл обрабатывается, пока файл все еще создается другим процессом.
Это может быть связано с этим? Флаг, который указывает, что файл готов к обработке.
Ответ 17
Мне лично нравятся новые строки в конце файлов исходного кода.
Возможно, это связано с Linux или всеми UNIX-системами. Я помню там ошибки компиляции (gcc, если я не ошибаюсь), потому что файлы исходного кода не заканчивались пустой пустой строкой. Почему это было сделано так, что вам интересно.
Ответ 18
ИМХО, это вопрос личного стиля и мнения.
В старые времена я не ставил эту новую строку. Сохраненный символ означает большую скорость через этот 14.4K модем.
Позже я поместил эту новую строку, чтобы было легче выбрать финальную строку с помощью shift + downarrow.