Version imprimable
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 ! ;)
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.
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 ...
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:Citation:
Envoyé par pontus21
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:
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)Code:select unChamp, length(unChamp) from laTable;
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
avant toute insertion.Code:mysql_query("SET NAMES UTF8")
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_
Par contre, avec la requête que tu m'as donnée, dans la console, ça me donne ça :
C'est normal ou pas alors ?Code:AIR CARAÏBES | 13
Je vais finir par n'y plus rien comprendre !!
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.
Ligne sans caractère accentué :
Donc c'est bien les caractères accentués qui prennent plus de place que prévu.Code:RUET | 4
Donc si j'ai bien compris, c'est mal encodé dans ma base ...
C'est bien ça ?
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.
Effectivement !
J'ai ceci avec char_length :
Et dans la console, en exécutant "set names utf8", mes résultats s'affichent correctement !Code:
2
En tous cas, merci beaucoup !!
Résolu ! :yaisse2: