Conversion ISO8859-15 en UTF8

**edwin301** · 01/04/2012, 13h46

Bonjour,

J'extrait via une connexion JDBC un champ CLOB dans l'encoding ISO8859-15 pour convertir et générer un fichier XML dans l'encoding UTF8 à partir d'un traitement JAVA.

Le problème est le suivant : les majuscules accentuées ne sont pas correctement convertis : des carrés à la place.

Tous les autres accents sortent bien.

**tchize_** · 01/04/2012, 21h02

Ce n'est pas un problème d'encodage mais un problème de fonte si t'as des carrés à l'affiche. Vérifie les octes dans le fichier en question et je suis certain qu'ils doivent être corrects.

**thelvin** · 01/04/2012, 21h05

Envoyé par edwin301

Le problème est le suivant : les majuscules accentuées ne sont pas correctement convertis : des carrés à la place.

Tous les autres accents sortent bien.

Dans ce cas, c'est dans la BDD que les majuscules accentuées sont incorrectes. Elles ont été mal enregistrées, il n'y a plus rien à y faire.

Ou alors, tu fais un traitement bizarre et inutile entre BDD et XML.

Edit : Ah, ce que dit tchize est fort possible, en effet.

**tchize_** · 02/04/2012, 09h55

La réponse de thelvin est aussi probable. Un CLOB ce n'est pas un BLOB, c'est soumis aux règles d'encodage de la DB. D'ailleurs, avec un CLOB, normalement, tu n'a pas à connaitre "l'encodage", tu récupère un Reader directement via Clob.getCharacterStream()

**edwin301** · 02/04/2012, 11h45

Il ne s'agit pas seulement de l'affichage mais dans le fichier, j'ai bien des carrés pour le caractère 'É', alors que en BDD j'ai 'Ã?'.

La bdd est en character set iso 8859 et le fichier de sortie en UTF8.
La conversion iso8859-15 en utf8 ne fonctionne pas et ceci uniquement pour les majuscules accentuées.

Pour un CLOB tu n'as pas à connaitre l'encodage oui, mais quand tu veux un format de sortie différent (impératif), il faut savoir l'encoding d'entrée et de sortie :
new String(maChaine.getBytes("ISO8859-15"), "UTF8").
Sans faire cela, tous les accents (majuscule et miniscule) sortent avec des caractères étranges.

Un conseil sans bidouiller ?

**adiGuba** · 02/04/2012, 11h51

Salut,

Envoyé par edwin301

new String(maChaine.getBytes("ISO8859-15"), "UTF8").

Si tu fait cela c'est normal que tu n'obtiennes rien de bien !!!

Tu converties une chaine en byte encodé en ISO8859-15, que tu re-transformes en chaine en décodant de l'UTF-8.

Une chaine n'est pas associé à un encodage : en mémoire les chars sont encodés en UTF-16 !

Tu ne dois spécifier l'encodage que lorsque tu lis ou écris un flux binaire.

Bref supprimes cette ligne de code et ca devrait marcher bien mieux... s'il n'y a pas d'autres atrocité de ce genre.

a++

**unknow0** · 02/04/2012, 11h53

Envoyé par edwin301

new String(maChaine.getBytes("ISO8859-15"), "UTF8").

si ne me m'abuse c'est sa le problème, la se que tu fait c'est décoder de l'iso comme si c'était de UTF8.
la ou tu doit spécifier UTF8 c'est au moment d'écrire ton fichier de sortie.

EDIT: grilé en mieu en plus xD

**tchize_** · 02/04/2012, 11h54

CA:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

new String(maChaine.getBytes("ISO8859-15"), "UTF8").

Ca ne fait CERTAINEMENT pas une conversion, ça fait une soupe!

Tu prend ta chaine, tu la "sauve" (byte[]) en ISO8859-15 et puis tu lui dit de la relire en disant "ha mais tout compte fait, non j'ai stocké de l'UTF-8", ca n'a pas de sens.

