为什么 Windows 使用 CR LF？答案

【问题标题】：Why does Windows use CR LF?为什么 Windows 使用 CR LF？
【发布时间】：2011-06-29 13:47:50
【问题描述】：

我了解两者之间的区别，所以没有必要深入探讨，但我只是想知道 Windows 使用 CR 和 LF 来指示换行符的原因是什么。似乎 Linux 方法（仅使用 LF）更有意义、节省空间且更易于解析。

【问题讨论】：

Newline#History
来自 Raymond Chen 的博客：blogs.msdn.com/b/oldnewthing/archive/2004/03/18/91899.aspx
这里是关于换行历史的维基百科：en.wikipedia.org/wiki/Newline#History
CR+LF 是正确的方法（它是标准），所以问题不在于为什么 Windows 正确，而是为什么 Mac 和 Unix/Linux做错了。 Standalone LF 的遗产是懒惰和走捷径。我总是 CR+LF，除了某些 Linux 的东西会在 CR+LF 上傻眼，所以我为此更改为 LF 模式。 IMO，曲解 CR+LF 比曲解独立的 LF 要糟糕得多。
@TwistedCode 确实，我在自己的一些程序中确实使用了没有 LF 的 CR。回到行首而不跳到下一行是很有用的。它们通常配合得很好，但每个都可以单独使用。虽然 CR 本身比 LF 更有用

标签： windows carriage-return line-endings linefeed

【解决方案1】：

过去，当使用 ~~点阵打印机~~ teletypes CR 会将回车返回到该行的第一个位置，而 LF 将返回到下一行。在文件本身中使用 CR+LF 可以将文件直接发送到打印机，而无需任何类型的打印机驱动程序。

感谢@zaph 指出它是电传打字机而不是点阵打印机

【讨论】：

非常常见的烦恼，却只带来很少的好处。
@Anders 实际上是电传打字机的原因，CR 将打印头返回到左侧，LF 推进了纸张。电传打字机先于点阵打印机。
@zaph 这就是我喜欢 Stack Overflow 的原因。 2 年后，我得到了更正并学到了一些新东西。
Windows 跟随 Unix 这么多年，令人费解的是，他们并没有遵循 LF 的 Unix 模型。
@belanger 令人费解的是，为什么 Unix 没有遵循早于 Unix 的 DEC 或 ASA（美国标准协会）。我相信 DEC 使用了 CR/LF。我在大学使用的 IBM/360 也使用了 CRLF，但 EBCDIC 显然没有另外，请查看 RFC 0821 (SMTP)、RFC 1939 (POP)、RFC 2060 (IMAP) 或 RFC 2616 (HTTP)。他们使用 CR/LF。

【解决方案2】：

@sshannin 从 Raymond Chen 的博客中发布了一个 URL，但它不再起作用了。该博客已更改其内部软件，因此 URL 已更改。

在浏览了新博客中的旧帖子后，我找到了here。

引自博客：

为什么行终止符是CR+LF？

该协议可以追溯到电传打字机时代。 CR 支架对于“回车”——CR 控制字符返回打印头（“马车”）到第 0 列而不推进纸张。 LF 看台对于“换行”——LF 控制字符将纸张前进了一行无需移动打印头。所以如果你想返回打印前往第 0 列（准备打印下一行）并推进纸（所以它打印在新纸上），你需要 CR 和 LF。

如果您访问各种互联网协议文档，例如 RFC 0821 (SMTP)、RFC 1939 (POP)、RFC 2060 (IMAP) 或 RFC 2616 (HTTP)，您将看到它们都将 CR+LF 指定为行终止序列。所以真正的问题不是“为什么 CP/M、MS-DOS 和 Win32 使用 CR+LF 作为线路终结者？”而是“为什么其他人选择不同于这些标准文件并使用其他一些行终结者？”

Unix 采用纯 LF 作为行终止顺序。如果你看 stty 选项，你会看到 onlcr 选项指定是否 LF 应改为 CR+LF。如果你弄错了这个设置，你获取阶梯文本，在哪里
each
    line
        begins 
上一行停止的地方。因此，即使是 unix，当处于原始模式时，也需要 CR+LF 来终止行。隐式 CR 在 LF 是一项 unix 发明之前，可能是一种经济，因为它节省了每行一个字节。

C 语言的 unix 祖先将这个约定带入了 C 语言标准，它只需要“\n”（编码 LF）来终止行，将负担放在运行时库上将原始文件数据转换为逻辑行。

C 语言还引入了术语“换行符”来表达 “通用行终止符”的概念。有人告诉我 ASCII 委员会在 1996 年左右将字符 0x0A 的名称更改为“换行符”，所以混乱程度被提高了。

