我想这里的每个人都熟悉这句谚语,即所有文本文件都应该以换行符结尾。我已经知道这个“规则”很多年了,但我一直在想——为什么?


当前回答

这个答案是一个技术性的答案,而不是观点。

如果我们想成为POSIX纯粹主义者,我们将一行定义为:

一个由零个或多个非<换行符>字符加上一个终止<换行符]字符组成的序列。

资料来源:https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206

不完整的行,如:

文件末尾的一个或多个非<换行符>字符序列。

资料来源:https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_195

文本文件为:

包含组织成零行或多行的字符的文件。这些行不包含NUL字符,长度不能超过{LINE_MAX}字节,包括<换行符>字符。虽然POSIX.1-2008没有区分文本文件和二进制文件(参见ISO C标准),但许多实用程序在操作文本文件时只产生可预测或有意义的输出。具有此类限制的标准实用程序总是在其STDIN或INPUT files部分中指定“文本文件”。

资料来源:https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_397

字符串为:

一个连续的字节序列,以第一个空字节结尾并包括第一个空字符。

资料来源:https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_396

由此,我们可以得出,只有当我们处理文件的一行或文件作为文本文件的概念时,我们才可能遇到任何类型的问题(即文本文件是由零行或多行组成的组织,并且我们知道的行必须以<newline>结尾)。

大小写:wc-l文件名。

从wc手册中,我们了解到:

行定义为一个由<newline>字符分隔的字符串。

如果JavaScript、HTML和CSS文件是文本文件,那么它们的含义是什么?

在浏览器、现代IDE和其他前端应用程序中,在EOF时跳过EOL没有问题。应用程序将正确解析文件。由于并非所有操作系统都符合POSIX标准,因此非OS工具(例如浏览器)根据POSIX标准(或任何OS级标准)处理文件是不切实际的。

因此,我们可以相对确信,EOF的EOL在应用程序级别几乎不会产生负面影响——无论它是否在UNIX OS上运行。

此时,我们可以自信地说,在客户端处理JS、HTML和CSS时,在EOF中跳过EOL是安全的。实际上,我们可以声明,缩小其中任何一个不包含<newline>的文件都是安全的。

我们可以进一步说,就NodeJS而言,它也不能遵守POSIX标准,因为它可以在非POSIX兼容的环境中运行。

那我们还剩什么?系统级工具。

这意味着唯一可能出现的问题是那些努力使其功能符合POSIX语义的工具(例如wc中所示的行的定义)。

即使如此,并不是所有的shell都会自动遵守POSIX。例如,Bash不默认为POSIX行为。有一个开关可以启用它:POSIXLY_CORRECT。

EOL的价值值得思考:https://www.rfc-editor.org/old/EOLstory.txt

为了所有实际意图和目的,让我们继续走在工具轨道上,考虑一下:

让我们处理一个没有EOL的文件。至此,本例中的文件是一个缩小的JavaScript,没有EOL。

curl http://cdnjs.cloudflare.com/ajax/libs/AniJS/0.5.0/anijs-min.js -o x.js
curl http://cdnjs.cloudflare.com/ajax/libs/AniJS/0.5.0/anijs-min.js -o y.js

$ cat x.js y.js > z.js

-rw-r--r--  1 milanadamovsky   7905 Aug 14 23:17 x.js
-rw-r--r--  1 milanadamovsky   7905 Aug 14 23:17 y.js
-rw-r--r--  1 milanadamovsky  15810 Aug 14 23:18 z.js

请注意,cat文件大小正好是其各个部分的总和。如果JavaScript文件的连接是JS文件的一个问题,那么更合适的问题是用分号开始每个JavaScript文件。

正如其他人在本主题中提到的:如果你想抓取两个输出仅为一行而不是两行的文件,该怎么办?换句话说,猫做它应该做的事。

猫的男人只提到阅读输入到EOF,而不是<newline>。请注意,cat的-n开关还将打印出一个非<换行符>终止的行(或不完整的行)作为一行,即计数从1开始(根据man的说法)

-n对输出线进行编号,从1开始。

现在我们了解了POSIX是如何定义行的,这种行为变得模棱两可,或者说实际上是不合规的。

了解给定工具的用途和合规性将有助于确定使用EOL结束文件的重要性。在C、C++、Java(JARs)等中,一些标准会规定一个新的有效性标准——JS、HTML、CSS不存在这样的标准。

