Je suis entrain de faire un système de modification d'article qui passe par l'utilisation d'un textarea :
<?php
include 'database.php';
global $db;
if(isset($_GET['id']) AND !empty($_GET['id'])){
if($_GET['id'] >= 1){
$edit_id = htmlspecialchars($_GET['id']);
$edit_publication = $db->prepare('SELECT * FROM publications WHERE id = :id');
$edit_publication->execute([
'id' => $edit_id
]);
if($edit_publication->rowCount() ==1) {
$edit_publication = $edit_publication->fetch();
$edit_publication = str_replace('<br />', "\n", $edit_publication['content']);
}
else{
die('Erreur ça n\'existe pas');
}
}
}
?><?=htmlspecialchars_decode($edit_publication)?>
On peut remarquer un :
str_replace()
afin de bien traité les sauts de lignes dans le textarea mais je rencontre un problème. Lorsque je j'affiche celui-ci dans le textarea, il apparait un saut de ligne supplémentaire :
Cela me pose un énorme problème comme vous pouvez le voir.
Par ailleurs je remarque que si je modifie le texte en retirant le saut de ligne dans ma base SQL est bien cela fonctionne et je n'ai plus les 2 sauts de ligne.
La première flèche montre qu'il y a un saut de ligne effectuer par la base SQL contrairement à la seconde où j'ai enlever à la main le saut de ligne.
Voici mon code pour intégrer le texte dans la Data Base (sachant que j'utilise une textarea afin de récolter le texte $content) :
de son code. Hors moi je ne peux pas le faire car j'ai derrière un système d'affichage des différent articles à la style Facebook il y a t'il un moyen de régler se problème sans retirer nl2br.
PS : je pense que la solution se trouve avec ma remarque sur la base sql et les sauts de ligne non demander mais je ne sais comment le résoudre.
Le nl2br doit être fait à l'affichage (de même pour htmlspecialchars au passage), pas à l'insertion ! Tu es en train de te complexifier la tâche pour strictement rien. Tu n'aurais pas à faire de htmlspecialchars_decode ni autre str_replace et le pire, avec ce htmlspecialchars_decode, c'est que tu réactives probablement les XSS, oups. Les données stockées en base doivent strictement correspondre à ce que l'utilisateur a saisi, tout traitement ne doit être fait que lors de l'affichage : comment tu veux sinon les retrouver telles quelles, à commencer pour leur édition ?
Et il faut veiller à coller les balises php à celles du textarea aussi
Si tu mets dans un textarea des données issues d'un autre textarea, il n'y a rien à faire de particulier, ni pour l'enregistrement, ni pour l'affichage, car le textarea renvoie le texte avec les sauts de lignes qu'il contient.
Maintenant, si tu veux afficher ce contenu dans un autre conteneur, il te faudra remplacer les sauts de ligne par des balise br via la fonction nl2br($machaine).
Ceci dit, indépendamment des préoccupations d'injection de HTML
Un htmlspecialchars peut être pour les XSS ? :roll: (sauf si le but était vraiment de rédiger en HTML, via un éditeur WYSIWYG - ce qui n'est visiblement pas le cas ici - en prenant d'autres mesures, un htmlspecialchars ne convenant plus)
> il te faudra remplacer les sauts de ligne par des balise br via la fonction nl2br($machaine)
nl2br ne remplace pas, elle ajoute une balise br avant le \r et/ou \n (idem, le nl2br étant à faire après un htmlspecialchars sinon les balises br vont être "échappées")
> Ceci dit, indépendamment des préoccupations d'injection de HTML
Pas sûr de comprendre le sens de cette remarque, ça fait un peu "démerde toi avec". Quitte à intervenir, ce serait tout de même bien de dire aux gens ce qu'ils doivent faire car on voit bien que le PO utilise htmlspecialchars où il ne faut pas et pas où il faudrait (et qu'avec un htmlspecialchars_decode il ne sert même pas à grand chose, une XSS en étant du coup réactivée).
« nl2br ne remplace pas, elle ajoute une balise br avant le \r et/ou \n »
nl2br Prononcez nl to br, soit en français nl par br.
Cette fonction fait ce qu'elle dit phonétiquement (avec un petit jeu de mot à la U2) : elle converti les sauts de ligne en '<br>' dont, non, elle n'ajoute pas de "/n", elle les remplace.
> Retourne string après avoir inséré <br /> ou <br> devant toutes les nouvelles lignes (\r\n, \n\r, \n et \r).
Donc, non, désolé, elle ne remplace pas les \r et/ou \n par des balises br, ils [les \r et/ou \n] sont toujours là après un nl2br. Le code du PO, avec son simple str_replace des balises br au SELECT et nl2br à l'INSERT, multiplies en plus par 2 les sauts de ligne à chaque édition.
A titre purement informatif puisque je réitère que nl2br devrait être employé à l'affichage/SELECT, pas à l'INSERT, si on voulait vraiment remplacer les \r et/ou \n par br, il faudrait employer : $out = preg_replace('~\R~', '<br>', $in);
Le nl2br doit être fait à l'affichage (de même pour htmlspecialchars au passage), pas à l'insertion ! Tu es en train de te complexifier la tâche pour strictement rien. Tu n'aurais pas à faire de htmlspecialchars_decode ni autre str_replace et le pire, avec ce htmlspecialchars_decode, c'est que tu réactives probablement les XSS, oups. Les données stockées en base doivent strictement correspondre à ce que l'utilisateur a saisi, tout traitement ne doit être fait que lors de l'affichage : comment tu veux sinon les retrouver telles quelles, à commencer pour leur édition ?
Et il faut veiller à coller les balises php à celles du textarea aussi
- Edité par julp 26 novembre 2021 à 22:00:08
Ok, mais pour le htmlspecialchars, j'ai toujours vu sur les forums de le mettre pour ne pas mettre n'importe quoi dans la base de donnée, non ?
Il ne faut pas reprendre toutes les conneries qu'on peut trouver sur Internet. Tu trouves logique de faire un htmlspecialchars des données qui vont en base, toi ? C'est contre-productif à tous les égards !
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
julp.fr ~ PHP < 8.0.0 : activer les erreurs PDO/SQL ~ PHP < 8.1.0 : activer les erreurs mysqli
julp.fr ~ PHP < 8.0.0 : activer les erreurs PDO/SQL ~ PHP < 8.1.0 : activer les erreurs mysqli
julp.fr ~ PHP < 8.0.0 : activer les erreurs PDO/SQL ~ PHP < 8.1.0 : activer les erreurs mysqli
julp.fr ~ PHP < 8.0.0 : activer les erreurs PDO/SQL ~ PHP < 8.1.0 : activer les erreurs mysqli