Je recherche un personnage pour utiliser un nom de fichier de fichier de fichier (je stocke plusieurs noms de fichiers dans une chaîne plainte). Windows semble ne pas autoriser : code>,
? Code>,
* code>,
<< / code>, code>,
" code>,
| code>,
/ code> et
\ code> dans les noms de fichiers. Évidemment,
\ code> et < code> / code> ne peut pas être utilisé, car ils signifient quelque chose sur un chemin. Y a-t-il une raison pour que l'une de ces autres ne devait pas être utilisée? Je pense juste que, semblable à
/ < / code> ou
\ code>, ces autres caractères non autorisés peuvent avoir une signification particulière que je ne devrais pas supposer ne sera pas dans les noms de chemin. de ces 7 autres caractères, sont définitivement sûrs ou sans danger à utiliser à cette fin? p>
6 Réponses :
Il est réellement possible de créer des fichiers em> de manière programmatique avec chaque caractère possible, sauf Qu'est-ce que vous utilisiez pour déterminer les fenêtres de caractères permettant à Windows? p>
mise à jour: l'ensemble des caractères autorisés par Windows est également déterminé par le système de fichiers sous-jacents et d'autres facteurs. Il y a un qui explique cela plus en détail. P> \ code>. (Au moins, c'était vrai à la fois et il est possible que Windows ait changé sa politique depuis.) Naturellement, les fichiers contenant certains caractères seront plus difficiles à travailler avec des autres. P>
Si vous essayez de renommer un fichier dans Windows Explorer, il appartient à cette liste et vous empêche de le faire. Je viens d'assumer que c'était comme ça à un niveau fondamental - mais vous dites que ce n'est pas le cas?
Il y a beaucoup de couches sous l'explorateur. :) J'ai mis à jour ma réponse avec plus d'informations.
Ne: Séparer un fichier en différentes fourches ... Nom: texte, nom: données, etc.? Et comment obtenez-vous une barre oblique dans un nom de fichier sous Windows? Je suis sous l'illusion qu'elle traite de la barre obliqueque et de la barre oblique inverse comme équivalent au niveau de l'appel du système.
Les flux de données alternatifs NTFS sont (sans surprise) une fonctionnalité NTFS. L'ensemble valide de caractères dans les noms de fichiers sur Windows dépend du système de fichiers et du sous-système sous-jacent i>. Je soupçonne que vous pouvez créer un fichier avec un : code> dans le nom à l'aide du sous-système POSIX.
Les caractères Les charactes Les caractères Le caractère Je choisirais le caractère de tuyau pour séparer les noms de fichiers. Il n'est pas utilisé dans les chemins et sa forme a une qualité de séparation naturelle. P>
Une alternative pourrait être d'utiliser XML dans la chaîne. Il y a un peu de frais généraux et certains caractères ont besoin d'un codage, mais l'avantage est qu'il peut gérer tous les caractères et le format est explicatif et bien défini. P> : code> et
" code> sont également utilisés dans les chemins. Colon est le délimiteur d'unité d'entraînement et les guillemets sont utilisés lorsque des espaces font partie d'un dossier ou d'un nom de fichier . p>
* code> et
? code> sont utilisés comme caractères génériques lors de la recherche de fichiers. p>
<< / code> et
> code> sont utilisés pour rediriger l'entrée et la sortie d'une application vers et depuis un fichier. P>
| code> est utilisé pour la sortie de la tuyauterie d'une application en entrée d'une autre application. P>
" code> n'est pas autorisé dans un chemin: il est considéré comme un délimiteur qui entoure un chemin lorsqu'il contient des caractères spéciaux, mais cela ne fait pas partie du chemin.
@Adrien: C'est certainement. Il peut être utilisé autour de tout le chemin ou autour d'un élément dans un chemin, comme C: \ "Fichiers du programme" \ Adobe.
@guffa: J'insiste, n'est pas. Les doubles qoutes sont utilisées comme moyen pour échapper à un caractère spécial, des espaces à préciser. Ils sont particulièrement interprétés par Windows Shell et Invite de commande, mais ne font pas partie du nom de fichier. Pouvez-vous me montrer un moyen de créer un fichier dont le nom contient des guillemets doubles, à l'aide de l'invite de commande ou de l'API Windows?
@Adrien: Un nom de fichier ne contient pas de marques de quoation, et je n'ai jamais dit qu'ils le font. Un chemin peut contenir des guillemets utilisés pour spécifier les composants du trajet, tout comme le colon et les backslashes sont utilisés dans un chemin d'accès pour séparer les composants, bien qu'un nom de fichier ne contienne jamais de côlon ou d'une barre oblique inverse.
Eh bien, désolé pour l'obstination, je n'y ai jamais pensé de cette façon, mais vous avez vraiment raison.
NTFS utilise également : code> pour les flux.
Pourquoi n'utilisez-vous aucun caractère avec une combinaison de touches Alt comme ‡ (alt + 0135) comme délimiteur? p>
C'est un caractère légal des noms de fichiers et ne peut être utilisé comme séparateur pour cette raison.
J'ai utilisé * code> dans le passé. La raison de la portabilité à Linux / Unix. True, techniquement, il peut également être utilisé sur ces fichiersysystems. En pratique, tous les systèmes d'exploitation courants l'utilisent comme une faute générique, c'est donc assez rare dans les noms de fichiers. En outre, les personnes ne sont pas surprises si les programmes rompent lorsque vous mettez un
* code> dans un nom de fichier. P>
Windows utilise le point-virgule sous forme de nom de fichier de fichier de fichier: (aussi, en python, le ; code>. Regardez la variable d'environnement de chemin, elle est remplie de
; code> entre les éléments de chemin. p>
os.path.pathsep code> renvoie
";" code>, alors qu'il se développe à
" code> sur UNIX ) p>
Etrange, cependant, que je puisse créer des fichiers avec des points-virgules.
c'est étrange, mais c'est comme ça que c'est ... lorsque vous ajoutez un chemin qui contient un ";" au% de path%, le chemin ajouté est entouré de " code> (qui n'est pas autorisé dans un Chemin). Peut-être qu'ils entourent des noms de fichiers avec
" code> et les séparant avec
; code> est votre solution.
Si vous entourez les noms de fichiers avec " code>, vous pouvez utiliser presque tout autre caractère comme délimiteur, tel qu'une virgule de la virgule. Ensuite, vous pouvez utiliser une routine de lecture CSV commune pour analyser la chaîne dans un tableau.
Si tout ce dont vous avez besoin est l'apparence em> d'un côlon et la créera de manière programmative, pourquoi ne pas utiliser de caractère UTF-8 qui juste a l'air em> comme un Colon? P>
Mon premier choix serait la lettre de modificateur (U + A789), car il s'agit d'un caractère typique de RTL et apparaît beaucoup comme un côlon. C'est ce que j'utilise lorsque j'ai besoin d'une date d'heure complète dans le nom de fichier, tel que Je resterais à l'écart des personnages comme la ponctuation hébreuse SOD PASUQ (U + 05C3), car il s'agit d'un caractère LTR et peut gâcher comment un système aligne le nom de fichier lui-même. P> file_2017-05-04_16꞉45꞉22_clientno.jpg code> p>
Pourquoi créer des problèmes pour vous-même? Allez avec les communs, comme Dash "-" ou des points "."
La mauvaise nouvelle est la suivante: sur de nombreux systèmes UNIX, le seul caractère qui n'est pas autorisé dans un nom de fichier est "/". Tous les autres sont valables (bien qu'ils puissent avoir besoin de s'échapper pour les cacher de la coquille par exemple).
Vous pouvez utiliser '/' dans les chemins UNIX (mais si vous faites cela, vous êtes Satan). À peu près la seule chose que vous ne pouvez pas utiliser est null.