Here’s another discussion of the subject, from a unix perspective

我已将第二个链接更改为 The Wayback Machine 中的快照，因为实际页面不再可用。

我希望这能回答你的问题。

【讨论】：

由于您并没有真正回答问题，只是在 comment 中更正了一个已过时的链接，因此这应该是真正的评论。无论如何，感谢您提供正确的链接。请添加为评论，此答案可能会被删除。
好的，我已经在这里添加了博客中的文本，所以如果链接再次失效，文本仍然可以在此处使用。我认为这应该保留为答案，而不仅仅是评论，因为这些信息实际上回答了最初提出的问题。
我真的讨厌微软定期淘汰链接的方式。
这个答案比例外的答案更详细，不仅回答了问题，而且回答了问题的猜测原因，恕我直言，它更好。
建议 SMTP、POP、IMAP 和 HTTP 以某种方式定义 '\n' 含义的标准是非常愚蠢的！！！这些定义了人们应该如何使用那些非常古老的协议进行通信。所有这些协议都做出了相同的选择，可能是基于第一个和更早的选择。我不认为 *nixes 使用 CR 或 LF。他们使用“新行”。机器级别非常低，需要您将它们告诉 LF 和 CR。继续使用它真的没有意义，因为当我的浏览器与 Apache 通信时，它确实使用了 CRLF。

【解决方案3】：

它来自过去的电传打字机（和打字机）。

过去，当您完成一行输入时，您必须将打字机的托架（它固定纸张并在您输入时向左滑动）移回该行的开头 (CR)。然后，您必须将纸张向前推进一行 (LF) 才能移动到下一行。

在某些情况下，您可能不想在返回马车时换行，例如，如果您打算用破折号删除一个字符（您只需覆盖它）。

但基本上，它归结为惯例。 DOS 使用完整的 CR/LF 约定，而 UNIX 将其缩短了一点。现在我们被困住了！

【讨论】：

【解决方案4】：

其他人已经给出了答案，但我想补充一下......我猜你太年轻了，不会用打字机？ ;) 马车是一个鼓。将其水平向右移动，将固定类型的头部带回页面的左边距。用您的手指和拇指旋转笔架会使页面前进一行。

【讨论】：

打字机？我想我曾经在博物馆里看到过其中一个:)
@Kyle 我不得不笑，这让我的一天充满了活力:)

【解决方案5】：

来自Wikipedia：

CR+LF 序列在许多采用电传打字机（通常是 ASR33）作为控制台设备的早期计算机系统上普遍使用，因为需要该序列将这些打印机定位在新行的开头。

【讨论】：

【解决方案6】：

我看到不止一个帐户，大意是发送两个字符（有时更多）而不是一个字符的原因是为了更好地将数据传输速率与物理打印速率匹配（这是一个很久以前）。移动打印头比打印单个字符花费的时间更长，发送额外字符是防止数据传输超过打印设备的一种方法。因此，我们在 Windows 中使用多个字符作为行尾字符的原因与我们使用 QWERTY 键盘的原因基本相同 -- 它旨在减慢速度。

显然，这种做法在 Windows 中一直延续到今天的原因是基于一些持续向后兼容的概念，最终只是简单的惯性。

但值得注意的是，Windows 在操作系统级别并未严格执行此约定。任何 Windows 应用程序都可以随意忽略该约定，具体取决于它尝试兼容的其他应用程序。

有趣的是，Wikipedia article about "Newline" 声称 Windows 8 可能会引入对仅使用 LF 的更改。该文章还指出，Mac OS X 引入了从 LF+CR 到仅 LF 的转换。

【讨论】：

“旨在减慢速度” - 需要引用。
实际上，整个第一段 - 需要引用。
这是一篇密切相关的 Jeff Atwood 文章，它引用了相同的 Wikipedia 内容：The Great Newline Schism。那里也有很多智能用户 cmets - 包括我的观点的一些证据，即这不是操作系统级别的问题，并且大多数 Windows 应用程序都可以很好地处理仅 LF 的文本文件。还有有趣的评论：“Windows 10 使用 CR/LF 来保持与 1963 Model 33 电传打字机的兼容性”。
@RenéG 我不需要引用，我在现场亲眼看到了。一些早期的点阵打印机甚至需要投入一些额外的 NUL 才能很好地衡量，因为随着接口波特率的增加，即使打印两个字符的时间，打印头也无法跟上。随着缓冲和流量控制的出现，这个问题就消失了，但早期的打印机没有。最后，随着打印机变成仅输出模式，它们使用了内置握手功能的并行接口。
“与流行的看法相反，QWERTY 布局并非旨在减慢打字员的速度，......” – Properties | QWERTY - Wikipedia