艳母全集

编译 | 苏宓

出品 | CSDN（ID：CSDNnews）

看成别称次序员，想必你对 CRLF 并不生分。

CRLF，全称 Carriage Return Line Feed，汉文翻译为回车换行。它由两个字符构成：CR (\\r，回车) 和 LF (\\n，换行)，其中回车是将光标出动到现时行的最左侧，而换行则是将光标下移一转。这里还需要说起的一个成见是——新行 (NL，NewLine)，它是指将光标下移一转，并出动到现时行的最左侧。

CRLF 的存在主若是为了兼容不同操作系统的文献款式。频繁，Windows 使用 CRLF 看成换行符，而 Unix/Linux 和 macOS 只使用 LF。

关联词，在实践开发中，CRLF 和 LF 的各异通常导致不少开发团队在处理文献时出现令东说念主头疼的编码伪善和粉碎。越来越多的开发者觉得：CRLF 已流程时，应该被顺利取销。

这个不雅点激发了不少争议，但也让东说念主运转再行想考：在当代开发环境中，咱们是否真的需要络续复旧 CRLF？

SQLite 之父发起号令

这则声明由好意思国软件开发者 D. Richard Hipp 发起的，他不仅创建了 SQLite 开源镶嵌式相关数据库，也开发了散播式版块领域系统 Fossil 和蚁合办事器 Althttpd 等软件。

D. Richard Hipp 示意，“回车”和“新行”皆是有用的领域字符。NL（新行）是最常见的操作，示意运转新的一转并从行首运转写。单独的 CR 无意也有用，尤其当你想遮蔽还是写好的翰墨时。而 LF（换行）基本上没什么用。莫得东说念主但愿在一转的中间罢手，然后向下出动一转并从归拢列络续写。莫得任何实践次序会这样作念。

LF 之是以存在，是在计较机末端如故电传打印机的时候留传住来的东西。

D. Richard Hipp 称，LF 出身于大致 70 年前的机械电传打字机期间。那时的电传打字机莫得使用晶体管，而是统统由齿轮、凸轮、马达、继电器和伺服装配构成的。它们卓越神奇，不错将通过两根铜线传输的二进制代码疗养为纸上的打印文本。

电传打字机就像是庸碌打字机雷同责任，每秒打印大致 5 个字符。打印头是一个包含字母的圆柱体或卵形小球。打印头与纸之间有一个浸有墨水的布带。为了打印一个字符，打印头会旋转到正确的位置，然后上前撞击，使布带上的墨水在纸上酿成所需字符的体式。每打印一个字符，整个打印头机构（小球、墨带以及各式领域凸轮和齿轮）皆会向右出动一个字符的位置。这一切每秒发生五次。这些机器运作时杂音很大，况兼会明显回荡。

在一转文本的末端，打印头必须复返到最左侧。打印头出动得很快，但出动到最左边仍需要时候。那时莫得内存，是以打印头必须不才一个字符到来之前统统移到左边。

为了兑现这少量，NL（新行）操作被分为两个子操作：CR（回车）和 LF（换行）。CR（回车）先行，启动打印头向左出动。当打印头还在出动时，LF（换行）会到达，导致纸张迂回一转。这个独特的 LF（换行）字符为打印头争取到富饶的时候，不才一个字符到达之前统统移到最左侧。

回看往日，文本行以 CRLF 扫尾的传统不错追料到 20 世纪 50 年代电传打字机的机械甩手。这是一个典型的例子，阐述底层兑现的细节怎样显现在用户界面中。

到 20 世纪 60 年代末和 70 年代初的 Multics 和 Unix 期间艳母全集，大大批东说念主意志到使用 CRLF 看成 NL（新行）是没专门旨的。

因此，发送单独的 CR 和 LF 字符的任务被打发给了电传打字机的拓荒驱动次序，因为硬件错误的照应应该在驱动次序层处理。计较机只需保存一个 NL（新行）字符，并选拔与电传打字机筹商的 LF（换行）代码来示意 NL，这里着实的 LF 在实践诈欺中莫得任何意旨，因此它的数字代码被再行用于示意 NL。

如今，CR 用 Unicode 编码中的 U+000d 看成代码点来示意，LF 和 NL 皆用 U+000a 示意。险些总计当代机器皆仅使用 U+000a 示意 NL，这个意旨也镶嵌在大大批编程谈话中，频繁使用反斜杠转义符 \\n。

