Apostrophe dans une recherche

Bonjours, a tous.

Plusieurs questions ici.

Voila je travail actuellement sur les fonctions de recherche d'un site juridique, et j'ai remarqué que quand je cherchais "Manquement d'État" ça ne me renvoie rien ! Alors que si je cherche "Sociétés commerciales" où "Contrat d'assurance" ça marche sans soucis.

J'ai donc remarqué que quand une recherche cumulait accent ET apostrophe ça ne fonctionnait pas.

Une fois le constat fait, j'ai compris le soucis, je vais voir dans la base et la je vois sur des milliers de documents dont les mots clé sont "Manquement d’État" ... Bon a ce moment la je vais voir le code du module d'insertion et là sans surprise, le précédent stagiaire avait fait des htmlentities() dans les INSERT :cry:

Du coup quand je cherchait un mot avec accent, vu que pour la recherche, je passe par htmlentities() ça marchait, idem pour les recherches sans accents. Mais quand on combine l'apostrophe et les accents ça ne trouve pas logiquement.


Donc première question, j'ai immédiatement remplacé tous les htmlentites des modules par des mysql_real_escape_string() dans les INSERT. Problème quand j'ajoute "Manquement d'état" dans ma base ça m'affiche "Manquement d\'état" et impossible de faire une recherche convenable sur "Manquement d'état".

Je vois dans le manuel php

"Si magic_quotes_gpc est activée, appliquez d'abord la fonction stripslashes() à vos données. Utiliser cette fonction sur des données qui ont déjà été protégées, les protégera une deuxième fois"

J'ai donc remplacé mes mysql_real_escape_string($texte) par des mysql_real_escape_string(stripslashes($texte)) dans mes INSERT et là, ça ajoute convenablement "Manquement d'état" dans ma base et je peux faire toutes les recherches que je veux en mélangeant majuscule minuscule apostrophe sans soucis. Mais est ce que la requête est bien sécurisé en associant escape et stripslashes comme j'ai du le faire ??

Sinon mon autre soucis, j'ai des dizaines de millier de "eacute;" "Eacute;" etc dans ma base. Y a t'il un moyen rapide de les remplacer ? sans avoir besoin de créer une fonction qui recupere les documents ou il y a des &eacute, remet les accents et fait un update. Car bon je suis en stage et je veux pas me rater avec une grosse boucle qui update toute une base qui contient des dizaines de millier de document ^^ mais je crois que j'aurai pas le choix...

Ou alors plutôt que tout remplacé dans la base, y a t il un moyen de construire une requete php qui trouve "Manquement d’État" dans ma base ? ^^


Merci d'avance de votre aide. Et désolé pour le pavé, j'essaie d'être le plus clair possible :ccool:

PS : la base est en utf8_unicode_ci

Citation:

---

J'ai donc remplacé mes mysql_real_escape_string($texte) par des mysql_real_escape_string(stripslashes($texte)) dans mes INSERT

---

Et le jour où les magic-quotes seront désactivées tu auras un stripslashes( ) de trop. Désactive les magic-quotes ou nettoie tes $_GET/$_POST/... selon get_magic_quotes_gpc( ).

Citation:

---

j'ai des dizaines de millier de "eacute;" "Eacute;" etc dans ma base. Y a t'il un moyen rapide de les remplacer ?

---

Regarde du côté de html_entity_decode( ). Attention au charset, voir la doc de la fonction.
Fais une sauvegarde et des tests avant d'appliquer la fonction à ta bdd.

Citation:

---

Ou alors plutôt que tout remplacé dans la base, y a t il un moyen de construire une requete php qui trouve "Manquement d’État" dans ma base ? ^^

---

Mauvaise solution.

Bonjour,

Tu indiques que ta base est en utf-8, je suppose donc que tes scripts sont en utf-8 également.
Si c'est le cas ; au même titre que pleins de fonctions autours des strings la fonctionnalité "magic quotes" est incompatible avec utf-8, elle peut casser les chaines de caractères utf-8.

Après, utiliser des fonctions d'échappement relatives à l'affichage HTML comme équivalent à l'échappement en base de données est une très grossière erreur.

