不同线路在不同平台结束背后的历史原因

Question

为什么DOS / Windows和Mac决定使用\ r \ n和\ r来代替行结尾而不是\ n？这只是试图成为“不同”的结果吗？来自Unix？

现在Mac OS X是Unix（类似），Apple是否从\ r切换到\ n？

Answer 1

DOS从CP / M继承了CR-LF行结尾（你称之为\ r \ n，只是使ascii字符显式）。 CP / M从影响CP / M设计师Gary Kildall的各种DEC操作系统继承了它。

使用CR-LF，以便电传打字机将打印头返回到左边距（CR =回车），然后移动到下一行（LF =换行）。

Unix人员在设备驱动程序中处理了这个问题，并在必要时将LF转换为CR-LF输出到需要它的设备。

正如您所猜测的，Mac OS X现在使用LF。

Answer 2

真的加入@Mark Harrison ...

告诉你Unix是“只输出程序员指定的文本”的人。而DOS被打破是完全错误的。还有人声称DOS在看到EOF字符时标记EOF是愚蠢的，这就提出了EOF字符究竟是什么的问题。

文本文件行结尾没有一个真正的约定 - 只有特定于平台的约定。毕竟，即使CR-LF，CR和LF也不是唯一可以使用的行结束约定，而且ASCII从来都不是唯一的字符集。问题是C标准库和运行时，它没有抽象出这个依赖于平台的细节。其他第三代语言（例如Pascal甚至Basic）管理它，至少在某种程度上。因此，当C编译器是为其他平台编写的时候，需要运行时库来实现与现有源代码和书籍的兼容性。

事实上，Unix和Multics最初需要控制台I / O的字符串转换，因为用户通常坐在需要CR LF线端的ASCII终端上。这个翻译是在设备驱动程序中完成的 - 目标是抽象出特定于设备的内容，假设采用一种约定并将其粘贴到存储的文本文件中更好。

C文本I / O hack原则上类似于CygWin现在所做的，黑客运行Linux运行时也可以在Windows上运行。有一个关于将它们变成Unix相似的黑客攻击的真实历史 - 然后还有Wine，将Linux转变为Windows。奇怪的是，你可以在 CygWin常见问题解答（2013年添加的Internet Archive链接 - 页面不再存在）。也许这只是他们的幽默感，因为他们基本上都在做他们批评的事情，但规模要大得多; - ）

C ++标准库（它实现的任何平台）使用iostream避免了这个问题，它消除了行结束。对于输出，这很适合我。对于输入，我需要更多的控制，所以我要么逐个字符地解释，要么使用扫描仪生成器。

[编辑>事实证明，上述被驳回的声明并非如此，从未如此。 std :: endl 字面上转换为 \ n 和flush。 \ n 与你在C中得到的 \ n 完全相同 - 它往往被称为“new line”，但它实际上是一个ASCII换行符，然后必要时由运行时翻译。有趣的是，错误的假设可以如此根深蒂固，你永远不会质疑它们 - 基本上，C ++没有选择做C做的事情（除了在顶部添加更多层）出于兼容性原因，这应该总是显而易见的。]

我的POV最大的责任在于C，但C并不是唯一一个未能预测其向其他平台迁移的项目。责备比尔盖茨只是疯了 - 他所做的只是购买和抛光当时流行的CP / M的变种。真的，这只是历史 - 我们不知道大多数文本文件中128到255的字符代码是什么的原因相同。鉴于易于处理所有三种线端约定，奇怪的是一些开发人员仍然坚持认为“我的平台约定是一种真正的方式，我会强迫它在你喜欢或不喜欢”。姿态。

此外 - Unicode行分隔符代码点U + 2028将在未来的文本文件中替换所有这些约定吗？ ; - ）

Answer 3

关于维基百科的关于行结尾的文章相当冗长。 “历史”部分回答至少部分问题： http://en.wikipedia.org/wiki/Newline#记录

Answer 4

有趣的是，CRLF几乎是互联网标准。也就是说，几乎所有面向行的标准互联网协议都使用CRLF。 SMTP，POP，IMAP，NNTP等。电子邮件正文由CRLF终止的行组成。