Il est souvent pratique de nommer les fichiers et les dossiers avec une date et une heure, comme le standard ISO 8601 format : 2014-12-10T22:35:28.460Z .
Malheureusement, le Mac Système de fichiers HFS utilise le COLON comme séparateur de chemin tout comme les OS de type Unix utilisent SOLIDUS / (barre oblique) et les systèmes d'exploitation Microsoft utilisent REVERSE SOLIDUS \ (barre oblique inversée). Ces trois caractères doivent être évités lorsque vous nommez un fichier ou un dossier pour des raisons de compatibilité.
Quel caractère pourrait être couramment utilisé pour remplacer le COLON ?
- Utilisation d'un HYPHEN
-rend difficile l'inversion programmatique de la conversion au format standard. - De même, l'utilisation d'un FULL STOP
.(période) rend la conversion inverse difficile car elles seront interprétées à tort comme des fractions de seconde.
Par exemple, lors de la programmation en Java 8 sur OS X Mountain Lion, l'appel à File::mkdir() pour la chaîne 2014-12-11T21:33:08 donne lieu à un dossier nommé 2014-12-11T21/33/08 .
3 votes
Pratiquement tous les systèmes de fichiers modernes prennent en charge les espaces dans les noms de fichiers. En outre, si la lisibilité n'est pas un problème, pourquoi ne pas éliminer les caractères incriminés et utiliser un format fixe, par exemple:YYYYMMDDTHHMMSSZ.
0 votes
Pourquoi ne pas utiliser le : qui semble fonctionner correctement à partir du shell. Je soupçonne que seuls les OS<=9 et classic ont un problème avec :, c'est donc un problème actuel. AL:pour que les systèmes d'exploitation MS puissent utiliser / comme division de répertoire
0 votes
@Mark Les versions modernes du Finder peuvent gérer les deux points. Mais lors d'un accès programmé, des problèmes surviennent.
0 votes
Je n'ai jamais eu de problème pour accéder à un fichier dont le nom comporte deux points. C'est juste bizarre dans le Finder, puisqu'il a été remplacé par une barre oblique.
2 votes
Plus précisément, HFS+ permet aux noms de fichiers de contenir / mais pas les deux points. Dans Terminal (ou partout où l'on accède au système de fichiers en utilisant l'API POSIX au lieu de l'API Macintosh), le / du nom tel qu'il est stocké sur le disque est traduit en : dans la RAM, et le : dans la RAM est à nouveau traduit en / lorsqu'un nouveau nom de fichier est stocké dans le catalogue. Les programmes utilisant l'API Macintosh traditionnelle ne sont pas affectés et voient le / tel qu'il apparaît sur le disque. De cette manière, chaque API ne dispose que d'un seul caractère interdit (enfin, deux si l'on compte NUL) et d'un seul séparateur de nom de fichier, sans interférer l'un avec l'autre.
0 votes
@BasilBourque quel accès à la programmation utilisez-vous ?
0 votes
@Mark Je programme en Java et en Objective-C. Voir la question mise à jour.