Application Java : Impossible de lire les iso-8859-1 fichier encodé correctement

J'ai un fichier qui est encodé en iso-8859-1, et contient des caractères tels que ô .

Je suis à la lecture de ce fichier avec le code java, quelque chose comme:

File in = new File("myfile.csv");
InputStream fr = new FileInputStream(in);
byte[] buffer = new byte[4096];
while (true) {
    int byteCount = fr.read(buffer, 0, buffer.length);
    if (byteCount <= 0) {
        break;
    }

    String s = new String(buffer, 0, byteCount,"ISO-8859-1");
    System.out.println(s);
}

Cependant le " caractère est toujours brouillé, généralement l'impression d'être un ? .

J'ai lu sur le sujet (et appris un peu sur le chemin), par exemple

mais ne peut toujours pas obtenir ce travail

Il est intéressant de noter cela fonctionne sur mon pc (xp), mais pas sur mon linux.

J'ai vérifié que mon jdk prend en charge le nécessaire charsets (ils sont de série, de sorte que ce n'est pas une surprise) à l'aide de :

System.out.println(java.nio.charset.Charset.availableCharsets());

Je dois ajouter que je suis capable de voir les personnages ou le fichier d'origine correctement à l'aide de mon terminal linux, si je chat le contenu du fichier
Ce codage de caractères utilisé par votre terminal?
Il est intéressant de noter - si j'ajoute le runtime java de propriété "-Dfile.encoding=UTF16" il fonctionne comme prévu, même si je ne vois pas pourquoi cela devrait avoir de l'importance - et je ne vois pas cela comme une solution, mais plus d'un hack. Il ne fonctionne pas avec la propriété définie à l'UTF8.

InformationsquelleAutor Joel | 2009-01-31

14

Je soupçonne que votre fichier n'est pas fait encodé en ISO-8859-1, ou d'un Système.ça ne veut pas savoir comment imprimer le caractère.

Je recommande de vérifier pour la première, vous examinent les octets dans le fichier. De vérifier pour la deuxième, examiner le caractère pertinent de la chaîne, de l'impression avec
```
 System.out.println((int) s.getCharAt(index));
```
Dans les deux cas, le résultat devrait être 244 décimal; 0xf4 hex.

Voir mon article sur Unicode débogage pour les conseils généraux (le code est en C#, mais il est facile de se convertir à Java, et les principes sont les mêmes).

En général, par le chemin, j'avais envelopper le flux avec un InputStreamReader avec le bon encodage, il est plus facile que de créer de nouvelles chaînes "à la main". Je réalise que ce n'est peut-être le code de démonstration si.

EDIT: Voici un moyen facile de prouver si oui ou non la console de travail:
```
 System.out.println("Here's the character: \u00f4");
```
- ont utilisé linux fichier outil pour tester le type de fichier: fichier --mime FranceJ2.csv FranceJ2.csv: text/plain; charset=iso-8859-1 et a également confirmé que je peux lire correctement, en disent vi, mais je vais suivre vos suggestions.
- Ne faites pas confiance à des outils qui tentent de détecter l'encodage des caractères automatiquement. Ils sont toujours basées sur des heuristiques, et à l'être. Ils ne savent pas ce que le texte de votre fichier est vraiment destiné à contenir.
- Un hexdump du fichier rendements: 0000000 0df4 000a (toutes suggestions!?)
- Comme Jon suggère dans son article, de vérifier les données à chaque étape. Si vous n'avez pas exécuter le code dans le débogueur, vous pouvez vider octets hexadécimaux pour console assurez-vous que vous avez vraiment de données à laquelle vous vous attendez. (Esp. s'il est petit)
- Comme l'a suggéré la valeur décimale du caractère 244. C'est mystérieux car il suggère que la rendre méconnaissable se produit au cours de la sys.sur appel, ou dans le terminal lui-même. Je sais que ce n'est pas le terminal depuis que je peux chat le fichier et voir son contenu, pas de problème. Hmmm
- Un peu de chance avec le Système.console().printf(s) alors?
- non, je crains que ça donne le même résultat. Bizarrement, même si j'ai remarqué que la mise -Dfile.l'encodage UTF16 l'amène à travailler, mais pas si elle est définie à l'UTF8. Je ne comprends pas pourquoi cela serait, et il semble de plus d'un hack qu'un correctif.
- Que faire si vous rediriger les sorties du programme vers un fichier, puis de chat il?
- de même, les caractères en sortir ?. Aussi, si je mets le débogueur sur elle, ils sont aussi de montrer une ?. Je suis plus perplexe.
- Veuillez vous référer à ma Réponse ci-dessous le code que j'ai utilisé pour obtenir ce travail. La suggestion dans ce post que le problème était dû au Système.sur appel était correcte. Merci à tous pour votre aide.
InformationsquelleAutor Jon Skeet
9

