回车符是否已过时？

我编写了一个开放源代码库，该库可以解析结构化数据，但由于看不到要点，因此特意省去了回车检测。它增加了额外的复杂性和开销，几乎没有好处。

令我惊讶的是，一个用户提交了一个错误，解析器无法正常工作，我发现了问题的原因是数据使用CR行尾而不是LF或CRLF。

自从切换到基于UNIX的平台以来，OSX一直没有使用LF样式的行尾吗？

我知道有些应用程序（例如Notepad ++）可以将行尾更改为显式使用CR，但我不明白为什么有人要这样做。

是否可以安全地排除支持（无论出于何种原因）决定使用旧Mac OS样式行尾的用户的统计上微不足道的支持？

更新：

需要说明的是，支持Windows行尾（即CRLF）不需要CR令牌识别。为了提高效率，词法分析器按每个字符进行匹配。通过静默忽略CR字符，CRLF令牌简化为LF。因此，CRLF令牌本身可以被认为是过时的，但这不是这个问题的目的。

最后一个为CR样式行结尾提供系统范围支持的操作系统是Mac OS 9。具有讽刺意味的是，在OSX中唯一仍将其用作默认值的应用程序是Microsoft Excel。

有一种好的做法，就是“对所接受的东西是自由的，对所发送的东西是保守的”。

换句话说，如果某人有机会（无论有多小）会给您cr行结尾（并希望它能正常工作），则需要提供支持。

TBH，我看不出添加CR支持会花费这么长时间。

当您cr在lexer窥视器中看到a 时，如果下一个字符是a nl，请吞下换行符并发出换行符，如果下一个字符不是a nl，则发出换行符并继续。

不会。CR并不是过时的（定义为“不再生产或使用”）。您自己已经提供了证据。这也许不常见，但并不过时。

至于对CR的“排除支持是否安全 ”？正如您所说，这不是失去销售的问题，您不能支持世界上所有奇怪的字符组合和文件格式，只有您自己知道软件和用户群。因此，我想说，如果您确信不添加它的支持负担（如mouviciel解释）不会超过添加它的时间负担，那么将其排除是安全的。但是在不了解产品和用户群的情况下，我不确定如何具体。

关于懒惰：您必须平衡：

• 努力更改代码，以便安全地处理CR（然后忘记它）。

• 努力向用户说明他们数十年来满意的文件为何突然使您的应用程序崩溃，找到可以在不影响您的销售的情况下使用的变通办法，并在此处征求论点和意见。

由您决定哪个路径最懒。

是否可以安全地排除支持（无论出于何种原因）决定使用旧Mac OS样式行尾的用户的统计上微不足道的支持？

也许没有太多的用户会检测到它，但是房间里有只大象：Windows行尾（CRLF）。如果您支持这些功能（即使我只使用Windows进行游戏，我通常也会这样做），但要支持这个历史悠久的百慕大三角区的第三部分应该是微不足道的。

如果您不支持这种情况，则至少应在文档中提及（“这不是错误”样式），以及如何更改文件以最简单的方式与工具一起使用（dos2unix例如）。

发送之前，有许多串行设备依赖于CR数据流的结束ETX。这是一个永远不会消失的惯例。

在您需要权衡成本与收益的情况下，我会将请求视为任何功能请求。

如果恰好有人要求获得CR支持，则没有必要。请参阅下面的书中的37个信号章节，他们说您只应该担心非常受欢迎的功能请求。

http://gettingreal.37signals.com/ch05_Forget_Feature_Requests.php

从MSDOS开始的MS OS使用CR + LF组合作为行分隔符（我认为主要是因为需要它们的矩阵打印机）。

是的，这真是令人遗憾，但您仍然需要对此事的支持。