Bonjour à tous,
 
 
Je rencontre des problèmes lors que j'essaye d'afficher des données issues de ma table dans lequel sont présent des apostrophes.
 
Exemple pour la phrase " Je suis sous l'arbre. "
Résultat : " Je suis sous l\ "
 
J'ai essayé la fonction addslashes mais ça ne change rien.

 
Merci pour votre aide,
 
José

addslashes ajoute les slashes. stripslashes retire les slashes.

Merci mais ça change rien. Ma phrase se coupe quand même à l'apostrophe dans ma zone de texte.

tu mets ca :
 
value="<?php echo $donnees['description4_informenter']"' />
 
ou si ca commence par un echo '...value='".addslashes($donnees['description4_informenter'])."' />', fais cela :
echo"<input type='text' name='description4' size='100' value=".$donnees['description4_informenter'])." />";
ca devrait marcher

C'est parce que tu a mis value='......'
Dès que le navigateur rencontre une apostrophe, il suppose qu'il s'agit de la fin de la valeur de l'attribut "value". Mets des guillemets.

Merci guybrush02, c'était tout bête en fait

Ou mieux : échappe ton texte avec htmlspecialchars().
Sinon le même problème va surgir si il y a un guillemet dans le texte, etc.

Puisque c'est un formulaire qu'il édite, utiliser htmlspecialchars a cet endroit va rendre son champ inconsistant : lors de la première modification, il y aura les entités HTML pour certaines guillemets (et co) et des "vraies" guillemets pour d'autres. L'idéal serait de faire le htmlspecialchars avant le stockage, pas à l'édition.

J'ai l'impression que tu crois que s'il met du html-encodé dans le value (parce que c'est comme ça qu'on fait en HTML, c'est comme ça que c'est prévu pour que ça marche), il va récupérer du html-encodé en POST... Mais c'est pas le cas. Peut-être même que tu pense que c'est du html-encodé qui va s'afficher, ce qui n'est pas non plus le cas.

Et faire un htmlspecialchars() avant le stockage Stockage dans la BDD, c'est bien ça que tu veux dire j'espère que non

Développe...

Dans une BDD on stocke des données pures et propres. Si je veux stocker "l'histoire de david & jonâthân", je stocke "l'histoire de david & jonâthân", et pas "l\'histoire de david &amp; jon©ùth©ùn".
 
Faut que développe aussi sur pourquoi il faut des données propres en BDD ?

C'est toi qui définis qu'une donnée "pure et propre" est la représentation "classique" de ta chaîne. La sémantique d'une donnée n'est pas universelle, elle est dépendante du domaine d'application.
 
Du point de vue purement relationnel, on se fout complètement de connaître la sémantique des types dont les instances sont stockées. Une donnée n'est propre que si elle satisfait les contraintes d'intégrité, pas parce que tu as décidé unilatéralement sa sémantique.

Non, des données propres sont des données telle qu'on attend qu'elle sortent, sans rien connaitre de la base. Si j'utilise ta BDD dans une autre appli, comment je vais savoir que telle champ est encodé en HTML, tel autre addslashé, tel autre rien du tout ?

Et surtout, quelle logique dans tout ça ?

Et comment tu va faire des recherche de chaines dans ta base, avec un LIKE par ex ? t'es obligé d'html-encoder la chaine recherchée ?

Et si tu veux calculer la taille d'une chaine en SQL tu fait comment ? Tu peux plus, tout est fucké.

Et si la sortie n'est PAS une page HTML ? Faut tout désencoder ? Et si tu veux faire quelque traitement de chaine que ce soit, pareil ?

Et le mec qui passe après toi sur le site dans 5 ans et qui va devoir tout piger, tu veux sa mort ? Faut qu'il fasse des fiches ?

Et les points positifs, ils sont où ?

 
 
C'est la sémantique du champ, pas la sémantique de la donnée.
 
 
Et surtout, quelle logique dans tout ça ?
 
 
Comme je l'ai dit, du point de vue purement relationnel, on ne se préoccupe pas de ces détails. Après, le choix de la sémantique dépend du domaine d'application. Si ses données sont supposées être utilisées dans ce contexte (output html), c'est à lui que revient le choix d'associer cette sémantique ou pas, pas à toi de définir universellement qu'il vaut mieux du raw.
 
 
Et comment tu va faire des recherche de chaines dans ta base, avec un LIKE par ex ? t'es obligé d'html-encoder la chaine recherchée ?
 
 
Et en quoi est-ce un souci d'html-encoder la chaîne ? Ta question n'a de sens qui si on suppose qu'il va effectuer ce genre d'opérations et est donc dépendante du domaine d'application.
 
Et si tu veux calculer la taille d'une chaine en SQL tu fait comment ? Tu peux plus, tout est fucké.
 
 
Qui a définit que la taille d'une chaîne devait être exactement sa longueur ? Et si je définis que la taille d'une chaîne, c'est le nombre de voyelles ? C'est absurde, oui, mais de nouveau ça te montre bien que la sémantique que tu associes n'est pas universelle, et dépendra du domaine dans lequel tu travailles.
 
