Si c’est « l’ordre alphabétique », alors ça devrait vraiment vouloir dire « l’ordre alphabétique »

• En voulant trier des fichiers photo par ordre alphabétique, l’auteur a constaté que le système d’exploitation et le gestionnaire de fichiers n’obtenaient pas le même résultat de tri
• Dans ls sous Linux, le tri se fait correctement, mais la plupart des gestionnaires de fichiers GUI comme Windows, Google Drive ou KDE Dolphin appliquent un « tri naturel » (natural sort) qui interprète numériquement les noms de fichiers contenant des chiffres
• Cela produit donc des résultats différents du tri lexicographique traditionnel, par exemple file-10.txt peut se retrouver avant file-9.txt
• La véritable cause du problème était que les deux téléphones utilisaient des conventions de nommage différentes : l’un ajoutait directement les millisecondes après les secondes, tandis que l’autre les séparait par un underscore
• Au final, la seule solution est d’uniformiser la convention de nommage des fichiers ou de modifier les réglages cachés de chaque gestionnaire de fichiers ; l’auteur regrette une époque où « les ordinateurs exécutaient les instructions de l’utilisateur au lieu de privilégier leurs suppositions »

---

Contexte et situation du problème

• L’auteur faisait une randonnée avec son père, chacun prenant des photos avec son téléphone Android, puis toutes les photos ont été placées dans un même dossier
• La convention des noms de fichiers photo était IMG_YYYYMMDD_HHmmss ou cette chaîne suivie de chiffres supplémentaires puis de .jpg
• Comme ce format encode l’année, le mois, le jour et l’heure dans cet ordre, il semblait logique que trier les fichiers par ordre alphabétique (lexicographique) les classe aussi par heure de prise de vue
• En utilisant un PC Windows, Google Drive, KDE Dolphin, etc., les fichiers suivant pourtant la même convention n’étaient pas triés dans le bon ordre
  • Exemple : une photo prise à 5:54 avec le téléphone du père apparaissait avant une photo de 9:20, puis se retrouvait après une photo de 12:11, bref l’ordre était incorrect
• Gnome et d’autres gestionnaires de fichiers sur smartphone donnaient le même résultat
• La commande ls sous Linux, elle, conservait l’ordre attendu, ce qui renforçait la confusion

Analyse de la cause

• Au départ, l’auteur pensait que l’un des deux téléphones utilisait un caractère étrange à la place de l’underscore (_), mais une vérification avec la commande Linux ls montrait un tri normal
• Sur différentes distributions Linux ainsi que sur un serveur OpenBSD, ls triait bien par ordre alphabétique
• En revanche, de nombreux gestionnaires de fichiers GUI (Windows, Google Drive, KDE Dolphin, etc.) comparent la valeur réelle des nombres lorsqu’un nom de fichier contient des chiffres
  • Ils appliquent donc par défaut un tri naturel (natural sorting) plutôt qu’un tri alphabétique strict
• Le tri naturel compare les chiffres présents dans une chaîne comme des valeurs numériques, et non comme de simples caractères
  • Exemple : file-9.txt < file-10.txt → l’ordre que les humains attendent généralement
  • Mais dans un tri traditionnel, 1 < 9, donc file-10.txt passe avant file-9.txt
• Pourtant, les gestionnaires de fichiers actuels, dès qu’ils détectent une « partie numérique », forcent un tri selon la valeur réelle de ce nombre, plaçant 9 avant 10
  • Ce comportement peut donc contredire l’ordre voulu par la personne qui a créé les noms de fichiers

Véritable cause du problème et solution

• Le téléphone du père ajoutait les millisecondes directement après les secondes, tandis que celui de l’auteur les séparait par un underscore
  • Téléphone du père : millisecondes collées juste après les secondes → le nombre devient plus grand et est repoussé plus loin dans le tri
  • Téléphone de l’auteur : séparation par underscore → traité comme une autre sous-chaîne
• Solution : renommer les fichiers d’un des deux appareils selon un motif cohérent permet de régler le problème
• Dans le cas de KDE Dolphin, il est possible de choisir un tri purement alphabétique dans les options, mais le réglage est caché, ce qui le rend peu pratique
• Comme les fonctionnalités varient selon les logiciels, il peut être nécessaire de configurer chaque programme séparément

Conclusion de l’auteur

• L’auteur critique le fait que, même lorsqu’on demande un « ordre alphabétique », le logiciel tente d’interpréter l’intention de l’utilisateur et applique un autre type de tri
• Il regrette la simplicité d’autrefois, quand les ordinateurs se contentaient d’exécuter exactement ce qu’on leur demandait

[GN⁺]

Avis Hacker News

