Discussion :

[pgilbert]

Bonjour !

Habituellement mon champs de recherche me permet de me dépanner de tous mes problèmes de développement mais je dois avouer que pour une fois je suis coincé. J'ai bien lu l'article d'Antoun sur les Jeux de caractères et collations sous MySQL 5 mais ça ne suffit pas à résoudre mon problème que voici :

Version de MySQL : 5.0.44
Hébergement : OVH mutualisé
Interclassement de la connexion : utf8_general_ci
Interclassement de ma base : utf8_general_ci
Interclassement de ma table : utf8_general_ci
Interclassement de mes colonnes : utf8_general_ci
Tests effectués avec phpMyAdmin 2.10.2

Ma table contient deux entrées, l'une avec la valeur Hervé, l'autre avec la valeur Herve dans un champs varchar.

La requête

Code :

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

SELECT * FROM `test` WHERE `title` LIKE 'herve';

retourne Herve

La requête

Code :

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

SELECT * FROM `test` WHERE `title` LIKE 'herve';

retourne Hervé

La requête

Code :

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

1
2
SET NAMES utf8;
SELECT * FROM `test` WHERE `title` LIKE 'herve';

retourne Herve

La requête

Code :

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

1
2
SET NAMES utf8;
SELECT * FROM `test` WHERE `title` LIKE 'hervé';

retourne Herve

Comment faire pour qu'une recherche avec le mot hervé avec ou sans accent me retourne toute les fiches qui contiennent ce mot avec et sans accent ?

Qu'ai-je donc oublié pour que cela ne fonctionne pas ?

Ma configuration ou mon hébergement peuvent-ils être responsables ?

Merci d'avance pour vos réponses

[Antoun]

a priori, tout est OK. es-tu sûr de visualiser toutes les lignes renvoyées par la requête ?

btw, quelle est la différence entre tes deux premières requêtes ? quel est ton @@character_set_client AVANT que tu ne fasses un SET NAMES ?

[pgilbert]

a priori, tout est OK. es-tu sûr de visualiser toutes les lignes renvoyées par la requête ?

Oui, oui, j'ai bien un affichage des 50 premiers résultats éventuels donc un seul en réalité...

btw, quelle est la différence entre tes deux premières requêtes ?

Une erreur en fait... J'ai oublié l'accent sur le e de "hervé"

quel est ton @@character_set_client AVANT que tu ne fasses un SET NAMES ?

latin1

Si tout est OK, ça m'embete... Je préfererai vraiment m'etre planté quelque part parce que je commence à perdre espoir. Merci si tu as une autre piste.

[Antoun]

quel est ton @@character_set_client AVANT que tu ne fasses un SET NAMES ?

latin1

Dans ce cas, tu ne dois surtout pas faire un SET NAMES utf8. Cela revient à dire que tu es en utf8 alors que tu es en latin1.
Peux-tu tester ainsi ?

SET NAMES latin1;
SELECT * FROM `test` WHERE `title` LIKE _latin1'hervé';
SELECT * FROM `test` WHERE `title` LIKE _latin1'herve';

[pgilbert]

Merci pour ta réponse Antoun !
Les requêtes que tu me fais faire renvoient les mêmes résultats qu'auparavant.

Par contre, j'ai avancé un peu dans mes investigations et je deviens inquiet car je me demande si tout a bien été paramétré correctement.

Voici ce que me renvoi "mon" phpMyAmin :

@@CHARACTER_SET_CLIENT => latin1
@@CHARACTER_SET_CONNECTION => utf8
@@CHARACTER_SET_SERVER => latin1
@@CHARACTER_SET_DATABASE => utf8
@@CHARACTER_SET_RESULTS => latin1

Voici ce que me renvoi le phpMyAmin d'OVH sur la même base :

@@CHARACTER_SET_CLIENT => utf8
@@CHARACTER_SET_CONNECTION => utf8
@@CHARACTER_SET_SERVER => latin1
@@CHARACTER_SET_DATABASE => utf8
@@CHARACTER_SET_RESULTS => utf8

Si j'ai tout bien compris et que je ne dis pas de bêtise, la variable @@CHARACTER_SET_RESULTS dépend de @@CHARACTER_SET_CLIENT donc il est normal qu'ils équivalent dans les deux configurations. Mais pourquoi le character set client est-il différent entre les deux accès ? Je croyais que ce paramètre dépendait du content-type définit en meta qui sont ici tout deux définis à utf-8. Je suis à côté de la plaque ou bien ?

Du coup, quand je visualise mes résultats dans le deuxième phpMyAdmin, les caractères accentués sont affichés en latin1 (Hervé). Comme tous les character set sont définis à utf8 sur cette config, j'en conclus que ce sont mes données qui sont mal encodées. D'ailleurs, si je les re-saisie dans cette configuration et que j'effectue ma recherche avec ou sans caractère accentué, j'ai bien le résultat espéré avec ET sans accent. Mais bien évidement, dans la première configuration de PMA j'ai alors un affichage erroné des valeurs (Herv?).

Je me demande donc si mes données ne seraient pas mal enregistrées depuis le début et j'en viens à m'interroger :

