Разница между File.separator и косой чертой в путях

В чем разница между использованием File.separatorи нормалью /в Java Path-String?

В отличие от двойной обратной косой черты, \\независимость от платформы, похоже, не является причиной, поскольку обе версии работают под 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 для работы с файлами вы можете безопасно использовать /(косую черту, а не обратную косую черту) на всех платформах. Код библиотеки обрабатывает перевод вещей в платформо-зависимые пути внутри страны.

Однако вы можете захотеть использовать его File.separatorв пользовательском интерфейсе, потому что лучше показать людям, что имеет смысл в их ОС, а не что имеет смысл для Java.

Обновление : я не смог за пять минут поиска найти документированное поведение "всегда можно использовать косую черту". Теперь, я уверен, что я видел это задокументированным, но в отсутствие нахождения официальной ссылки (потому что моя память не идеальна), я бы продолжал использовать, File.separatorпотому что вы знаете, что это будет работать.

Вы используете, File.separatorпотому что когда-нибудь ваша программа может работать на платформе, разработанной в далекой стране, стране странных вещей и незнакомых людей, где лошади плачут, а коровы управляют всеми лифтами. На этой земле люди традиционно используют символ «:» в качестве разделителя файлов, и поэтому JVM покорно подчиняется их желаниям.

Хотя использование File.separator для ссылки на имя файла является излишним (для тех, кто представляет себе далекие земли, я думаю, что их реализация JVM заменит a /на :аналогично тому, как jvm из окон заменяет его на a \).

Однако иногда вы получаете ссылку на файл, а не создаете его, и вам необходимо проанализировать его, и для того, чтобы сделать это, вам нужно знать разделитель на платформе. File.separator поможет вам сделать это.

Хорошо, давайте проверим некоторый код.
File.javaстроки с 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) Постобработка указанной строки пути
URI, если необходимо. Это используется в win32, например, для преобразования "/ c: / foo" в "c: / foo". Строка пути все еще имеет разделители слэша; код в классе File переведет их после возврата этого метода.

Это означает, FileSystem.fromURIPath()что постобработка по пути URI только в Windows, и потому в следующей строке:

p = p.replace('/', File.separatorChar);

Он заменяет каждый «/» на системно-зависимый seperatorChar, вы всегда можете быть уверены, что «/» безопасен в каждой ОС.

Ну, есть больше ОС, чем Unix и Windows (портативные устройства и т. Д.), А Java известна своей переносимостью. Лучше всего использовать его, чтобы JVM могла определить, какая из них лучше для этой ОС.

Хотя это не имеет большого значения на обратном пути, но на обратном пути.

Конечно, вы можете использовать «/» или «\» в новом файле (путь строки), но 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.

Портативность просто и понятно.

«Java SE8 для программистов» утверждает, что Java справится с любым из них. (стр. 480, последний абзац). В примере утверждается, что:

c:\Program Files\Java\jdk1.6.0_11\demo/jfc

разберутся просто отлично. Обратите внимание на последний разделитель (в стиле Unix).

Это липко и, вероятно, подвержено ошибкам, но это то, что они (Deitel и Deitel) утверждают.

Я думаю, что путаница для людей, а не Java, является достаточной причиной, чтобы не использовать эту (неправильную?) Функцию.

Как господа описали разницу с деталями варианта.

Я хотел бы рекомендовать использовать Apache Commons io api, класс FilenameUtilsпри работе с файлами в программе с возможностью развертывания на нескольких ОС.

Путь к файлу или каталогу указывается с использованием соглашений об именах хост-системы. Однако класс File определяет зависящие от платформы константы, которые можно использовать для обработки имен файлов и каталогов независимо от платформы.

Files.seperator определяет символ или строку, которые разделяют каталог и компоненты файла в имени пути. Этот разделитель - '/', '\' или ':' для Unix, Windows и Macintosh соответственно.

Если вы используете Java 7, проверьте Path.resolve () и Paths.get () .

Использование File.separator заставило Ubuntu генерировать файлы с «\» в имени вместо каталогов. Может быть, мне лень, как я делаю файлы (и каталоги), и я мог бы избежать этого, независимо от того, что каждый раз использую «/», чтобы избежать файлов с «\» в названии.

Что вы должны сделать, если вы пытаетесь создать файл по какому-либо готовому пути (сохраненному в базе данных, например), используя разделитель Linux?

Может быть, просто используйте путь для создания файла:

new File("/shared/folder/file.jpg");

Но Windows использует другой разделитель ( \). Итак, является ли альтернативой преобразование разделителя слеша в платформу независимым? Подобно:

new File(convertPathToPlatformIndependent("/shared/folder"));

Этот метод, convertPathToPlatformIndependentвероятно, будет иметь какое-то разделение на "/" и объединиться с File.separator.

Ну, для меня это нехорошо для языка, который не зависит от платформы (верно?), А Java уже поддерживает использование в /Windows или Linux. Но если вы работаете с путями и вам нужно каждый раз вспоминать об этом преобразовании, это будет кошмаром, и вы не получите никакой реальной выгоды для приложения в будущем (возможно, во вселенной, описанной @Pointy).