./4652 > Je vais répondre à la place de Zerosquare, mais en gros l'UTF-8 est vendu comme un moyen de transporter de l'Unicode là où l'ASCII étendu (8 bits) est autorisé, sans avoir besoin d'adapter les applications de transport de flux, contrairement à UTF-16 ou UTF-32 qui introduiraient des zéro dans le flux. (J'imagine que tu sais déjà tout ça, mais bon)

(Fausse bonne idée) C'est génial pour tous les scripts utilitaires unix qui fonctionnent avec des chaînes binaires 8 bits terminées par un zéro, parce que du coup tu n'as pas besoin de les mettre à jour pour supporter ce nouvel encodage. (risque élevé d'ajouter de nouveaux bugs) Donc tout marche déjà sans que tu n'aies rien à faire… !

Sauf qu'en pratique, et à part quelques exceptions, les applications ont toujours — un peu, ou même beaucoup — besoin de comprendre ce qui transite par elles. Et c'est là que toute la logique tombe à l'eau.
Tu finis tôt ou tard par devoir corriger chaque application pour ajouter un support explicite UTF-8. (Mais le plus tard possible parce qu'on a vraiment pas envie de le faire… ^^)

Au final tu as juste fonctionné pendant des années avec un support partiel et bogué de la chose sans t'en préoccuper, ce qui ne signifie pas pour autant que des utilisateurs ça et là n'aient pas été incommodés par la chose; mais tu n'en avais rien à foutre, donc ils essayaient de contourner les problèmes, par exemple en évitant de mettre des accents "parce que ça pose des problèmes"… (Parfait exemple de non-solution)

À titre d'exemple tout con, un shell comme bash, zsh, ou autre, si codé sans support spécifique UTF-8, ne va pas comprendre ce qui lui arrive en recevant certaines séquences de caractères UTF-8 à partir du [driver du] clavier… Inutile de mentionner que l'expérience utilisateur est alors complètement à chier… (Je ne mentionne pas ça au hasard…)


(Y'a souvent le même genre de problème avec les espaces dans les noms de fichiers aussi… On va te répondre "ben ne mets pas d'espace ! ", et là tu te diras "belle mentalité !" )