Et si la sortie n'est PAS une page HTML ? Faut tout désencoder ? Et si tu veux faire quelque traitement de chaine que ce soit, pareil ?  
 
 
Bis repetita.
 
Et le mec qui passe après toi sur le site dans 5 ans et qui va devoir tout piger, tu veux sa mort ? Faut qu'il fasse des fiches ?
 
 
L'évolution du logiciel ou de la source de données est un autre problème. Par ailleurs, peu importe le choix que l'on fait, c'est la documentation qui aidera le type dans 5 ans à s'en sortir. Toi, tu pars du postulat que TA sémantique est universelle, et que tout le monde doit considérer qu'en l'absence de documentation, c'est elle qui prévaut, ce qui est faux.
 
Et les points positifs, ils sont où ?
 
 
 
Je n'ai pas dit qu'il s'agissait d'un meilleur choix *dans l'absolu*. J'ai juste indiqué que s'il se contente d'utiliser cette donnée dans de l'HTML, l'idéal serait qu'il effectue le traitement avant de sauver les données.

C'est pas exactement vrai, certains caractères doivent être échappés (les apostrophes, par exemple, dans les chaînes de caractères) sinon ça fait pêter le SQL et ça ouvre la porte à des failles d'injection sql  
 
Mais l'échappement en question se fait avec la fonction d'échappement spécifique à la DB (en PHP, parce que PHP est débile), habituellement de la forme dbname_escape_datatype (en PHP, parce que les créateurs de PHP sont des imbéciles) (et sauf avec mysql pour qui il faut utiliser mysq_real_escape_string, parce que les devs de mysql sont les seuls à concurrencer ceux de PHP question défaut de matière grise) quand on utilise un PHP version inférieure à 5.1 ou qu'on est trop stupide pour utiliser PDO (parce qu'on est vraiment très con), sûrement pas avec addslashes (qui n'existe que parce que les devs de PHP sont d'incurables crétins)

Nan, c'est très utile dans plein d'autres contextes (échapper une chaine pour générer du JS par ex)

edit : merde j'ai effacé des trucs  sans le vouloir mais masklinn a répondu cf en dessous.

La sémantique du champ est fuckée dans ce cas, parce que c'est d'une stupidité impressionnante.

Aucun rapport.

Simple: c'est crétin, ça n'a aucune raison d'être fait, ça augmente la taille des données stockées en base et ça ne sert strictement à rien.

Dans le relatif comme dans l'absolu, c'est même la pire.

Ca n'a rien d'idéal non.

Et apprends à quoter, parce que te lire comme te répondre c'est un chemin de croix.

Pour stocker tes données, sauf à passer par un ORM, t'es bien obligé de passer par du SQL, donc d'escaper

Tu parles de stocker dans le sens "envoyer", je parle de stocker dans le sens "conserver" (stocker quoi ) (edit ; ouais bon en anglais t'as raison )

Donc est d'accord. Mais certes la précision est utile pour le lecteur

Bah disons que la seconde partie c'est le problème de la DB, habituellement tu t'en contrefous de la manière dont c'est stocké en interne par la DB (enfin pas complètement mais la majorité des détails ne sont pas intéressants), la partie intéressante/importante c'est la manière dont toi tu stockes la donnée, c'est à dire ton interaction avec la db pour lui demander d'effectuer le stockage même

Ca doit bien être la première fois que j'entends que c'est la donnée qui impose la sémantique à un même attribut.
Le typage n'a jamais et n'imposera jamais une sémantique. Ce n'est pas parce qu'il s'agit d'un champ de type "chaîne de caractères" que la sémantique d'une chaîne doit y être associée. Simple exemple (stupide, mais suffisant) : "1" n'a pas la sémantique de 1.  
 
Le typage, comme dans la programmation, n'est qu'un moyen de limiter les mauvais comportements et les erreurs de manipulation. En aucun cas le typage n'est apte à englober (ni même exprimer) la sémantique d'une donnée, et encore moins d'un attribut d'une relation.  
 
 

Oh, et bien entendu, il est universellement reconnu qu'il vaut mieux diminuer la complexité spatiale que la complexité temporelle........
 
 

Tu n'as donc jamais mis les pieds en dehors de ton monde pratique et formatté ?  
 

A la vue du développement et de l'argumentaire exposé, je ne peux que m'incliner.

Un goût de déja-vu dans ce genre de fake-quiproquo

guybrush02, tu devrais te reconvertir dans la politique.
Ce serait mieux pour tout le monde.

Je rêve...

Dans le cas général, oui. Le sacrifice d'espace pour un gain de temps est une optimisation. Il est également reconnu que l'intérêt de flinguer ses données est discutables.
 
Si après test tu conclus que tu pourrais échanger de l'espace pour gagner en performances (ce qui n'est pas nécessairement le cas, il est fréquent que les webapps soient limités par les DBs elle même limitées par leurs accès disque, auquel cas augmenter la taille des données stockées sur le disque va diminuer les perfs plutôt que les augmenter), tu dénormalises proprement en créant une colonne supplémentaire dans laquelle tu vas cacher la version escapée de tes données.

