CR LF,LF和CR换行类型之间的区别?


755

我想知道CR LF(Windows),LF(Unix)和CR(Macintosh)换行类型之间的区别(如果可能,还带有示例)。


9
非常相似,但不完全相同\n通常由换行表示,但不一定是换行。
Adrian McCarthy 2012年

92
CR和LF是ASCII和Unicode控制字符,而\r\n是在某些编程语言中使用的抽象。结束这个问题掩盖了问题之间的根本差异,并使错误信息永久存在。
阿德里安·麦卡锡

5
@AdrianMcCarthy亲密投票以某种方式充当答案的方式存在问题;一个声称两者相同的答案可能会被否决,然后以非常非常错误的方式显示为灰色,但只需要4个同意的选票(与赞成票相当)就可以完成非常错误的结局,除非在之后发生了
乔恩·汉纳

这种问题的表述固然更好,但从所有实际出发,它仍然是同一问题。
Jukka K. Korpela 2014年

6
@ JukkaK.Korpela:不,实际上不是。 \n在所有编程语言中并不意味着同一件事。
Adrian McCarthy 2014年

Answers:


346

实际上,实际上是关于文件中存储哪些字节。CR是用于回车(从打字机时代开始)以及LF换行的类似字节码。它仅指代作为行尾标记放置的字节。

与往常一样,在Wikipedia上获取更多信息。


52
我认为这也非常有用一提的CR是转义字符\rLF是转义字符\n。此外,Wikipedia:Newline
罗伯特·范纳班迪

1
用简单的话CR and LF就是根据这个链接的行尾和新行,这是正确的吗?
shaijut

@shaijut CR代表回车。那就是使打字机回车的原因。因此,基本上是正确的。
AliFurkan

763

CR和LF是控制字符,分别编码0x0D(十进制13)和0x0A(十进制10)。

它们用于标记文本文件中的换行符。如前所述,Windows使用两个字符CR LF序列;Unix仅使用LF,而旧的MacOS(OSX之前的MacIntosh)使用CR。

伪历史的观点:

如Peter所示,CR = 回车,LF =换,两个表达式都起源于旧打字机/ TTY。LF将纸张上移(但保持水平位置不变),CR返回“托架”,以便键入的下一个字符将位于纸张的最左侧位置(但在同一行上)。CR + LF两者都在做,即准备键入新行。随着时间的流逝,代码的物理语义不再适用,并且由于内存和软盘空间非常宝贵,因此某些OS设计人员决定只使用其中一个字符,而彼此之间的交流并不很好。 -)

大多数现代文本编辑器和面向文本的应用程序都提供选项/设置等,这些选项/设置允许自动检测文件的行尾约定并相应地显示它。


11
因此,实际上Windows是唯一正确使用这些字符的操作系统,即回车符和换行符。
罗尔夫(Rolf)'18

4
那么,说在Windows上创建的文本文件与这三个文件之间的兼容性最高,即最有可能在所有三个OS子集中显示的文本文件,是否准确?
Prometheus

3
@Hashim它可能会正确显示,但是尝试运行带有回车符的文本Shell脚本通常会导致错误
Omer

用简单的话CR and LF就是根据这个链接的行尾和新行,这是正确的吗?
shaijut

我发现某些Windows样式的文件(CR+LF)在其他系统上可以显示双换行符。假定显示文本的编辑器同时支持回车符和换行符作为换行符,因此可以在需要1的地方创建2行。因此,尽管CR+LF可能是兼容的,但我认为这并非没有问题。
Magnus Bull

458

这是一个很好的总结,我发现:

回车(CR)字符(0x0D\r)将光标移动到行的开头,而不会前进到下一行。在Commodore和早期Macintosh操作系统(OS-9和更早版本)中,此字符用作换行符。

换行(LF)字符(0x0A\n)将光标向下移动到下一行而不返回到该行的开头。该字符在基于UNIX的系统(Linux,Mac OSX等)中用作换行符

行尾(EOL)序列(0x0D 0x0A\r\n)实际上是两个ASCII字符,是CR和LF字符的组合。它将光标向下移动到下一行和该行的开头。在大多数其他非Unix操作系统(包括Microsoft Windows,Symbian OS和其他操作系统)中,此字符用作换行符。

资源


1
“垂直制表符”字符将光标向下移动,并将位置保持在行中,而不是LF字符。LF是EOL。
12431234123412341234123 '16

2
@TaylorLeese / r / n和/ n / r是否相同?
Vicrobot

175

由于没有答案可以说明这一点,因此简要总结一下:

回车(MAC OSX之前的版本)

  • CR
  • \ r
  • ASCII码13

换行(Linux,MAC OSX)

  • 如果
  • \ n
  • ASCII码10

