Різниця між 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 замінить на /такий :же, як Windows 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
публічний конспект 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 міг визначити, який із них найкращий для цієї ОС.

Хоча це не має великої різниці в дорозі, але на зворотному шляху.

Звичайно, ви можете використовувати або "/" або "\" у новому файлі (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.

портативність звичайна і проста.

"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).