Pour sauver en UTF-8, on crée un Writer avec de l'utf-8, et tu fais un write(laString) avec ça. Et tu n'a pas besoin de l'encodage d'origine:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
Reader r = clob.getReader();
OutputStream outputStreamFichier = new FileOutputStream(....);
Writer w = new OutputStreamWriter(outputStreamFichier,"UTF-8"));
char[] buffer = new char[2048];
int read = 0;
while ( (read=r.read(buffer)) > 0)
   w.write(buffer,0,read);

+ nettoyage / flush / fermeture etc

**edwin301** · 02/04/2012, 12h06

Je vois qu'y a de la bonne volonté.
Cependant si j'ai ajouté cette conversion c'est parceque le simple fait d'utiliser un writer avec l'encoding UTF-8
Writer w = new OutputStreamWriter(outputStreamFichier,"UTF-8"))

ne suffit pas pour traiter correctement les accents en minuscule.

**tchize_** · 02/04/2012, 12h15

tu les lit comment de la DB tes données? A priori, ça semble indiquer que les données sont stockée de travers dans la base de données. LA soupe que tu fais est une soupe corrective a posteriori, mais il y a toujours des pertes.

**edwin301** · 02/04/2012, 13h35

Une requête via connexion JDBC permet d'extraire le CLOB.
Puis utilisation d'un reader pour stocker le CLOB dans un StringBuffer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

BufferedReader clobReader = new BufferedReader(clob.getCharacterStream());

**tchize_** · 02/04/2012, 13h42

Dans ce cas, si ce n'est pas bon a la sortie du bufferedReader, c'est vraisemblablement qu'on a stocké n'importe quoi dans la DB. C'est stocké comment dans la DB. Le processus qui y écrit est-il correct?

**adiGuba** · 02/04/2012, 13h44

Un peu plus de code serait le bienvenue, surtout s'il y a d'autres surprises comme cela....

Ensuite s'il s'agit d'une appli Desktop tu peux utiliser JOptionPane.showMessage() pour vérifier que ta chaine soit correctement encodé une fois récupéré depuis la BD.

Sinon comment tu vérifies l'encodage du fichier final ?

a++

**thelvin** · 02/04/2012, 13h47

Ce qui revient à ce qu'on a déjà dit : si ça se trouve les données sont mal enregistrées dans la BDD. Ce n'est pas avec la bouillie que tu nous as montrée qu'on va pouvoir savoir si c'est le cas ou non. Si tu peux trouver un moyen de lire correctement ce CLOB, avec n'importe quel outil de BDD, dans ce cas, les données y sont peut-être correctes. Sinon, non.

Autre possibilité : le driver JDBC se trompe en détectant automatiquement le charset employé pour transmettre ce CLOB, et résultat tu lis des données erronées. Auquel cas, il va peut-être falloir regarder dans la configuration de ce driver, comment imposer un charset. Ou quelque chose comme ça.

Dans tous les cas, XML n'a rien à voir là-dedans, et les traitements à base de getBytes() ont peu de chance de pouvoir réparer quoi que ce soit (par contre ils peuvent très facilement casser des choses.)

**edwin301** · 02/04/2012, 14h14

Je ne connais pas exactement le process qui a été utilisé pour charger les données en base.

En terme de code, pour écrire ensuite dans le fichier c'est la ligne suivante qui est réalisée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Writer fos =  new BufferedWriter(new OutputStreamWriter(
				        new FileOutputStream(f, true), "UTF-8"));
fos.write(xml);

xml étant la chaîne à écrire.

Voici ce que j'ai en base dans le CLOB pour le mot Activités par exemple : ActivitÃ©s (en ISO-8859-15).
Dans le fichier en sortie j'ai Activités grâce à la fameuse ligne String(maChaine.getBytes("ISO8859-15"), "UTF8"), sinon ça reste ActivitÃ©s.

