Discussion :

[boteha]

Bonjour,

Je cherche Ã, pas a ni A.

Il faut une requête sensible à la casse et aux accents.

J'essaye dans phpMyAdmnin :

Code :

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

SELECT * FROM `mf2pqcm_posts` WHERE `post_text` LIKE '%Ã%' COLLATE utf8mb4_cs_as;

MySQL répond :

Unknown collation: 'utf8mb4_cs_as'

J'ai aussi essayé :

Code :

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

1
2
 
SELECT * FROM `mf2pqcm_posts` WHERE `post_text` LIKE '%Ã%' COLLATE latin1_general_cs;

COLLATION 'latin1_general_cs' is not valid for CHARACTER SET 'utf8mb4'

Pouvez-vous m'aider ?

Merci d'avance.

[Séb.]

Quel jeu de caractères utilises-tu ? Si utf8mb4 alors tu peux utiliser la collation utf8mb4_0900_as_cs

Code SQL :

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

1
2
3
SELECT ALL tes_colonnes
FROM mf2pqcm_posts
WHERE post_text LIKE '%Ã%' COLLATE utf8mb4_0900_as_cs;

Ou :

Code SQL :

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

WHERE POSITION('Ã' IN post_text COLLATE utf8mb4_0900_as_cs) > 0;

[boteha]

Bonjour,

Je te remercie cela fonctionne parfaitement.

Certains auront compris que mon problème est de réparer des tables dont les caractères accentués ont été massacrés lors d'un changement de version SQL (passage à 8.0 chez OVH).

è est remplacé par é, ê par ê, etc.

à est remplacé par "Ã*", très vicieux car l'espace blanc derrière à ne correspond pas à un espace normal sur le clavier.

Pour être prudent :

UPDATE mf2pqcm_posts SET post_text = REPLACE(post_text , 'Ã ' , 'à') WHERE `post_text` LIKE '%Ã %' COLLATE utf8mb4_0900_as_cs;

J'attends un peu avant de cocher Résolu.

[Séb.]

REPLACE(post_text , 'Ã ' , 'à')

Ceci est une mauvaise idée. Ta BdD doit être indépendante de tout codage externe, ici HTML.

De plus le COLLATE devrait être au moins au niveau du REPLACE() et pas uniquement du WHERE, autrement tu risques de faire de mauvais remplacements.

T'es-tu assuré du bon paramétrage CHARSET/COLLATION actuel de ta base, de tes tables, et de tes colonnes ?
As-tu essayé de rattraper avec CONVERT() ? https://dev.mysql.com/doc/refman/8.0...nction_convert

[boteha]

Bonjour,

Merci de ton suivi.

Ceci est une mauvaise idée. Ta BdD doit être indépendante de tout codage externe, ici HTML.

Tu as raison, sauf qu'il s'agit d'un petit forum qui n'existe qu'en version HTML.
Il est surtout vrai que les entités HTML vont poser des problèmes pour la recherche.
Mais facile de remplacer ces entités HTML par des caractères accentués, je vais le faire.

De plus le COLLATE devrait être au moins au niveau du REPLACE() et pas uniquement du WHERE, autrement tu risques de faire de mauvais remplacements.

Là c'est plus technique.
Peux-tu me dire où je dois glisser le deuxième COLLATE dans la requête ?

Code :

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

UPDATE mf2pqcm_posts SET post_text = REPLACE(post_text , 'é' , 'é') WHERE `post_text` LIKE '%é%' COLLATE utf8mb4_0900_as_cs;

T'es-tu assuré du bon paramétrage CHARSET/COLLATION actuel de ta base, de tes tables, et de tes colonnes ?
As-tu essayé de rattraper avec CONVERT() ?

Le paramétrage de la base est correct, c'est la migration d'OVH qui a causé le problème.

Avec des signes comme », …, etc, dans la base je ne pense pas que CONVERT () puisse me sauver.
Qu'en penses-tu ?

[Séb.]

Le paramétrage de la base est correct

Tu ne le donnes pas, donc à voir.

c'est la migration d'OVH qui a causé le problème.

Si tout est correctement paramétré il n'y a pas de raison.
Ton problème peut par exemple provenir de caractères codés UTF8 qui auraient initialement été stockés en tant que Latin1.
=> Lors de l'import dans la nouvelle base/table tu te retrouves avec un double-codage

Avec des signes comme », …, etc, dans la base je ne pense pas que CONVERT () puisse me sauver.
Qu'en penses-tu ?

Ces symboles sont des caractères UTF mal codés. L'idée est de les repasser en Latin1 pour les recoder correctement :

Code SQL :

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

SELECT ALL CONVERT(CAST(CONVERT('pépère' USING latin1) AS BINARY) USING utf8mb4); -- pépère

À utiliser avec précaution au risque d'ajouter une couche de mauvais codage.