J'ai une classe client FTP qui renvoie InputStream pointant le fichier. Je voudrais lire la ligne de fichier en rangée avec bufferedreader. Le problème est que le client renvoie le fichier en mode binaire et le fichier est codé ISO-8859-15.
4 Réponses :
La chaîne d'origine est dans ISO-8859-15, le flux d'octets lus par votre INPUTStreamReader sera dans ce codage. Donc, lisez-le à l'aide de ce codage (spécifiez-le dans le constructeur INPUTStreamReader). Qui indique à l'INPUTStreamReader que le flux d'octets entrants est dans l'ISO-8859-15 et d'effectuer les conversions d'octets à caractère appropriées.
Il sera maintenant dans le format standard Java UTF-16 et vous pouvez alors faire ce que vous souhaitez faire.
Je pense que le problème actuel est que vous le lisez à l'aide de votre codage par défaut (en ne spécifiant pas de codage dans INPUTStreamReader), puis en essayant de le convertir, au cours de laquelle il est trop tard.
Utiliser le comportement par défaut pour ce type de classes se termine souvent par chagrin. C'est une bonne idée de spécifier des codages où que vous puissiez, et / ou par défaut l'encodage VM via -DFILE.CODING
Doit avoir été malcliquez, désolé, il est parti trop tard pour annuler :(
Avez-vous essayé:
BufferedReader r = new BufferedReader(new InputStreamReader("ISO-8859-1"))
...
S / B ISO-8859-15, pas ISO-8859-1
Essayez ceci:
BufferedReader br = new BufferedReader(
new InputStreamReader(
ftp.getInputStream(),
Charset.forName("ISO-8859-15")
)
);
String row = br.readLine();
Si le fichier / le flux / tout ce qui contient vraiment du texte codé ISO-8859-15, vous devez simplement spécifier que lorsque vous créez l'entréeStreamreader: puis readline () créera des chaînes valides dans le codage natif de Java (qui est UTF-16, pas UTF-8).
Je suis sûr que si vous n'utilisez pas la forme du constructeur qui prend un argument de codeur, pas seulement une chaîne ou une brict, vous n'obtiendrez pas une exception sur l'entrée malformée.
@Tchrist: Vous parlez du constructeur ISR qui prend un argument CharSetDecoder, non? C'est vrai que tous les autres ctors créent des décodeurs que remplacent caractères non valides au lieu de jeter des exceptions. Mais je ne pense pas qu'un décodeur ISO-8859-15 jetterait de toute façon une exception. Chaque valeur d'octet possible correspond à un caractère valide, et c'est le seul moyen de détecter une entrée mal formée.
Oui c'est vrai. Le problème est que lorsque vous demandez UTF-8 et ne l'obtenez pas - et ne reçoivent pas une exception !! De même pour la sortie, si vous (stupidement) par défaut sur l'encodage par défaut de la plate-forme, lequel sur le Mac remplace au moins des points de code malapplables avec ? caractères, à nouveau avec ni avertissement ni exception. Je suis habitué à un comportement de beaucoup plus sûr avec Perl dans ces zones et les défauts Java sont simplement brisés. Notre intégralité de code (la partie Java, pas la partie Perl) est criblée de mauvaises erreurs à cause de cela. Vous donne presque envie de faire du singe-patch le STD Java Libs. presque . ☺
Je ne vois pas comment UTF-8 est impliqué ici - Java utilise UTF-16 en interne, pas UTF-8.
Désolé, cela aurait dû dire UTF-16. Fixé.