Comment peut-on obtenir un absolu ou un fichier normalisé chemin dans .NET?

Comment peut-on avec un minimum d'effort (en utilisant une partie déjà existante installation, si possible) de convertir les chemins comme c:\aaa\bbb\..\ccc à c:\aaa\ccc?

InformationsquelleAutor mark | 2009-08-12
  1. 35

    Path.GetFullPath peut-être?

    • Je ne crois pas que ce soit garantie pour renvoyer un nom canonique. Il garantit seulement le nom retournée peuvent être utilisés pour faire référence au fichier absolument vs relativement
    • Chemin d'accès.GetFullPath(@"c:\aaa\bbb\..\ccc") = c:\aaa\ccc - assez bon pour moi.
    • Correct, mais il ne vérifie pas si le chemin est valide.
    • Chemin utils ne devrait pas réellement vérifier un fichier valide, ou même de toucher le système de fichiers (mais il y a peu de cas, il n').
    • Ne fonctionne pas pour les fichiers relatifs chemins, depuis un préfixe comme: "C:/" seront ajoutés.
    • Qui dépendent entièrement de la façon dont vous l'utilisez.
    • Pour cette méthode, il n'y a pas tout les surcharges. Comment devrais-je l'utiliser differenty?
    • C'est ce que GetFullPath devrait le faire. NB Chemin d'accès.GetFullPath(@"\..\aaa") renvoie le non-sens "C:\..\aaa" attendu que le Chemin d'accès.GetFullPath(@"..\aaa") renvoie le chemin absolu de votre Chemin.CurrentDirectory()
    • Réponse ci-dessous prend en charge la casse.

    InformationsquelleAutor leppie
  2. 52

    Je voudrais écrire comme ceci:

    public static string NormalizePath(string path)
{
    return Path.GetFullPath(new Uri(path).LocalPath)
               .TrimEnd(Path.DirectorySeparatorChar, Path.AltDirectorySeparatorChar)
               .ToUpperInvariant();
}

    Ce doit gérer quelques scénarios comme

    1. uri et le potentiel des caractères d'échappement, comme les

      file:///C:/Test%20Project.exe -> C:\TEST PROJECT.EXE

    2. les segments du chemin spécifié par des points pour désigner actuel ou répertoire parent

      c:\aaa\bbb\..\ccc -> C:\AAA\CCC

    3. tilde raccourcie (long) les chemins

      C:\Progra~1\ -> C:\PROGRAM FICHIERS

    4. incompatible répertoire caractère délimiteur

      C:/Documents\abc.txt -> C:\DOCUMENTS\ABC.TXT

    Autres, il peut ignorer les cas, de fuite \ répertoire caractère délimiteur etc.

    • Bon et concis solution de chemin de normalisation, exactement ce que je cherchais. +1
    • Ne pas utiliser ToUpper() et ses amis pour tout code que vous voulez pour être portable. Il y a de la casse des systèmes de fichiers dans le monde. Aussi il n'est pas si gentil si vous êtes l'affichage de ces valeurs pour les utilisateurs, dans le cas où vous voulez préserver les cas et l'utilisation de la casse, de tri et de comparaisons. Sinon, regarde bien.
    • Cela dépend de ce que vous entendez par "canonique", mais, depuis Windows traite les chemins d'accès de fichier comme insensibles à la casse, je dirais que vous ne besoin d'un cas de conversion, sinon, il est possible pour n'être plus qu'un "canonique" chemin d'accès pour le même fichier. Je préfère baisse des cas bien.
    • Il ne fonctionne pas avec des chemins relatifs. De cette manière, il n': private string NormalizePath(string path) { return path.Remplacer(Chemin D'Accès.DirectorySeparatorChar, Chemin D'Accès.AltDirectorySeparatorChar) .ToUpperInvariant(); }
    • Ce fut une excellente solution au problème. Merci pour cet affichage.
    • mérite plus upvotes
    • D'autre part, si l'on utilise cette variante de NormalizePath pour copier ou déplacer un fichier quelque part, elle/il a le plus probablement s'attend à ce que le boîtier de ne pas changer. En tant qu'utilisateur, je voudrais interdire un tel programme qui change mon soin househeld des systèmes de dénomination.
    • Peut-être que ce serait mieux pour encapsuler des premières chaînes de chemin, et, au lieu de fournir (ou, de préférence, utiliser) une classe qui définit les opérations de comparaison et de tout ce dont on a besoin.
    • Parce que c'est vraiment t question: ne pas changer les noms à l'boîtier! Il est impoli de l'utilisateur point de vue visuel, et parfois carrément problématique. Si il y a une raison pour faire un canoniques de comparaison, c'est le travail d'une chaîne insensible à la casse comparer (éventuellement avec un dictionnaire, ou quoi que ce soit): l'IC accès est géré post-"canonique" dans le système de fichiers Windows API!
    • Il ne fonctionne pas avec une lettre de lecteur sans final antislash comme C: (c'est pas une URI valide). Pas sûr que c'est un chemin d'accès, mais définitivement l'un que l'utilisateur peut taper.

    InformationsquelleAutor nawfal
  3. 20

    De mise en forme canonique est l'une des principales responsabilités de la Uri classe .NET.

    var path = @"c:\aaa\bbb\..\ccc";
var canonicalPath = new Uri(path).LocalPath; //c:\aaa\ccc
    • Donc je suppose qu'il vérifie que le chemin existe réellement?
    • Non, le Uri classe est uniquement responsable de la génération de chemins. Le système de contre qui ces chemins sont pertinentes n'est pas pris en compte. Une fois que vous obtenez le chemin d'accès via la méthode dans ma réponse, vous auriez encore besoin de vérifier qu'il existe via le File classe (ou autre).
    • Remarque ce n'est pas de normaliser la lettre de lecteur (par exemple "C:\" et "c:\" les deux de sortir inchangé). Donc ce n'est pas vraiment "canonique", dans le sens de l'être unique, en tout cas.
    • Depuis le Windows FS est CI, en supposant un chemin d'accès est "canonocial', puis un autre chemin d'accès différents dans le cas où seule EST canonique et de l'équivalent de même avec boîtier différences. Le consommateur doit également utiliser CI string compare aussi pertinent que tous les cas-les différentes formes est sur le même.
    InformationsquelleAutor bdukes