Après certaine enquête, je viens de découvrir qu'il ya quelques projets de codage de détection dans le monde java, si le getEncoding dans InputStreamReader ne fonctionne pas:Quel est le détecteur de codage le plus précis?
Cependant, je vraiment Je ne sais pas quel est le meilleur parmi tous. Quelqu'un avec une expérience pratique peut-il me dire lequel est le meilleur en Java?
J'ai personnellement utilisé jchardet dans notre projet (juniversalchardet n'était pas disponible à l'époque), juste pour vérifier si un flux était UTF-8 ou non.
Il était plus facile à intégrer à notre application que l'autre et a abouti à d'excellents résultats.
J'ai trouvé une ligne de réponse:
http://fredeaker.blogspot.com/2007/01/character-encoding-detection.html
Il dit quelque chose vealuable ici:
La force d'un détecteur de codage de caractères est de savoir si ou non son accent est mis sur l'analyse statistique ou Découverte de prologue HTML META et XML. Si vous traitez des fichiers HTML avec META, utilisez cpdetector. Sinon, votre meilleur pari est monq.stuff.EncodingDetector ou com.sun.syndication.io.XmlReader.
Voilà pourquoi je me sers cpdetector maintenant. Je vais mettre à jour le poste avec le résultat de celui-ci.
Vous souciez-vous uniquement des fichiers qui sont déjà étiquetés avec le jeu de caractères via XML ou META? Ce test est très, très suspect (à tel point que je l'ai fait moi-même). Les fichiers de test qu'il utilise ne sont pas du vrai contenu, mais ce sont des tableaux de code. C'est-à-dire, ils ne sont pas "texte dans l'encodage X" mais "texte en anglais avec une liste des points de code dans l'encodage X". Cependant, tous les fichiers de test sont marqués avec le codage. Une comparaison devrait être faite, mais pas avec ces fichiers de test. –
Tests supplémentaires: j'ai exécuté le scénario de test dans ce blog avec les mêmes détecteurs (dernières versions) sur des données non balisées. SEULEMENT ICU détecté: EUC-jp, iso-2022-jp, koi8-r, iso-2022-cn iso-2022-kr .... Seulement ICU et Mozilla jchardet détecté: SJIS, GB18030, big5 ... I utilisé des exemples de http://source.icu-project.org/repos/icu/icu/trunk/source/extra/uconv/samples/ et du répertoire utf-8 (certains ont été convertis à partir de fichiers dans la page de codes cible). –
J'ai vérifié juniversalchardet et ICU4J sur certains fichiers CSV, et les résultats sont incompatibles: juniversalchardet avait de meilleurs résultats:
Il faut donc considérer les codages auxquels il devra probablement faire face. En fin de compte j'ai choisi ICU4J.
Notez que ICU4J est toujours maintenu.
Notez également que vous pouvez utiliser ICU4J, et dans le cas où elle retourne nulle parce qu'elle n'a pas réussi, essayez d'utiliser juniversalchardet. Ou le contraire.
AutoDetectReader de Apache Tika exactement ce que fait - essaie d'abord d'utiliser HtmlEncodingDetector, puis UniversalEncodingDetector (qui est basé sur juniversalchardet), et tente ensuite Icu4jEncodingDetector (basé sur ICU4J).
Notez que InputStreamReader.getEncoding() retourne simplement l'encodage passé dans le constructeur ou l'encodage par défaut de la plate-forme, il ne fait rien avec les données de flux. –
Merci! Je suis conscient de cela. C'est pourquoi je suis si impatient de savoir lequel est le meilleur. –
Il y a aussi Apache Tika, qui semble être basé sur ICU4J. –