Безопасно ли преобразовывать пути к файлам Windows в пути к файлам Unix с помощью простой замены?

Например, скажем, у меня было так, что все мои файлы будут перенесены с компьютера с Windows на компьютер с Unix как таковой: C:\test\myFile.txtна {somewhere}/test/myFile.txt(буква диска на данном этапе не имеет значения).

В настоящее время наша служебная библиотека, которую мы написали самостоятельно, предоставляет метод, который выполняет простую замену всех обратных слешей на прямые:

public String normalizePath(String path) {
   return path.replaceAll("\\", "/");
}

Косые черты зарезервированы и не могут быть частью имени файла, поэтому структура каталогов должна быть сохранена. Тем не менее, я не уверен, есть ли другие сложности между окнами и путями Unix, о которых мне может понадобиться беспокоиться (например, имена не-ascii и т. Д.)

Да, если вы делаете замену только в Windows и выключаете ее при работе в других системах.

Выполнять замену в Unix-подобных системах неправильно, поскольку \это допустимый символ в имени файла или каталога на Unix-подобных платформах. На этих платформах только NULи /запрещено в именах файлов и каталогов.

Кроме того, некоторые функции Windows API (в основном функции нижнего уровня) не позволяют использовать прямую косую черту - с ними необходимо использовать обратную косую черту .

Да, но все это спорный вопрос. Java плавно преобразует косые черты в косые черты в Windows. Вы можете просто использовать прямые косые черты для всех путей, которые жестко заданы или сохранены в конфигурации, и это будет работать для обеих платформ.

Лично я всегда использую косую черту даже в Windows, потому что это не escape-символ. Независимо от того, находится ли необработанный путь в коде или внешний в файле свойств, я кодирую его одинаково.

Попытайся! Это будет работать в Windows. Очевидно, измените фактический путь на то, что существует, и у вашего пользователя есть разрешение на чтение.

File f = new File("c:/some/path/file.txt");
if (!f.canRead()) {
  System.out.println("Uh oh, Snowman was wrong!");
}

Бонус: вы можете даже смешивать слэши в одном и том же пути!

File f = new File("c:/some\\path/file.txt");
if (!f.canRead()) {
  System.out.println("Uh oh, Snowman was wrong again!");
}

Другая сложность в Windows заключается в том, что она также поддерживает нотацию UNC, а также традиционные буквы дисков.

Доступ к файлу на удаленном файловом сервере возможен как \\server\sharename\path\filename.

Нет . Есть гораздо больше вещей , чтобы думать о чем только разделителей пути (символ «\ против /» вещь). Как упоминает Роб Y, есть способы обработки пробелов и их высокая частота использования Windows. В двух средах есть разные недопустимые символы. Существует готовность Unix разрешить почти все, когда сбегает ведущий "\". В Windows используется «» для работы со встроенными пробелами. В Windows используется UCS-16, а в Unix - ASCII или UTF-8.

и т.д. , и т.д. , и т.д.

Но для многих приложений, которые могут накладывать ограничения на имена путей, которыми они должны манипулировать, вы на самом деле можете сделать это именно так, как вы предлагаете. И это будет работать, по крайней мере, во многих случаях, но не во всех.

Каждая операционная система Microsoft, начиная с MS-DOS, понимала на уровне ядра как прямую , так и обратную косую черту .

Поэтому в Windows вы можете свободно конвертировать между ними; оба имеют равный статус как зарезервированные разделители. В любом допустимом пути вы можете заменить обратную косую черту косой чертой и наоборот, не меняя ее значения в том, что касается ядра.

В ранних версиях DOS command.comинтерпретатор Microsoft делал это настраиваемым параметром, который использовал косую черту для отображения и анализа путей. Это было в конечном итоге удалено.

Некоторые программы пользовательского пространства в Windows, такие как, ну, оболочка Windows ( explorer.exe), не любят косые черты. Это просто дрянное программирование в этих программах.