Précédent   Forum des professionnels en informatique > Bases de données > MySQL > Outils
Outils Forum d'entraide sur les outils pour MySQL. Avant de poster -> Outils MySQL
Partagez cette discussion sur d'autres réseaux sociaux : Viadeo Twitter Google Facebook Digg Delicious MySpace Yahoo
Réponse Proposer ce sujet en actualité
 
Outils de la discussion
Publicité
'
Vieux 05/02/2007, 13h07   #1
Invité régulier
 
Homme Dylann Cordel
Développeur Web
Inscription : juillet 2005
Messages : 12
Détails du profil
Informations personnelles :
Nom : Homme Dylann Cordel
Âge : 26
Localisation : France, Isère (Rhône Alpes)

Informations professionnelles :
Activité : Développeur Web
Secteur : High Tech - Multimédia et Internet

Informations forums :
Inscription : juillet 2005
Messages : 12
Points : 9
Points : 9
Envoyer un message via MSN à Squallynou
Par défaut [Résolu] Recherche accentuée et accentuee

Bonjour,

J'ai une table qui contient des champs en utf8_swedish_ci.
Prenons par exemple 4 enregristrements dont le champ "test1" contient :
évènement
évenement
evènement
evenement

Lorsque je les rentre via phpmyadmin, ils sont stockés tels quels et lorsque je recherche evenement j'ai les 4 enregistrements.
Mais quand il sont stockés telsquels c'est qu'ils ne sont pas en utf8, donc j'ai refais le test en les inserant en utf8 ce qui donne un truc du genre :
ÄîvÂ"nement
Äîvenement
evÂ"nement
evenement

Et là quand je fais la recherche sur evenement, je n'ai plus qu'un seul résultat.

Voici les différentes requetes que j'ai utilisé :

INSERT INTO accents VALUES ('', CONVERT( _latin1 'évènement' USING utf8));
INSERT INTO accents VALUES ('', CONVERT( _latin1 'évenement' USING utf8));
INSERT INTO accents VALUES ('', CONVERT( _latin1 'evènement' USING utf8));
INSERT INTO accents VALUES ('', CONVERT( _latin1 'evenement' USING utf8));

Et pour le select :

SELECT * FROM accents WHERE test1 LIKE CONVERT( _latin1 'evenement' USING utf8) COLLATE utf8_swedish_ci);

SI quelqu'un a une idée...

Merci d'avance
Squallynou est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 06/02/2007, 00h38   #2
Rédacteur/Modérateur

 
Avatar de Antoun
 
Homme Antoine Dinimant
Consultant en Business Intelligence
Inscription : octobre 2006
Messages : 5 854
Détails du profil
Informations personnelles :
Nom : Homme Antoine Dinimant
Âge : 42
Localisation : France, Paris (Île de France)

Informations professionnelles :
Activité : Consultant en Business Intelligence
Secteur : Conseil

