Почему текстовые файлы должны заканчиваться символом новой строки? - PullRequest
1273 голосов
/ 08 апреля 2009

Я предполагаю, что все здесь знакомы с пословицей, что все текстовые файлы должны заканчиваться символом новой строки. Я знал об этом «правиле» много лет, но всегда задавался вопросом - почему?

Ответы [ 18 ]

9 голосов
/ 08 апреля 2009

Предположительно просто, что какой-то код синтаксического анализа ожидал его там.

Я не уверен, что считаю это «правилом», и, конечно, я не придерживаюсь этого в религиозном отношении. Наиболее разумный код будет знать, как анализировать текст (включая кодировки) построчно (любой выбор конца строки), с или без новой строки в последней строке.

Действительно - если вы заканчиваете новой строкой: есть ли (в теории) пустая последняя строка между EOL и EOF? Один, чтобы задуматься ...

7 голосов
/ 06 марта 2016

Я сам удивлялся этому годами. Но сегодня я нашел хорошую причину.

Представьте файл с записью в каждой строке (например, файл CSV). И что компьютер писал записи в конце файла. Но это внезапно рухнуло. Ну и дела была последняя строка завершена? (не очень хорошая ситуация)

Но если мы всегда завершаем последнюю строку, то мы бы знали (просто проверьте, завершена ли последняя строка). В противном случае нам, вероятно, придется каждый раз сбрасывать последнюю строку, чтобы быть в безопасности.

7 голосов
/ 20 июня 2015

Почему (текстовые) файлы должны заканчиваться символом новой строки?

Так же выражается многими, потому что:

  1. Многие программы не работают или не работают без него.

  2. Даже в программах, которые хорошо обрабатывают файл, отсутствует окончание '\n', функциональные возможности инструмента могут не соответствовать ожиданиям пользователя - что может быть неясно в данном случае.

  3. Программы редко запрещают final '\n' (я не знаю ни о чем).


Тем не менее, напрашивается следующий вопрос:

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

  1. Самое важное - Не писать код, который предполагает, что текстовый файл заканчивается новой строкой . Если файл соответствует формату, это приводит к повреждению данных, хакерским атакам и сбоям. Пример:

    // Bad code
    while (fgets(buf, sizeof buf, instream)) {
      // What happens if there is no \n, buf[] is truncated leading to who knows what
      buf[strlen(buf) - 1] = '\0';  // attempt to rid trailing \n
      ...
    }
    
  2. Если необходим последний трейлинг '\n', предупредите пользователя об его отсутствии и о предпринятых действиях. IOWs, проверьте формат файла. Примечание. Это может включать ограничение максимальной длины строки, кодировки символов и т. Д.

  3. Четко определите, документируйте, как обрабатывать код отсутствующего финала '\n'.

  4. Не, по возможности, генерировать файл с отсутствующим окончанием '\n'.

3 голосов
/ 23 ноября 2018

Здесь очень поздно, но я только что столкнулся с одной ошибкой в ​​обработке файлов, которая возникла из-за того, что файлы не заканчивались пустым переводом строки. Мы обрабатывали текстовые файлы с sed, а sed опускал последнюю строку в выводе, что приводило к неверной структуре json и отправляло остальную часть процесса в состояние отказа.

Все, что мы делали, было:

Существует один пример файла: foo.txt с некоторым содержанием json внутри.

[{
    someProp: value
},
{
    someProp: value
}] <-- No newline here

Файл был создан на машине вдов, и оконные сценарии обрабатывали этот файл с помощью команд powershall. Все хорошо.

Когда мы обрабатывали один и тот же файл, используя команду sed sed 's|value|newValue|g' foo.txt > foo.txt.tmp Недавно сгенерированный файл был

[{
    someProp: value
},
{
    someProp: value

и boom, он завершил работу остальных процессов из-за неверного JSON.

Так что всегда полезно заканчивать свой файл пустой новой строкой.

3 голосов
/ 01 июля 2009

У меня всегда было впечатление, что правило пришло со времен, когда анализ файла без завершающего перевода строки был трудным. То есть вы должны написать код, в котором конец строки определен символом EOL или EOF. Проще было предположить, что строка заканчивается EOL.

Однако я считаю, что правило основано на компиляторах C, требующих перевода строки. И, как указано в Предупреждение компилятора «Нет новой строки в конце файла» , #include не добавит новую строку.

0 голосов
/ 08 апреля 2009

Представьте, что файл обрабатывается, пока файл еще генерируется другим процессом.

Это может быть связано с этим? Флаг, указывающий, что файл готов к обработке.

0 голосов
/ 08 апреля 2009

Мне лично нравятся новые строки в конце файлов исходного кода.

В этом отношении он может происходить из Linux или всех систем UNIX. Я помню там ошибки компиляции (gcc, если я не ошибаюсь), потому что файлы исходного кода не заканчивались пустой новой строкой. Почему так сделано, остается только удивляться.

0 голосов
/ 08 апреля 2009

ИМХО, это вопрос личного стиля и мнения.

В старые времена я не ставил этот перевод строки. Сохраненный символ означает большую скорость через этот модем 14.4K.

Позже я поместил эту новую строку, чтобы было легче выбрать последнюю строку, используя shift + downarrow.

...