回车和换行(Windows)

  • CRLF
  • \ r \ n
  • ASCII代码13,然后是ASCII代码10

如果您看到ASCII码的格式很奇怪,它们只是基数/基数不同的数字13和10,通常是基数8(八进制)或基数16(十六进制)。

http://www.bluesock.org/~willg/dev/ascii.html


46

杰夫·阿特伍德(Jeff Atwood)最近有一篇与此有关的博客文章:伟大的Newline Schism

这是维基百科的精髓:

CR + LF序列在许多采用电传打字机(通常为ASR33)作为控制台设备的早期计算机系统中普遍使用,因为需要此序列将这些打印机放置在新生产线的开头。在这些系统上,通常会常规编写文本以使其与这些打印机兼容,因为尚未很好地开发出将设备的硬件详细信息隐藏在应用程序中的设备驱动程序的概念。应用程序必须直接与电传打字机对话并遵循其约定。这两个功能的分离掩盖了以下事实:打印头无法在一个字符的时间内从最右端返回到下一行的开头。这就是为什么序列总是先随CR发送的原因。实际上,通常有必要发送额外的字符(外部CR或NUL,将被忽略)以使打印头有时间移到左边距。即使电传打字机被具有更高波特率的计算机终端所取代,许多操作系统仍支持自动发送这些填充字符,以与需要多个字符时间才能滚动显示的廉价终端兼容。


5
+1通过这种简单的理解,我一直记得组合的顺序。即使在今天,我们仍然可以在任何inktjet打印机中看到这种机械逻辑(我很喜欢理解,因为我讨厌学习)。我其他的记忆技巧是:“ mac?返回发件人”和“ NewLineFeed”(记住NL === LF并记住\ n,因为CR已经包含R了)
GitaarLAB 2013年

3
“我很可疑……需要两个控制代码来进行计时”。那不是它的意思。它说,这里有多余的CR和NUL是为了让它有时间返回,而不是原始的CR LF。
朱利安·卢梭

11
@Adrian你会接受角色扮演吗?1)在过去的电传打字时代,我们使用的打印机是必需的<CR><CR><LF>-因此,我当然只尝试了一种<CR>。我<CR><LF>A经过一排排很长的邮件,在托架完全返回之前,您可以听到有人A打印。
约翰·汉堡

11
@Adrian 2)别忘了,这是在机电时代,每个角色都只完成一个功能。我们经常通过打印一行,然后发送<CR><CR>并键入正确数量的空格,然后重新打印相同的单词来强调单词:原始的粗体形式。
约翰·汉堡

3
@Adrian 3)最后,这使用的是Baudot(或Murray代码),而不是ASCII。五个数据位,介于一个开始位和一个半停止位之间。你怎么能有一半?在开始发送下一个字符之前等待半秒时间,以使打印头有时间返回中心。
约翰·汉堡

16

CR-ASCII码13

LF-ASCII码10。

理论上CR将光标返回到第一个位置(在左侧)。LF向下移动一行,将光标移入一行。过去,这就是您控制打印机和文本模式监视器的方式。这些字符通常用于标记文本文件中的行尾。不同的操作系统使用不同的约定。如您所指出的,Windows使用CR / LF组合,而OSX之前的Mac仅使用CR等。


7

基于ASCII或兼容字符集的系统分别使用LF(换行,0x0A,十进制10)或CR(回车,0x0D,十进制13)或CR后跟LF(CR + LF,0x0D 0x0A); 这些字符基于打印机命令:换行指示应将一行纸从打印机中送出,回车指示打印机托架应返回到当前行的开头。

这是细节


5

“记录分隔符”或“行终止符”的悲惨状态是黑暗计算时代的产物。

现在,我们认为要表示的任何东西在某种程度上都是结构化数据,并且符合定义行,文件​​,协议,消息,标记等的各种抽象。

但是从前这不是完全正确的。应用程序内置控制字符和特定于设备的处理。既需要CR又需要LF的脑死亡系统,对于记录分隔符或行终止符根本没有任何抽象。为了使电传打字机或视频显示返回到第一列,CR是必不可少的,而LF(今天,NL,相同代码)对于使其前进到下一行是必需的。我想做一些除了将原始数据转储到设备之外的事情的想法太复杂了。

想象一下,Unix和Mac实际上为行尾指定了一个抽象。可悲的是,他们指定了不同的名称。(首先是Unix,这是Unix。)自然,他们使用的控制代码已经“接近” SOP。

由于当今我们几乎所有的操作软件都是Unix,Mac或MS操作软件的后代,因此我们陷入了混乱的局面。


1

从EBCDIC NL = x'15'得出的NL在逻辑上可以与CRLF x'odoa ascii进行比较。。。口语化地(因为只有奥秘的人使用ebcdic),NL等于CR或LF或CRLF

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.