requete sql avec ou sans accent

Bonjour à tous,

Site : charset=iso-8859-1
Base de données : latin1_swedish_ci.

Je cherche à faire la requête suivante :

Code:

---

SELECT DISTINCT id FROM $matable WHERE mot LIKE '%ecreter%' COLLATE ...

---

J'ai lu beaucoup de chose à ce sujet, mais je ne dois pas tout comprendre.

Lorsque je suis les conseils de ce site : http://johannes-fetz.blogspot.fr/200...ents-avec.html je devrais utiliser SQL_Latin1_General_Cp437_CI_AI après collate ... mais j'ai le message suivant : Unknown collation: 'SQL_Latin1_General_Cp437_CI_AI' ????

Mon but est de, par exemple, trouver le mot écrêter dans la base même si la recherche est avec le mot "ecreter" ou "écreter" ...

D'avance, merci de m'aider à comprendre pourquoi ça ne marche pas chez moi ?

Parce que l'article que tu cites parle de SQL Server et que visiblement tu utilises Mysql.

L'interclassement que tu veux est plutôt "latin_general_ci".

Attention il y a un interclassement sur la table et sur les colonnes également.

merci sabotage pour ta réponse, je n'avais remarqué que c'était SQL Server

Mais si j'utilise "latin_general_ci" j'ai le message suivant :

Code:

---

Unknown collation: 'latin_general_ci'

---

Tout est en "latin1_swedish_ci", tables et colonnes

Que faire ?

Tu dois faire une faute dans ta requête.
Utilise phpmyadmin pour ce genre d'opérations, ça évite les erreurs bêtes.

une faute ? :aie:
voici ma requete

Code:

---

SELECT DISTINCT id, title FROM matable WHERE (title LIKE '%ecreter%' COLLATE latin_general_ci)

---

??

J'utilise phpmyadmin, mais pourquoi me recommandes-tu ça ??
C'est grâce à phpmyadmin que je sais que mes tables sont en latin1_swedish_ci

et si je fais la requete avec latin1_swedish_ci :

Code:

---

SELECT DISTINCT id, title FROM matable WHERE (title LIKE '%ecreter%' COLLATE latin1_swedish_ci)

---

le mot "écrêter" n'est pas trouvé :(

Ce que je voulais dire c'est qu'il faut mettre le bon interclassement sur tes colonnes plutôt que de le faire dans la requête.
Dans phpmyadmin tu auras du voir que c'est "Latin1_general_ci" :P

tu es un génie sabotage :ccool:

Merci infiniment, j'aurai mis 10 ans à trouver ça tout seul

Bon week-end à toi ;)

Cyril

:calim2: gloups, je me permets de réouvrir le post, je parviens à trouver le mot rechercher avec accent

Code:

---

SELECT DISTINCT id, title FROM matable WHERE (title LIKE '%écrêter%' COLLATE latin1_general_ci)

---

la requete trouve bien le mot écrêtre
mais si ma requete est

Code:

---

SELECT DISTINCT id, title FROM matable WHERE (title LIKE '%ecreter%' COLLATE latin1_general_ci)

---

alors je ne trouve pas le mot écrêter ??? je voudrais vraiment que le mot écrêter soit trouvé même si on ne tape pas les accents ...

Tu es encore avec "swedish"

non, c'est juste une erreur dans le thread
latin1_general_ci c'est ok normalement ?

C'est bête à dire maintenant mais j'ai testé

Code:

---

1 2 3 4 5

SELECT 'écrêter' LIKE 'ecreter' COLLATE latin1_swedish_ci // VRAI   SELECT 'écrêter' LIKE 'ecreter' COLLATE latin1_general_ci // FAUX

---

c'est donc latin1_swedish_ci qu'il te faut.

si on reprend notre discussion, ce n'est pas si évident que ça fonctionne chez toi ; il serait interessant que tu regardes le résultat de ces deux requêtes.

... autre point à vérifier : les données sont enregistrées normalement en bdd ? Je veux dire que si elles ont été enregistrées par exemple avec htmlentities, la recherche qui ne tient pas compte das accents ne pourrait pas fonctionner...

Directement via phpmyadmin j'ai testé les 2 requêtes que tu me proposes (dans matable)

matable est complètement en latin1_general_ci :

Citation:

---

SELECT 'écrêter' LIKE 'ecreter' COLLATE latin1_general_ci

---

j'obtiens ce message :

Citation:

---

#1253 - COLLATION 'latin1_general_ci' is not valid for CHARACTER SET 'utf8'

---

matable est complètement en latin1_swedish_ci, j'obtiens ce message :

Citation:

---

SELECT 'écrêter' LIKE 'ecreter' COLLATE latin1_swedish_ci

---

