Java: comment déterminer le bon encodage du jeu de caractères d'un flux

En référence au thread suivant: Application Java: impossible de lire correctement le fichier encodé iso-8859-1

Quelle est la meilleure façon de déterminer par programme le codage de jeu de caractères correct d'un flux d'entrée / fichier?

J'ai essayé d'utiliser ce qui suit:

File in =  new File(args[0]);
InputStreamReader r = new InputStreamReader(new FileInputStream(in));
System.out.println(r.getEncoding());

Mais sur un fichier dont je sais qu'il est encodé avec ISO8859_1, le code ci-dessus renvoie ASCII, ce qui n'est pas correct, et ne me permet pas de restituer correctement le contenu du fichier sur la console.

J'ai utilisé cette bibliothèque, similaire à jchardet pour détecter l'encodage en Java: http://code.google.com/p/juniversalchardet/

Vous ne pouvez pas déterminer le codage d'un flux d'octets arbitraire. C'est la nature des encodages. Un codage signifie un mappage entre une valeur d'octet et sa représentation. Ainsi, chaque encodage «pourrait» être le bon.

La méthode getEncoding () retournera l'encodage qui a été mis en place (lisez le JavaDoc ) pour le flux. Il ne devinera pas l'encodage pour vous.

Certains flux vous indiquent quel encodage a été utilisé pour les créer: XML, HTML. Mais pas un flux d'octets arbitraire.

Quoi qu'il en soit, vous pouvez essayer de deviner un encodage par vous-même si nécessaire. Chaque langue a une fréquence commune pour chaque caractère. En anglais, le caractère apparaît très souvent mais ê apparaîtra très très rarement. Dans un flux ISO-8859-1, il n'y a généralement pas de caractères 0x00. Mais un flux UTF-16 en a beaucoup.

Ou: vous pouvez demander à l'utilisateur. J'ai déjà vu des applications qui vous présentent un extrait du fichier dans différents encodages et vous demandent de sélectionner le "correct".

Vérifiez ceci: http://site.icu-project.org/ (icu4j) ils ont des bibliothèques pour détecter le jeu de caractères d'IOStream pourrait être simple comme ceci:

BufferedInputStream bis = new BufferedInputStream(input);
CharsetDetector cd = new CharsetDetector();
cd.setText(bis);
CharsetMatch cm = cd.detect();

if (cm != null) {
   reader = cm.getReader();
   charset = cm.getName();
}else {
   throw new UnsupportedCharsetException()
}

Voici mes favoris:

TikaEncodingDetector

Dépendance:

<dependency>
  <groupId>org.apache.any23</groupId>
  <artifactId>apache-any23-encoding</artifactId>
  <version>1.1</version>
</dependency>

Échantillon:

public static Charset guessCharset(InputStream is) throws IOException {
  return Charset.forName(new TikaEncodingDetector().guessEncoding(is));    
}

GuessEncoding

Dépendance:

<dependency>
  <groupId>org.codehaus.guessencoding</groupId>
  <artifactId>guessencoding</artifactId>
  <version>1.4</version>
  <type>jar</type>
</dependency>

Échantillon:

  public static Charset guessCharset2(File file) throws IOException {
    return CharsetToolkit.guessEncoding(file, 4096, StandardCharsets.UTF_8);
  }

Vous pouvez certainement valider le fichier pour un jeu de caractères particulier en le décodant avec un CharsetDecoderet en faisant attention aux erreurs "malformed-input" ou "unmappable-character". Bien sûr, cela ne vous indique que si un jeu de caractères est incorrect; il ne vous dit pas si c'est correct. Pour cela, vous avez besoin d'une base de comparaison pour évaluer les résultats décodés, par exemple savez-vous à l'avance si les caractères sont limités à un sous-ensemble ou si le texte adhère à un format strict? L'essentiel est que la détection des jeux de caractères est une supposition sans aucune garantie.

Quelle bibliothèque utiliser?

Au moment d'écrire ces lignes, ce sont trois bibliothèques qui émergent:

• GuessEncoding
• ICU4j
• juniversalchardet

Je n'inclus pas Apache Any23 car il utilise ICU4j 3.4 sous le capot.

Comment savoir lequel a détecté le bon jeu de caractères (ou le plus proche possible)?

Il est impossible de certifier le jeu de caractères détecté par chacune des bibliothèques ci-dessus. Cependant, il est possible de leur demander à tour de rôle et de noter la réponse renvoyée.

Comment noter la réponse retournée?

Chaque réponse peut se voir attribuer un point. Plus une réponse a de points, plus le jeu de caractères détecté est fiable. Il s'agit d'une méthode de notation simple. Vous pouvez en élaborer d'autres.

Existe-t-il un exemple de code?

Voici un extrait complet de la mise en œuvre de la stratégie décrite dans les lignes précédentes.