Tu n'a pas trop le choix, va falloir t'assurer que les données en base n'ont pas été cassées par les magic quotes et tu devras de toutes manière tout nettoyer en virant les entités présentes dans toutes les colonnes de toutes les tables (passe par les procédures stockées).

N'oublie pas de remercier aussi très, mais alors très chaleureusement le précédent stagiaire :aie:

Merci de vos réponses :)

Pour le magic quote, j'avoue n'avoir jamais utilisé cette fonctionnalité. Ça ce désactive ou ? ^^

Sinon :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

$requete = mysql_query( "SELECT id,mot_cles // id est l identifiant de mon document, mot_cles la liste des mots cles FROM matable WHERE mot_cles LIKE "%'.htmlentities("é").'%" OR "%'.htmlentities("è").'%" etc... pour tous les caractères avec accent.   while ($res = mysql_fetch_array($requete, MYSQL_ASSOC)) { $tab[$res['id']]=html_entity_decode($res['mot_cles']) }   foreach($tab as $id => $value) { mysql_query(" UPDATE matable SET mot_cles = ".mysql_real_escape_string($value)." WHERE id = $id") }

---

Vous pensez qu'un truc comme ça fonctionnerait ? Pour tout remplacer ?

Bien sur je vais faire une sauvegarde préalable de la base :p

Euh je sais pas trop si mes scripts sont en UTF8, mon notepad++ est en ANSII c'est tout ce que je peux te dire ^^

Salut,

tu trouveras ça dans le php.ini
Tu peux aussi tester si cette fonctionnalité est activée avec get_magic_quotes_gpc().

Ton script PHP est pas mal, mais par contre, sur une grosse base de données avec des dizaines de milliers d'enregistrements, je pense que c'est cuit.
Sans compter que toutes les colonnes de toutes les tables ont dû être traitées de la même manière et pas seulement la colonne "mot-cles".
Tu vas bloquer le serveur pour un sacré moment avec le risque du timeout.

Dans l'ordre,
- tu prépares tout sur le serveur de dev
- tu copies la base en production sur le serveur de dev
- tu désactives les "magic_quotes" si nécessaire (pense à redémarrer le serveur)
- tu corriges le code PHP en charge de l'enregistrement des données en base (tu vires si tu trouves addslashes()) et remplaces par mysql_real_escape_string(),
- tu fais l'inventaire de toutes les colonnes à balayer de toutes les tables
- tu portes le code de remplacement des entités HTML en procédure stockée
- tu écris la procédure stockée générale qui va balayer toute la base et appeler la fonction de nettoyage
- tu testes tout
- tu arrêtes le serveur de prod pour maintenance
- tu sauvegardes la dernière version de la base en production
- tu importes cette sauvegarde sur ton serveur de dev
- tu exécutes la procédure stockée de nettoyage
- si pas d'erreurs :
- tu modifies en conséquence le php.ini du serveur de prod
- tu publies le code PHP corrigé
- tu exportes les données corrigées du serveur de dev vers le serveur de prod
- tu redémarres tous les services
- fin de la maintenance

Purée, sacré stage dis-donc.
A vrai dire c'est pas le travail d'un stagiaire, m'enfin...

Merci de la réponse ! Je vais regardé ca dans la journée pour le magic_quote.

Pour ce qui est de la base. J'ai pas voulu prendre trop de risque.

J'ai exporté les tables corrompu dans un .sql ( j etais en dessous de 16 mo donc c'est bon )

J'ai ouvert le fichier avec notepad++, et j'ai remplacé tous les é et autre caractère spéciaux par les bons caractères avec la fonction remplacer tout. J'ai pensé comme toi que mon script PHP aller trop envoyer de requete donc je me suis abstenu.

Après j'ai truncate les tables en question, et importé mon .sql modifier.

J ai eu une peu peur au moment du truncate quand même mais apparemment ça a bien fonctionné donc bon ^^

Ouep bah je suis stagiaire mais y a pas d autre informaticien dans la boite en fait ^^

