CR LF,LF和CR断线类型之间的区别?

3zz*_*zzy 679 line-breaks

我想知道CR LF(Windows),LF(Unix)和CR(Macintosh)换行符类型之间的差异(如果可能的话,有示例).

mjv*_*mjv 694

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

它们用于标记文本文件中的换行符.正如您所指出的,Windows使用CR LF序列的两个字符; Unix只使用LF而旧的MacOS(OSX前MacIntosh)使用CR.

一个伪造的历史观点:

正如彼得指出,CR = 回车和LF = 换行,两个表达式有他们的老打字机/ TTY根.LF将纸张向上移动(但保持水平位置相同)并且CR带回"滑架",以便输入的下一个字符位于纸张的最左侧位置(但在同一条线上).CR + LF正在做两件事,即准备打新线.随着时间的推移,代码的物理语义不适用,并且由于内存和软盘空间非常宝贵,一些操作系统设计人员决定只使用其中一个字符,他们之间的沟通并不是很好; - )

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

  • 罗尔夫 - 该声明假设在新技术中保留旧术语/技术是正确的。CRLF = 2 字节。CR = 1,LF = 1。随着它们的频繁使用,这实际上会转化为大量的数据。Windows 再一次选择与整个 *NIX 世界不同。 (31认同)
  • 是否有技术原因(对于打字机)导致 LF CR 闻所未闻? (9认同)
  • @QuaternionsRock 简短的答案是因为 CR 在电传打字机上需要很长时间。将 CR 放在 LF 之前可以让马车有时间返回另一侧。有时,即使使用 CRLF,您也必须发送 NUL 来给它更多时间。 (9认同)
  • 因此,实际上Windows是唯一正确使用这些字符的操作系统,即回车符和换行符。 (4认同)
  • 那么,说在Windows上创建的文本文件是三者中最兼容的,即最有可能在所有三个OS子集上显示,这是否准确? (4认同)
  • @Hashim可能会正确显示,但是尝试运行带有回车符的文本Shell脚本通常会导致错误 (2认同)

Tay*_*ese 434

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

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

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

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

资源

  • “垂直制表符”字符将光标向下移动并保持行中的位置,而不是 LF 字符。LF 为 EOL。 (2认同)
  • @TaylorLeese / r / n和/ n / r是否相同? (2认同)
  • 感谢您强调:经典 MacOS:`CR` = `\r`,Unix 和 MacOS:`LF` = `\n`,Windows:`CRLF` = `\r\n`。 (2认同)

Pet*_*ter 312

它实际上只是存储在文件中的字节.CR回车的字节码(从打字机的日子开始),LF同样地,用于换行.它只是指作为行尾标记放置的字节.

维基百科上,一如既往地提供更多信息.

  • 我认为提及`CR`是转义字符`\ r``和`LF`是转义字符`\n`也是有用的.另外,[Wikipedia:Newline](https://en.wikipedia.org/wiki/Newline). (36认同)
  • 令人遗憾的是,卓越的 LFCR 选项缺失了。它的好处是,通过先进行换行,Selectric 高尔夫球在执行回车时不会用新鲜的墨水涂抹刚刚打印的行</s> (3认同)
  • @shaijut CR 代表回车。这就是打字机上的滑车返回的原因。所以,大部分是正确的。 (2认同)

ahn*_*cad 158

由于没有答案说明这一点,简洁总结:

回车(MAC pre-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


Man*_*anu 45

杰夫阿特伍德最近发表了一篇关于此事的博客文章:Great Newline Schism

这是维基百科的精髓:

序列CR + LF在许多采用电传打字机(通常是ASR33)作为控制台设备的早期计算机系统中普遍使用,因为需要这一序列来将这些打印机定位在新线的开始处.在这些系统上,文本通常经常被组合以与这些打印机兼容,因为从应用程序中隐藏这些硬件细节的设备驱动程序的概念尚未得到很好的发展.应用程序必须直接与电传打字机对话并遵循其惯例.两个功能的分离隐藏了这样一个事实,即打印头在一个字符时间内不能从最右边返回到下一行的开头.这就是为什么序列始终首先与CR一起发送的原因.实际上,通常需要发送额外的字符(无关的CR或NUL,这些字符被忽略)以使打印头时间移动到左边距.即使在具有较高波特率的计算机终端取代了远程类型之后,许多操作系统仍然支持自动发送这些填充字符,以便与需要多个字符时间来滚动显示的更便宜的终端兼容.

  • @Adrian你会接受角色体验吗?1)在我以前的电传打字机中,我们使用的打印机需要`<CR> <CR> <LF>` - 所以我当然只用一个`<CR>`进行了实验.我在长行之后发送了`<CR> <LF> A`,你可以听到*在车厢完全返回之前打印的'A`. (11认同)
  • @Adrian 2)不要忘记,这是在机电时代,每个角色都只有一个功能.我们经常通过打印线来强调一个单词,然后发送`<CR> <CR>`并输入正确数量的空格,然后重新打印相同的单词:粗体形式的粗体. (11认同)
  • +1通过这种简单的理解,我始终记住组合的顺序.即使在今天,我们仍然可以在任何喷墨打印机中看到这种机械逻辑(我喜欢理解,因为我讨厌学习).我的其他记忆技巧是:"mac?返回发件人"和"NewLineFeed"(记住NL === LF并记住\n,因为CR已经有了R的缩写) (5认同)
  • "我很可疑......时间需要两个控制码".这不是它所说的.它说额外的CR和NUL在这里是为了给它回来的时间,而不是原来的CR LF. (3认同)
  • @Adrian 3)最后,这是使用Baudot(或Murray代码),而不是ASCII.五个数据位,在一个起始位和一个半停止位之间.你怎么能有一半?在开始发送下一个字符之前等待半个小时,让打印头时间返回到中心. (3认同)

Dmi*_*ryK 16

CR - ASCII代码13

LF - ASCII码10.

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


nav*_*gar 11

CR 和 LF 是一组特殊的字符,可以帮助我们格式化代码。

  1. CR (\r) 代表回车。它将光标放在行的开头,但不会创建新行。这就是经典 Mac 操作系统的工作原理(目前不适用,除非您正在处理旧文件)。

  2. LF (\n) 代表换行。它创建一个新行,但不会将光标放在该行的开头。光标停留在最后一行的末尾。这就是 Unix(包括 macOS)和 Linux 的工作原理。

  3. CRLF (\r\n) 创建一个新行并将光标置于新行的开头。这就是我们在 Windows 操作系统中看到的方式。

Git默认使用 LF。因此,当我们在 Windows 上使用 Git 时,它会抛出“CRLF 将被 LF 替换”之类的警告,并自动将所有 CRLF 转换为 LF,以便代码变得兼容。

注意:别担心……不要将其视为警告,而应将其视为通知。

  • 回复“这就是 MAC 操作系统的工作原理”*:[仅限旧 Mac](https://en.wikipedia.org/wiki/Newline#Representation)([经典 Mac 操作系统](https://en.wikipedia. org/wiki/Classic_Mac_OS))。 (2认同)

pie*_*fou 7

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

这是细节.


Dig*_*oss 5

"记录分隔符"或"行终结符"的悲惨状态是计算黑暗时代的遗产.

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

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

Unix和Mac实际上为行尾指定了一个抽象,想象一下.可悲的是,他们指定了不同的.(Unix,ahem,排在第一位.)当然,他们使用的控制代码已经与SOP"接近"了

由于我们今天几乎所有的操作软件都是Unix,Mac或MS操作软件的后代,因此我们不得不忍受线路结束的混乱.