J'ai jamais mis les pieds en dehors du monde pratique non, effectivement. Apparement toi par contre tu vis à 100% dans le monde malpratique.

Voire théorique (et fixé sur une toute petite partie de la théorie), en fait.

 
Tu viens d'anéantir 20 ans d'abstraction et d'Object Design.
Félicitations, t'es pret pour passer à LOGO.

 
figure 1 : je ne connais rien au fonctionnement du web.

Bah même pas, dans le monde théorique tu normalises et tu stockes que les données référence. Les données référence, je vois pas dans quel monde ça peut être les données échappées.

J'avais raté cette partie, mais il vient aussi de chier sur 40 ans de théorie des types

 
Figure 2 : je n'ai pas non plus la moindre expérience d'utilisation d'une base de données dans le monde réel.

 
Liskov doit se retourner dans sa tombe
Fake edit: je sais, je sais, qu'elle est pas morte.

'tain et je passe sur la tentative de justification derrière, c'est juste un étalage d'incompétence...

Oui, ça c'est la partie de la théorie qu'il ne connait pas.

Vu son discours (et son profil, mm si j'ai rien contre les doctorants), qq chose me dit qu'il est fixé sur un petit aspect de la théorie (les types, les relations ?), en se branlant avec ça et en zappant tout le reste. (et ptet mm qu'il dit des conneries sur les types, ça je sais pas )

Sachant que même ce petit aspect de la théorie n'apporte rien au débat. Personne n'a jamais prétendu que le typage imposait un formattage de données. Enfin pas moi

   N'est-ce pas l'inverse que tu préconises dans la situation présente ?
 
 
 

Pour rappel, la phrase à partir de laquelle vous vous êtes amusés àm'incendier, "La sémantique d'une donnée n'est pas universelle, elleest dépendante du domaine d'application." n'a toujours pas vu deréponses autre que "c'est stupide" ou un smiley équivalent (quand aux autres interventions, je regrette vraiment de voir ça sur ce forum).  
 
Pour recentrer : tu dis que personne n'a jamais prétendu que le typage imposait un formattage des données. Pourtant :
 - Tu considères que, sous prétexte qu'un fragment HTML est stocké sous forme de texte, que seule la version brute de ce fragment HTML doit être stocké,  
 - Que ce sont les opérations par défaut associées au type (recherche, longueur, ...) qui doivent dicter la façon avec laquelle la donnée est stockée (par opposition aux opérations qui ont un réel sens sur la donnée). N'imposes-tu pas le formattage de la donnée par rapport aux opérations sur le type ? Est-ce que matcher "Paris - x 75056" quand on recherche "5056" a vraiment le sens de la recherche ?
 
Quitte à paraître borné et m'exposer à d'autres critiques/insultes, prenez au moins la peine de vous renseigner avant d'être aussi désagréables avec les gens. Ce ne sont pas les articles ni les auteurs (Peckham, Wand, Weber, ... pour ne citer qu'eux) sur les ontologies qui manquent.

Je préconise de ne pas optimiser quand il n'y en a pas besoin.

Dans le cas général, oui. Et ce n'est pas un prétexte, un fragment HTML c'est un fragment HTML. Les deux possibilités sont de le stocker en tant que texte (brut) ou en tant que fragment HTML. Aux dernière nouvelles aucune DB ne supporte le stockage de fragments HTML ou SGML, le choix est donc relativement limité.

Pardon

Pas percuté ton problème.

Premature optimisation is the root of all evil...dans le cas présent on perd bien plus qu'on ne gagne. Le champ ne stocke plus du texte mais "du texte échappé pour s'afficher correctement si on l'inclut dans du html", ce qui fausse / influe sur toute autre opération que son affichage dans du html.  
On stocke habituellement des données pour pouvoir les traiter de la manière la plus pratique possible pour la majorité des cas, pas pour que ce soit très simple dans un cas et très prise de tête dans tous les autres.
 
 

 
Hors contexte cette affirmation n'a rien de choquant. En contexte ("on fait du web, donc stocker du code html au lieu de stocker du texte est cohérent" ), c'est juste crétin à tous les niveaux, désolé.  
Tu vas éviter de refaire l'encodage à chaque affichage, mais tu y perds dans tous les autres cas (recherche, exploitation des données ailleurs que sur le web...), pour n'importe-quel développeur qui sait ce qu'il fait c'est juste une hérésie.

Non. La phrase que je te reproche à la base, c'est "L'idéal serait de faire le htmlspecialchars avant le stockage, pas à l'édition."

edit : ceci dit je pourrais aussi te reprocher la phrase que tu cites (séparation des couches, tout ça), mais ce n'est pas le sujet.

Tout ce qui je dis moi, c'est que stocker du HTML en BDD dans le cas présent :
- Ce n'est pas pratique
- Ca n'a aucun intérêt
- C'est la galère à maintenir

Après tes points théoriques sur le typage et autres, tant qu'ils ne contredisent pas ces 3 points, je m'en fiche un peu.

Est-ce que matcher "lorem ipsum &times; titit toto tutu" quand on recherche times a vraiment le sens de la recherche?

On est gentil et on débat tranquillement, sinon je vais baffer