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

12

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

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

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

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

MxLDevs
источник
4
Просто следите за пробелами - ставить пробелы в именах папок Windows гораздо чаще, чем в именах каталогов Unix. В частности, "\ Program Files" доставляет меня постоянно. В зависимости от того, как вы используете пути, вам может понадобиться экранировать пробел с помощью «\».
Роб
1
@delnan для простоты, давайте ограничим область путей, чтобы исключить переменные пути.
MxLDevs
2
@MxyL Проблема не исчезнет, ​​когда вы жестко закодируете путь, а не используете переменную окружения. Если вы просто хотите путь, который не взорвется, все будет в порядке. Если вам нужен осмысленный путь или если вы хотите взаимодействовать с другим программным обеспечением (или ожиданиями пользователей ...), вам нужны вызовы оценки для каждого пути.
1
@delnan Я в основном сосредоточен на создании правильного пути, но это хороший момент. Пути, которые я конвертирую, должны быть достаточно простыми, чтобы они сами по себе имели смысл.
MxLDevs
3
Обратная косая черта разрешена в именах файлов в Linux, поэтому замена обратной косой черты в пути Linux может добавить недопустимые каталоги. Например, /foo\\barне эквивалентно в /foo/barLinux.

Ответы:

7

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

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

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

Деми
источник
4

Да, но все это спорный вопрос. 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!");
}

источник
1
Если вы прочитаете весь мой ответ, вы увидите, где я говорю, что всегда использование разделителя файлов Unix будет работать правильно в обоих местах, конвертация не требуется.
Вопрос гласит, что файлы будут переданы, и оставляет открытым способ хранения имен файлов . Я добавил комментарий к вопросу с просьбой дать разъяснения по этому вопросу. Основываясь на ответе, я отредактирую свой ответ соответствующим образом.
Весьма маловероятно, что программа фактически содержит внутри себя введенный вручную список всех передаваемых файлов. Гораздо более вероятно, что для перечисления файлов используется какой-то автоматизированный механизм. Учитывая параметры задачи, как они указаны в вопросе, этот механизм обеспечивает традиционные пути в стиле Windows. В своем нынешнем виде, этот ответ говорят ОП , чтобы решить другую проблему вместо того, чтобы, не говоря им , как или даже , что они должны преобразовать в Их или иную проблему.
Элия ​​Каган
Пожалуйста, прочитайте мой предыдущий комментарий.
1
Windows распознает как fowrard, так и обратную косую черту, и так было с ранних версий MS-DOS. Т.е. каждое ядро ​​Microsoft OS имеет поддержку разделителя косой черты. Ранние COMMAND.COMинтерпретаторы имели предпочтение во время выполнения: вы могли настроить, какой слеш интерпретатор будет использовать для печати и анализа.
Каз
3

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

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

Саймон Б
источник
1
Я думаю, что это единственная упомянутая проблема, которая на самом деле является проблемой для этого приложения. Если задействованы пути UNC, они не могут быть с пользой преобразованы в путь в стиле Unix.
Жюль
2

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

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

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

Росс Паттерсон
источник
1
Я не думаю, что эти проблемы верны для поставленного вопроса. Обработка пространства - это проблема пользовательского интерфейса; Системы Unix могут обрабатывать пробелы в именах файлов так же, как Windows. Недопустимые символы Windows являются надмножеством символов Unix. В именах файлов Windows не должно быть обратной косой черты (кроме разделителей каталогов, которые будут преобразованы). Использование кавычек для встроенных пространств - это проблема уровня пользовательского интерфейса, а не проблема обработки файлов. Код преобразования, по-видимому, написан на Java, поэтому должен автоматически обрабатывать преобразование UCS16-> UTF8.
Жюль
-1

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

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

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

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

Kaz
источник
1
Хотя это и правда, я не верю, что это полезно для вопроса OP, который (AIUI) включал преобразование существующих имен путей, которые уже включили бы в них обратные слеши. Это является очень полезным для написания кросса-платформенного кода , чтобы понять , что вы можете просто использовать слеш и они работают в большинстве контекстов, но в данном случае я не думаю , что это помогает.
Жюль
@Jules OP передает файлы из Windows. Этот ответ объясняет, что нет обратной косой черты, которую нужно заменить. Они вообще не находятся в самой файловой системе Windows. Все пути выражены косой чертой (и Windows даже понимает это).
Каз