Informations forums :
Inscription : octobre 2006
Messages : 5 854
Points : 9 540
Points : 9 540
Mon interprétation de tes requêtes est inverse : tu as déclaré en latin1 (avec l'introduction _latin1) des textes que ton client (phpMyAdmin ?) avait en fait rédigés en utf8. Du coup, tu bousille tous tes accents...

Je ne saurais trop te recommander l'article cité en signature...
__________________
Antoun
Expert SQL, BO, Essbase

La bible d'Essbase est parue !
Antoun est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 06/02/2007, 08h16   #3
Invité régulier
 
Homme Dylann Cordel
Développeur Web
Inscription : juillet 2005
Messages : 12
Détails du profil
Informations personnelles :
Nom : Homme Dylann Cordel
Âge : 26
Localisation : France, Isère (Rhône Alpes)

Informations professionnelles :
Activité : Développeur Web
Secteur : High Tech - Multimédia et Internet

Informations forums :
Inscription : juillet 2005
Messages : 12
Points : 9
Points : 9
Envoyer un message via MSN à Squallynou
Oui je m'en suis rendu compte après en fait.

Le truc, c'est qu'à ma boite on travaille avec Xaraya, un CMF bien poussé. Et les données sont stockées en UTF8, dans une table latin_swedish_ci.
J'ai essayé toutes les conversions possibles, mais rien n'y fait : je n'arrive pas à "laisser" le contenu en UTF8 tout en mettant la table en UTF8 : "ÄîvÂ"nement" reste "ÄîvÂ"nement", alors qu'il devrait se rafficher correctement .
J'ai essayé de passer par un blob avant de repasser en Mediumtext utf8 comme expliqué sur un site (commentcamarche je crois), mais ça n'a rien changé.

J'ai enregistré ton doc, je le lirais ce midi merci.


[EDIT] J'ai lu ton doc, il est bien foutu. Mais jen 'ai pas réussi à trouver un solution à mon problème...
Je viens de faire un test assez étrange : dans l'une des tables en latin1, j'ai deux champs : champ1 et champ2 qui étaient à l'origine tous deux en latin1.
J'ai changé uniquement le second en le mettant en utf8.
Mais lorsque j'ajoute les même données via Xaraya, les deux champs ont exactement la même valeur : Ä@vâ§nement tous les deux. Si Xaraya envoie les données au format UTF8, que ce soit écrit ainsi dans le champ latin c'est normal, mais pourquoi ça l'est aussi dans le champ en utf8 ???

Je suis perdu là...

[REDIT] En faisant un UNHEX(HEX(champTableLatin)) lors de l'insert dans une table en UTF8, j'arrive bien à récupérer les accents. Donc il n'y a plus qu'à trouver une solution pour l'ajout via Xaraya : pourquoi les accents restent ils mal codés même si le champ est en utf8 ?

[REREDIT] Il semblerait que MySQL n'accepte que les données au format "standard" en entrée et les réencode ensuite dans la jeu de caractère du champ ? Celà expliquerait pourquoi lorsque Xaraya envoie ¨Ä@vâ§nement" et que le champ est en latin1, ça reste Ä@vâ§nement et si le champ est en uft8, ça reste aussi Ä@vâ§nement puisque MySQL réencoderai à nouveau les lettres Ä et @ en les interprétant comme du latin1 ?

Y a t'il une config qui permet à MySQL de décoder l'encodage d'arrivée ?
Squallynou est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 06/02/2007, 21h25   #4
Rédacteur/Modérateur

 
Avatar de Antoun
 
Homme Antoine Dinimant
Consultant en Business Intelligence
Inscription : octobre 2006
Messages : 5 854
Détails du profil
Informations personnelles :
Nom : Homme Antoine Dinimant
Âge : 42
Localisation : France, Paris (Île de France)

Informations professionnelles :
Activité : Consultant en Business Intelligence
Secteur : Conseil

Informations forums :
Inscription : octobre 2006
Messages : 5 854
Points : 9 540
Points : 9 540
En gros, tu as compris le truc : MySQL convertit tout automatiquement, ce qui fait que en temps normal tout se passe comme sur des roulettes même entre encodages différents, et mais que si à un moment ou un autre il y a un grain de sable, il est très dur de s'en débarasser... La seule exception à cette conversion automatique est effectivement la conversion en BLOB ou depuis un BLOB.

Il n'y a pas de "détection" possible. C'est le client qui indique à MySQL avec quel jeu de caractère il envoie et il affiche les données. SHOW VARIABLES LIKE 'char%' te permet de voir quel jeu de caractère est déclaré au niveau du client, puis à celui de la connexion.

Regarde déjà l'en-tête de tes pages Xaraya, afin de vérifier le jeu de caractère déclaré, mais je suppose que ça doit être de l'UTF8.

Ton problème peut venir d'une fonction PHP comme htmlentities() ou html_entity_decode() à qui il faut préciser le jeu de caractères, sous peine de voir tout étiquetté à tort en latin1...
__________________
Antoun
Expert SQL, BO, Essbase

La bible d'Essbase est parue !
Antoun est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 09/02/2007, 07h29   #5
Invité régulier
 
Homme Dylann Cordel
Développeur Web
Inscription : juillet 2005
Messages : 12
Détails du profil
Informations personnelles :
Nom : Homme Dylann Cordel
Âge : 26
Localisation : France, Isère (Rhône Alpes)

Informations professionnelles :
Activité : Développeur Web
Secteur : High Tech - Multimédia et Internet

Informations forums :
Inscription : juillet 2005
Messages : 12
Points : 9
Points : 9
Envoyer un message via MSN à Squallynou
Merci,

Je verrais comment modifier ça. Maintenant que je connais la source du problème ça devrait être plus simple . Le seul hic c'est que xaraya est un monstre ^^ Et si je modifie ça va mettre du temps, chose que les clients ne nous accordent pas forcément lol.

Je tag en "résolu" Merci encore pour tes infos.

D.
Squallynou est déconnecté   Envoyer un message privé Réponse avec citation 00
Réponse Proposer ce sujet en actualité Cette discussion est résolue.
Outils de la discussion



Fuseau horaire GMT +2. Il est actuellement 20h45.


 
 
 
 
Partenaires

Hébergement Web