8

我只是在仔细阅读问题，发现System.getProperty(line.separator)用于代替\n作者的评论，即代码是“可移植的”。通过阅读各种论坛，我看到了两组：

  1. 那些说 Linux 和 Windows 对换行符的解释存在差异的人，这弥补了这一点（没有明确的证据）。
  2. 那些说通过显示代码和输出示例没有区别的人，显然只适用于该代码示例而不是普遍适用。

我的感觉是：它可能是非标准的操作系统，例如您公司的工业扫描仪的操作系统，您会注意到其中的差异。我什么时候才能看到\n和之间的区别line.separator？你能举个例子吗？你是如何发现变异发生在哪里的？

4

3 回答 3

11

这是操作系统的标准行分隔符：

Windows: '\r\n'
Mac (OS 9-): '\r'
Mac (OS 10+): '\n'
Unix/Linux: '\n'

这意味着如果您将行分隔符硬编码为\n，您将在 Linux 和 OS X 中获得预期的结果，但 Windows 无法正确识别行结尾。但是，通过使用更通用line.separator的来表示您的行尾，它们将解析为执行操作系统的预期行尾实现可能碰巧是什么。

于 2014-05-17T02:36:26.913 回答
8

不正确的行尾是一个常见的烦恼。例如，这是 Windows 记事本在使用\n而不是\r\n（Windows 的 line.separator）写入文件时显示的内容：

带框而不是换行符的记事本

那些小盒子应该是换行符。

反之，when\r\n代替\n(Unix' line.separator) 会更糟，并且会以奇怪而奇妙的方式破坏 shell 脚本和配置文件。

例如，sh当尝试运行仅包含ls但带有\r\n行分隔符的 shell 脚本时，这是 Debian 和派生发行版上的输出（它看起来很垃圾，因为回车会导致终端覆盖部分行）：

: not foundsh: ls

StackOverflow 上每天有几个问题来自被这个问题困扰的人，例如这里、这里和这里。

于 2014-05-17T02:32:43.537 回答
6

如果你弄错了，你将搞砸与其他应用程序交换数据的能力。您需要了解什么时候可以假设 Java 会帮助您......以及什么时候不能。

Linux 应用程序通常只使用换行符 (\n) 作为其换行符。Windows 应用程序使用回车后跟换行符 (\n\r) 的组合。

如果您正在使用高级 Java I/O 例程——如果你正在使用处理字符的 Readers 和 Writers，而不是低级 Streams，尤其是字节流——这些库将转换 \n（哪个 java、按照惯例，在内部用作其换行符）到适合平台的表示形式中。如果您使用的是较低级别的函数，则必须意识到这种区别并自己做正确的事。

于 2014-05-17T02:36:12.427 回答