même punition :cry:

Citation:

---

#1253 - COLLATION 'latin1_swedish_ci' is not valid for CHARACTER SET 'utf8'

---

Ai-je fais ce qu'il fallait pour tester ce que tu souhaitais sabotage ?
Je ne pensais pas que ma database était en utf8 ???
En tout cas, mon code est en iso-8859-1 et les fichiers, général dans eclipse, son par défaut en Cp1252

ABCIWEB, mes données ne sont pas enregistré avec htmlentities

je dois avouer que maintenant, je suis paumé !!! :calim2:

Dans phpmyadmin, change provisoirement le mode de connexion en latin1 (ca se passe sur la page d'accueil) pour le test.

j'ai exactement le même résultat que toi

pour rappel, AVEC MON CODE, si tout est en latin1_swedish_ci et si je tape "LIKE '%écrêter%'" :
- ma requete ne me renvoie rien

Si je passe ma database est en latin1_general_ci et si je recherche "LIKE '%écrêter%'"
- ma requete me retourne correctement le mot écrêter

Si je recherche "LIKE '%ecreter%'"
- ma requete ne me retourne pas "écrêter"

!!

Tu peux nous fournir un dump de ta base ?

Sinon petite réflexion complémentaire, c'est indispensable le charset iso-8859-1 ? Parce que si c'est un nouveau site et tant qu'à se prendre la tête sur des problème d'encodage il serait plus indiqué d'utiliser le charset utf-8.
Nombre de fonctions php comme json_encode ne sont compatibles qu'avec le charset utf-8, sans compter la plupart des modules externes qui pourront communiquer avec php, une lib comme jquery par exemple, etc. Bref utiliser l'iso-8859-1 c'est clairement pas une solution d'avenir...

je ne peux envoyer un dump de la base, mais j'en ai refait une simplifiée

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62

-- phpMyAdmin SQL Dump -- version 4.0.4.1 -- http://www.phpmyadmin.net -- -- Client: 127.0.0.1 -- Généré le: Dim 24 Novembre 2013 à 18:33 -- Version du serveur: 5.6.11 -- Version de PHP: 5.5.3   SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO"; SET time_zone = "+00:00";     /*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */; /*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */; /*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */; /*!40101 SET NAMES utf8 */;   -- -- Base de données: `test` -- CREATE DATABASE IF NOT EXISTS `test` DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci; USE `test`;   DELIMITER $$ -- -- Procédures -- CREATE DEFINER=`root`@`localhost` PROCEDURE `test_multi_sets`() DETERMINISTIC begin select user() as first_col; select user() as first_col, now() as second_col; select user() as first_col, now() as second_col, now() as third_col; end$$   DELIMITER ;   -- --------------------------------------------------------   -- -- Structure de la table `table1` --   CREATE TABLE IF NOT EXISTS `table1` ( `t_id` int(11) NOT NULL AUTO_INCREMENT, `t_name` varchar(150) COLLATE latin1_general_ci NOT NULL, PRIMARY KEY (`t_id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci AUTO_INCREMENT=4 ;   -- -- Contenu de la table `table1` --   INSERT INTO `table1` (`t_id`, `t_name`) VALUES (1, 'écrêter'), (2, 'toto'), (3, 'titi');   /*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */; /*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */; /*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;

---

et le code

Code:

---

1 2 3 4 5 6 7 8 9 10 11

$db = mysql_connect($sql_serveur, $sql_user, $sql_pass) or die ("Could not connect to mysql server"); if (!mysql_select_db($db_argil_music, $db)) {echo 'Database connection failed'; exit;}   //$rq = "SELECT 'écrêter' LIKE 'écrêter' COLLATE latin1_swedish_ci"; $rq = "SELECT * FROM table1 WHERE t_name LIKE '%écrêter%' COLLATE latin1_general_ci"; //$rq = "SELECT * FROM table1 WHERE t_name LIKE '%toto%' COLLATE latin1_general_ci"; $rs = mysql_query($rq, $db) or die(mysql_error());   while($data = mysql_fetch_assoc($rs)){ echo "=> ".$data['t_name']; }

---

J'ai lu ce que tu dis ABCIWEB sur d'autres forum, mais si j'en suis venu à poser la question c'est justement parce que j'aimerais éviter de tout convertir en utf8.
En fait, je crains de devoir tout re-tester, les formulaires, tous les $_POST, $_GET et surtout, j'écris des données dans des fichiers ... si les accents ne suivent pas ... :oops: alors j'aimerais trouver une solution sans tout convertir, non ?? ou est-ce que je me trompe et je dois tout convertir ?

petit complément d'information, pour vous évitez de perdre du temps, lorsque je convertis mon code en swedish dans ma base, alors le mot "écrêter" est correctement trouvé par ma requête.

Je me demande donc pourquoi ce code de test fonctionne très bien, alors et non sur mon site :(

je n'ai même pas besoin d'ajouter de COLLATE !!!!

Citation:

---

Envoyé par Cyril012

Je me demande donc pourquoi ce code de test fonctionne très bien, alors et non sur mon site :(

---

Parce que la configuration sur le serveur distant n'est pas la même que chez toi en local. C'est sans doute dû à la configuration par défaut.

Citation:

---

Envoyé par Cyril012

J'ai lu ce que tu dis ABCIWEB sur d'autres forum, mais si j'en suis venu à poser la question c'est justement parce que j'aimerais éviter de tout convertir en utf8.
En fait, je crains de devoir tout re-tester, les formulaires, tous les $_POST, $_GET et surtout, j'écris des données dans des fichiers ... si les accents ne suivent pas ... :oops: alors j'aimerais trouver une solution sans tout convertir, non ?? ou est-ce que je me trompe et je dois tout convertir ?

---

Oui enfin il n'y a pas tout à re tester, uniquement les fonctions dont on doit spécifier l'encodage, plus un header php pour l'entête apache, une requête php à la bdd pour spécifier l'encodage, le meta charset dans le html, et prendre soin d'enregistrer le fichier dans le format utf-8. En incluant le lecture d'un tuto cela ne devrait pas prendre plus de quelques jours. Mais bon tu partirais sur de meilleures bases et le site sera plus facilement évolutif/ouvert à l'échange de données. Et si tu veux faire d'autres sites/développements il faudra bien te mettre à ce "nouveau" standard un jour ou l'autre (+ de 78% des sites web actuels) et c'est peut-être le bon moment.

D'un autre côté si le site a peu de chances d'évoluer et que tu exerce cette activité à titre récréatif, l'iso-8859-1 peut encore faire l'affaire.

Mais disons que ce n'est pas recommandé de même d'ailleurs que l'emploi de l'extension mysql que tu pourrais assez facilement remplacer par mysqli (ou par pdo mais cela demande plus de travail). Pour les anciens sites on s'arrange avec l'existant mais pour les nouveaux sites il faudrait éviter d'employer des anciennes normes (l'iso-8859-1 est limitatif) ou des fonctions qui sont en passe de devenir obsolète (mysql est obsolète en php 5.5).

merci pour ABCIWEB pour tes conseils, je vais tout migrer en utf8, c'est certain.
Je ne savais pas pour msqli ! je vais me renseigner.

Concernant mon problème de base, le code que j'ai fourni fonctionne parfaitement bien en swedish. J'avais juste une coquille un peu plus loin dans mon code qui ne me permettait pas de tirer les bonnes conclusions.

Merci encore pour votre aide et vos réflexion très enrichissantes ;)

Bon courage à vous 2 :ccool:

Cyril

Citation:

---

Envoyé par Cyril012

Je ne savais pas pour mysqli ! je vais me renseigner.

---

mysqli a été créée pour pouvoir faire une mise à jour rapide de son code en venant de la vieille extension mysql. La syntaxe est presque identique à mysql ce qui facilite les choses.

Par contre si tu as plus de temps à investir, il serait plus rentable de t'intéresser à pdo qui est plus souple d'emploi et plus agréable à écrire. Notamment mysqli ne supporte pas les marqueurs nommés pour les requêtes préparées et il est impossible de passer un tableau de données directement en paramètre pour associer les variables, ce qui est très pratique avec pdo. Pratiquement tous les exemples de code actuels sont donnés avec pdo qui est le nouveau standard pour accéder aux bdd avec php, alors que mysqli est une option plus simple (mais relativement marginale) pour maintenir son code à jour.

Voilà c'était pour préciser les choses et dire que mysqli c'est bien mais plutôt à considérer comme une alternative pour les gens pressés, l'objectif à terme étant d'utiliser pdo.

wow !! le pdo ... je viens de lire des articles ... je vais y venir, c'est certain :)
cela reste encore trop risqué pour moi sur ce site mais je vais lire ça de prêt pour une conversion futur.

Merci en tout cas pour les infos ;) :ccool:

Je suis en train de convertir en utf8 et j'avais une petite question (), que dois-je sélectionner comme interclassement dans ma base données utf8_general_ci ? utf8_swedish_ci ?

merci d'avance ;)

On utilise en général utf8_general_ci. Et parfois utf8_bin si tu veux pouvoir faire une recherche sensible à la casse et aux caractères accentués, mais comme c'est plus souvent un inconvénient qu'un avantage, on utilise la plupart du temps utf8_general_ci.

merci ABCIWEB .... beaucoup :lol:
bonne continuation