Tout ce que tu m'expliques sur les simples et doubles quotes, je le sais, c'est justement la raison de ma question.
A l'envoie du $_Post, les \r et \n ne sont pas exécutés.
Donc au moment de ton test de strings, il faut tester les caractères \r et \n en clair avant de les envoyer à la boite mail, et donc utiliser les simples quotes.
C'est donc pour moi totalement illogique d'utiliser les doubles quotes dans ce cas précis, mais encore une fois il m'arrive souvent de me tromper...

Pour la deuxième partie de ton message, vue que l'on est en france, les caractères accentués sont utilisés assez souvent dans les Posts, et donc je trouve plus que judicieux de les convertir surtout quand ta page est encodée en UTF-8.
Mais je suis certain, que tu es d'accord avec moi sur ce point maintenant, donc sujet clos pour le htmlentities, enfin si tu le permets évidemment.

Pour la deuxième partie de ton message, vue que l'on est en france, les caractères accentués sont utilisés assez souvent dans les Posts, et donc je trouve plus que judicieux de les convertir surtout quand ta page est encodée en UTF-8.
Mais je suis certain, que tu es d'accord avec moi sur ce point maintenant, donc sujet clos pour le htmlentities, enfin si tu le permets évidemment.

Comment te faire comprendre qu'il n'y a pas besoin de convertir un 'é' en 'é' pour faire afficher un 'é' dans une page codée en UTF-8
Encore une fois (déjà dit) ce forum est codé en UTF-8, les post envoyés affichent bien les caractères accentués, et malgré tout lorsque tu affiches le code source de la page tu vois bien des 'é' et non pas des 'é'

Le plus simple est de faire un simple test:

<?php
header('Content-Type: text/html; charset=UTF-8');
echo 'Non convertis: éèàù';
echo 'Convertis: ' . htmlentities('éèàù', ENT_QUOTES, 'UTF-8');
?>

Bon et bien les caractères accentués s'affichent bien quand le document est lui-même enregistré en UTF-8 aussi.
Il n'empêche que la fonction htmlentities fonctionne en UTF-8 de cette façon et convertit donc tous les caractères.
Par contre, j'avoue que l'intèrêt de htmlentities est finalement discutable...
A part l'affichage des caractères accentués d'une page en UTF-8 avec un autre encodage.
Bon ben, tu avais raison sur ce point, j'ai encore appris un truc ce soir

Merci à vous tous pour vos conseils et votre aide...

J'ai modifié mon code dans "mail.php" :

<?php

					
					$nom=$_POST['nom'];
					$email=$_POST['email'];
					$sujet=$_POST['sujet'];
					$message=$_POST['message'];
					
					// coupe le message en lignes de 70 caractères max
					$message=wordwrap($message, 70); //Dans le cas où nos lignes comportent plus de 70 caractères, nous les coupons en utilisant wordwrap()
					$destinataire='[email protected]';
					
					$headers  = 'MIME-Version: 1.0' . "\r\n";
					$headers .= 'Content-type: text/html; charset=utf-8' . "\r\n";
					$headers .= 'From: '.$nom.' <'. $email.' >' . "\r\n";
					
					if(mail($destinataire, $sujet, $message, $headers))
					{
						header('Location: merci.php');
					}
					else
					{
						header('Location: erreur.php');
					}
					
					unset($nom, $email, $sujet, $message, $headers) ;
?>

Maintenant, je n'ai plus de problème : Yahoo! affiche correctement les caractères spéciaux et les accents. Pour info, je n'ai modifié que cela : je n'ai pas changé le charset dans .htaccess (qui est utf-8), la BdD est aussi en utf-8.

Bref, tout va pour le mieux... =D>

Seul problème maintenant, comment me protéger du spam ? Comment éviter l'insertion de code html via les champs à remplir ? Avec htmlentities ? Est-il nécessaire de me prémunir contre les injections SQL sachant que je n'ai pas mis de code pour me conecter à la BdD ?

Mais, ceci est une autre histoire

Maintenant, je n'ai plus de problème : Yahoo! affiche correctement les caractères spéciaux et les accents. Pour info, je n'ai modifié que cela : je n'ai pas changé le charset dans .htaccess (qui est utf-8), la BdD est aussi en utf-8.
Bref, tout va pour le mieux... =D>

Cool et puis maintenant tu sais comment fonctionne htmlentities...

Seul problème maintenant, comment me protéger du spam ?

De cette façon:
remplace:

$nom=$_POST['nom'];
$email=$_POST['email'];
$sujet=$_POST['sujet'];
$message=$_POST['message'];

