正如他们所说，对你所写的内容要严格，对你所读的内容要自由。
您的应用程序应该能够正常读取两个行尾。如果您想使用换行符，并可能让 Windows 用户感到不安，那很好。
但是除了记事本之外，我玩过的大多数程序似乎都对这两种方法都很满意。
（我在 Windows 上使用 Cygwin，这让一切变得有趣）
标准 Python 发行版带有两个命令行脚本（在工具/脚本中），称为 crlf.py 和 lfcr.py，可以在 Windows 和 Unix/Linux 行结尾之间进行转换。
在 .NET 中，新行由 表示Environment.NewLine，因此该框架的设计方式是在运行时使用系统的新行（CR+LF 或仅 CR 或仅 LF）来使用。当然，这最终在 Mono 中很有用。
我怀疑您会发现大多数现代 Windows 程序（除了记事本之外）都可以很好地处理仅换行符的文件。但是，使用 windows 程序生成的文件仍然倾向于以 crlf 结尾。
大多数情况下，行尾将由运行时库以特定于平台的方式自动处理。例如，打开文件的 C 程序将fopen(..., "r")在任何平台上以一致的方式（仅换行）查看行，而不管实际的行结尾如何。
据我所知，只有记事本存在行分隔符问题。世界上几乎所有其他软件都接受这三种类型的分隔符中的任何一种，也可能接受其他类型的分隔符。不幸的是，记事本是当今大多数计算机用户的首选编辑器。我认为微软让这种情况继续下去是极其不负责任的。我从来没有玩过Vista，但我相信问题仍然存在，就像在XP中一样。有人知道下一个版本吗？
正如其他人所说，如果需要，周围有很多（非常微不足道的）转换器。请注意，如果您在 Ascii 模式下使用 FTP 进行传输，它将自动进行转换...
事实上，记事本是最突出的程序，有 LF 结尾的问题......
我看到的最烦人的是带有混合行结尾的文本文件，基本上是由人们在 Unix 上编辑 Windows 文件完成的，或者是实用程序在不检查正确格式的情况下添加内容。
要开心，只需遵循标准的建议即可。
http://unicode.org/standard/reports/tr13/tr13-5.html
并为旧 MacOS 等特殊情况提供选项。或者如果您能可靠地检测到它们，则自动处理此案。
我建议以 Unix 风格格式化你的文本。忘记 Windows 用户。因为没有 Windows 用户对文档或数据使用纯文本。如果您传递纯文本，他们会感到不安。他们总是期望 Word 或 Excel 文档。即使他们使用纯文本文件，他们会遇到的唯一问题就是奇怪地显示文本。
但是 Unix 用户会体验到他们的所有工具都无法正常工作。尤其是Unix，要严格遵守标准。
PS。哦，如果您的 Windows 用户是开发人员，只需在 Unix 中格式化文本，并告诉他们这是来自 Unix 的文件。
不知道你说“处理”是什么意思，但基本上你可以这样说：
string convertLineBreaks(String line, String lineBreakYouWant) {
replace all ^M^J or ^M or ^J in line with lineBreakYouWant
return line
}
编辑：我怀疑在重新阅读您的问题后，您的意思是如何处理无法处理不正确（对于目标系统）换行符的其他人的程序。
我建议 1) 使用可以处理的程序或 2) 通过脚本运行文件，该脚本可以找到任何类型的换行符，然后将它们转换为适合您系统的任何类型。