On est en 2013 faudrait peut-être utiliser PDO parce que là c'est une passoire...

Citation:

---

Envoyé par walane

On est en 2013 faudrait peut-être utiliser PDO parce que là c'est une passoire...

---

Entierement d'accord. Mais bon le site y a une centaine de .php qui utilise tous mysql. Et mon stage dur même pas 2 mois.

Alors si il m'embauche pendant l'été je lui change tout pas de soucis :lol:

edit : Nouveau soucis ! J'ai verifié les magic_quote sont bien activé, mais comment je les désactive chez OVH ? :roll:

edit 2 : ah c'est bon ^^

Citation:

---

Envoyé par Coolraoul

Entierement d'accord. Mais bon le site y a une centaine de .php qui utilise tous mysql. Et mon stage dur même pas 2 mois.

Alors si il m'embauche pendant l'été je lui change tout pas de soucis :lol:

edit : Nouveau soucis ! J'ai verifié les magic_quote sont bien activé, mais comment je les désactive chez OVH ? :roll:

edit 2 : ah c'est bon ^^

---

Une centaine de .php ?!! :aie:
Oh j'aimerais pas reprendre ce projet là moi ^^

Citation:

---

Envoyé par walane

Une centaine de .php ?!! :aie:
Oh j'aimerais pas reprendre ce projet là moi ^^

---

Des centaines même, avec pas un seul commentaire nul part :cry: Déroutant les 2 premiers jour mais après on s'y retrouve dans le bordel ^^

Sinon j'ai remis les magic_quote ... car du coup dans mes recherches "'-- coucou" j affichais toute ma base mdr. Je suppose qu'il faut rajouté des stripslashes aux htmlentites des $_POST ? ( ou addslashes ? ) ou alors faut utilisé aussi mysql_real_escape_string quand on interroge la base ? mais je prend pas le risque je vais en oublié et ça va laisser des injections potentiel.

Du coup vu que le magic_quote est activé, dans mes modules d'insertion qui contiennent des INSERT INTO

je remet mes : mysql_real_escape_string(stripslashes($texte))

Ou je peux juste laisser laisser $texte vu que le magic quote est activé ?

Oui non alors t'as pas compris.

La fonction "magic_quote_gpc" reproduisait un peu les mêmes fonctionnalités que "mysql_real_escape_string" pour protéger les variables dans les requêtes, mais la fonction "mysql_real_escape_string" plus récente est aussi plus sécurisante. Cela fait donc des lustres que l'on déconseille l'utilisation des magic quotes et que l'on protège ses variables dans une requête avec mysql_real_escape_string.

Le pb est que sur les vieilles configurations, "magic_quote_gpc" peut-être activé par défaut, bien qu'il est déprécié en php5.3 et sera supprimé en php 5.4. Alors pour pouvoir utiliser "mysql_real_escape_string" on es obligé (pour éviter de faire double emploi avec "magic_quote_gpc") soit de désactiver la fonction "magic_quote_gpc" au niveau du serveur, soit de vérifier au niveau du script s'il est activé et d'appliquer la fonction "stripslashes" pour supprimer l'effet du magic_quotes_gpc avant d'utiliser la fonction mysql_real_escape_string.

Donc si tu peux désactiver "magic_quote_gpc" dans ton .htaccess c'est plus simple et tu utilises simplement mysql_real_escape_string pour protéger tes variables sans traitement préalable, c.a.d :

Code:

---

$query = "SELECT * FROM table WHERE champ1 = '".mysql_real_escape_string($variable1)."' AND champ2 = '".mysql_real_escape_string($variable2)."'";

---

Si tu ne peux pas désactiver magic_quote_gpc au niveau du serveur alors il faut faire un traitement préalable dans ton script pour supprimer - à l'aide de la fonction stripslahes - les éventuels slash ajoutés par la fonction magic_quote_gpc, pour pouvoir ensuite appeler la fonction mysql_real_escape_string, soit :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