Par:

$regex_head = '/[\n\r]/';
$nom = trim(preg_replace($regex_head, '', $_POST['nom']));
$email = trim(preg_replace($regex_head, '', $_POST['email']));
$sujet = trim($_POST['sujet']);
$message = trim($_POST['message']);

Comment éviter l'insertion de code html via les champs à remplir ?

Tout en gardant à l'esprit que le mieux étant à mon avis de filtrer plus strictement les $_Post, pour cela je te conseil de regarder du côté de preg_match() et preg_replace()...
De plus en recherchant sur le forum, tu trouveras pleins d'exemples..
Sinon tu sais maintenant que t'a boite mail fait elle-même la conversion htmlentities ou htmlspecialchars()...

Est-il nécessaire de me prémunir contre les injections SQL sachant que je n'ai pas mis de code pour me conecter à la BdD ?

Sinon regarde par exemple ici:
php-debutant/intval-mysql-real-escape-s ... 49902.html

Ouuuppppssss ! J'ai été un peu trop vite...

Finalement, il y a des erreurs.
Quand je mets dans mon message ou dans le sujet un backslash, un slash, un guillemet double ou un guillemet simple je me retrouve toujours avec un backslash devant. Exemple : c'est "con" devient c\'est \"con\"

Je fais comment ? Sachant qu'un htmlentities en spécifiant UTF-8 ne donne rien de mieux (et c'est pire !)

Test Comme Cela:

remplace:

$nom=$_POST['nom'];
$email=$_POST['email'];
$sujet=$_POST['sujet'];
$message=$_POST['message'];

Par:

$regex_head = '/[\n\r]/';
$nom = trim(stripslashes(preg_replace($regex_head, '', $_POST['nom'])));
$email = trim(stripslashes(preg_replace($regex_head, '', $_POST['email'])));
$sujet = trim(stripslashes($_POST['sujet']));
$message = trim(stripslashes($_POST['message']));

Ps:
je t'invite à te documenter sur ces fonctions:
http://fr.php.net/htmlentities
http://www.php.net/manual/fr/function.trim.php
http://fr.php.net/stripslashes
http://fr.php.net/manual/fr/function.preg-replace.php

Et sinon:

Lorsque magic_quotes est activé, tous les caractères ' (guillemets simples), " (guillemets doubles), \ (antislash) et NUL sont échappés avec un antislash.

Ce qui expliquerai les antishash...

Cela vient effectivement de la configuration get_magic_quotes_gpc du serveur.

Dans ton cas elle est sur "on" ce qui insère automatiquement des anti slashes dans les variables gpc (GET, POST, COOKIE). Mais la recommandation (norme actuelle par défaut) est de mettre cette configuration sur "off" donc à terme elle sera sur "off" et à ce moment là tu devras re modifier ton code en enlevant les stripslashes.

D'où l'intérêt de vérifier la config serveur, et ton code sera valide quelle que soit la configuration get_magic_quotes_gpc du serveur. Donc tu es plus tranquille et tu n'auras pas besoin de modifier ton code à l'avenir en faisant comme ci-dessous :

function Verif_magicquotes ($chaine)
{
if (get_magic_quotes_gpc()) $chaine = stripslashes($chaine);

return $chaine;
} 

$regex_head = '/[\n\r]/';

$nom = trim(preg_replace($regex_head, '', Verif_magicquotes($_POST['nom'])));
$email = trim(preg_replace($regex_head, '', Verif_magicquotes($_POST['email'])));
$sujet = trim(Verif_magicquotes($_POST['sujet']));
$message = trim(Verif_magicquotes($_POST['message']));

@Dr@ke C'est aussi bien que tu aies supprimé ton dernier message

function Verif_magicquotes ($chaine)
{
if (get_magic_quotes_gpc()) $chaine = stripslashes($chaine);
return $chaine;
}

$regex_array = array('\r\n', '\n', '\r');

$nom = trim(Verif_magicquotes(str_replace($regex_array, '', $_POST['nom'])));
$email = trim(Verif_magicquotes(str_replace($regex_array, '', $_POST['email'])));
$sujet = trim(Verif_magicquotes($_POST['sujet']));
$message = trim(Verif_magicquotes($_POST['message']));

Ca fonctionne beaucoup mieux maintenant...

Ps: m'apprendra a ne pas tester...

function Verif_magicquotes ($chaine)
{
if (get_magic_quotes_gpc()) $chaine = stripslashes($chaine);
return $chaine;
}

$regex_array = array('\r\n', '\n', '\r');

