C'est faux, et je l'ai montré dans un commentaire précédent.
En effet. Je me basais sur le papier de recherche et j'ai eu tort. Tu sembles avoir raison sur le fait que l'implémentation n'a pas l'air d'être stricte. J'ai regardé un peu le code et je regarderai plus tard en détail les algos implémentés pour voir s'il y a une raison et si cela vaudra le coup d'essayer de rendre le test strict.
Ce n'est pas dit, et il faut bien se dire que les gens qui ont écrit ça à l'origine ont clairement testé eux-mêmes plusieurs implémentations (même dans le papier de recherche, ils citent déjà plusieurs types de tests et comment ils ont simplifié). Il faut bien voir que la rapidité et l'exhaustivité des langages est importante. Idéalement uchardet devrait être capable de détecter n'importe quel langage/charset et toujours rester rapide (voire très rapide). Si on se rend compte que certaines approximations peuvent accélérer la détection par 10 avec une qualité de détection très proche, clairement l'approximation vaut le coup.
Par exemple dans le papier, ils expliquent que l'approche naïve est de faire des stats par caractère, mais cela prend énormément de ressources CPU et mémoire. Au final, ils séparent juste la distribution en 2 groupes (caractères fréquemment et peu utilisés), ce qui rend le calcul beaucoup plus rapide et moins gourmand en ressource tout en gardant un résultat satisfaisant sur des textes d'une longueur minimale.
C'est certes moins précis, mais entre un résultat instantané et un calcul qui va charger des dizaines de dictionnaires en mémoire, créer un pic CPU, et prendre plusieurs secondes (pour ouvrir juste un bête fichier texte!), le choix est vite fait. Personne ne veut attendre plusieurs secondes à chaque ouverture d'un fichier dans gedit ou pour lancer son lecteur multimédia avec des sous-titres.
Je pense que le vrai problème de tes exemples est que ce sont des mots seuls et courts. uchardet ne sera probablement jamais efficace sur ce type de cas d'usage; et si c'est le tien principalement, alors uchardet n'est en effet pas fait pour toi.
Par contre uchardet sera toujours plus efficace à partir d'une ou deux phrases (plus efficace dans le sens où ce sera instantané tout en prenant en charge énormément plus de langages et charset; dans tous les cas, clairement si tu compares chaque mot avec un dictionnaire, ton algorithme sera toujours plus efficace, mais à quel prix!).
En tous les cas, merci pour le rapport de bug. Je regarderai si ça peut être amélioré avec un coût raisonnable quand je pourrai. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: exemple
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal toutf8: autodétecter et convertir de n'importe quel encodage de caractères vers UTF8. Évalué à 5.
En effet. Je me basais sur le papier de recherche et j'ai eu tort. Tu sembles avoir raison sur le fait que l'implémentation n'a pas l'air d'être stricte. J'ai regardé un peu le code et je regarderai plus tard en détail les algos implémentés pour voir s'il y a une raison et si cela vaudra le coup d'essayer de rendre le test strict.
Ce n'est pas dit, et il faut bien se dire que les gens qui ont écrit ça à l'origine ont clairement testé eux-mêmes plusieurs implémentations (même dans le papier de recherche, ils citent déjà plusieurs types de tests et comment ils ont simplifié). Il faut bien voir que la rapidité et l'exhaustivité des langages est importante. Idéalement uchardet devrait être capable de détecter n'importe quel langage/charset et toujours rester rapide (voire très rapide). Si on se rend compte que certaines approximations peuvent accélérer la détection par 10 avec une qualité de détection très proche, clairement l'approximation vaut le coup.
Par exemple dans le papier, ils expliquent que l'approche naïve est de faire des stats par caractère, mais cela prend énormément de ressources CPU et mémoire. Au final, ils séparent juste la distribution en 2 groupes (caractères fréquemment et peu utilisés), ce qui rend le calcul beaucoup plus rapide et moins gourmand en ressource tout en gardant un résultat satisfaisant sur des textes d'une longueur minimale.
C'est certes moins précis, mais entre un résultat instantané et un calcul qui va charger des dizaines de dictionnaires en mémoire, créer un pic CPU, et prendre plusieurs secondes (pour ouvrir juste un bête fichier texte!), le choix est vite fait. Personne ne veut attendre plusieurs secondes à chaque ouverture d'un fichier dans gedit ou pour lancer son lecteur multimédia avec des sous-titres.
Je pense que le vrai problème de tes exemples est que ce sont des mots seuls et courts. uchardet ne sera probablement jamais efficace sur ce type de cas d'usage; et si c'est le tien principalement, alors uchardet n'est en effet pas fait pour toi.
Par contre uchardet sera toujours plus efficace à partir d'une ou deux phrases (plus efficace dans le sens où ce sera instantané tout en prenant en charge énormément plus de langages et charset; dans tous les cas, clairement si tu compares chaque mot avec un dictionnaire, ton algorithme sera toujours plus efficace, mais à quel prix!).
En tous les cas, merci pour le rapport de bug. Je regarderai si ça peut être amélioré avec un coût raisonnable quand je pourrai. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]