软件是否可以处理其他系统的换行符？

Linux/BSD    linefeed         ^J    10     x0A
Windows/IBM  return linefeed  ^M^J  13 10  x0D x0A
old Macs     return           ^M    13     x0D
others?

由于精神错乱，我打算在文本文件中使用Linux版本的换行符。但是，当我将文本文件带到Windows时，某些程序在文本中使用换行符不能很好地播放。我们将如何处理？

解决方案

我怀疑我们会发现大多数现代Windows程序("记事本"除外)都能很好地处理仅换行符的文件。但是，使用Windows程序生成的文件仍倾向于带有crlf结尾。

在大多数情况下，运行库将以特定于平台的方式自动处理行尾。例如，一个用fopen(...，" r")打开文件的C程序将在任何平台上以一致的方式(仅换行)看到行，而不管实际的行尾如何。

不确定与我们说"交易"时的意思，但是基本上我们只能说类似以下内容：

string convertLineBreaks(String line, String lineBreakYouWant) {
  replace all ^M^J or ^M or ^J in line with lineBreakYouWant

  return line
}

编辑：我怀疑在重读问题后，意思是我们如何处理无法处理错误(针对目标系统)换行符的其他人的程序。

我建议1)使用可以处理的程序，或者2)通过脚本运行文件，该脚本查找任何类型的换行符，然后将其转换为适合我们系统的任何类型。

正如他们所说，在写作上要严格，在阅读上要宽松。

应用程序应该能够正常读取两个行尾。如果我们想使用换行符，并可能使Windows用户不高兴，那就很好。

但是，除了记事本以外，我玩过的大多数程序似乎都对这两种方法都满意。

(而且我在Windows上使用Cygwin，这使所有事情都变得有趣了)

标准的Python发行版附带两个名为crlf.py和lfcr.py的命令行脚本(在工具/脚本中)，可以在Windows和Unix / Linux行尾之间进行转换。

[来源]

在.NET中，新行用Environment.NewLine表示，因此该框架的设计方式是在运行时使用系统的新行(CR + LF或者仅CR或者仅LF)。当然，这在Mono中最终很有用。

据我所知，只有记事本的行分隔符有问题。实际上，世界上任何其他软件都接受这三种类型的分隔符中的任何一种，也可能接受其他类型的分隔符。不幸的是，如今，记事本是大多数计算机用户的首选编辑器。我认为让这种情况继续下去对微软极为不负责任。我从没有玩过Vista，但是我相信问题仍然存在，就像XP中一样。有人知道下一个版本吗？

正如其他人所说，如果需要的话，周围有很多(非常琐碎的)转换器。请注意，如果我们在Ascii模式下使用FTP进行传输，它将自动进行转换...

确实，记事本是最杰出的程序，它的LF结束有问题...

我看到的最烦人的是带有混合行结尾的文本文件，基本上是由人们在Unix上编辑Windows文件完成的，或者是实用程序在不检查正确格式的情况下添加内容。