• Je pense que le mode de tri adopté par Microsoft, Google et KDE couvre des cas plus intuitifs et plus courants, et que la situation de l’auteur est extrêmement rare ; la plupart des gens veulent bien plus souvent que « 10 » arrive après « 9 », les environnements de bureau parlent d’un tri « par nom » et non « alphabétique », donc il n’y a pas de malentendu ; je n’aime pas trop quand l’ordinateur essaie de deviner l’intention, mais comme la sauvegarde automatique ce genre de chose est utile dans la vie réelle ; ce serait bien d’avoir aussi une vraie option de tri alphabétique strict, mais par défaut il est logique que le cas général le plus intuitif prime

  • Moi aussi, je suis assez intelligent pour comprendre parfaitement que « 10 » vient avant « 9 » en ordre alphabétique, mais dans un gestionnaire de fichiers je veux que « 10 » vienne après « 9 », je n’ai pas envie d’ajouter un 0 devant les nombres à un chiffre, et si plus tard il faut passer à trois chiffres, renommer à nouveau est pénible ; pour des fichiers d’audiobooks découpés par chapitres, en tenant compte du fait que tous les lecteurs ne trient pas correctement, j’utilise des formats comme « Chapter 01.mp3 » ou « Chapter 001.mp3 », j’ai même écrit un script d’automatisation, mais ce n’est toujours pas très joli et c’est du travail inutile ; ce serait vraiment mieux si tous les appareils reconnaissaient correctement les nombres
  • Je ne suis pas d’accord ; s’il n’existait qu’une seule manière universelle de représenter les nombres sous forme de texte, je pourrais l’accepter, mais comme il y a beaucoup de variantes dans la saisie des nombres, je pense que la fonction de « lecture d’intention » ne marche correctement que dans certains cas ; les décimales, séparateurs de milliers, notations scientifiques, etc. introduisent des exceptions complexes, et dès qu’on regarde les exigences de près on voit que c’est difficile à implémenter de manière fiable
  • Je trouve irréaliste de prétendre que préfixer les nombres par des zéros est naturel et habituel pour les gens ; par exemple, quand une version passe de 5.9.17 à 5.10.0, personne ne renomme tous les anciens dossiers en 5.09.17 ; aujourd’hui le mode de tri standard n’est ni ambigu ni contre-intuitif, alors qu’un tri strictement lexicographique ne convient pas à une interface utilisateur
  • Le problème, c’est que ce changement diffère de l’ancien tri alphabétique « bête », ce qui surprend et déroute les gens ; il aurait mieux valu proposer séparément le mode « intelligent » voulu par la majorité et le mode « alphabétique strict » ; si l’option était présentée simplement et clairement, même les non-spécialistes n’auraient pas une expérience confuse
  • Tu dis que les cas où l’on veut que « 10 » vienne avant « 9 » sont plus fréquents, mais tu voulais probablement dire l’inverse ; et pour information, le nom officiel du tri « par nom » est « Natural sort order »

• Ce sujet me rappelle le débat « Worse is better » ; le mode de tri simple basé sur ANSI/Unicode demandé par l’auteur est au contraire une fonction dont seule une minorité de développeurs a besoin ; en pratique, 99 % des utilisateurs de GUI veulent un tri intuitif ; identifier l’utilisateur principal a un impact énorme sur la conception d’un produit ; une fonction plus avancée peut convenir à un produit, mais pour un système la simplicité peut être plus adaptée à la croissance et à l’évolution

  • Le modèle mental du développeur consiste à traiter naïvement les noms contenant des nombres mêlés au texte, alors que l’utilisateur ordinaire trouve naturel que 10 vienne après 9 ; il ne faut pas imposer à tout le monde le mode de pensée propre aux développeurs
  • J’aimerais savoir ce que pense la personne qui réclame une approche « moins bonne » du tri des majuscules/minuscules : faut-il vraiment suivre l’ordre des code points ASCII/Unicode, ou bien normaliser en un seul caractère pour regrouper les variantes de casse ?
  • Prétendre qu’on n’ajoute pas d’option à cause de la « cible utilisateur » n’est pas convaincant ; proposer les deux approches n’a rien de difficile ; un logiciel vraiment meilleur est celui qui sait accueillir des besoins variés, quitte à placer cela dans un mode avancé ; même dans une logique 80/20, certaines fonctions peu utilisées restent nécessaires ; je suis lassé de voir des fonctions évidentes disparaître au nom d’une vision parfaite de l’utilisateur

• Le tri automatique est ce qu’il y a de plus agaçant quand on cherche des fichiers nommés avec des hash ; sous Windows, c’est l’une des rares options que je désactive immédiatement via le registre ; il me manque souvent l’époque où l’ordinateur faisait simplement ce qu’on lui demandait ; aujourd’hui j’ai l’impression qu’il ne cherche plus seulement à « lire dans l’esprit de l’utilisateur », mais à changer sa façon de penser, et ça me rebute ; même dans l’open source, je n’aime pas cette mentalité autoritaire qui dit que « l’utilisateur a tort »

  • Le problème n’est pas limité aux hash simples ; cela devient encore plus confus avec divers identifiants contenant au milieu des nombres sans signification ; quand il faut retrouver un fichier avec des blocs numériques dans un ID utilisateur, un timestamp Unix, etc., voir des noms comme abcd89764237 et abcd683426834 placés à des endroits manifestement étranges fait perdre du temps avant de comprendre pourquoi