$nom = trim(Verif_magicquotes(str_replace($regex_array, '', $_POST['nom'])));
$email = trim(Verif_magicquotes(str_replace($regex_array, '', $_POST['email'])));
$sujet = trim(Verif_magicquotes($_POST['sujet']));
$message = trim(Verif_magicquotes($_POST['message']));

Ca fonctionne beaucoup mieux maintenant...

Ps: m'apprendra a ne pas tester...

ça fonctionne moyen voir pas pour ce qui est de la protection des injections de retours lignes
Il faudrait écrire

$regex_array = array("\r\n", "\n", "\r");

pour les mêmes raisons que j'écrivais avec des doubles quotes

function Protege_header($value)
                {
                        $value = str_replace("\n", "", str_replace("\r", "", $value));
                        return $value;
                }

Relis ce que j'en disais plus haut
Une doc complémentaire ici

Donc je remet mon code initial (qui était plus lisible) avec la fonction trim et Verif_magicquotes
(cela dit ton code avec regex array est également bon pour peu que tu mette les éléments de ton tableau entre double quote)

function Verif_magicquotes ($chaine)
{
if (get_magic_quotes_gpc()) $chaine = stripslashes($chaine);
return $chaine;
}

function Protege_header($value)
{
$value = str_replace("\n", "", str_replace("\r", "", $value));
return $value;
}

                $nom = trim(Protege_header(Verif_magicquotes($_POST['nom'])));
                $email = trim(Protege_header(Verif_magicquotes($_POST['email'])));
                $sujet = trim(Verif_magicquotes($_POST['sujet']));
                $message = trim(Verif_magicquotes($_POST['message']));

Et puis réfléchis à deux fois avant de me dire (comme dans le post que tu as supprimé) que la fonction stripslashes va supprimer les \ des caractères invisibles de retour ligne "\n" ou "\r" sinon

Bon tu as l'air de t'énerver, mais maintenant je prend un peu de temps pour tester...
Il est logique d'utiliser les simples guillemets, prend un peu de distance...
J'ai essayé de t'expliquer mais bon...
Bien c'est pas compliqué -> Démonstration:

<?php
header('Content-Type: text/html; charset=UTF-8');
$text = $_POST['envoye'];
$regex_array = array('\r\n', '\n', '\r');
$regex_array2 = array("\r\n", "\n", "\r");
$nom = $text;
$nom2 = trim(str_replace($regex_array2, '', $text));
$nom3 = trim(str_replace($regex_array, '', $text));
if (isset($_POST['envoye'])) {
echo 'en clair: ';
var_dump($nom);
echo 'ta methode: ';
var_dump($nom2);
echo 'la mienne: ';
var_dump($nom3);
}
?>
<form action="#" method="post">
<table summary="Free IP INFO">
<tr>
<td><input type="radio" name="envoye" value='ggg\r\ncxc' onclick="submit();" /><b>Ok</b>&nbsp;</td>
</tr>
</table>
</form>

Tu véras que ce qui est reçue au moment du Post est en clair, et non exécuté, un conseil met à jour tous tes formulaires mails
Car ta méthode avec les doubles guillemets ne sert a rien du tout...

[EDIT]
Oups j'oubliais: non met


[EDIT2]
Ryle et Zeus m'avaient fais un super Topo sur les guillemets, ce n'est pas pour rien

Bon tu as l'air de t'énerver, mais maintenant je prend un peu de temps pour tester...
Il est logique d'utiliser les simples guillemets, prend un peu de distance...
J'ai essayé de t'expliquer mais bon...
Bien c'est pas compliqué -> Démonstration:

<?php
header('Content-Type: text/html; charset=UTF-8');
$text = $_POST['envoye'];
$regex_array = array('\r\n', '\n', '\r');
$regex_array2 = array("\r\n", "\n", "\r");
$nom = $text;
$nom2 = trim(str_replace($regex_array2, '', $text));
$nom3 = trim(str_replace($regex_array, '', $text));
if (isset($_POST['envoye'])) {
echo 'en clair: ';
var_dump($nom);
echo 'ta methode: ';
var_dump($nom2);
echo 'la mienne: ';
var_dump($nom3);
}
?>
<form action="#" method="post">
<table summary="Free IP INFO">
<tr>
<td><input type="radio" name="envoye" value='ggg\r\ncxc' onclick="submit();" /><b>Ok</b>&nbsp;</td>
</tr>
</table>
</form>

Tu véras que ce qui est reçue au moment du Post est en clair, et non exécuté, un conseil met à jour tous tes formulaires mails
Car ta méthode avec les doubles guillemets ne sert a rien du tout...