Je précise que si je génère un fichier ISO, à ce moment-là le mot Activités apparaît bien sans faire la transformation de la chaîne, idem pour les majuscules accentuées.
Le problème est que c'est un charset UTF8 qui est attendu ce qui pose problème uniquement pour les majuscules accentuées, pour rappel.

**adiGuba** · 02/04/2012, 14h24

Envoyé par edwin301

Donc soit les données sont mal encodé dans la base de données, et il serait préférable de corriger cela.
Soit c'est le driver JDBC qui est mal configuré et qui lit mal les données...

Dans les deux cas la solution est en amont et pas dans le code.

Envoyé par edwin301

Dans le fichier en sortie j'ai Activités grâce à la fameuse ligne String(maChaine.getBytes("ISO8859-15"), "UTF8"), sinon ça reste ActivitÃ©s.

Comme on l'a dit ce genre de code est une hérésie.
Si ca semble marcher pour certains caractères c'est justement parce que la lecture de "maChaine" est incorrecte. Mais c'est du bidouillage qui tombe en "marche"...

a++

**tchize_** · 02/04/2012, 14h46

Envoyé par edwin301

Donc les données dans le CLOB sont a priori déjà corrompues. Essayer de rattraper la soupe avec la bouillasse qu'il y a dedans est compliqué.
Un chose me chifonne, d'où tire-tu la conclusion que le CLOB est en ISO-8859-15? Quel base de données (oracle, mysql, ....)

Pour résumer les chose, créer et récupérer les données vers un CLOB, les opérations suivante devraient avoir été effectuées:

fichier(au format encodage 1) -> lecture avec un reader (avec encodage 1) -> String java -> envoie par le driver JDBC (encodage 2) -> décodage par serveur DB (encodage 2) et stockage dans le serveur (encodage 3) -> lecture par le serveur (encodage 3) -> envoi vers java (encodage 4) -> décodage par le driver (encodage 4) -> String -> envoi vers un writer (encodage 5).

La partie en bleu ne devrais pas te concerner.

Quand les encodages ont le mêmes chiffres, il doivent être les même car il s'agit de points où l'on transfère du binaire. Encodage 2 a peu de chances d'être inccorect. En général le serveur est capable de se dépatouiller. De mon expérience, 60% des erreurs sur encodage 1 (le fichier sur disque est en UTF-8, on le lit avec un reader ISO-8859-1 par exemple), 30% des erreurs dans le choix encodage 5 (on écrit en utf-8 alors que le client veux de l'iso) et 10% des erreur dans la configuration du driver JDBC (le serveur pense qu'on travaille sur la connexion en XYZ et en fait on est en ABC). Mais dans ce dernier cas, les varchars aussi sont corrompus!

A noter que si on fait cette erreur:

fichier(utf-8) -> lecture avec un reader (iso-8859-1) -> String java -> envoie par le driver JDBC (encodage 2) -> décodage par serveur DB (encodage 2) et stockage dans le serveur (encodage 3) -> lecture par le serveur (encodage 3) -> envoi vers java (encodage 4) -> décodage par le driver (encodage 4) -> String -> envoi vers un writer (iso-8859-1).

on peux avoir l'impression que tout est correct car au final on réécrit avec un writer inverse du reader d'origine, et on obtiens un fichier final en utf-8. Mais malheurseument, ça foire sur des cas borderline: certains caractère précis en utf-8 qui, lut avec un filtre iso donnent des caractères osbcont dans le language chinois qui ne peuvent pas être stockés dans la base de données, ou des surrogates qui sont simplifiées par java

**OButterlin** · 02/04/2012, 17h24

Envoyé par edwin301

ça ne peut pas être de l'ISO-8859-15, il est codé sur 8bits.
ça ressemble plus à de l'UTF-8.
ce qui tend à confirmer que les données sont déjà corrompues dans la DB ou qu'elles sont codées en UTF.