/* Fonction qui teste la configuration get_magic_quotes_gpc du serveur. Si activé, supprime avec la fonction stripslashes les antislashes "\" insérés dans les chaines de caractère des variables gpc (GET, POST, COOKIE) */   function Verif_magicquotes ($chaine) { if (get_magic_quotes_gpc()) $chaine = stripslashes($chaine);   return $chaine; }   $variable1 = Verif_magicquotes ($variable1); $variable2 = Verif_magicquotes ($variable2 );   $query = "SELECT * FROM table WHERE champ1 = '".mysql_real_escape_string($variable1)."' AND champ2 = '".mysql_real_escape_string($variable2)."'";

---

L'avantage du code ci-dessus c'est qu'il est portable et fonctionnera tout aussi bien quelque soit la configuration du serveur. Mais bon comme get_magic_quotes_gpc n'existe déjà plus dans php5.4, autant si possible ne pas s'encombrer avec ce traitement supplémentaire et désactiver get_magic_quotes_gpc au niveau du serveur ce qui permet un code plus simple comme dans mon premier exemple.

Par contre l'ânerie à ne pas faire serait d'utiliser systématiquement un stripslashes

Code:

---

$query = "SELECT * FROM table WHERE champ1 = '".mysql_real_escape_string(stripslashes($variable1))."' AND champ2 = '".mysql_real_escape_string(stripslashes($variable2))."'";

---

car dès que ton code migrera vers un serveur moderne (et donc sans possibilité d'activer get_magic_quotes_gpc), ce stripslashes sera en trop et fera bugguer tes requêtes. C'est ce que t'expliquait Séb. dès la première réponse et il faudrait que tu comprenne cela avant d'aller plus loin !

En fait, si, j'ai bien compris que le magic_quote c'est pas cool et qu'il faut la désactiver et toujours saisir mysql_real_escape_string() dans une requète.

Le problème c'est que j'ai trop peu de temps, dans mes taches de stages ne figurait pas ces soucis de BDD que j'ai découvert et je suis déjà depuis quelques jour sur cet imprévu.

Donc en fait le problème c'est que TOUTES les pages .php qui utilisent la base ( c'est a dire a vu de nez 200 voir 300 ) pour la consulter, ont tenu compte du magic_quote.

Et donc y a des centaines et des centaines de requêtes qui ce balade sous cette forme

Code:

---

$query = "SELECT * FROM table WHERE champ1 = '".htmlentities($variable1)."' AND champ2 = '".htmlentities($variable2)."'";

---

J'ai donc deux solutions, soit je désactive le magic_quote et je fais

Code:

---

$query = "INSERT INTO* table VALUES(mysql_real_escape_string($variable)

---

mais en désactivant le magic_quote, les centaines de requêtes de type

Code:

---

$query = "SELECT * FROM table WHERE champ1 = '".htmlentities($variable1)."' AND champ2 = '".htmlentities($variable2)."'";

---

vont créer des failles et surtout les recherches avec apostrophe ne fonctionneront pu. Je dois donc toutes les modifiers ce qui réprésente un assez long boulot quand même.

Deuxième solution, celle que j'ai choisis, qui n'ai pas la bonne, "l'ânerie" mais je n'ai pas trop le choix ... Laisser le magic_quote pour juste avoir a changer les modules d'insertion dans la base ( là y en a que 10 ça va vite )

Code:

---

$query = "INSERT INTO* table VALUES(mysql_real_escape_string(stripslashes($variable))

---

Après perso ça m'emmerde de faire du rafistolage, j'aime quand les choses sont bien faite, ça n'en tiendrai qu'a moi je changerais tout, je mettrai tout en PDO au passage d'ailleurs. Mais si j'explique au maitre de stage que je dois passer la fin de mon stage a améliorer la qualité du code ... lui tant que ça marche pour l'utilisateur ça lui va il est pas informaticien ...

Si j'ai tout finit et que j'ai une semaine je m'attaquerai a ce chantier, sinon tant pis je laisserai une note a la fin du stage pour que le prochain stagiaire est comme thème de stage de refaire toutes les requêtes pour qu'elles soit sécurisés et prète pour faire la transition de mysql a PDO.

