Sécurité de données récupérées d'un formulaire traitées en PHP et SQL

Je cherche à résoudre un problème de sécurité qui devrait être très classique mais pour lequel je ne trouve que des solutions partielles. Quelqu'un aurait-il une solution complète qui marche partout ?

4 actions possibles :
1) J'obtiens du texte, avec un formulaire <textarea> (il peut contenir des retours à la ligne).

2) Je mets le contenu dans une base SQL

3) Je récupère ce texte de la base SQL pour la remettre dans le textearea ("value") afin de le présenter à la modification

4) Je le prends dans la base SQL pour l'afficher en HTML entre <p> et </p>

Suivant que je suis sur mon PC (j'utilise WAMP) ou sur mon serveur (OVH), je n'obtiens pas la même chose. J'ai essayé mysql_real_escape_string et htmlspecialchars pour 1). Il semble que sur wamp, les "\" ajoutés ne passent pas dans la base alors que sur OVH ils passent. Pour les enlever, j'utilise stripslashes, mais quand il y a des "\l\n", cela enlève l'antislash et je me retrouve avec les caractères "ln" au lieu d'un retour à la ligne. J'utilise aussi nl2br pour la phase 4). Bref, je tourne en rond et il y a toujours quelque chose qui cloche !

Merci de votre aide.

Je réponds à ma propre question , au moins partiellement, car cela peut intéresser d'autres personnes. J'ai trouvé dans les FAQ une réponse partielle : mon serveur WAMP a (get_magic_quotes_gpc) à 0 alors que celui de mon serveur OVH l'a à 1. Cela veut dire que ce dernier rajoute des antislash dans les GET, POST et Cookies.

Cela étant dit, voici ma réponse à l'heure actuelle :
1) à la sortie des POST et des GET, utiliser la fonction stripslashes pour enlever les antislashs rajoutés automatiquement si get_magic_quotes_gpc est à 1. Sinon, cela ne fait pas de mal, tout au moins si on ne s'attend pas à avoir des antislash.

2) quand on écrit la requête SQL, on protège les données par mysql_real_escape_string : on notera que les retor à la ligne et les caractères spéciaux se retrouvent tels quels dans la base

3) Quand on veut afficher dans le textearea, on n'a aucune précaution particulière à avoir. On prend le texte venant de la base SQL tel quel.

4) Enfin, quand on veut afficher en HTML, on applique d'abord htmlspecialchars qui transforme en particulier les < et >, mais aussi les divers guillemets.. Puis on applique nl2br qui remplace les retour à la ligen par la balise <br />

Si quelqu'un peut revoir ma copie...

Encore une fois, après essai, je corrige ma propre réponse en réécrivant tout pour une meilleure lecture :

1) à la sortie des POST et des GET, utiliser la fonction stripslashes pour enlever les antislashs rajoutés automatiquement si get_magic_quotes_gpc est à 1. Sinon, cela ne fait pas de mal, tout au moins si on ne s'attend pas à avoir des antislash. On en profite pour appliquer htmlspecialchars de façon à ne plus avoir de "vrais" guillemets ou signes ">" et "<".

2) quand on écrit la requête SQL, on protège les données par mysql_real_escape_string : on notera que les retour à la ligne se retrouvent tels quels dans la base. Par contre, les guillemets, < et > ont été convertis en 1). Les antislashs ajoutés par mysql_real_escape_string ne sont pas mis dans la base.

3) Quand on veut afficher dans le textearea, on n'a aucune précaution particulière à avoir. On prend le texte venant de la base SQL tel quel. Les "<" et ">" qui auraient pu gêner (cf. ma première solution plus haut) ont été convertis par htmlspecialchars en 1)

4) Enfin, quand on veut afficher en HTML, on applique nl2br qui remplace les retour à la ligne par la balise <br />. Les autres caractères ont été convertis en 1) avant mise dans la base SQL.

Si quelqu'un peut revoir ma copie...