web-dev-qa-db-fra.com

Est-il sûr de convertir des chemins de fichiers Windows en chemins de fichiers Unix avec un simple remplacement?

Par exemple, disons que je l'ai eu pour que tous mes fichiers soient transférés d'une machine Windows vers une machine Unix en tant que telle: C:\test\myFile.txt à {somewhere}/test/myFile.txt (la lettre de lecteur n'est pas pertinente à ce stade).

Actuellement, notre bibliothèque d'utilitaires que nous avons écrite nous-mêmes fournit une méthode qui remplace simplement toutes les barres obliques inverses par des barres obliques:

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

Les barres obliques sont réservées et ne peuvent pas faire partie d'un nom de fichier, la structure du répertoire doit donc être préservée. Cependant, je ne sais pas s'il y a d'autres complications entre Windows et les chemins Unix dont je pourrais avoir à m'inquiéter (par exemple: noms non ascii, etc.)

javafile-systems
12
MxLDevs

Oui, si vous ne faites que le remplacement sous Windows, et désactivez-le lors de l'exécution sur d'autres systèmes.

Le remplacement sur des systèmes de type Unix est faux parce que \ est un caractère valide dans un nom de fichier ou de répertoire sur les plates-formes de type Unix. Sur ces plates-formes, seuls NUL et / sont interdits dans les noms de fichiers et de répertoires.

En outre, certaines fonctions de l'API Windows (principalement celles de niveau inférieur) ne permettent pas l'utilisation de barres obliques - barres obliques inverses doit être utilisé avec eux.

7
Demi

Oui, mais tout cela est un point discutable. Java convertit de manière transparente les barres obliques en barres obliques inverses sous Windows. Vous pouvez simplement utiliser des barres obliques pour tous les chemins codés en dur ou stockés dans la configuration et cela fonctionnera pour les deux plates-formes.

Personnellement, j'utilise toujours la barre oblique même sous Windows car c'est pas le caractère d'échappement. Que le chemin brut soit en code ou externalisé dans un fichier de propriétés, je l'encode de la même manière.

Essayez! Cela fonctionnera sous Windows. De toute évidence, changez le chemin réel en quelque chose qui existe et votre utilisateur a la permission de lire.

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

Bonus: vous pouvez même mélanger des barres obliques dans le même chemin!

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

Une autre complication sous Windows est qu'il prend également en charge la notation UNC ainsi que les lettres de lecteur traditionnelles.

Un fichier sur un serveur de fichiers distant est accessible en tant que \\server\sharename\path\filename.

3
Simon B

Non. Il y a beaucoup plus de choses à penser que le simple séparateur de chemin (la chose "\ vs /"). Comme le mentionne Rob Y, il y a la façon dont les espaces sont gérés et leur fréquence élevée dans l'utilisation de Windows. Il existe différents personnages illégaux dans les deux environnements. Il y a la volonté d'Unix d'autoriser presque tout ce qui est échappé par un "\". Windows utilise "" pour gérer les espaces intégrés. Windows utilise UCS-16 et Unix utilise ASCII ou UTF-8).

etc. , etc. , etc.

Mais, pour de nombreuses applications qui peuvent imposer des contraintes sur les chemins d'accès qu'elles doivent manipuler, vous pouvez réellement le faire exactement comme vous le suggérez. Et cela fonctionnera dans au moins un grand nombre de cas, mais pas tous.

2
Ross Patterson