Je suis le mainteneur de uchardet depuis peu. C'est effectivement la meilleure alternative à l'heure actuelle pour la détection de charset en Libre. Les "classiques" (enca, libguess...) utilisés jusque là sont ridicules d'inefficacité, sans compter ceux qui essaient de réimplémenter une telle détection avec des algos naïfs (ex: gtksourceview, voire VLC, mais eux ne font pas vraiment de détection basé sur le fichier en fait).
Néanmoins la lib est encore loin d'être parfaite. Mais je vais essayer d'améliorer cela avec le temps.
Et voilà, on en arrive enfin à la raison pour laquelle j'ai écrit ce journal. uchardet utilise une méthode statistiques fondée sur la fréquence des lettres. C'est bien, parce que c'est rapide, et que ce n'est pas gros. Mais l'inconvénient, c'est qu'il lui arrive de se tromper, entre deux codecs proches et deux langues proches, quand le fichier comprend peu de caractères spéciaux.
Même si c'est possible que l'algo se trompe entre des codages proches sur certains textes, je pense que le vrai problème est que les données devraient être mises à jour pour certains codages, et surtout uchardet ne prend pas encore en charge tous les codages (même certains qui sont très courant). Un exemple simple, c'est que uchardet est nul pour le français par exemple si vous avez des vieux textes pas écrit en UTF-* (en français, historiquement on utilisait surtout ISO-8859-15, voire ISO-8859-1, y a encore pas si longtemps de cela. Or uchardet n'a de prise en charge d'aucun de ces deux charsets assez communs).
Mais ça devrait s'améliorer. Dans tous les cas, ça va dans le bon sens. mpv utilise dorénavant uchardet comme mode de détection par défaut (si c'est compilé avec). Ce qui fait que je peux enfin regarder mes films avec des sous-titres japonais ou coréen (ce qui était mon cas d'usage principal qui m'a poussé à regarder et tester ce qui existait, le pousser dans divers logiciels, pour finalement devenir le mainteneur d'uchardet) sans me prendre la tête à savoir si le créateur du fichier l'a fait en UTF-8, en EUC-KR ou quoi que ce soit d'autre...
gtksourceview sont sur le point de merger mes patchs, ce qui veut dire par exemple que gedit pourra enfin ouvrir mes fichiers non-UTF-8 sans que je me prenne la tête à sélectionner le bon charset dans une liste déroulante.
Etc.
Donc j'ai écrit un petit script python, qui se fonde sur l'utilsation d'un dictionnaire pour détecter la langue du fichier.
J'y avais pensé aussi. Par contre, ton approche est trop bourrine pour être facilement extensible. Utiliser un dico complet (en plus tu prends en charge que 3 langues, et ça ralentit déjà), c'est normal que ce soit lent. Par contre toutes les langues ont des mots très courants, et ceux-là, oui clairement c'est une approche très intéressante. En fait c'est une approche très proche de l'algo d'uchardet qui se base sur des stats de suites de deux ou trois lettres, ce que tu appliques à des mots complets. À partir de là se pose aussi la question de ce qu'est un mot.
Je vois que tu tokenizes tes mots avec l'expression régulières "\w". Ça marchera pour tes trois langues choisies (anglais, français, russe), mais par par exemple ça ne marchera pas avec du Japonais ou du Chinois qui ne séparent pas les mots avec des espaces.
Pour cela, il y a des segmenteurs (comme tinysegmenter que je maintiens aussi mais n'ai pas touché depuis longtemps).
En tous les cas, oui, utiliser une liste limitée des mots (pas tous les mots) très utilisés statistiquement dans un langage peut être très intéressant pour compléter d'autres méthodes de détection (uchardet lui-même combine plusieurs méthodes de détection d'ailleurs) et donner une note globale de "confiance" dans un résultat de détection.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Au sujet d'uchardet
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é à 10.
Salut,
Je suis le mainteneur de uchardet depuis peu. C'est effectivement la meilleure alternative à l'heure actuelle pour la détection de charset en Libre. Les "classiques" (enca, libguess...) utilisés jusque là sont ridicules d'inefficacité, sans compter ceux qui essaient de réimplémenter une telle détection avec des algos naïfs (ex: gtksourceview, voire VLC, mais eux ne font pas vraiment de détection basé sur le fichier en fait).
Néanmoins la lib est encore loin d'être parfaite. Mais je vais essayer d'améliorer cela avec le temps.
Même si c'est possible que l'algo se trompe entre des codages proches sur certains textes, je pense que le vrai problème est que les données devraient être mises à jour pour certains codages, et surtout uchardet ne prend pas encore en charge tous les codages (même certains qui sont très courant). Un exemple simple, c'est que uchardet est nul pour le français par exemple si vous avez des vieux textes pas écrit en UTF-* (en français, historiquement on utilisait surtout ISO-8859-15, voire ISO-8859-1, y a encore pas si longtemps de cela. Or uchardet n'a de prise en charge d'aucun de ces deux charsets assez communs).
Mais ça devrait s'améliorer. Dans tous les cas, ça va dans le bon sens. mpv utilise dorénavant uchardet comme mode de détection par défaut (si c'est compilé avec). Ce qui fait que je peux enfin regarder mes films avec des sous-titres japonais ou coréen (ce qui était mon cas d'usage principal qui m'a poussé à regarder et tester ce qui existait, le pousser dans divers logiciels, pour finalement devenir le mainteneur d'uchardet) sans me prendre la tête à savoir si le créateur du fichier l'a fait en UTF-8, en EUC-KR ou quoi que ce soit d'autre...
gtksourceview sont sur le point de merger mes patchs, ce qui veut dire par exemple que gedit pourra enfin ouvrir mes fichiers non-UTF-8 sans que je me prenne la tête à sélectionner le bon charset dans une liste déroulante.
Etc.
J'y avais pensé aussi. Par contre, ton approche est trop bourrine pour être facilement extensible. Utiliser un dico complet (en plus tu prends en charge que 3 langues, et ça ralentit déjà), c'est normal que ce soit lent. Par contre toutes les langues ont des mots très courants, et ceux-là, oui clairement c'est une approche très intéressante. En fait c'est une approche très proche de l'algo d'uchardet qui se base sur des stats de suites de deux ou trois lettres, ce que tu appliques à des mots complets. À partir de là se pose aussi la question de ce qu'est un mot.
Je vois que tu tokenizes tes mots avec l'expression régulières "\w". Ça marchera pour tes trois langues choisies (anglais, français, russe), mais par par exemple ça ne marchera pas avec du Japonais ou du Chinois qui ne séparent pas les mots avec des espaces.
Pour cela, il y a des segmenteurs (comme tinysegmenter que je maintiens aussi mais n'ai pas touché depuis longtemps).
En tous les cas, oui, utiliser une liste limitée des mots (pas tous les mots) très utilisés statistiquement dans un langage peut être très intéressant pour compléter d'autres méthodes de détection (uchardet lui-même combine plusieurs méthodes de détection d'ailleurs) et donner une note globale de "confiance" dans un résultat de détection.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]