Je travaille actuellement avec un code impliquant un enregistrement d'un fichier dans un fichier défini par l'utilisateur. Si l'utilisateur passe dans un nom de fichier sans extension, le code ajuste l'extension basée sur le type de fichier (stocké en interne).
Cependant, j'ai du mal à déterminer si le nom de fichier transmis au code a une extension ou non. J'utilise Notez également que ce même comportement est évident dans Alors, ce que je prends, c'est que .Net et Windows diffèrent sur ce qu'ils pensent comme une extension.
Puisque cela tirerait la définition de mon code d'une extension appropriée plus conforme à la façon dont Windows traite des choses. Ou y a-t-il quelque chose qui me manque ici qui dit explicitement que je dois permettre aux espaces dans mes extensions?
J'ai recherché et trouvé Ceci légèrement question similaire , mais les documents qui y sont liés ne spécifient que qu'il n'est pas recommandé de mettre fin à l'extension avec un espace / une période - ils ne disent rien des espaces dans l'extension. chemin.hacastension (nom de fichier) et chemin.getextension (nom de fichier) mais il semble présenter un comportement étrange:
file.ext => .ext est l'extension. C'est bien.
ceci est un fichier.ext => .ext est l'extension. C'est aussi bien.
Ceci est un fichier. Pas une extension => . Pas une extension est l'extension. Cependant, je penserais à cela comme un fichier sans extension. Windows le pense aussi lorsque je crée un fichier avec ce nom (Création d'un fichier avec une extension non reconnue Cause Windows pour l'appeler un fichier ExtensionName , tandis que les fichiers sans prolongation, tels que celui-ci sont simplement appelés Fichier ).
ceci est un fichier.Pas d'une extension => .not une extension est l'extension. Même problème que ci-dessus.
chemin.getfilenamewithoutextension (nom de fichier) (par exemple, il indique le nom de fichier sans extension sur les deux derniers exemples pour être juste Ceci est un fichier ).
si (! chemin.hacastension (nom de fichier) || chemin.getextension (nom de fichier) .Contains ("")) {...}
3 Réponses :
Il n'y a pas de définition officielle de ce qu'est une extension. La convention commune est que tout après la finale Toutefois, si vous saisissez une énorme liste de toutes les extensions courantes, je pense que vous ne trouverez que une poignée d'exemples où des espaces dans une extension sont utilisés.
Je dirais, interdire les espaces dans des extensions. 999/1000 fois que l'utilisateur ne l'entend pas comme une extension.
Pour quote Wikipedia sur les noms de fichiers :
. (DOT): autorisé mais le dernier événement sera interprété comme le séparateur d'extension dans VMS, MS-DOS et Windows. Dans d'autres OSES, généralement considérées comme faisant partie du nom de fichier, et plus d'un arrêt complet peut être autorisé.
. est l'extension.
Merci d'avoir répondu à mes deux questions :)
L'extension sur un nom de fichier dans Windows est purement une convention. Le Lorsque vous dites "Windows le pense aussi", ce n'est vraiment que du code d'explorateur qui tente d'analyser les extensions, et il utilise simplement un algorithme légèrement différent de celui. getextension et HASExtension Ne cherchez qu'un point dans le nom de fichier et agissez en conséquence. Vous êtes libre de mettre des espaces partout où vous aimez dans le nom de fichier (y compris l'extension).
D'accord, merci pour la réponse. D'un point de vue humain, considérez-vous qu'il est raisonnable d'assumer que l'utilisateur ne voulait probablement pas que ce soit une extension s'il a un espace dedans?
Vous pouvez facilement imaginer que personne ne créerait un programme qui utilise des extensions avec des espaces dans eux, de sorte que tout espace d'extension doit signifier que ce n'est pas une extension.
Comment le système de fichiers traite les noms et la manière dont les noms de fichiers Windows Shell (I.E. Explorer) sont deux bêtes complètement différentes.
Le système de fichiers ne se soucie pas des espaces, des points ou de quoi que ce soit d'autre, le nom de fichier n'est qu'une chaîne opaque (avec quelques restrictions sur les caractères autorisés). La séparation Nom / extension n'est qu'une convention maquillée. La coquille, d'autre part, est libre de constituer sa propre interprétation de quelle extension est que son objectif n'est pas de stocker et de récupérer des informations de fichier, mais plutôt de fournir à l'utilisateur une meilleure expérience. Alors n'allez pas regarder là-bas pour des réponses.
Je suggérerais d'aller avec ce que le rendement system.io Les méthodes (car après la convention est bonne), mais vous pouvez faire ce que vous préférez dans votre code s'il y a une bonne raison pour cela. < / p>
"Le système de fichiers ne se soucie pas des espaces, des points" - ce n'est-ce pas vrai ... Créez des fichiers se terminant par DOT ou SPACE (vous pouvez le faire avec Cygwin, par exemple) et voir comment le système les gère. (Mieux vaut faire cela sur une FS que vous ne vous souciez pas de.) Et c'est une question d'ingénierie humaine. Windows Explorer est la manière dont la plupart des utilisateurs interagissent avec le système et que ses bizarreries doivent être comptabilisées.
@Jimbalter imo Les bizarreries de Windows Explorer ne doivent être comptabilisés que dans les réponses aux questions de dépassement de pile marquées en conséquence (que celle-ci n'est pas, et en outre, le code qu'il contient est clairement une affaire C # /. NET).
UM, la question concerne les utilisateurs de Windows et ce que "Windows pense", qui lors de la lecture minutieuse de la question est en fait sur ce que Windows Explorer affiche comme type de fichier. L'OP a voulu savoir sur le caractère raisonnable de l'écriture de code .NET qui agit de la même manière. Et je n'ai pas commenté ce qui devrait être "comptabilisé dans les réponses", ce que les faits sont, alors je trouve que votre réponse soit une paille non pertinente. Je ne répondrai pas plus loin.
Je suis capable de créer un fichier
ceci est un fichier. Pas une extension à l'aide de Windows 7 et de Windows XP. IFaites un clic droit sur le bureau, le nouveau document texte pour créer le fichier. Ou parlez-vous de créer le fichier en utilisant .net?@THOMAS Je peux créer ces fichiers avec .NET ou avec Windows 7. Mon point est que Windows ne reconnaît pas le ". Pas une extension" comme poste de fichier, alors que .NET le fait.
Aucune de vos revendications de ce que "Windows ne pense" est soutenu par des preuves ou des exemples.Les fonctions .NET suivent la pratique standard - les caractères suivant le dernier
. dans le dernier segment d'un chemin est l'extension. . Faire quelque chose de différent si des espaces se produisent après le. est un travail supplémentaire sans bonne raison. Aussi, pour votre cas d'utilisation, il n'est pas nécessaire de faire la distinction - si le nom de fichier a déjà l'extension appropriée au type de contenu, alors ne faites rien, sinon ajoute l'extension appropriée ... c'est mieux que remplaçant L'extension existante, qui pourrait ne pas être réellement une.Pour ce qui est "OK" ... Quoi que vous fassiez, c'est bien tant que vous Documentez-le , afin que vos utilisateurs sachent comment leur entrée sera manipulée.