换行符

时间:2008-09-26 04:52:18

标签: text encoding newline

您的软件是否处理来自其他系统的换行符?

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上时,某些程序在我的文本中不能很好地使用换行符。你会怎么处理这个?

8 个答案:

答案 0 :(得分:3)

正如他们所说,严格按照你所写的内容和所读的内容进行自由。

您的应用程序应该能够正确读取两个行结尾。如果您想使用换行符,并且可能会让Windows用户感到不安,那很好。

但是对于记事本来说,我玩的大多数程序似乎对这两种方法都很满意。

(我在Windows上使用Cygwin,这让一切变得有趣)

答案 1 :(得分:1)

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

[Source]

答案 2 :(得分:1)

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

答案 3 :(得分:0)

我怀疑你会发现大多数现代Windows程序(除了记事本之外)只处理换行文件就好了。但是,使用Windows程序生成的文件仍然倾向于使用crlf结尾。

大多数情况下,行结束将由运行时库以特定于平台的方式自动处理。例如,打开带有fopen(..., "r")的文件的C程序将在任何平台上以一致的方式(仅限换行)查看这些行,而不管实际的行结尾。

答案 4 :(得分:0)

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

答案 5 :(得分:0)

正如其他人所说,如果需要,有许多(相当琐碎的)转换器。请注意,如果您在Ascii模式下使用FTP进行传输,它将自动执行转换...

实际上,Notepad是最有效的程序,有LF结尾的问题......

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

答案 6 :(得分:0)

要开心,请遵循标准中的建议。

http://unicode.org/standard/reports/tr13/tr13-5.html

并为旧MacOS等特殊情况提供选项。如果可以可靠地检测到它,请自动处理。

我建议以Unix风格格式化文本。忘掉Windows用户吧。因为没有Windows用户将纯文本用于文档或数据。如果你传递纯文本,他们会很沮丧。他们总是期待Word或Excel文档。即使他们使用纯文本文件,他们唯一会遇到的问题就是奇怪地显示文本。

但Unix用户将体验他们的所有工具将无法正常工作。特别是对于Unix,严格遵循标准。

PS。 哦,如果您的Windows用户是开发人员,只需在Unix中使用文本格式化,并告诉他们来自Unix的文件。

答案 7 :(得分:-2)

当你说'交易'时,不确定你的意思,但基本上你可以这样说:

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

  return line
}

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

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