FILTRE À GROS MOTS POUR LIVRE D'OR

Commentaire de depression le 03/12/2007 12:49:43

Ca ne donne pas envie de rire mais plutôt de pleurer.

global $database_x
global $x

Tu peux passer ces variables à ta fonction en paramètre par référence.

$mot = $tab["$i"];

$i est un entier, c'est affreux ce que tu fais.

mysql_select_db($database_x, $x);

Ca, tu le mets hors de ta boucle.

Une requête dans la base à chaque mot, c'est crade!

Mets plutôt tes gros mots dans un fichier, et fais un file_get_contents

Ensuite, Il y a strpos()

Commentaire de armenak le 03/12/2007 13:16:44

Vous m'avez tué, merci...

Commentaire de webdeb le 03/12/2007 13:26:01

Nan pas ereg() mais preg_replace()

Commentaire de codefalse le 03/12/2007 15:41:38 administrateur CS

Bien que de toute facon, je suppose que parser un texte pour y trouver des caractères interdit soit quelque chose de très lourd, tu a beaucoup de maniere différentes :

1) Tu fait un explode de ton texte avec des espace, ensuite tu récupere depuis une bdd (pourquoi pas) la liste des mots interdits, que tu met dans un tableau, ensuite tu joue avec les in_array

2) Même idée, mais avec la fonction preg_replace_callback.
Tu sépare par espace, tu fait appel à ta fonction qui contient un tableau (un appel ! un seul appel à la bdd) de mots interdits, s'il est trouvé : soit tu fait un break et tu refuse l'ajout, soi tu le remplace par rien (moyen)

3) Encore plus simple, un preg_replace, premier parametre, ton tableau contenant les mots interdits, deuxieme parametre ce qu'il faut mettre en échange (genre co***rd=>mon coeur), le troisieme parametre .... ton texte

Et hop ! Tu gagne un temps ENORME ! :)

Commentaire de codefalse le 03/12/2007 16:14:28 administrateur CS

De toute facon il doit y avoir autant de possibilités que d'utilisateurs CS ;)

@Armenak, le but n'est pas de te "tuer" mais de te montrer tes points faibles. C'est pas forcément facile de se prendre des remarques du genre "ton code sert à rien, il est nul", etc. Je sais, je suis passé par là aussi :) Mais au final, si on accepte de comprendre nos erreurs, on progresse mieux, et on repart de plus belle.
Ce qui est dit n'est pas là pour te prouver que tu ne vaut rien et que tu ne peux pas faire partie du cercle très privé de cs (ce qui est totalement débile), le but, c'est de te montrer tes erreurs pour progresser.

Si on ne te dit que du bien, comment va tu évoluer ?

Maintenant que tu à vu ou sont tes erreurs, quelles sont les solutions pour optimiser ton code, refait le, améliore le, et repropose nous quelque chose de meilleur, vraiment meilleur. Peut-être déjà sur le forum, afin qu'il soit validé, et une fois que l'accord est trouvé, dans les codes.

Je ne veux pas te décevoir, mais je pense que ce code sera supprimé car il montre ce qu'il ne faut pas faire. Apres, je n'ai pas les droits de faire ca, on verra bien ce qu'en disent les admins.

Courage à toi et a bientot pour une amélioration ! :)

Commentaire de kiki67100 le 03/12/2007 16:47:58

J'attent la mise a jour ! :)
je noterais a se moment là

++

Commentaire de malalam le 03/12/2007 20:19:22 administrateur CS

Hello,

je suis très embêté...sincèrement, je ne devrais pas laisser cette source, je devrais la supprimer. Mais, Armenak, tu sembles sympathique, et avoir quelqu'un de ton âge (sans vouloir enfoncer, hein ;-) ) qui se met au php, ça ne donne pas envie de tuer sa nouvelle vocation dans l'oeuf.
Bref...je parlerai des solutions au problème que tu tentes de résoudre ici un peu plus bas. Tout d'abord, le code :
un foreach($tab as $mot)serait aussi efficace et prendrait moins de lignes que ton while() (et tu économiserais un count()).
ereg() est mauvais en terme de performances, SURTOUT utilisé comme ça. Si tu tiens à utiliser une expression régulière, utilise preg_match(), mais encore faut-il utiliser une expression régulière! Là, tu ne fais que vérifier si un mot est présent dans une chaîne. A ce compte la, strpos() est largement plus adapté. Mais là en l'occurence, ce n'est pas ce qu'il faut faire en effet. Ton code va interdire des mots qui ne devraient pas l'être.

Maintenant, le sujet du code. C'est une problématique importante...elle l'est de plus en plus d'ailleurs (Internet, soyons honnête, devient vraiment une décharge...les jeunes ne savent plus ni écrire, ni se comporter correctement); je pense que de l'eau va couleur sous les ponts avant que l'on trouve une solution plus efficace que la censure manuelle (voyez CS). Tenter de trouver un algo qui censure côté serveur (donc en php par exemple), c'est juste suicidaire (ou plutôt un meurtre: celui de votre serveur web). Impliquer en plus son serveur DB, cela devient du masochisme (ou du sadisme, donc, tout dépend de qul côté on se place).
Après tout, le fautif se trouve côté client. Donc je pense qu'une telle vérification devrait se faire côté client, dans l'absolu...sauf que, évidemment, côté client...c'est contournable par un esprit malintentionné -ce sera le cas à tous les coups- et un tant soit peu doué -ça heureusement, c'est beaucoup plus rare.
Du coup, on fait quoi ? Bah à mon avis, le meilleur moyen est de parvenir à instaurer une atmosphère et un système favorisant l'auto-censure. Nous sommes à l'ère du web 2.0, pour reprendre un terme à la mode. Il y a des tonnes de sites, de plus en plus, qui fonctionnent grâce aux utilisateurs; le contenu, ce sont eux, les utilisateurs. ET beaucoup de sites s'en tirent fort bien...pourquoi ? Parce ces sites ont réussi à faire en sorte que les utilisateurs aient intérêt à bien se comporter : ils seront populaires et aimés si tel est le cas...
C'est con, mais ça marche, et c'est vers cela que l'on tend. L'autocensure.

