为什么 java 7 中没有 Files.readAllLines(String path)？ [关闭]答案

【问题标题】：Why is threre not a Files.readAllLines(String path) in java 7? [closed]为什么 java 7 中没有 Files.readAllLines(String path)？ [关闭]
【发布时间】：2012-09-24 04:21:14
【问题描述】：

我正在尝试学习 Java 7 中的 nio 2 包，但偶然发现了 Files.readAllLines(Path p, Charset cs) 方法。我觉得它非常有用，但我认为应该有一个没有cs 参数的版本，就像：

 public static List<String> readAllLines(String path)
    throws IOException
{ return readAllLines(Paths.get(path), Charset.defaultCharset());}

我确信大多数时候无论如何都会使用默认字符集调用该方法，所以为什么没有快捷方式。关于字符集我有什么遗漏可以证明没有这种方法是合理的吗？我很惊讶，因为 Scala 有这个选项：

Source.fromFile("fileName").getLines

所以我不明白为什么 Java 不应该。有意见吗？

【问题讨论】：

也许他们想阻止使用默认字符集，或者他们想尽量减少添加的方法数量。
太糟糕了，downvoter 没有评论原因
假设默认字符集是让宇宙一开始就陷入字符编码地狱的原因。
@OliverStutz，也许他是 nio2 的开发者之一 :)
新闻快讯：readAllLines(String path) 被添加到 Java SE 8 中，并且假定的字符集始终为 UTF-8。

标签： java java-7 nio2

【解决方案1】：

[...] 在大多数情况下，无论如何都会使用默认字符集调用该方法，

不是真的。大多数情况下，它将使用您希望文件编码的字符集来调用它。现在通常是 UTF-8：

Files.readAllLines("fileName", StandardCharsets.UTF_8)

您的应用程序可以使用不同的默认字符编码在多个平台和操作系统上执行。您不希望您的应用程序因此而中断。

我认为这是一个不错的选择，可以解决过去错误的设计决策。许多旧的 Java 方法使用默认系统编码，导致不一致的行为或应用程序，例如在 Windows 和 Linux 之间。强制选择字符编码只会让您的应用程序更便携、更安全。

顺便说一句，因为您提到了 io.Source 类 - 请注意，它返回一个迭代器而不是 List<String> 就像 Files 类一样。优点：文件被延迟加载，而不是一次全部加载到巨大的ArrayList<String>。缺点：您必须手动关闭源代码（在您的代码 sn-p 中不能这样做）。

【讨论】：

+1 他们真的应该弃用没有字符集之类的String.getBytes()
好吧，我想说我希望文件被编码的字符集是我的默认字符集（无论如何在我的情况下它是 UTF_8 :)）。如果 UTF_8 在任何情况下都是最合理的选项，那么他们可以使用该选项作为默认选项
@Chirlo：+1，这是一个合理的假设。但我仍然认为明确 charset 是个好主意。
那么让我们说我希望有一个Files.readAllLinesWithDefaultCharset(file) 方法:) 至少对我来说会有所不同。顺便说一句，在io.Source 上给小费+1。

【解决方案2】：

您必须询问设计人员，但他们很可能同意我的观点，即不鼓励将整个文件读入内存。它无法扩展，并且引入了不必要的时间和空间成本。一次处理一行文件。

【讨论】：