• le phpMyAdmin d'OVH effectuerait-il automatiquement un SET NAMES utf8 ?
• comment dois-je configurer mes scripts php pour que mes valeurs s'enregistrent correctement en base ? (puisque le problème est le même dans mes scripts que dans mon PMA)
• dois-je convertir mes données actuelles et si oui, comment faire ?

Antoun, si tu as d'autres éléments de réponse, je te remercie par avance

[Antoun]

Les pépins d'affichage avec phpMyAdmin sont classiques. D'après ce que j'ai constaté, avec des données utf8, tu peux obtenir soit un affichage correct des données, soit un affichage correct des pages de phpMyAdmin lui-même, mais pas les deux. Les paramètres à régler sont le choix de la collation sur la page d'accueil de phpMyAdmin et le jeu de caractères de ton navigateur.

Pour savoir si tes données sont correctes, tu peux par exemple tester LENGTH() et CHAR_LENGTH() sur un de tes "Hervé". Si tout est OK, la CHAR_LENGTH() doit être de 5 (nombre de caractères unicode) et la LENGTH() de 6 (nombre d'octets).Si tu obtiens 6 et 6, c'est que ton é est vraiment enregistré comme é (auquel cas la procédure de re-déclaration est un peu tordue...).

[pgilbert]

Pour savoir si tes données sont correctes, tu peux par exemple tester LENGTH() et CHAR_LENGTH() sur un de tes "Hervé". Si tout est OK, la CHAR_LENGTH() doit être de 5 (nombre de caractères unicode) et la LENGTH() de 6 (nombre d'octets).Si tu obtiens 6 et 6, c'est que ton é est vraiment enregistré comme é (auquel cas la procédure de re-déclaration est un peu tordue...).

Bonne idée, je n'y avais pas pensé !

Et bien il y a bien un problème avec mes données puisque j'ai 8 en CHAR_LENGTH et 6 en LENGTH.

C'est donc que mes données sont encodées deux fois en utf-8 non ?

[Antoun]

Et bien il y a bien un problème avec mes données puisque j'ai 8 en CHAR_LENGTH et 6 en LENGTH.

Je suppose que tu veux dire le contraire ? la CHAR_LENGTH ne peut pas être inférieure à la LENGTH ?

C'est donc que mes données sont encodées deux fois en utf-8 non ?

Je ne sais pas trop... je te conseille de tester un SUBSTRING et un ORD(SUBSTRING) sur chacun de tes 6 ou 8 caractères pour être sûr de ce qu'il y a dans ta colonne.

[pgilbert]

Je suppose que tu veux dire le contraire ? la CHAR_LENGTH ne peut pas être inférieure à la LENGTH ?

Oui, désolé pour cet inversion, j'ai bien 6 en CHAR_LENGTH et 8 en LENGTH.

Je ne sais pas trop... je te conseille de tester un SUBSTRING et un ORD(SUBSTRING) sur chacun de tes 6 ou 8 caractères pour être sûr de ce qu'il y a dans ta colonne.

Je dois t'avouer que je n'y comprends plus trop...

Code :

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

SELECT title, ORD(SUBSTRING(title, -2, 2)) FROM test

Me retourne 50051 (c'est donc le é de hervé)

Aurais-tu encore un peu de patiente et de gentillesse pour me dire si mes données sont bien encodés ?

Merci encore !

[Antoun]

ce que je voulais dire, c'était :

Code :

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

1
2
3
4
SELECT title, ORD(SUBSTRING(title, 1, 1)), SUBSTRING(title, 1, 1) FROM test ;
SELECT title, ORD(SUBSTRING(title, 2, 1)), SUBSTRING(title, 2, 1) FROM test ;
...
SELECT title, ORD(SUBSTRING(title, 6, 1)), SUBSTRING(title, 6, 1) FROM test ;

[pgilbert]

Salut Antoun !

C'est bien ce que j'ai fais...
La requête

Code :

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

SELECT title, ORD(SUBSTRING(title, 5, 1)), SUBSTRING(title, 5, 1) FROM test

Retourne 50051 et ? pour le é de hervé. Pour les autres caractères, j'ai bien le code ascii correspondant.

[Antoun]

C'est bizarre, car 50051 donne à en latin1, et non é... En utf8, c'est le à tout seul. ça laisse penser effectivement à de l'utf8 déclaré en latin1, puis passé tel quel en utf8, mais ensuite tronqué de certains caractères... Si tu as vraiment perdu une partie des données, elles vont devoir être reconstituées à la main ! Si tu as un moyen de repartir de l'origine, c'est largement préférable.

[pgilbert]

Salut !

Je reviens pour donner quelques nouvelles sur mon problème.

Du coup, j'ai écrit une routine maison pour convertir l'ensemble de mes tables et mes données et j'ai ajouté la commande "SET NAMES utf8" juste après la connexion à la base de données pour toutes mes requête et cela fonctionne à merveille. Je n'explique donc pas pourquoi mes données était encodée deux fois en utf8.

Antoun, je te remercie une fois de plus pour ton aide et tes aiguillages.

A+