Par contre, on peut, et je pense qu'il faut, détecter les points de codes qui ne sont pas valides dans un encodage donné. Et ça, uchardet ne le fait visiblement pas.
Uchardet le fait.
Son algo est basé sur un papier de recherche qui combine 3 méthodes:
1/ le codage, c'est à dire la détection de séquences d'octets illégaux. Ce dont vous parlez. Il s'agit en fait de la méthode naïve la plus répandue quand quelqu'un va vouloir réimplémenter une détection de charset (par exemple gtksourceview utilisait grosso modo cet algorithme). Elle marche plutôt bien notamment pour les codages multi-bytes qui ont pas mal de séquences illégales. Par contre elle est très peu utile (voire souvent carrêment inutile) pour différencier les codages single-byte qui ont tous quasi les mêmes tableaux de caractères légaux (en particulier les ISO-8859-X).
Donc si uchardet le fait, bien entendu. Mais c'est loin d'être suffisant pour traiter la plupart des cas (il y a énormément de codages single-byte. En fait tous les langages européens sont codables sur une variante ISO-8859, et cet algo ne permet aucune détection pour un texte qui utilise une de ces variantes).
Notez pour l'anecdote, et c'est assez marrant, que Firefox rend mal la page même qui explique l'algo de leur ancienne méthode de détection (on voit des caractères cassés, typique d'un encodage raté). En fait, Mozilla n'utilise plus cet algo et a remplacé par une détection par langue.
Or un simple test avec uchardet montre que ce dernier détecte correctement le codage comme "WINDOWS-1252" (bon c'était probablement de l'ISO-8859-1, mais Windows-1252 est un superset donc acceptable). Comme quoi, je pense que c'était une erreur de la part de Mozilla d'abandonner cet algo.
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. Dernière modification le 24 novembre 2015 à 15:54.
Uchardet le fait.
Son algo est basé sur un papier de recherche qui combine 3 méthodes:
1/ le codage, c'est à dire la détection de séquences d'octets illégaux. Ce dont vous parlez. Il s'agit en fait de la méthode naïve la plus répandue quand quelqu'un va vouloir réimplémenter une détection de charset (par exemple gtksourceview utilisait grosso modo cet algorithme). Elle marche plutôt bien notamment pour les codages multi-bytes qui ont pas mal de séquences illégales. Par contre elle est très peu utile (voire souvent carrêment inutile) pour différencier les codages single-byte qui ont tous quasi les mêmes tableaux de caractères légaux (en particulier les ISO-8859-X).
Donc si uchardet le fait, bien entendu. Mais c'est loin d'être suffisant pour traiter la plupart des cas (il y a énormément de codages single-byte. En fait tous les langages européens sont codables sur une variante ISO-8859, et cet algo ne permet aucune détection pour un texte qui utilise une de ces variantes).
2/ La distribution de caractère.
3/ La distribution de suites de 2 caractères.
Voir le papier ici: http://www-archive.mozilla.org/projects/intl/UniversalCharsetDetection.html
Notez pour l'anecdote, et c'est assez marrant, que Firefox rend mal la page même qui explique l'algo de leur ancienne méthode de détection (on voit des caractères cassés, typique d'un encodage raté). En fait, Mozilla n'utilise plus cet algo et a remplacé par une détection par langue.
Or un simple test avec uchardet montre que ce dernier détecte correctement le codage comme "WINDOWS-1252" (bon c'était probablement de l'ISO-8859-1, mais Windows-1252 est un superset donc acceptable). Comme quoi, je pense que c'était une erreur de la part de Mozilla d'abandonner cet algo.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]