Bonsoir, Je suis de retour
Bonne nouvelle, Nolem, ..., ..., .... ( les pseudo sont trop dur a retenir

Voila j'ai balancé sont script rafistolé d'après vos conseil enfin vos commentaire

Donc voila vous voila débarrassé du moteur de recherche car celui la fonctionne un peu près normalement.
mais, voila ....

Pour une image sa gère mais pour plusieurs sa gère pas, j'ai réussi a posé une annonce avec une images, ok jusqu'à la sa roule donc j'au voulu faire en sorte que je puissent en mettre plusieurs rien a faire sa coince . Donc ma manipulation était celle-ci : ai-je bien fait ?
fichier qui traite l'image :

// le fichier joint
$file_name=virer_accents($file_name); //nettoyage du nom de fichier
$file_name=ereg_replace(" ","_",$file_name);
$file_name=ereg_replace("'","",$file_name);
//$file_name=addslashes($file_name);
$img=ereg_replace(" ","_",$file_name);
$img=ereg_replace("'","",$file_name);

// vérification du type et du poids de l'image
if ($img!="")
{
$doss="img/";
if (file_exists($doss.$img)) $err3=1;
if (($file_type!="image/jpeg") and ($file_type!="image/pjpeg")) $err1=1; //vérification du type MIME de l'image  and ($file_type!="image/jpeg"))
if ($file_size>$poids_max) $err2=1; //poids du fichier, pas plus de ... ko
}

Donc dans la base de donnée j'ai crée / rajouté deux champ pour les images :

CREATE TABLE gadjo_annonces (
  id bigint(20) NOT NULL auto_increment,
  id_user bigint(20) NOT NULL default '0',
  id_cat mediumint(11) NOT NULL default '0',
  tel varchar(20) NOT NULL default '',
  tel_2 varchar(20) NOT NULL default '',
  date varchar(20) NOT NULL default '',
  text blob NOT NULL,
  img varchar(30) NOT NULL default '',
  img2 varchar(30) NOT NULL default '',
  img2 varchar(30) NOT NULL default '',
  KEY id (id)


) TYPE=MyISAM;

Le fichier qui permet d'inserer l'annonce:

	// insertion annonce
	$query="insert into $table_annonces (id, id_user, id_cat, tel, tel_2, date, text, img)";
	$query.=" values ('','$id_user', '$id_cat', '$tel', '$tel_2', '$date', '$text', '$img')";
	$res=mysql_query($query);
	if ($img!="")
	{
	if (copy($file, "$dest/$file_name") and ($res)) $mess="ann";
	}
	else
	{
		if ($res) $mess="ann";
	}

tu vas sur quelles sites pour tes tutos ?
par exemple ereg_replace tu le sort d'ou ?

tu vas sur quelles sites pour tes tutos ?
par exemple ereg_replace tu le sort d'ou ?

Oui utilises plutôt str_replace avec des tableaux. Sinon dans ta bdd j'ai vu que tu avais deux fois le même champ "img2"...

Pour le reste tu ne donne qu'une partie du code donc pas facile...

re,

Peux tu mettre sur le forum la fonction virer_accents(). Tu devrais centraliser toutes les instructions de nétoyage du nom du fichier dans une fonction. Or là, tu utilises une fonction personnelle pour virer les accents et après tu utilises des fonctions systèmes pour finir de nettoyer le nom du fichier. Également, tu fais appelles à une fonction pour expressions régulières (ereg_replace).

1 oublie ereg_replace. Elle est obsolète pour diverses raisons depuis php 5.3.
2 la fonction strtr() te permet de faire la même chose en une ligne.

$file_name= strtr ($file_name," '","__");

if (($file_type!="image/jpeg") and ($file_type!="image/pjpeg")) $err1=1;

Je pense que tu voudrais dire plutôt ceci ?

if (($file_type!="image/jpeg") OR ($file_type!="image/pjpeg")) $err1=1; // À noter que la dans ton cas tu peux écrire « || » à la place de « OR » 

En lisant ton code SQL, j'entrevoie des erreurs d'appréciation et de syntaxe. Je peux me tromper, mais j'écrirai un truc dans ce style :

CREATE TABLE gadjo_annonces (
  id_annonce INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
  id_user INT NOT NULL,
  id_cat INT NOT NULL,
  date_annonce DATETIME NOT NULL  DEFAULT CURRENT_TIMESTAMP,
  description TEXT NOT NULL,
  img VARCHAR(128) NOT NULL,
  img2 VARCHAR(128) NOT NULL,
  img3 VARCHAR(128) NOT NULL,
  FOREIGN KEY(id_user) REFERENCES user(id_user),
  FOREIGN KEY(id_cat) REFERENCES cat(id_cat)
)ENGINE = InnoDB CHARACTER SET utf8 COLLATE utf8_bin;

À noter que :
* j'ai volontairement supprimé tel, tel2 puisqu'il devrait plutôt être dans la table user, (d'ailleurs telephone_fixe,telephone_mobile pour chipoter un peu)
* je n'ai pas mis vraiment de contrainte d'intégrité (CONSTRAINT ... ON DELETE CASCADE etc.),
* l'encodage de tes caractères sera en utf-8
* la table sera moins rapide mais bénéficiera des transactions entres autres (InnoDB)

Toutefois, j'aimerai voir la structure de tes tables user et cat stp.

En ce qui concerne ta requête, on est d'accord que d'abords tu te connectes à la base (mysql_connect, mysql_selectdb) ?
Pour rester simple, regarde ceci :

$sql = mysql_real_escape_string(sprintf(INSERT INTO gadjo_annonces(id_user,id_cat,description,img)
VALUES ('%d','%d','%s','%s'),$id_user,$id_cat,$date,$text,$img));
$query=mysql_query($sql) or die ("impossible d'exécuter la requête : ".mysql_errno()." -> ".mysql_error());

ps : (code fait de tête, je peux m'être trompé. Si quelqu'un peu vérifier mon code SVP, je le remercie par avance)

[quote="Nolem"]
1 oublie ereg_replace. Elle est obsolète depuis php 5.3.
2 la fonction strtr() te permet de faire la même chose en une ligne.

$file_name= strtr ($file_name," '","__");

Tant qu'à faire puisqu'il y a plusieurs lignes autant utiliser un tableau cible et un tableau de remplacement.
Enfin juste pour dire au passage qu'il vaut mieux éviter d'utiliser strtr en utf_8 car cette fonction n'est pas compatible avec le traitement multi-octets alors que c'est ok pour str_replace

strtr c'est le mal,
faut utilisé str_replace

strtr c'est le mal,
faut utilisé str_replace

(je m'autoquote)
str_replace c'est le mal

mais pourquoi : parce que la plupart des fonction str ne marche qu'en ANSI, et comme il faut aimé bosser en UTF-8 bah ca va pu str_replace etant lui aussi capricieux sur certaine config

y'a pas mal de methode sur le net pour remplacer les accents, peux son vraiement viable, j'en avais vu une pas mal, qui mettait en entité les accent (é = &eacute) avec des preg genre /&(\w)acute/
c'etait vraiement pas mal

soit comme moi on fait le barabare
1. un coup de iconv() type translit, avec des preg apres (simple efficasse et adaptable)
2. filter_var() avec un SANITIZE type URL
3. on s'en fout que ca soit sous win, linux, osx on peu creer un fichier avec des accents et des espaces et c'est juste les admins qui savent pas configurer leur server


pour continuer ma campagne anti mysql_query, utiliser PDO c'est moins compliquer y'a pas a transformer les valeurs (aller expliquer qu'il faut echapé des carateres pour eviter des injection a des debutant, en plus des while que personne comprendre comment ca marche...)

Hello,

Ça ne résout pas le problème, si on écrit ceci ?

function mon_strtr($chaine){
    $de = " 'éèà"; //etc.
    $vers = "__eea"; //etc.
    
    $chaine = utf8_decode($chaine);
    $chaine = strtr($chaine,$de,$vers);
    
    return utf8_encode($chaine);
}

Je suis entièrement d'accord avec toi pour préconiser l'utilisation de l'objet pdo. Cependant, je mets une réserve :
* le sript est en procédural
* écrire à l'objet, c'est acquérir et comprendre également sa philosophie

strtr c'est le mal,
faut utilisé str_replace

strtr c'est le mal,
faut utilisé str_replace

(je m'autoquote)
str_replace c'est le mal

mais pourquoi : parce que la plupart des fonction str ne marche qu'en ANSI, et comme il faut aimé bosser en UTF-8 bah ca va pu str_replace etant lui aussi capricieux sur certaine config

str_replace() fonctionne correctement si les entêtes, le code et l'encodage du document sont cohérents.

Je n'ai vu aucun contre exemple probant qui vienne de la fonction elle-même, où alors j'aimerais bien qu'on me dise lesquels et ça me permettrait de mettre à jour ce tuto qui a été lu par de nombreuses personnes et qui n'ont rien trouvé à dire à ce propos.

Perso j'utilise str_replace() en permanence pour des remplacements de caractères en utf-8 - dont on parle précisément ici - et jamais eu de problème.

C'est ce que dit également cette page de référence mise à jour le 2009/10/21.

(aller expliquer qu'il faut echapé des carateres pour eviter des injection a des debutant, en plus des while que personne comprendre comment ca marche...)

On peux dire simplement d'utiliser mysql_real_esacpe_string() pour protéger les données dans les requêtes. Est-ce inabordable ?

Encore une fois, je ne dis pas de ne pas utiliser PDO et personne ne va dans ce sens. Je dis simplement que pour du code en cours comme celui çi, c'est pas la peine d'apprendre à l'auteur - qui plus est débutant - à utiliser PDO avant d'aller plus loin. Sinon comme le faisait remarquer Nolem, à la prochaine étape je t'entend déjà dire de tout reprendre en POO pour faciliter la maintenance du code... et être cohérent. A ce rythme là, l'est pas près de fonctionner son script. Et au moment où il le sera il y aura d'autres techniques et il faudra tout reprendre

While est une fonction multi usage qui permet entre autre de lister la ressource d'une requête, contrairement à un foreach qui ne fonctionne que sur les tableaux. Mais tu n'es pas obligé d'expliquer non plus tous les détails avant de montrer comment récupérer les lignes d'une requête.

Bon c'est certain que c'est simple avec PDO. Mais c'est plus déroutant si l'on a pas un peu déjà vu la syntaxe POO, alors que la syntaxe mysql classique ressemble plus au code procédural utilisé dans son code.

Tu penses réellement que thekingkong est suffisamment armé pour comprendre PDO plus facilement qu'une requête basique ?

Cela dit après tout, c'est à lui de décider...

Tiens au fait, il me semble qu'il nous manque un tuto sur PDO... si le coeur t'en dis...

str_replace() fonctionne correctement si les entêtes, le code et l'encodage du document sont cohérents.

ouai c'est justement la le probleme dans le principe ca le fait, mais la plupart des demandes sur les forums c'est de la que vient le problème et y'a quand meme beaucoup de reglages (apache, php, encodage du fichier)

While est une fonction multi usage qui permet entre autre de lister la ressource d'une requête, contrairement à un foreach qui ne fonctionne que sur les tableaux. Mais tu n'es pas obligé d'expliquer non plus tous les détails avant de montrer comment récupérer les lignes d'une requête.

oui et non dans le sans ou a chaque appelle de mysql_fetch retourne la ressource de la ligne en cours on pourrais tres bien faire ducoup tant que mysql_fetch_assoc retourne quelque chose dans la condition on continu.

bon apres PDO je comprend ta position et tu as raison (pour le coté object) (ducoup ouai je le lancerai peu etre dans un ptit tuto PDO)

enfaite y'a quelque temps je suis allé a des cours PHP pour débutant (formation + cour fac) juste pour rire, et j'ai vraiment été outré par de debit de conneries que j'ai entendu, je devrais faire un topic la dessus c'était enorme

sinon thekingkong > t'as d'autre table, comme une table categories ? users ?

str_replace() fonctionne correctement si les entêtes, le code et l'encodage du document sont cohérents...
ouai c'est justement la le probleme dans le principe ca le fait, mais la plupart des demandes sur les forums c'est de la que vient le problème et y'a quand meme beaucoup de reglages (apache, php, encodage du fichier)

Il n'y a donc pas de souci avec str_replace() puisque tu me dis que les problèmes viennent d'une mauvaise maîtrise des réglages pour encoder correctement en utf-8.

Et si problème il y a, ils ne se limiteront pas à cette fonction, donc de toutes façons il faut maîtriser l'encodage en utf-8 quand on veut travailler en utf-8, plutôt que d'accuser telle ou telle fonction, qui comme toutes les fonctions travaillent correctement si on les emploient dans le bon contexte.

Par contre même avec un encodage correct, strtr() n'est pas adapté. Cela revient donc à répéter mon post initial :

En utf-8 utilisez str_replace() plutôt que strtr()

j'ai retrouver le site
http://www.weirdog.com/blog/php/supprim ... n_php.html

j'ai retrouver le site
http://www.weirdog.com/blog/php/supprim ... n_php.html

C'est du bidouillage de débutant avec une mauvaise approche du sujet.

Quand on travaille en UTF-8, on travaille en utf-8 avec les règles de l'utf-8 et les fonctions adaptées, et l'on essaye pas de faire des remplacements (sauf cas exceptionnel) pour pouvoir utiliser des fonctions qui ne sont pas adaptées.

Et si l'on veut transformer des fichers d'ISO-8859-1 en UTF-8 (puisque c'était la préoccupation initiale de l'auteur du blog que tu as donné en lien) on a aucun intérêt à remplacer un é par son entité html &eacute, puisqu'il faut faire exactement l'inverse cf cet exemple

D'ailleurs cet exemple comme celui précédemment donné comme référence figurent tous les deux dans ce tuto sur l'encodage en utf-8 qui sans être exhaustif, permet de partir sur de bonnes bases.

Cette parenthèse fermée, il serait temps de revenir au topic initial

Cette parenthèse fermée, il serait temps de revenir au topic initial

ca fait parti du sujet... (la fameuse fonction virer_accents)

faudrait deja savoir l'intérêt de supprimer les accents, parce que moi j'en vois aucun (mais je suis sur que vous grouillez d'exemple).

Quand on autorise un téléchargement de fichier on a tout intérêt de virer les accents, les espaces et autres caractères qui ne permettraient pas d'avoir un chemin de fichier valide accessible par une URL.

Quand on autorise un téléchargement de fichier on a tout intérêt de virer les accents, les espaces et autres caractères qui ne permettraient pas d'avoir un chemin de fichier valide accessible par une URL.

ca c'est faux, url_encode est la pour ca, la ce que tu dis c'est par pur esthétisme (mais un esthétisme qui ne marchera pas pour beaucoup de cas)