File.separator和path之间的斜杠之间的区别
在Javapathstring中使用File.separator和normal /有什么区别？
与双反斜杠相比\ \\平台独立似乎不是原因，因为这两个版本都在Windows和Unix下工作。
public class SlashTest { @Test public void slash() throws Exception { File file = new File("src/trials/SlashTest.java"); assertThat(file.exists(), is(true)); } @Test public void separator() throws Exception { File file = new File("src" + File.separator + "trials" + File.separator + "SlashTest.java"); assertThat(file.exists(), is(true)); } }
为了改变这个问题，如果/在Unix和Windows上工作，为什么要使用File.separator ？
使用Java库处理文件，您可以在所有平台上安全地使用/ （斜杠，而不是反斜杠）。 库代码处理将内容转换为特定于平台的path。
但是，您可能希望在UI中使用File.separator ，因为最好向人们展示在他们的操作系统中有什么意义，而不是Java的意义。
更新 ：在五分钟的search中，我无法findlogging的“你总是可以使用斜线”的行为。 现在，我确定我已经看到了它的logging，但是在找不到正式的参考（因为我的记忆不完美），我会坚持使用File.separator因为你知道这将工作。
你使用File.separator因为有一天你的程序可能运行在一个遥远的土地上，一个奇怪的东西和陌生的人的地方，那里的马哭和牛操作所有的电梯。 在这片土地上，人们传统上使用“：”字符作为文件分隔符，因此JVM忠实地服从他们的愿望。
虽然使用File.separator来引用文件名是矫枉过正的（对于那些想象不到的人来说，我想他们的JVM实现会用/replace/ ，就像windows的jvm用\replace它一样）。
但是，有时你得到的是文件引用，而不是创build文件，你需要parsing它，为了做到这一点，你需要知道平台上的分隔符。 File.separator可以帮助你做到这一点。
那么，有更多的操作系统比Unix和Windows（便携式设备等），Java以其便携性而闻名。 最好的做法是使用它，所以JVM可以确定哪一个最适合该操作系统。
虽然在途中没有太大的区别，但它在回来的路上。
当然你可以在新的File（String path）中使用'/'或'\'，但File.getPath（）只会给你一个。
便携性简单明了。
晚会到了晚会 我在Windows 10上使用JDK 1.8和Eclipse MARS 1。
我发现
getClass().getClassLoader().getResourceAsStream("path/to/resource");
作品和
getClass().getClassLoader().getResourceAsStream("path"+File.separator+"to"+File.separator+"resource");
不起作用
getClass().getClassLoader().getResourceAsStream("path\to\resource");
不起作用。 后两个是相同的。 所以…我有很好的理由不使用File.separator。
好的，我们来看一些代码。
File.java File.<init>第428到435行File.<init> ：
String p = uri.getPath(); if (p.equals("")) throw new IllegalArgumentException("URI path component is empty"); // Okay, now initialize p = fs.fromURIPath(p); if (File.separatorChar != '/') p = p.replace('/', File.separatorChar);
让我们读取fs/*(FileSystem)*/.fromURIPath() ：
java.io.FileSystem
public abstract String fromURIPath（String path）
如有必要，后处理给定的URIpathstring。 这用于win32，例如，将“/ c：/ foo”转换为“c：/ foo”。 pathstring仍然有斜线分隔符; 在这个方法返回之后，File类中的代码将会把它们翻译出来。
这意味着FileSystem.fromURIPath()仅在Windows中对URIpath进行后处理，因为在下一行中：
p = p.replace('/', File.separatorChar);
它用系统相关的seperatorCharreplace每个'/'，你可以确定'/'在每个操作系统中都是安全的。
正如先生们用不同的细节描述了不同之处。
我想推荐在处理程序中的FilenameUtils时使用Apache Commons io api类FilenameUtils ，以便在多个操作系统上进行部署。
文件或目录的path名是使用主机系统的命名约定来指定的。 但是，File类定义了与平台相关的常量，这些常量可以用来以独立于平台的方式处理文件和目录名。
Files.seperator定义了将目录和文件组件分隔开来的字符或string。 这个分隔符分别是Unix，Windows和Macintosh的“/”，“\”或“：”。
如果您正在使用Java 7，请检出Path.resolve（）和Paths.get（） 。
“Java SE8程序员”声称， Java也会应付。 （第480页，最后一段）。 这个例子声称：
c:\Program Files\Java\jdk1.6.0_11\demo/jfc
将parsing得很好。 记下最后一个（Unix风格）分隔符。
这很俗气，可能很容易出错，但他们（Deitel和Deitel）声称。
我认为对于人而不是Java的混淆是不够的，不能使用这个（mis？）特性。
使用File.separator使得Ubuntu生成带有“\”的文件，而不是目录。 也许我正在懒我制作文件（和目录），可以避免它，无论每次使用“/”，以避免“\”的文件名