De l'analyse du fichier en tant que blocs de taille fixe d'octets n'est pas bon --- ce si certain personnage a un octet de la représentation qui se situe à cheval entre deux blocs? Utiliser un InputStreamReader avec l'encodage de caractères approprié à la place:
```
 BufferedReader br = new BufferedReader(
         new InputStreamReader(
         new FileInputStream("myfile.csv"), "ISO-8859-1");

 char[] buffer = new char[4096]; //character (not byte) buffer 

 while (true)
 {
      int charCount = br.read(buffer, 0, buffer.length);

      if (charCount == -1) break; //reached end-of-stream 

      String s = String.valueOf(buffer, 0, charCount);
      //alternatively, we can append to a StringBuilder

      System.out.println(s);
 }
```
Btw, n'oubliez pas de vérifier que les caractères unicode peuvent en effet être affichés correctement. Vous pouvez également rediriger la sortie du programme vers un fichier et de le comparer avec le fichier d'origine.

Comme Jon Skeet suggère, le problème peut également être la console liés. Essayez System.console().printf(s) pour voir si il y a une différence.

InformationsquelleAutor Zach Scrivena
6

@Joel - votre propre réponse confirme que le problème est la différence entre le codage par défaut sur votre système d'exploitation (UTF-8, l'un Java a ramassé) et à l'encodage de votre terminal à l'aide de l'ISO (ISO-8859-1).

Considérer ce code:
```
public static void main(String[] args) throws IOException {
    byte[] data = { (byte) 0xF4 };
    String decoded = new String(data, "ISO-8859-1");
    if (!"\u00f4".equals(decoded)) {
        throw new IllegalStateException();
    }

    //write default charset
    System.out.println(Charset.defaultCharset());

    //dump bytes to stdout
    System.out.write(data);

    //will encode to default charset when converting to bytes
    System.out.println(decoded);
}
```
Par défaut, mon Ubuntu (8.04) terminal utilise le codage UTF-8. Avec ce codage, c'est imprimée:

UTF-8

?ô

Si je passe du terminal de l'encodage ISO 8859-1, c'est imprimée:

UTF-8

ôÃ

Dans les deux cas, la même octets sont émis par le programme Java:
```
5554 462d 380a f4c3 b40a
```
La seule différence est dans la façon dont le terminal est interpréter les octets qu'il reçoit. Jeu de caractères ISO 8859-1, ô est codé comme 0xF4. En UTF-8, ô est codé comme 0xC3B4. Les autres personnages sont communs aux deux codages.
- Je suis certainement manqué quelque chose - quel est le 5554 462d 380a f4c3 b40a dump ? Certainement pas le System.out.write(data) appel ?
- Ce sont les octets de la JRE écrit à l'appareil (STDOUT) avec tous les trois appels à System.out. Le 0A octets marque les retours à la ligne écrite par println. Il y avait une réponse écrite par l'auteur de la question, depuis supprimé, mais je ne pense pas être capable de lire, il ajoute beaucoup.
- Merci pour la suite, je compris qu'il y avait une réponse par l'auteur depuis supprimé - ne peut pas le lire - merci 🙂
InformationsquelleAutor McDowell
3

Si vous le pouvez, essayez d'exécuter votre programme à debugger pour voir ce qui est à l'intérieur de votre " s " de la chaîne de fois qu'il est créé. Il est possible qu'il ait corriger le contenu, mais la sortie est tronqué après le Système.out.println(s) d'appel. Dans ce cas, il est probablement décalage entre ce que Java pense est l'encodage de votre sortie et l'encodage de caractères de votre terminal/console sous Linux.

InformationsquelleAutor Peter Štibraný
1

En gros, si il fonctionne sur votre PC XP mais pas sous Linux, et vous êtes l'analyse de l'exacte même fichier (c'est à dire vous l'avez transféré de façon binaire entre les cases), puis il a probablement quelque chose à voir avec le Système.out.println appel. Je ne sais pas comment vous vérifiez la sortie, mais si vous le faites en vous connectant avec un shell à distance à partir de la boîte de XP, ensuite, il ya le jeu de caractères de la coquille (et le client) à prendre en compte.

En outre, ce que Zach Scrivena l'indique est vrai aussi - vous ne pouvez pas supposer que vous pouvez créer des chaînes à partir de blocs de données de cette façon - soit utiliser un InputStreamReader ou de lire l'intégralité des données dans un tableau en premier (évidemment pas d'aller travailler pour un gros fichier). Cependant, puisqu'il ne semble pas fonctionner sur XP, alors je crois que ce n'est probablement pas votre problème dans ce cas précis.

InformationsquelleAutor Eek

Vous devez vous connecter pour publier un commentaire.