Version imprimable
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.
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.
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.Citation:
Envoyé par edwin301
Ou alors, tu fais un traitement bizarre et inutile entre BDD et XML.
Edit : Ah, ce que dit tchize est fort possible, en effet.
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()
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 ?
Salut,
Si tu fait cela c'est normal que tu n'obtiennes rien de bien !!!Citation:
Envoyé par edwin301
:arrow: 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++
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.Citation:
Envoyé par edwin301
la ou tu doit spécifier UTF8 c'est au moment d'écrire ton fichier de sortie.
EDIT: grilé en mieu en plus xD
CA:
Ca ne fait CERTAINEMENT pas une conversion, ça fait une soupe!Code:new String(maChaine.getBytes("ISO8859-15"), "UTF8").
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:
+ nettoyage / flush / fermeture etcCode:
2
3
4
5
6
7
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.
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.
Une requête via connexion JDBC permet d'extraire le CLOB.
Puis utilisation d'un reader pour stocker le CLOB dans un StringBuffer :
Code:BufferedReader clobReader = new BufferedReader(clob.getCharacterStream());
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?
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++
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.)
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 :
xml étant la chaîne à écrire.Code:
2
3
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.
Donc soit les données sont mal encodé dans la base de données, et il serait préférable de corriger cela.Citation:
Envoyé par edwin301
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.
Comme on l'a dit ce genre de code est une hérésie.Citation:
Envoyé par edwin301
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++
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é.Citation:
Envoyé par edwin301
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
ça ne peut pas être de l'ISO-8859-15, il est codé sur 8bits.Citation:
Envoyé par edwin301
ç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.
Ni l'un ni l'autre c'est de l'utf-8-vu-en-iso, bref, c'est des caractère, déterminer un encodage nécessite qu'on aie les octets, pas les caractères :)Citation:
Envoyé par OButterlin
Sauf qu'en l'occurrence, é est la représentation de é UTF-8 en ISO-8859-1.
Donc, pour moi, à la base c'est de l'UTF-8
Il s'agit d'une base de données Oracle 11G et le NLS_CHARACTERSET est WE8ISO8859P15.
A priori il s'agit d'un fichier XML UTF8 chargé en base, que l'on réextrait.
ce serait bien de voir le code qui fait ce chargement :)