Sois-en remercié jusqu'à la neuvième bobine du dernier film qui passera dans mon smplayer !
Ainsi que pour ta dépêche, fort intéressante.
De rien. 🤗
J'avais pensé à un truc bien plus simple, du style « encodage de la config, mais utf-8 si le player détectait un unicode »
En fait c'est ce que la plupart des logiciels faisaient (et que beaucoup font encore).
Le premier point (codage de la config par défaut) fonctionne dans un monde où on s'échange jamais de fichiers entre personnes (et donc on crée nos propres fichiers et on ne travaille jamais que sur ceux-ci). Mais la réalité est toute autre: en vrai, on s'échange constamment des fichiers (et cette tendance a été décuplée avec internet). Et même le cas du "on crée nos propres fichiers" reste imparfait. Les machines et OS ont évolué, les codages par défaut aussi. Je dois avouer ne plus bien me souvenir des locales par défaut dans nos Linux, y a 20 ans, mais ça ne m'étonnerait pas plus que cela, si à l'époque, on avait des charset non-UTF-8 configurés par défaut dans nos systèmes en fonction de la langue qu'on configurait dans les préférences systèmes. Cela voudrait donc dire que si on essaie de relire nos vieux fichiers de l'époque (ceux sans métadonnées de charset), on aurait des problèmes de décodage.
D'ailleurs je viens de faire une recherche vite fait sur le web et trouve encore des documentations, genre du Linux Documentation Project, qui conseille aux francophones d'utiliser ISO-8859-15: https://tldp.org/HOWTO/Francophones-HOWTO-6.html
Donc même dans le cas hypothétique où on n'échangerait jamais de fichiers avec autrui, on pourrait se retrouver avec des décodages problématiques, juste parce qu'on met à jour son OS ou parce qu'on a plusieurs machines.
Pour le point sur la détection de UTF-8 (ou autre codage multi-octet), comme je dis dans l'article, cela reste relativement simple puisqu'il est très simple de tomber sur des cas invalides. En gros, on peut croire que se limiter au premier concept (détection de caractère invalide, autrement dit l'algorithme naïf) est suffisamment fiable au moins pour ce qui est de la détection de UTF-8. Néanmoins même cela n'est pas parfait. Contrairement à la détection des charsets mono-octets, j'ai encore un peu trop de faux positifs/négatifs à mon goût, liés à une mauvaise détection de UTF-8. C'est à dire, qu'avec uchardet 0.0.8, il m'arrive encore parfois que uchardet sorte UTF-8 par erreur avec un score légèrement meilleur que la bonne réponse (un codage mono-octet), comme il arrive à l'inverse qu'un codage mono-octet sorte en réponse erronée avec un score qui bat de très peu le score du codage UTF-8. Dans les 2 cas, la raison est parce que cette version d'uchardet a gardé la logique que pour UTF-8, la vérification naïve suffit (cette croyance vient de l'algorithme originel, de l'époque où c'était un code Mozilla). Mais ce n'est pas vrai et le score attribué avec cette étape seulement n'est simplement pas assez subtil, donc pas fiable.
Et ce sera une des grandes différences (parmi d'autres) avec uchardet 0.1.0: même pour UTF-8, il y aura maintenant de la détection statistique par langage. Cela rend malheureusement uchardet moins bon pour les langages non pris en charge, mais en même temps, pour tous les langages pris en charge, cela a tout simplement rendu l'outil d'autant plus fiable et efficace. Franchement c'est sans équivoque, avec mes récentes améliorations, je n'ai simplement plus de ce genre de faux positifs/négatifs dont je parlais plus haut.
Enfin bon, je suis déjà très fier des améliorations qu'on trouvera dans la version suivante. Je pense même qu'on va pouvoir améliorer plusieurs trucs pour rendre les résultats encore plus fiables (mais faut que je fasse plus de tests). 😊
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Ah, c'est grâce à toi...
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Sortie de uchardet 0.0.8 pour la détection de codages de caractères. Évalué à 7.
De rien. 🤗
En fait c'est ce que la plupart des logiciels faisaient (et que beaucoup font encore).
Le premier point (codage de la config par défaut) fonctionne dans un monde où on s'échange jamais de fichiers entre personnes (et donc on crée nos propres fichiers et on ne travaille jamais que sur ceux-ci). Mais la réalité est toute autre: en vrai, on s'échange constamment des fichiers (et cette tendance a été décuplée avec internet). Et même le cas du "on crée nos propres fichiers" reste imparfait. Les machines et OS ont évolué, les codages par défaut aussi. Je dois avouer ne plus bien me souvenir des locales par défaut dans nos Linux, y a 20 ans, mais ça ne m'étonnerait pas plus que cela, si à l'époque, on avait des charset non-UTF-8 configurés par défaut dans nos systèmes en fonction de la langue qu'on configurait dans les préférences systèmes. Cela voudrait donc dire que si on essaie de relire nos vieux fichiers de l'époque (ceux sans métadonnées de charset), on aurait des problèmes de décodage.
D'ailleurs je viens de faire une recherche vite fait sur le web et trouve encore des documentations, genre du Linux Documentation Project, qui conseille aux francophones d'utiliser ISO-8859-15: https://tldp.org/HOWTO/Francophones-HOWTO-6.html
Donc même dans le cas hypothétique où on n'échangerait jamais de fichiers avec autrui, on pourrait se retrouver avec des décodages problématiques, juste parce qu'on met à jour son OS ou parce qu'on a plusieurs machines.
Pour le point sur la détection de UTF-8 (ou autre codage multi-octet), comme je dis dans l'article, cela reste relativement simple puisqu'il est très simple de tomber sur des cas invalides. En gros, on peut croire que se limiter au premier concept (détection de caractère invalide, autrement dit l'algorithme naïf) est suffisamment fiable au moins pour ce qui est de la détection de UTF-8. Néanmoins même cela n'est pas parfait. Contrairement à la détection des charsets mono-octets, j'ai encore un peu trop de faux positifs/négatifs à mon goût, liés à une mauvaise détection de UTF-8. C'est à dire, qu'avec uchardet 0.0.8, il m'arrive encore parfois que uchardet sorte UTF-8 par erreur avec un score légèrement meilleur que la bonne réponse (un codage mono-octet), comme il arrive à l'inverse qu'un codage mono-octet sorte en réponse erronée avec un score qui bat de très peu le score du codage UTF-8. Dans les 2 cas, la raison est parce que cette version d'
uchardeta gardé la logique que pour UTF-8, la vérification naïve suffit (cette croyance vient de l'algorithme originel, de l'époque où c'était un code Mozilla). Mais ce n'est pas vrai et le score attribué avec cette étape seulement n'est simplement pas assez subtil, donc pas fiable.Et ce sera une des grandes différences (parmi d'autres) avec uchardet 0.1.0: même pour UTF-8, il y aura maintenant de la détection statistique par langage. Cela rend malheureusement uchardet moins bon pour les langages non pris en charge, mais en même temps, pour tous les langages pris en charge, cela a tout simplement rendu l'outil d'autant plus fiable et efficace. Franchement c'est sans équivoque, avec mes récentes améliorations, je n'ai simplement plus de ce genre de faux positifs/négatifs dont je parlais plus haut.
Enfin bon, je suis déjà très fier des améliorations qu'on trouvera dans la version suivante. Je pense même qu'on va pouvoir améliorer plusieurs trucs pour rendre les résultats encore plus fiables (mais faut que je fasse plus de tests). 😊
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]