public static String guessEncoding(InputStream input) throws IOException {
    // Load input data
    long count = 0;
    int n = 0, EOF = -1;
    byte[] buffer = new byte[4096];
    ByteArrayOutputStream output = new ByteArrayOutputStream();

    while ((EOF != (n = input.read(buffer))) && (count <= Integer.MAX_VALUE)) {
        output.write(buffer, 0, n);
        count += n;
    }
    
    if (count > Integer.MAX_VALUE) {
        throw new RuntimeException("Inputstream too large.");
    }

    byte[] data = output.toByteArray();

    // Detect encoding
    Map<String, int[]> encodingsScores = new HashMap<>();

    // * GuessEncoding
    updateEncodingsScores(encodingsScores, new CharsetToolkit(data).guessEncoding().displayName());

    // * ICU4j
    CharsetDetector charsetDetector = new CharsetDetector();
    charsetDetector.setText(data);
    charsetDetector.enableInputFilter(true);
    CharsetMatch cm = charsetDetector.detect();
    if (cm != null) {
        updateEncodingsScores(encodingsScores, cm.getName());
    }

    // * juniversalchardset
    UniversalDetector universalDetector = new UniversalDetector(null);
    universalDetector.handleData(data, 0, data.length);
    universalDetector.dataEnd();
    String encodingName = universalDetector.getDetectedCharset();
    if (encodingName != null) {
        updateEncodingsScores(encodingsScores, encodingName);
    }

    // Find winning encoding
    Map.Entry<String, int[]> maxEntry = null;
    for (Map.Entry<String, int[]> e : encodingsScores.entrySet()) {
        if (maxEntry == null || (e.getValue()[0] > maxEntry.getValue()[0])) {
            maxEntry = e;
        }
    }

    String winningEncoding = maxEntry.getKey();
    //dumpEncodingsScores(encodingsScores);
    return winningEncoding;
}

private static void updateEncodingsScores(Map<String, int[]> encodingsScores, String encoding) {
    String encodingName = encoding.toLowerCase();
    int[] encodingScore = encodingsScores.get(encodingName);

    if (encodingScore == null) {
        encodingsScores.put(encodingName, new int[] { 1 });
    } else {
        encodingScore[0]++;
    }
}    

private static void dumpEncodingsScores(Map<String, int[]> encodingsScores) {
    System.out.println(toString(encodingsScores));
}

private static String toString(Map<String, int[]> encodingsScores) {
    String GLUE = ", ";
    StringBuilder sb = new StringBuilder();

    for (Map.Entry<String, int[]> e : encodingsScores.entrySet()) {
        sb.append(e.getKey() + ":" + e.getValue()[0] + GLUE);
    }
    int len = sb.length();
    sb.delete(len - GLUE.length(), len);

    return "{ " + sb.toString() + " }";
}

Améliorations: la guessEncodingméthode lit entièrement le flux d'entrée. Pour les grands flux d'entrée, cela peut être un problème. Toutes ces bibliothèques liraient tout le flux d'entrée. Cela impliquerait une grande consommation de temps pour détecter le jeu de caractères.

Il est possible de limiter le chargement initial des données à quelques octets et d'effectuer la détection du jeu de caractères sur ces quelques octets uniquement.

Les bibliothèques ci-dessus sont de simples détecteurs de nomenclature qui, bien sûr, ne fonctionnent que s'il y a une nomenclature au début du fichier. Jetez un œil à http://jchardet.sourceforge.net/ qui scanne le texte

Autant que je sache, il n'existe pas de bibliothèque générale dans ce contexte pour convenir à tous les types de problèmes. Donc, pour chaque problème, vous devez tester les bibliothèques existantes et sélectionner la meilleure qui satisfait les contraintes de votre problème, mais souvent aucune d'elles n'est appropriée. Dans ces cas, vous pouvez écrire votre propre détecteur d'encodage! Comme je l'ai écrit ...

J'ai écrit un outil meta java pour détecter le codage de charset des pages Web HTML, en utilisant IBM ICU4j et Mozilla JCharDet comme composants intégrés. Ici vous pouvez trouver mon outil, veuillez lire la section README avant toute autre chose. En outre, vous pouvez trouver quelques concepts de base de ce problème dans mon article et dans ses références.

Ci-dessous, j'ai fourni quelques commentaires utiles que j'ai expérimentés dans mon travail:

• La détection des jeux de caractères n'est pas un processus infaillible, car elle est essentiellement basée sur des données statistiques et ce qui se passe réellement est de deviner et non de détecter
• icu4j est l'outil principal dans ce contexte par IBM, à mon humble avis
• TikaEncodingDetector et Lucene-ICU4j utilisent tous les deux icu4j et leur précision n'avait pas de différence significative par rapport à l'icu4j dans mes tests (au plus% 1, si je me souviens bien)
• icu4j est beaucoup plus général que jchardet, icu4j est juste un peu biaisé pour les encodages de la famille IBM tandis que jchardet est fortement biaisé vers utf-8
• En raison de l'utilisation répandue de UTF-8 dans le monde HTML; jchardet est un meilleur choix que icu4j dans l'ensemble, mais ce n'est pas le meilleur choix!
• icu4j est idéal pour les encodages spécifiques d'Asie de l'Est tels que EUC-KR, EUC-JP, SHIFT_JIS, BIG5 et les encodages de la famille GB
• Les deux icu4j et jchardet sont une débâcle dans le traitement des pages HTML avec les encodages Windows-1251 et Windows-1256. Windows-1251 aka cp1251 est largement utilisé pour les langues cyrilliques comme le russe et Windows-1256 aka cp1256 est largement utilisé pour l'arabe
• Presque tous les outils de détection de codage utilisent des méthodes statistiques, de sorte que la précision de la sortie dépend fortement de la taille et du contenu de l'entrée
• Certains encodages sont essentiellement les mêmes avec des différences partielles, donc dans certains cas, l'encodage deviné ou détecté peut être faux mais en même temps être vrai! En ce qui concerne Windows-1252 et ISO-8859-1. (reportez-vous au dernier paragraphe de la section 5.2 de mon article)

J'ai trouvé une belle bibliothèque tierce qui peut détecter l'encodage réel: http://glaforge.free.fr/wiki/index.php?wiki=GuessEncoding

Je ne l'ai pas testé de manière approfondie, mais cela semble fonctionner.

Si vous utilisez ICU4J ( http://icu-project.org/apiref/icu4j/ )

Voici mon code:

String charset = "ISO-8859-1"; //Default chartset, put whatever you want

byte[] fileContent = null;
FileInputStream fin = null;

//create FileInputStream object
fin = new FileInputStream(file.getPath());

/*
 * Create byte array large enough to hold the content of the file.
 * Use File.length to determine size of the file in bytes.
 */
fileContent = new byte[(int) file.length()];

/*
 * To read content of the file in byte array, use
 * int read(byte[] byteArray) method of java FileInputStream class.
 *
 */
fin.read(fileContent);

byte[] data =  fileContent;

CharsetDetector detector = new CharsetDetector();
detector.setText(data);

CharsetMatch cm = detector.detect();

if (cm != null) {
    int confidence = cm.getConfidence();
    System.out.println("Encoding: " + cm.getName() + " - Confidence: " + confidence + "%");
    //Here you have the encode name and the confidence
    //In my case if the confidence is > 50 I return the encode, else I return the default value
    if (confidence > 50) {
        charset = cm.getName();
    }
}

N'oubliez pas de mettre tout le try-catch qu'il faut.

J'espère que cela fonctionne pour vous.

Si vous ne connaissez pas l'encodage de vos données, ce n'est pas si facile à déterminer, mais vous pouvez essayer d'utiliser une bibliothèque pour le deviner . Il y a aussi une question similaire .

Pour les fichiers ISO8859_1, il n'existe pas de moyen facile de les distinguer de l'ASCII. Pour les fichiers Unicode, cependant, on peut généralement le détecter sur la base des premiers octets du fichier.

Les fichiers UTF-8 et UTF-16 incluent une marque d'ordre d'octet (BOM) au tout début du fichier. La nomenclature est un espace insécable de largeur nulle.

Malheureusement, pour des raisons historiques, Java ne le détecte pas automatiquement. Des programmes comme Notepad vérifieront la nomenclature et utiliseront le codage approprié. En utilisant unix ou Cygwin, vous pouvez vérifier la nomenclature avec la commande file. Par exemple:

$ file sample2.sql 
sample2.sql: Unicode text, UTF-16, big-endian

Pour Java, je vous suggère de consulter ce code, qui détectera les formats de fichiers courants et sélectionnera le bon encodage: Comment lire un fichier et spécifier automatiquement le bon encodage

Une alternative à TikaEncodingDetector est d'utiliser Tika AutoDetectReader .

Charset charset = new AutoDetectReader(new FileInputStream(file)).getCharset();

En Java clair:

final String[] encodings = { "US-ASCII", "ISO-8859-1", "UTF-8", "UTF-16BE", "UTF-16LE", "UTF-16" };

List<String> lines;

for (String encoding : encodings) {
    try {
        lines = Files.readAllLines(path, Charset.forName(encoding));
        for (String line : lines) {
            // do something...
        }
        break;
    } catch (IOException ioe) {
        System.out.println(encoding + " failed, trying next.");
    }
}

Cette approche essaiera les encodages un par un jusqu'à ce que l'un d'eux fonctionne ou que nous en manquions. (BTW ma liste d'encodages ne contient que ces éléments car ce sont les implémentations de jeux de caractères requises sur chaque plate-forme Java, https://docs.oracle.com/javase/9/docs/api/java/nio/charset/Charset.html )

Pouvez-vous choisir le jeu de caractères approprié dans le constructeur :

new InputStreamReader(new FileInputStream(in), "ISO8859_1");