Discussion :

[pontus21]

Bonjour,

Je rencontre un petit problème d'encodage des caractères dans une JList.
En effet, je récupère une liste de clients dans une base de données mysql (données encodées en utf-8) et lors de l'affichage dans la JList, les caractères accentués ne s'affichent pas correctement ...

Quelqu'un aurait une idée ?

Merci d'avance !

[tchize_]

La première chose à faire est de déterminer si t'as reçu stocké les données sur la db. L'utilisation d'outils comme phpmyadmin et des requetes sql déterminant la longueur d'une string devrais permettre de déterminer si il y a cohérence entre le texte stocké et la manière donc mysql le vois.
En gros la longueur de chaque texte stocké dans la db doit strictement correspondre au nombre de caractères qu'il devrait contenir. Si t'as stocké "cassé" dedans et que la longeur rapportée par mysql est 5, tout va bien, si elle est de 6, t'as raté le stockage (caractère "é" a été explosé en deux morceaux pendant le transit).

Une fois confirmé que la db est saine, (note qu'un affichage correcte dans phpmyadmin de tes données ne veux pas dire qu'elle sont saine, çà peut vouloir dire que tu a eu une erreur d'encodage et que, à l'affichage, tu fais l'erreur inverse, seul des tests sur la longueur peuvent déterminer comme mysql vois tes données), il faut déterminer que tu reçois sainement les données. C'est souvent là qu'est l'erreur. Le plus simple est de récupérer le contenu d'un select et de stocker tout çà dans un fichier avec une FileWriter configuré en UTF-8. Tu ouvre ensuite ce même fichier, avec une autre application, en précisant le format utf-8. Si les données s'affichent correctement, t'as tout reçu ok

Une fois que tu confirme que t'as tout correctement et que çà s'affiche toujours mal, faut envisager un merdage dans la fonte, essaie de changer la fonte du JList.

[pontus21]

Ouh la ! Assez compliqué tout ça !

Enfin je vais quand même regarder pour voir d'où vient mon erreur.

Sinon, dans phpmyadmin, j'avais un encodage merdique, donc les données s'affichaient mal. J'avais vérifié dans un terminal, que mes données étaient bien rentrées dans mysql. Est-ce que à l'aide du terminal, ça permet d'être sûr que mes données sont bien encodées dans la base ?

Sinon, je vais essayer d'écrire mes données dans un fichier ...

[tchize_]

Est-ce que à l'aide du terminal, ça permet d'être sûr que mes données sont bien encodées dans la base ?

non, car a chaque fois tu aura au minimum 2 encodage impliqué, voir plus. Dans le cas du terminal vont etre impliqués: l'encodage de la db, l'encodage de la connection entre le client console et la db, l'encodage de la console. Exemple de ce qui pourrait se produire:

ton "é" est encodé de travers sur la db, suite à un micmac utf-8/iso 8859-1, tu lit depuis le client, la db extrait deux caractère , le client, recois deux caractère et envoie çà sur la console, pensant que la console est iso-8859-1. Il envoie donc deux octets à la console. Mais la console est en utf-8, elle recois deux octet et affiche un seul glyph qui regroupe les deux octets. Et ho, c'est le caractère d'origine qui a subit le micmac inverse à la sauvegarde....

Le plus simpel pour etre fixé de savoir si c'est stocké dans la db correctement:

Code :

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

select unChamp, length(unChamp) from laTable;

Je parle par expérience. J'ai travaillé à une époque avec du oracle. Tout passait bien jusuq'à ce que qqn fasse du copier/coller des double quotes fermantes depuis word. ET là on s'est rendu compte que tout était stocké de travers dans la db, mais que l'erreur faites à l'envoi vers la db subissait une erreur inverse au retour (youpie hein)

[pontus21]

Effectivement, j'ai dû avoir un soucis de ce type !
Ca devait être exactement ce que tu as dit pour mon terminal.

J'ai modifié mon script d'importation de données dans ma base en mettant

Code :

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

mysql_query("SET NAMES UTF8")

avant toute insertion.
Et effectivement, maintenant, c'est ok dans mon appli java, et également dans phpmyadmin.

Dans la console, ça ne s'affiche plus correctement, sauf si je mets en encodage iso-8859-1 !
Bref, problème résolu !
Merci tchize_

[pontus21]

Par contre, avec la requête que tu m'as donnée, dans la console, ça me donne ça :

Code :

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

AIR CARAÏBES               |                 13

C'est normal ou pas alors ?

Je vais finir par n'y plus rien comprendre !!

[tchize_]

avant de paniquer regarde si t'as pas eu d'espace à l'import ^^ Le mieux c'est de comparer avec un ligne sans caractère accentués.

[pontus21]

Ligne sans caractère accentué :

Code :

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

RUET                       |                  4

Donc c'est bien les caractères accentués qui prennent plus de place que prévu.
Donc si j'ai bien compris, c'est mal encodé dans ma base ...
C'est bien ça ?

[tchize_]

meaculpa, c'est pas LENGTH, c'est CHAR_LENGTH la méthode à utiliser. LENGTH compte les byte, ton comptage est donc correct si t'es en utf-8 dans le cas présent.

[pontus21]

Effectivement !
J'ai ceci avec char_length :

Code :

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

1
2
| PULSE                       |                       5 | 
| AIR CARAÏBES               |                      12 |

Et dans la console, en exécutant "set names utf8", mes résultats s'affichent correctement !

En tous cas, merci beaucoup !!
Résolu !