• Puisque tout le monde prétend connaître les besoins de l’utilisateur moyen, je me demande pourquoi personne ne propose que l’ordinateur modifie aussi automatiquement les noms de fichiers eux-mêmes à sa guise ; si on ne veut pas imposer le tri ASCII, rien n’oblige non plus à rester attaché aux noms incluant une extension ; en réalité, l’utilisateur ne se soucie pas des extensions jpg ou png, ni de la casse ; c’est surtout dans l’univers Windows que les extensions ont longtemps été utilisées pour des raisons de compatibilité ancienne ; on impose des « noms de fichiers à la manière des ordinateurs », alors pourquoi s’acharner uniquement à casser le « tri à la manière des ordinateurs » ? Comme on ne peut pas savoir avec certitude ce que veulent les utilisateurs, il ne faut pas l’affirmer trop vite

• Personnellement, je préfère dans la plupart des cas le tri basé sur les versions décrit dans l’article ; voir un affichage en ordre alphabétique me donne presque l’impression d’un bug ; pour moi, le problème n’est pas le concept de tri, mais l’étiquetage

  • En réalité, ce n’est pas présenté comme « alphabétique » ; l’auteur a confondu « tri par nom » et « tri alphabétique »
  • Le comportement décrit est utile, mais la bonne solution serait d’en informer l’utilisateur à l’avance ou de lui laisser choisir une option
  • La commande sort de Linux prend aussi en charge aujourd’hui le tri par version (sort -V) ; je ne connais pas son fonctionnement interne, mais dans la plupart des situations cela marche bien, et surtout on peut l’activer ou le désactiver facilement
  • Le mode de tri mentionné dans l’article est « lexical », mais les gens ne connaissent généralement pas la différence entre « lexical » et « alphabetic »

• On ne donne pas l’ordre de trier les fichiers « alphabétiquement », on demande un tri « par nom », donc l’interprétation peut varier selon l’OS ; je pense qu’ils ont choisi, sur la base de la logique et des données, l’interprétation la plus adaptée pour la majorité des utilisateurs ; peut-être qu’à l’avenir on ajoutera une règle du type « s’il y a des 0 dans les groupes de chiffres, on revient au vrai ordre alphabétique », ou peut-être une option de choix utilisateur

  • S’il y a un 0 devant un nombre et qu’on le considère comme de l’octal, avec fonctionnement seulement si les chiffres suivants sont entre 0 et 7, ce serait intuitif
  • Mais ce changement d’interprétation date déjà de 10 à 20 ans ; auparavant, dans les gestionnaires de fichiers, « tri par nom » signifiait bien « ordre alphabétique/lexicographique »

• Dans macOS Foundation, NSString.localizedStandardCompare() est officiellement fourni pour le tri de Finder ; Windows fournit aussi StrCompareLogical, autrement dit chaque plateforme formalise officiellement le tri par nom, c’est-à-dire le tri naturel

  • Je trouvais intéressant que ce soit différent de la commande ls, et maintenant j’en suis venu à penser que cette approche est meilleure ; dans une app photo, on trie généralement par horodatage, et si un fichier a vraiment besoin d’un tri strict par nom, je trierais plutôt par date de création ou je normaliserais directement le nom du fichier

• Un rapport Unicode mentionne clairement que selon la langue, la méthode de tri varie avec le contexte ; par exemple, si l’on trie « A-10 » alphabétiquement sans reconnaître le nombre, « A-10 » arrive avant « A-2 » ; c’est complexe, mais je pense que c’est précisément pour cette raison que les navigateurs de fichiers ont choisi le tri naturel

  • Mais comme -10 est inférieur à -2, ne devrait-on pas obtenir l’ordre inverse ?

• Trier de façon à ce que « foo9 » vienne avant « foo10 », c’est du « natural sort » ; j’ai récemment découvert une manière de faire du tri naturel en deux lignes de Python, et j’en suis très content ; je recommande ce code Stack Overflow

  • La commande sort(1) prend aussi en charge le tri naturel (-V) ; si on crée des fichiers image et qu’on les trie avec ls | sort -V, cela fonctionne correctement ; on peut aussi trier la sortie de du -sh * avec l’option sort -h

• Ce tri où l’on obtient quelque chose comme « Image-1.jpg, Image-11.jpg, Image-2.jpg » ne me manque pas ; je me souviens qu’au début le tri naturel me paraissait étrange, mais quand Windows est passé à un tri par valeur numérique, c’est devenu vraiment pratique ; les fichiers se mettaient dans un ordre naturel, et j’en étais très satisfait

  • Mais pour certaines personnes, cet ordre correspond justement à ce qu’elles attendent, donc cela dépend de chacun