Czy konwersja ścieżek plików systemu Windows na ścieżki plików systemu Unix jest bezpieczna za pomocą prostej zamiany?

Powiedzmy na przykład, że miałem to tak, że wszystkie moje pliki zostaną przeniesione z komputera z systemem Windows na maszynę unix jako taką: C:\test\myFile.txtdo {somewhere}/test/myFile.txt(litera dysku jest w tym momencie nieistotna).

Obecnie nasza biblioteka narzędzi, którą sami napisaliśmy, udostępnia metodę polegającą na prostym zastąpieniu wszystkich ukośników odwrotnych ukośnikami:

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

Ukośniki są zastrzeżone i nie mogą być częścią nazwy pliku, dlatego struktura katalogów powinna zostać zachowana. Nie jestem jednak pewien, czy istnieją inne komplikacje między oknami i ścieżkami uniksowymi, o które mógłbym się martwić (np .: nazwy nie-ascii itp.)

Tak, jeśli wykonasz zamianę tylko w systemie Windows i wyłączysz ją podczas uruchamiania w innych systemach.

Wykonanie zamiany na systemach uniksowych jest złe, ponieważ \jest prawidłowym znakiem w nazwie pliku lub katalogu na platformach uniksowych. Na tych platformach tylko NULi /są zabronione w nazwach plików i katalogów.

Ponadto niektóre funkcje interfejsu API systemu Windows (głównie funkcje niższego poziomu) nie zezwalają na stosowanie ukośników do przodu - należy stosować z nimi ukośniki odwrotne .

Tak, ale cała ta sprawa jest sporna. Java płynnie konwertuje ukośniki do ukośników w systemie Windows. Możesz po prostu użyć ukośników dla wszystkich ścieżek, które są zakodowane na stałe lub zapisane w konfiguracji i będzie działać na obu platformach.

Osobiście zawsze używać ukośnik nawet w systemie Windows, ponieważ jest to nie postać ucieczki. Niezależnie od tego, czy surowa ścieżka znajduje się w kodzie, czy na zewnątrz w pliku właściwości, koduję ją w ten sam sposób.

Spróbuj! Będzie to działać w systemie Windows. Oczywiście zmień rzeczywistą ścieżkę na coś, co istnieje, a użytkownik ma uprawnienia do czytania.

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

Bonus: możesz nawet mieszać ukośniki na tej samej ścieżce!

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

Kolejną komplikacją w systemie Windows jest to, że obsługuje on również notację UNC, a także tradycyjne litery dysków.

Dostęp do pliku na zdalnym serwerze plików można uzyskać jako \\server\sharename\path\filename.

Nie. Jest o wiele więcej rzeczy do przemyślenia niż tylko separator ścieżek (rzecz „\ vs /”). Jak wspomina Rob Y, istnieje sposób, w jaki obsługiwane są spacje i ich wysoka częstotliwość w systemie Windows. W obu środowiskach występują różne nielegalne postacie. Istnieje gotowość Unixa, aby pozwolić na prawie wszystko, gdy ucieka przed wiodącym „\”. Windows używa „” do radzenia sobie z osadzonymi przestrzeniami. Windows używa UCS-16, a Unix ASCII lub UTF-8.

itd. , itd. , itd.

Ale w przypadku wielu aplikacji, które mogą nakładać ograniczenia na ścieżki, którymi muszą manipulować, faktycznie można to zrobić tak, jak sugerujesz. I będzie działać w co najmniej dużej liczbie przypadków, po prostu nie we wszystkich.

Każdy system operacyjny Microsoft, poczynając od MS-DOS, rozumiał na poziomie jądra zarówno ukośniki do przodu , jak i ukośniki odwrotne .

Dlatego w systemie Windows możesz swobodnie konwertować między nimi; oba mają równy status jako zarezerwowane separatory. W dowolnej prawidłowej ścieżce możesz zamienić ukośniki odwrotne ukośnikami i odwrotnie, bez zmiany jego znaczenia, jeśli chodzi o jądro.

We wczesnych wersjach DOS command.cominterpreter Microsoftu ustawiał konfigurowalne preferencje, które slash był używany do wyświetlania i analizowania ścieżek. To zostało ostatecznie usunięte.

Niektóre programy przestrzeni użytkownika w systemie Windows, takie jak och, powłoka systemu Windows ( explorer.exe), nie lubią ukośników. To po prostu tandetne programowanie w tych programach.