[EDIT]
Oups j'oubliais: non met


[EDIT2]
Ryle et Zeus m'avaient fais un super Topo sur les guillemets, ce n'est pas pour rien

Ryle et Zeus ne t'ont pas tout dis...

Bon je t'en dirai plus demain, mais si tes formulaires d'envoi de mail sont comme ce que tu préconises, tu as du souci à te faire. Au passage as-tu lu mon lien qui expliquait cela dans le détail ?

Sinon mes smiles sont sur le ton de la plaisanterie. Cela m'amuse assez que tu m'explique des choses sans avoir compris le fond du problème (idem que pour htmlentities avec l'UTF-8).

Je ne remet pas en cause ton niveau de programmation général, mais sur php tu as de grooosses lacunes qu'il te sera d'autant plus long à combler que tu réponds du tac au tac sans connaître les subtilités du langage.

Et puis quand bien même on indiquerait une chaine de caractères entre double quote alors qu'elle pourrait être entre simples quotes, cela ne nécessite pas pour autant une mise à jour du code puisqu'on obtient le même résultat. Les optimisations ne se situes pas à ce niveau là.

Par contre dans le sujet dont nous parlons, les doubles quotes sont indispensables avec un str_replace sur les \n et \r , sinon cela ne remplace rien.

Ton test n'est pas valide car non adapté à ce qu'il faut tester.

Pour faire quelque chose de correct il faut que tu testes avec un champ textarea dans lequel tu inséreras des retours lignes.
Ensuite tu appliques tes différentes fonctions pour supprimer les retours lignes et tu testes le résultat avec par exemple :

if (strpos($variable, "\n") !== false) echo '\n trouvé';

Je ne m'énerve pas, mais bon niveau "distance" comme tu dis... justement tu n'a pas assez de recul ou de connaissances suffisantes pour pouvoir parler de php sans réfléchir un peu plus que maintenant

Tu crois réellement que pour pirater un formulaire d'envoi de mail il suffit d'écrire des \r ou \n dans le champ de saisie ? Ben ça prouve que tu n'as pas lu le lien que je t'ai donné dans mon précédent post.

Avant de savoir encore faut-il apprendre. Après peut-être tu pourras m'expliquer

sur php tu as de grooosses lacunes qu'il te sera d'autant plus long à combler que tu réponds du tac au tac sans connaître les subtilités du langage.
Avant de savoir encore faut-il apprendre. Après peut-être tu pourras m'expliquer

T'as du oublier un ou deux o à grosses lacunes


C'est l'ajout des caractères chr(13) et chr(10) dans un Post qui pose problème et donc la syntaxe de \r et \n fonctionne mais prête largement à confusion surtout dans ce cas précis...
D'où l'illogisme qui s'en dégage...
Car les caractères \r et \n, comme le démontre mon script, ne sont pas interprétés au moment du Post mais seulement à l'affichage des données.

Donc les saut de lignes dans les textarea... dont tu parles, n'ont rien avoir avec \r et \n.
"\r" et "\n" dans un str_replace sont juste un moyen de les détecter...
Ceux-ci sont d'ailleurs très souvent insérés en clair dans les headers des mails...

Je pense que dans les notions en Php ,dont tu parles, on peut souligner l'importance de l'utilisation de la bonne syntaxe.
Et encore plus en développement...
Je pense aussi que mon code était plus que correct pour détecter des \r et \n en clair.
Et pour les chr(13) et chr(10), avec cette syntaxe, maintenant oui je suis d'accord

La bonne syntaxe:

function Verif_magicquotes ($chaine)
{
if (get_magic_quotes_gpc()) $chaine = stripslashes($chaine);
return $chaine;
}

$regex_array = array(chr(13).chr(10), chr(10), chr(13));

$nom = trim(Verif_magicquotes(str_replace($regex_array, '', $_POST['nom'])));
$email = trim(Verif_magicquotes(str_replace($regex_array, '', $_POST['email'])));
$sujet = trim(Verif_magicquotes($_POST['sujet']));
$message = trim(Verif_magicquotes($_POST['message']));

Salut les gens,

@AB: Les préconisations dont tu parles sont interressantes. Te serait-il possible d'en faire un résumé
et le rendre disponible en section Faq ou contributions... voir un exemple les regroupants ?. Le sujet,
à mon avis, s'y prête assez bien.

Le topic, malheureusement, tourne un peu en rond. Les méthodes (les fonctions) que tu exposes,
bien qu'évidentes, se diluent dans le discour, contradictoire, d'un autre.

Si ca t'es possible, je pense que ca en ravirait d'autres que moi

@+ bon code