例如,可以不使用wc-l文件名,而是使用awk“{x++}END{print x}”文件名,并确保任务的成功不会受到我们可能要处理的文件(例如,第三方库,例如我们固化的精简JS)的影响,除非我们的目的是真正按照POSIX兼容的方式计算行数。

结论

在现实生活中,对于某些文本文件(如JS、HTML和CSS),在EOF时跳过EOL会产生负面影响(如果有的话)。如果我们依赖于<newline>的存在,我们将工具的可靠性限制在我们编写的文件上,并将自己暴露在第三方文件引入的潜在错误中。

故事的寓意:工程师工具没有依赖EOF中EOL的弱点。

请随意发布用例,因为它们适用于JS、HTML和CSS,我们可以在其中检查跳过EOL是如何产生不利影响的。

其他回答

为什么(文本)文件应该以换行符结尾?

正如许多人所表达的,因为:

许多程序运行不好,或者没有它就会失败。即使能很好地处理文件的程序缺少结尾“\n”,该工具的功能也可能无法满足用户的期望——在这种情况下,这一点可能不清楚。程序很少禁止最后的“\n”(我不知道有)。


然而,这引出了下一个问题:

代码应该如何处理没有换行符的文本文件?

最重要的是,不要编写假设文本文件以换行符结尾的代码。假设文件符合某种格式会导致数据损坏、黑客攻击和崩溃。例子://错误的代码while(fgets(buf,buf大小,instream)){//如果没有\n,buf[]被截断,会发生什么buf[strlen(buf)-1]=“\0”;//尝试删除尾部\n...}如果需要最后一个结尾“\n”,请提醒用户该结尾不存在以及所采取的操作。IOW,验证文件的格式。注意:这可能包括对最大行长度、字符编码等的限制。清楚地定义,文档,代码对缺少final“\n”的处理。尽可能不要生成缺少结尾“\n”的文件。

多年来,我自己也在想这个问题。但我今天遇到了一个很好的理由。

想象一个每行都有记录的文件(例如:CSV文件)。电脑在文件末尾写记录。但它突然坠毁了。天哪,最后一行完成了吗?(情况不太好)

但是如果我们总是终止最后一行,那么我们就会知道(只需检查最后一行是否终止)。否则,为了安全起见,我们可能不得不每次都放弃最后一行。

这源于使用简单终端的早期。换行符用于触发传输数据的“刷新”。

今天,不再需要换行符。当然,如果没有换行符,许多应用程序仍然存在问题,但我认为这是这些应用程序中的一个错误。

然而,如果你有一个需要换行符的文本文件格式,那么你可以得到非常便宜的简单数据验证:如果文件以结尾没有换行符的行结尾,那么你就知道文件已损坏。每行只有一个额外的字节,您可以高精度地检测损坏的文件,几乎不需要CPU时间。

现在已经很晚了,但我在文件处理中遇到了一个错误,这是因为文件没有以空换行结尾。我们使用sed处理文本文件,sed省略了输出的最后一行,这导致无效的json结构,并将流程的其余部分发送到失败状态。

我们所做的就是:

有一个示例文件,比如:foo.txt,其中包含一些json内容。

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

该文件是在寡妇计算机中创建的,窗口脚本正在使用PowerShell命令处理该文件。一切都很好。

当我们使用sed命令sed的|value|newValue|g'foo.txt>foo.txt.tmp处理同一文件时

新生成的文件是

[{
    someProp: value
},
{
    someProp: value

和boom,由于无效的JSON,它使其余过程失败。

因此,用空的新行结束文件始终是一个好的做法。

最后缺少换行符的文件还有一个实际的编程问题:read-Bash内置(我不知道其他read实现)无法按预期工作:

printf $'foo\nbar' | while read line
do
    echo $line
done

这只打印foo!原因是,当read遇到最后一行时,它将内容写入$line,但返回退出代码1,因为它已到达EOF。这打破了while循环,因此我们永远无法到达echo$line部分。如果要处理这种情况,必须执行以下操作:

while read line || [ -n "${line-}" ]
do
    echo $line
done < <(printf $'foo\nbar')

也就是说,如果由于文件末尾的非空行导致读取失败,则执行回显。当然,在这种情况下,输出中将有一个额外的换行符,而输入中没有。