Sinon, comme solution intermédiaire entre l’ânerie et la bonne solution je vais prendre ta solution de la fonction qui vérifie le magic_quote au moins pour les 10 modules d'insertion, ça sera déjà ça.

Mais tu penses qu'un jour OVH forcera le passage en 5.4 ?

PS : Sinon j'ai un nouveau problème mais je vais peux être ouvrir un nouveau sujet xD

Ah ok alors oui utilises au minimum la solution intermédiaire avec la fonction Verif_magicquotes ... au moins cette partie de code ne sera pas à refaire.

Nan sinon php 5.3 sera proposé encore de très nombreuses années mais bon vous êtes dans un beau bin's avec ces entités html dans une base de donnée. Notamment vous ne pourrez pas faire de recherche insensible aux caractères accentués alors que cela ne pose aucun souci sans ce problème causé par le fait d'enregistrer des données avec htmlentities.

Bah en faite comme je l'ai dit au dessus, j'ai plus ou moins résolue le problème. Déjà par chance toutes les archives avant 2007 n’était pas corrompu, c'est le stagiaire de 2008 qui a mit ces htmlentities partout ^^

J'ai exporté en .sql toutes les bases concernés, et j'ai fais un truc bête et méchant, "remplacer tout" é par "é" dans notepad++, et j'ai fais ça pour tous les codes html qui trainait. J'ai truncate puis ré-importé mes fichiers .sql et ça a bien fonctionné.


------------------

Mais par contre j'en viens a mon nouveau souci, y a une des bases ou je n'ai pas pu faire cette opération ! Car celui qui l'a crée a eu la bonne idée de stocker tous les mots clés dans un champ "mots_cles" de type ... roulement de tambours ... "blob" :ccool: Une dizaine de mot dans des types "blob", une idée qui frole le génie.

Du coup je n'ai aucune idée de comment exporter ce truc. J'ai exporté dans un .SQL mais les champs "mots_cles" ne ressemblent plus a rien dans le .sql, y a t'il un moyen d exporté une base correctement puis de la remettre sans perdre les données stocké dans un type "blob" ?

Sinon si je change le type de "blob" en "text" est ce que je vais avoir du charabia dans "mots_cles" ou est ce que avec un peu de chance ça va restitué les textes contenus dans les types "blob" ?

Salut,

mon petit doigt me dit que le stagiaire 2008 doit être en fuite maintenant

Pour récupérer tes BLOB en texte, tu fais un simple CAST. Par exemple :

Code:

---

CAST(t_table.blob_col AS CHAR(100) CHARACTER SET utf8)

---

Je pense qu'en utilisant CONVERT ça devrait fonctionner aussi

Oui il doit être très loin alors qu'il est car je viens d'en découvrir encore de belle sur l'accès aux données que tout le monde peux voir sans payer xD

Alors, j'ai essayé sur une table test de faire

Code:

---

ALTER TABLE `test` CHANGE `mot_cles` `mot_cles` TEXT NOT NULL

---

sans succès ça me convertit bien mais mon texte est tronqué je ne sais pas pourquoi.

Sinon CAST et CONVERT c'est utilisable dans PhpMyAdmin ça ?

Car j'ai testé CAST(`test`.`mot_cles` AS CHAR(100) CHARACTER SET utf8) sans succès

Car je travail ni sous MySql ni Database express, je les ai d'installé mais je les ai toujours utilisé qu'en local donc si y a un autre moyen car je sent que je vais galerer a configurer ^^

Non tu ne dois pas altérer ta colonne BLOB.
Tu dois en créer une à côté en VARCHAR par exemple et faire un UPDATE qui remplirait cette nouvelle colonne avec les données issues du CAST

Désolé de ne répondre que maintenant j'avais mis le soucis du blob de coté et voila que j'y revient.

Mon problème, c'est que CAST ou CONVERT sont des fonctions MySQL, et je ne travail que dans PhpMyAdmin, je n'ai aucune idée de comment me connecter a ma base OVH depuis MySql ou Oracle, je n'ai toujours utilisé ces logiciels qu'en local ...

Il n'y a pas un équivalent du cast directement dans PhpMyAdmin ?

Merci :)