尽管如斯，仍有少数机器坚抓在 NL 之前发送 CR，而 U+000a 的官方 Unicode 称号仍然是 LF。此外，一些契约（如 HTTP、SMTP、CSV）仍然“条目”每行以 CRLF 扫尾。如今险些总计软件皆会经受单独的 NL 字符（莫得前置 CR）来示意行舍弃。你必须卓越仔细地寻找，才气找到着实将 U+000a 诠释为换行的拓荒或诈欺次序。

D. Richard Hipp 直言：

“这一传统，即在每个 NL（新行）之前发送无须的 CR（回车），发源于旋转拨号电话期间，致使是在集成电路发明之前。这种作念法在咱们的当代宇宙中还是莫得原理络续存在了。独特的 CR 莫得任何实践用途，仅仅给次序员带来不必要的隔断，浮滥带宽。”

CRLF 已流程时！

在这样的配景下，D. Richard Hipp 发起号令——「总计追求简易、和平，并但愿促进东说念主类喜悦的东说念主，请与我整个反对使用 CRLF，匡助它赶快成为历史的遗址。」

为此，他建议了四点建议：

罢手将“linefeed”（LF）看成 U+000a 代码点的称号。往日二十年内构建的大大批技巧，以及往日半个世纪的大大批技巧，还是将 U+000a 通晓为“newline”（新行）而不是“linefeed”（换行）。诚然“linefeed”是它的历史称号，但那又有什么相关呢？在险些总计实践诈欺中，它示意的是“新行”，因此请顺利称它为“newline”。

罢手发送不必要的 CR（回车）。仅在你如实需要用新内容遮蔽现时行时才使用 CR。在 NL（新行）之前加上 CR 统统是浮滥带宽。除非你必须与某些阻塞的系统通讯，而这些系统毅力停留在 1950 年代，不然不要在 NL 前加上 CR。

即使某些现存契约（如 HTTP、SMTP、CSV、FTP）技巧上条目以 CRLF 看成行尾，也不要驯顺。只发送 NL。尽管技巧上不正确，但险些总计这些契约的兑现皆会经受单独的 NL 看成行尾符号。不要屈服于 CRLF 的领域。

建造那些在收受到莫得前置 CR 的 NL 时推崇特殊或报错的软件。总计当代软件皆应经受单独的 U+000a 字符看成有用的行尾符号。系统可能会为了向后兼容而经受 CR 加 NL，但条目 CR 加 NL 的软件是有问题的。

在 D. Richard Hipp 看来，CRLF 的拆伙早该到来了，因为它早就逾期了。

带来的影响

万万没料到，此话一出，激发次序员蛮横的共识，同期也有不少东说念主抓有不同的看法。

有开发者称，「我统统甘心。这会导致无穷的杂乱，尤其是在跨平台文本文献中。更不消说以编程面貌剖释了。」

不外，也有来自 HN 上的网友 forrestthewoods 示意：

我蛮横反对这个不雅点。

简便来说——别怀恨，我方照应。处理不同或羼杂的行扫尾如实是个幽微的小隔断，但并不复杂或艰苦。不要为了让我方松弛少量就让别东说念主承担不必要的隔断。经受它，络续前行。

@Animats 觉得，「与其号令，倒不如劝服微软。因为这恰是 DOS 留传导致让这一切得以延续」。

@bmitc 称：除了那些谋划晦气的 Unix 用具和 Git，谁还会被这种问题困扰？为了合乎 Linux，我将裁剪器确立为非论在哪个操作系统上皆使用 LF，并确保 Git 不再浑浊行扫尾。在处理串行契约时，我从来莫得遭受侵略题。

跟着争议的发酵，D. Richard Hipp 迫于无奈之下，至当天更新了我方的声明，他示意：

看起来(1)现在主流中的软件依赖于逾期的 CRLF 行扫尾的数目比我原先预感的还要多；

(2) 许多东说念主并不认可我创建一个无 CRLF 宇宙的关注。

唉，这让我有些失望，但现实即是如斯。感谢总计自在尝试这个目标的东说念主，原本险些奏凯了！因此，我在此猬缩这项提议，并已将我总计的系统规复为在轨范条目的情况下生成 CRLF。确切缺憾。

不外，此次实验带来一个不测的平允，我在 Fossil 和 althttpd 中发现并建造了一些问题，这些次序此前条目必须使用 CRLF，且不允许使用单独的 NL 看成替代。

那么，你是否在开发中遭受过 CRLF 问题？

https://fossil-scm.org/home/ext/crlf-harmful.md

https://news.ycombinator.com/item?id=41830717