Tout récemment j’ai assisté à un grave accident de communication par Dropbox entre Windows et OS-X : une dame sous Windows dépose sur un partage Dropbox une feuille Excel avec un nom à coucher dehors, le monsieur sous OS-X qui devait agir en fonction des données n’a jamais pu ouvrir le fichier, tout le monde s’est agité jusqu’à ce qu’un malin remarque les crochets carrés dans le nom du fichier, acceptés sans sourciller par Windows, rejetés par OS-X.
Les documents informatiques que tout un chacun crée avec son traitement de texte [1] ou son tableur doivent recevoir des noms pour être enregistrés. Il est tentant de donner à chaque document un nom qui exprime clairement sa teneur. L’habitude s’est ainsi prise de donner des noms assez longs qui sont parfois des phrases entières. Malheureusement cette habitude peut causer des catastrophes.
Pour que le nom d’un document, comme d’ailleurs tout autre texte, puisse être enregistré dans la mémoire ou sur le disque dur d’un ordinateur, il doit être codé selon certaines conventions. L’établissement de ces conventions a donné lieu (et continue à donner lieu) à d’âpres controverses, et tous les systèmes informatiques, tous les logiciels n’obéissent pas aux mêmes règles, même si la diversité a beaucoup reculé depuis une quinzaine d’années. Il existe depuis 1991 une norme internationale, Unicode, qui permet de désigner tous les caractères de toutes les écritures passées ou présentes, des hiéroglyphes aux sinogrammes. Mais désigner un caractère ne détermine pas la façon de le représenter dans l’ordinateur, et là c’est encore un peu la tour de Babel. Le codage UTF-8, qui est une horreur de complication, s’est imposé de façon majoritaire, mais pas universelle (78 % des sites Web en 2013).
Lorsqu’un document est enregistré dans un système et que l’on tente de le relire dans un système qui utilise un autre codage, par exemple Windows et OS-X, on peut avoir des caractères qui apparaissent sous une forme inattendue, ce qui peut le rendre illisible. Mais si la différence de codage porte sur le nom du fichier, c’est encore plus gênant, et la plupart du temps le fichier est illisible. Il m’est arrivé ainsi, avant la convergence UTF-8, de perdre sans recours plusieurs centaines de fichiers d’un seul coup en essayant de les transférer de Windows à Linux [2].
Pour éviter de tels incidents dramatiques, il existe une norme Posix des caractères autorisés dans les noms de fichiers, et il FAUT la respecter. En voici le passage le plus important :
"The set of characters from which portable filenames are constructed.
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 . _ -
The last three characters are the period, underscore, and hyphen characters, respectively."
On voit que sont notamment bannis les caractères composés (avec accents, cédilles, etc.), ainsi que les parenthèses, crochets carrés ou pointus, accolades, barres obliques à droite ou à gauche, esperluettes, virgules et autres signes de ponctuation hormis le point. L’espace est interdit en début et en fin, et de toute façon il est déconseillé parce qu’il est source de difficultés dès lors que l’on veut traiter les fichiers par un programme.
Respectez les règles Posix et tout ira mieux !