Le problème
Récemment, un collègue nous rapporte le cas suivant : un flux Switch génère des dossiers automatiquement via le configurateur « Hiérarchie des archives ». Jusqu’ici rien d’inhabituel mais quelque chose cloche. Voilà que deux dossiers sont créés et chacun portent exactement le même nom ! Normalement cela est impossible, tout OS digne de ce nom ne vous permettra pas de créer plusieurs dossiers ou fichiers au nom similaire. Alors quoi, notre ami venait-il tout juste de créer un glitch dans la matrice ?

Passé l’effet de surprise, la réponse est évidente…non ! Il n’y a pas ici deux dossiers portant le même nom contre toute évidence. Même si un accès via terminal semble confirmer cette impression…

Encodage de caractères
Tout ceci n’est que trompe-l’oeil. Aussi vrai qu’une loi de science dure, il est impossible d’avoir deux dossiers ou fichiers aux noms identiques. La réponse est donc toute trouvée, ces deux éléments n’ont tout simplement pas le même nom ! C’est parti pour les 7 erreurs.
Le problème pourrait être tout simplement des caractères d’espaces excédentaires. Disons que le premier dossier s’appellerait « Travaux » et le deuxième « Travaux » (soient deux espaces après le mot Travaux). Mais dans notre cas, rien d’apparent ?! Pour aller plus loin, il faut s’intéresser au contenu de la chaîne de caractères et à son encodage.

La sélection du nom du dossier ne révèle pas d’espaces excédentaires…a priori
Si l’on extrait le code hexadécimal de nos deux noms de dossiers, on s’aperçoit immédiatement d’un différentiel. Le premier dossier est codé sous la forme « 457420766F696C61CC80 » quand le deuxième est codé sous la forme « 457420766F696C61CC80E2808B ». On repère donc qu’au moins un caractère s’est glissé négligemment dans notre nom de dossier. Or l’analyse du code « E2808B » trahit le complot. En effet, il s’agit ici du code pour le caractère « Zero-Width-Space » que l’on traduira par « Espace de largeur nulle ».

Voilà pourquoi la sélection manuelle des noms de dossiers ne semblait rien révéler a priori. De quoi rendre chèvre bien des opérateurs et la situation peut devenir encore plus amusante si vous travaillez avec des serveurs NAS et des collaborateurs utilisant des OS différents. Si l’Unicode devient aujourd’hui la norme pour les systèmes d’exploitation, vous pourriez bien un jour disposer d’un outil utilisant un autre encodage comme ANSI par exemple.
De fait un caractère aussi innocent que le « e accent aigu » (é) pourrait bien vous surprendre. Mais avant d’aller plus loin, il faut déjà comprendre la différence entre un glyphe et un caractère. Un glyphe est une forme abstraite et peut constituer tout ou partie d’un caractère ou de plusieurs caractères (cas des ligatures). Dans le cas du « é », nous n’avons pas un mais deux glyphes dont le « e » de base et le caractère d’accentuation (diacritique).
Une fois cela dit, l’Unicode précise que le caractère accentué pourra être spécifié selon sa forme « rassemblée » (\u00E9 => é) ou precomposée (\u0065\u00B4 => e+´). In extenso, si un système génère un dossier avec un encodage X et qu’un autre utilise un encodage Y, vous pourriez bien avoir deux dossiers de même nom tout simplement car leurs noms ne seront pas encodés de la même façon !

Quelle solution donc ?
Si vous devez générer des dossiers via des systèmes automatisés au travers de systèmes et collaborateurs utilisant des OS et des outils différents, nous ne pouvons que vous conseiller d’éviter l’utilisation de caractères accentués. Même si cela fait mal à son Molière, rappelons-nous que l’informatique est d’abord une création anglo-saxonne.
Et si malgré tout, vous continuiez à constater la survenue de dossiers et fichiers identiquement nommés, intéressez-vous à l’encodage des caractères. Nous l’avons dit, la loi est inviolable et aucun OS ne vous permettra de créer de telles chimères.
Décidément, malgré toutes vos précautions, rien ne semble expliquer vos problèmes ? N’hésitez pas à nous contacter pour une étude sur-mesure.
Photo by Markus Spiske on Unsplash