为什么DOS/Windows和Mac决定使用\ r \n和\ r来代替行结尾而不是\n？它只是试图与Unix"不同"的结果吗？
现在Mac OS X是Unix(类似),Apple是否从\ r切换到\n？
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.
真的加入@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年添加的互联网档案链接 - 页面不再存在)中阅读一些错误的针对Windows的线端批评.也许这只是他们的幽默感,因为他们基本上正在做他们批评的事情,但是在更大的规模上;-)
C++标准库(它实现的任何平台)使用iostream避免了这个问题,它消除了行结束.对于输出,这很适合我.对于输入,我需要更多的控制,所以我要么逐个字符地解释,要么使用扫描仪生成器.
[ 编辑 事实证明,上述被驳回的主张并非如此,而且从未如此.从std::endl字面上翻译成a \n和flush.这\n与\n你在C中完全相同- 它往往被称为"新行",但它实际上是一个ASCII换行符,然后在必要时由运行时翻译.如此错误的假设可以如此根深蒂固,你永远不会质疑它们 - 基本上,C++没有选择做C所做的(除了在顶部添加更多层)出于兼容性原因,这应该是显而易见的.
我的POV最大的责任在于C,但C并不是唯一一个未能预测其转向其他平台的项目.责备比尔盖茨只是疯了 - 他所做的只是购买和抛光当时流行的CP/M的变种.真的,这只是历史 - 我们不知道大多数文本文件中128到255的字符代码是什么的原因相同.鉴于易于处理所有三个线路终端惯例,有些开发人员仍然坚持认为"我的平台惯例是一种真正的方式,而且我会强迫它在你喜欢或不喜欢"的态度,这是奇怪的.
此外 - Unicode行分隔符代码点U + 2028将替换未来文本文件中的所有这些约定吗？;-)
关于维基百科的关于行结尾的文章相当冗长."历史"部分至少回答了您的部分问题:http: //en.wikipedia.org/wiki/Newline#History
有趣的是，CRLF几乎是互联网标准。也就是说，几乎所有面向线路的标准互联网协议都使用CRLF。SMTP，POP，IMAP，NNTP等。电子邮件的正文由CRLF终止的行组成。
京公网安备 11010802040832号 | 京ICP备19059560号-6 