Ces petites considérations mises à part : si on veut vraiment coder une censure...je pense, moi, que je procèderais différemment. Ce sera un algo gourmand de toute manière. Alors si vraiment j'avais le besoin de censurer des données utilisateurs, et pas le temps/les ressources nécessaires, pour faire une censure manuelle, voilà ce que je ferais : puisque je ne fais pas confiance dans les saisies de mes uitilisateurs, je ne les mettrais pas en ligen de suite, ce serait du différé? à J+1 par exemple. Le soir, une tâche CRON tournerait et irait vérifier tous les messages en attente de validation, et les censurerait (là...un dico sans doute, en base vu que ça ne se ferait qu'une fois par nuit, et avec force d'expressions régulières), puis les validerait pour mise en ligne.

Commentaire de guill76 le 03/12/2007 21:10:16

Salut,
Ouais c'est vrai mais dans ce cas faut faire le parsing en c ou en cpp et pas en php, ou un mix des 2 avec une tache php qui te fait l'extract des post des utilisateurs de la journée, une tache c++ qui te parse tes fichiers et qui te balance un petit rapport puis purge tes fichiers extraits et une derniere en php qui te supprime les posts correspondants trouvés dans ce rapport.

Commentaire de kiki67100 le 03/12/2007 22:52:20

armenak  >http://www.manuelphp.com/php/function.strpos.php

Commentaire de coucou747 le 03/12/2007 23:01:53

"Tenter de trouver un algo qui censure côté serveur (donc en php par exemple), c'est juste suicidaire"-> les filtres de bayes des anti spams sont parfaitement adapte a ce genre de source... Les filtres de bayes font intervennir des notions de proba et statistique avancee... mais ca ne tue en rien le serveur... (pour bien faire faudrait coder ca en sql directement)

sinon un preg_replace de ce genre :
$texte=preg_replace('/(vilain|traitre|mechant|)/', '<img src="bip.png" alt="censure"/>', $texte);
offre un filtrage de chaque mot mais pas du post en general


faudrait que j'ecrive un truc sur Bayes en SQL et si ca ne suffit pas, en C pour SQL ou php (chaud, mais utile)

Commentaire de coucou747 le 04/12/2007 06:54:20

if (strpos($mot,$texte)!==false){
header('Location: http://monsite/mondir/voiedegarage.php');
exit;
}

la Location dans un header ca prend une URL absolue

Commentaire de codefalse le 04/12/2007 12:51:11 administrateur CS

remplace la fonction ereg, car elle n'est pas performante (et deprecated :p)
Utilise preg_match si tu fait des expressions regulières, sinon strpos ();

quand tu veux une fonction en php, tu va dans ton navigateur et tu tape :
http://php.net/nomFonction

http://php.net/strpos

Commentaire de coucou747 le 04/12/2007 13:36:47

max@debian:~$ php -r "if (strpos('test', 't')!==false)echo 'OK'.\"\\n\";"
OK
max@debian:~$ php -r "if (strpos('test', 'u')!==false)echo 'OK'.\"\\n\";"
max@debian:~$


ca marche parfaitement bien, mais il faut mettre strpos($texte, $mot) et pas strpos($mot,$texte)

Commentaire de armenak le 05/12/2007 09:08:59

MALALAM, j'ai eu hier soir une attaque de spam, et le filtre à gros mots n'y a rien fait puisqu'aucun des mots utilisés, des mots simples et courants, n'était dans la liste. Cependant la majorité de ces mots étaient des liens, aussi j'ai ajouté un preg_match comme tu me le conseilles, mais ciblé sur la chaine "http", ce qui m'évitera tous les liens.

Commentaire de armenak le 07/12/2007 11:47:38

Petit problème avec preg_match. Dans le manuel dit ça :

"\b, dans le masque, indique une limite de mot,"

J'ai donc, bon élève, codé comme ça pour ne récupérer $mot qu'en tant que mot et non en tant que partie éventuelle de mot:

preg_match("/\b$mot\b/i",$texte))

Et bien, ça ne fonctionne absolument pas, j'y ai gagné encore une centaine de cheveux blancs (regardez les heures dans l'historique!).

Par contre, en utilisant la syntaxe que j'avais prévue à l'origine pour la fonction ereg avnnt d'avoir été soumis à la lapidation par tout CS, c'est accepté par le serveur et donne le résultat escompté

if (preg_match("/^$mot$/i",$texte))

Allez m'expliquer ça...

Commentaire de coucou747 le 07/12/2007 15:08:55

http://www.google.fr/search?hl=fr&q=regexp+modificateurs
http://www.aliasdmc.fr/coursjavas/cours_javascript600.html

La propriété javascript ignoreCase de l'objet RegExp permet de connaître la valeur du modificateur i.

Commentaire de armenak le 08/12/2007 18:58:54

La fonction pour supprimer les accents d'Arnotic se trouve ici : http://www.phpcs.com/codes/SUPPRIMER-ACCENTS_12788.aspx