Почему текстовые файлы должны заканчиваться символом новой строки?
Я понимаю, что это старый пост, но людям может быть полезно знать, что мастер миграции Azure (доступный на Codeplex - не может ссылаться на то, что Codeplex в данный момент я набираю это) будет делать это легко.
10 ответов
Because that’s how the POSIX standard defines a line:
- 3.206 Line
- A sequence of zero or more non-
characters plus a terminating character.
Therefore, lines not ending in a newline character aren't considered actual lines. That's why some programs have problems processing the last line of a file if it isn't newline terminated.
There's at least one hard advantage to this guideline when working on a terminal emulator: All Unix tools expect this convention and work with it. For instance, when concatenating files with cat, a file terminated by newline will have a different effect than one without:
$ more a.txt
foo
$ more b.txt
bar$ more c.txt
baz
$ cat {a,b,c}.txt
foo
barbazAnd, as the previous example also demonstrates, when displaying the file on the command line (e.g. via more), a newline-terminated file results in a correct display. An improperly terminated file might be garbled (second line).
For consistency, it’s very helpful to follow this rule – doing otherwise will incur extra work when dealing with the default Unix tools.
Think about it differently: If lines aren’t terminated by newline, making commands such as cat useful is much harder: how do you make a command to concatenate files such that
- it puts each file’s start on a new line, which is what you want 95% of the time; but
- it allows merging the last and first line of two files, as in the example above between
b.txtandc.txt?
Of course this is solvable but you need to make the usage of cat more complex (by adding positional command line arguments, e.g. cat a.txt --no-newline b.txt c.txt), and now the command rather than each individual file controls how it is pasted together with other files. This is almost certainly not convenient.
… Or you need to introduce a special sentinel character to mark a line that is supposed to be continued rather than terminated. Well, now you’re stuck with the same situation as on POSIX, except inverted (line continuation rather than line termination character).
Now, on non POSIX compliant systems (nowadays that’s mostly Windows), the point is moot: files don’t generally end with a newline, and the (informal) definition of a line might for instance be “text that is separated by newlines” (note the emphasis). This is entirely valid. However, for structured data (e.g. programming code) it makes parsing minimally more complicated: it generally means that parsers have to be rewritten. If a parser was originally written with the POSIX definition in mind, then it might be easier to modify the token stream rather than the parser — in other words, add an “artificial newline” token to the end of the input.
ИМХО, это вопрос личного стиля и мнения.
В прежние времена я не ставил этот перевод строки. Сохраненный символ означает большую скорость через этот модем 14.4K.
Позже я поместил эту новую строку, чтобы было легче выбрать последнюю строку, используя shift + downarrow.
I лично мне нравятся новые строки в конце файлов с исходным кодом.
В этом отношении он может возникать в Linux или во всех системах UNIX. Я помню там ошибки компиляции (gcc, если я не ошибаюсь), потому что файлы исходного кода не заканчивались пустой новой строкой. Почему так сделано, остается только удивляться.
Представьте, что файл обрабатывается, пока файл еще генерируется другой процесс.
Это может быть связано с этим? Флаг, указывающий, что файл готов к обработке.
Предположительно просто, что какой-то код синтаксического анализа ожидал его там.
Я не уверен, что рассмотрел бы это «правило», и это, конечно, не то, что я придерживаюсь религиозно. Наиболее разумный код будет знать, как анализировать текст (включая кодировки) построчно (любой выбор конца строки), с или без новой строки в последней строке.
Действительно - если вы заканчиваете новой строкой : есть ли (в теории) пустая последняя линия между EOL и EOF? Один, чтобы обдумать ...
Это происходит с самых первых дней, когда использовались простые терминалы. Символ новой строки использовался для запуска «сброса» переданных данных.
Сегодня символ новой строки больше не требуется. Конечно, у многих приложений все еще есть проблемы, если нет новой строки, но я бы посчитал это ошибкой в этих приложениях.
Если, однако, у вас есть формат текстового файла, где вам требуется новая строка, Вы получаете простую проверку данных очень дешево: если файл заканчивается строкой, в конце которой нет перевода строки, вы знаете, что файл поврежден. Имея только один дополнительный байт для каждой строки, вы можете обнаружить поврежденные файлы с высокой точностью и почти без использования процессорного времени.
В основном, есть много программ, которые не будут правильно обрабатывать файлы, если они не получат окончательный EOL EOF.
GCC предупреждает вас об этом, потому что это ожидается как часть стандарта C. (очевидно, раздел 5.1.1.2)
It may be related to the difference between:
- text file (each line is supposed to end in an end-of-line)
- binary file (there are no true "lines" to speak of, and the length of the file must be preserved)
If each line does end in an end-of-line, this avoids, for instance, that concatenating two text files would make the last line of the first run into the first line of the second.
Plus, an editor can check at load whether the file ends in an end-of-line, saves it in its local option 'eol', and uses that when writing the file.
A few years back (2005), many editors (ZDE, Eclipse, Scite, ...) did "forget" that final EOL, which was not very appreciated.
И не только это, но они неверно истолковали этот окончательный EOL как «начать новую строку» и фактически начали отображать другую строку, как если бы она уже существовала.
Это было очень хорошо видно в «правильном» текстовом файле с хорошим текстовым редактором, таким как vim, по сравнению с открытием его в одном из вышеуказанных редакторов. Он отображал дополнительную строку ниже реальной последней строки файла. Вы видите что-то вроде этого:
1 first line
2 middle line
3 last line
4
Каждая строка должна заканчиваться символом новой строки, включая последний. В некоторых программах возникают проблемы с обработкой последней строки файла, если он не завершен новой строкой.
GCC предупреждает об этом не потому, что не может обработать файл, а потому, что он должен как часть стандарта.
Стандарт языка C говорит Исходный файл, который не является пустым, должен заканчиваться символом новой строки, которому непосредственно не должен предшествовать символ обратной косой черты.
Так как это предложение «должен», мы должны выдать диагностическое сообщение для нарушения этого rule.
Это находится в разделе 2.1.1.2 стандарта ANSI C 1989. Раздел 5.1.1.2 стандарта ISO C 1999 (и, вероятно, также стандарта ISO C 1990).
Ссылка: Почтовый архив GCC / GNU .
Мне всегда казалось, что это правило пришло из тех времен, когда при синтаксическом анализе файла не заканчивалась новая строка. было сложно. То есть вы закончите писать код, в котором конец строки определялся символом EOL или EOF. Было просто проще предположить, что строка заканчивается EOL.
Однако я считаю, что это правило получено из компиляторов C, требующих новой строки. И как указано в предупреждении компилятора «Нет новой строки в конце файла» , #include не добавит новую строку.