[Résolu] Problème d'échappement d'apostrophes

Problème d'échappement d'apostrophes [Résolu] - PHP - Programmation

Marsh Posté le 10-05-2009 à 11:56:57    

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.

Code :
  1. <input type='text' name='description4' size='100' value='".addslashes($donnees['description4_informenter'])."' />


 
Merci pour votre aide,
 
José


Message édité par antitrust56 le 10-05-2009 à 18:15:18
Reply

Marsh Posté le 10-05-2009 à 11:56:57   

Reply

Marsh Posté le 10-05-2009 à 13:36:43    

addslashes ajoute les slashes. stripslashes retire les slashes.

Reply

Marsh Posté le 10-05-2009 à 14:43:27    

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

Reply

Marsh Posté le 10-05-2009 à 14:55:27    

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 ;)

Reply

Marsh Posté le 10-05-2009 à 14:56:08    

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.

Reply

Marsh Posté le 10-05-2009 à 18:14:20    

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


Message édité par antitrust56 le 10-05-2009 à 18:14:44
Reply

Marsh Posté le 10-05-2009 à 20:24:21    

guybrush02 a écrit :

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.


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.


---------------
Contes de fées en yaourt --- --- zed, souviens-toi de ma dernière lettre. --- Rate ta musique
Reply

Marsh Posté le 11-05-2009 à 08:20:33    

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.

Reply

Marsh Posté le 11-05-2009 à 14:30:31    

guybrush02 a écrit :

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 [:pingouino dei] [:pingouino dei] [:pingouino dei] Stockage dans la BDD, c'est bien ça que tu veux dire [:pingouino dei] j'espère que non :/

Message cité 1 fois
Message édité par theredled le 11-05-2009 à 14:32:29

---------------
Contes de fées en yaourt --- --- zed, souviens-toi de ma dernière lettre. --- Rate ta musique
Reply

Marsh Posté le 11-05-2009 à 14:47:08    

theredled a écrit :

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


Développe...

Reply

Marsh Posté le 11-05-2009 à 14:47:08   

Reply

Marsh Posté le 11-05-2009 à 14:50:21    

guybrush02 a écrit :


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 ?


---------------
Contes de fées en yaourt --- --- zed, souviens-toi de ma dernière lettre. --- Rate ta musique
Reply

Marsh Posté le 11-05-2009 à 15:19:42    

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.

Reply

Marsh Posté le 11-05-2009 à 15:29:14    

guybrush02 a écrit :

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ù ?

 

[:petrus75]

Message cité 1 fois
Message édité par theredled le 11-05-2009 à 15:30:23

---------------
Contes de fées en yaourt --- --- zed, souviens-toi de ma dernière lettre. --- Rate ta musique
Reply

Marsh Posté le 11-05-2009 à 15:42:04    

theredled a écrit :


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 ?


 
 
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.

Reply

Marsh Posté le 11-05-2009 à 15:45:25    

theredled a écrit :

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".


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 :o  
 
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)


---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 11-05-2009 à 15:47:47    

masklinn a écrit :

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.


Message édité par theredled le 11-05-2009 à 15:50:40

---------------
Contes de fées en yaourt --- --- zed, souviens-toi de ma dernière lettre. --- Rate ta musique
Reply

Marsh Posté le 11-05-2009 à 15:48:41    

guybrush02 a écrit :

C'est la sémantique du champ, pas la sémantique de la donnée.


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

guybrush02 a écrit :

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.


Aucun rapport.

guybrush02 a écrit :

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.


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.

guybrush02 a écrit :

Qui a définit que la taille d'une chaîne devait être exactement sa longueur ?


 [:k-nar]

guybrush02 a écrit :

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.


 [:paco ty]

guybrush02 a écrit :

Je n'ai pas dit qu'il s'agissait d'un meilleur choix *dans l'absolu*.


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

guybrush02 a écrit :

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.


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.

theredled a écrit :


Hého :o

 

Je parle pas de l'échappement des données dans la requête évidemment, mais de leur stockage :o


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

Message cité 2 fois
Message édité par masklinn le 11-05-2009 à 15:49:56

---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 11-05-2009 à 15:52:27    

masklinn a écrit :


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


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

 

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

Message cité 1 fois
Message édité par theredled le 11-05-2009 à 15:54:34

---------------
Contes de fées en yaourt --- --- zed, souviens-toi de ma dernière lettre. --- Rate ta musique
Reply

Marsh Posté le 11-05-2009 à 15:55:59    

theredled a écrit :


Tu parles de stocker dans le sens "envoyer", je parle de stocker dans le sens "conserver" (stocker quoi :o) (edit ; ouais bon en anglais t'as raison [:thalis])
 
Donc est d'accord. Mais certes la précision est utile pour le lecteur :o


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 :)


---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 11-05-2009 à 15:58:44    

masklinn a écrit :


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


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.  
 
 

masklinn a écrit :


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.


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é ?  
 

masklinn a écrit :


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


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

Reply

Marsh Posté le 11-05-2009 à 15:58:49    

masklinn a écrit :


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 :)


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


---------------
Contes de fées en yaourt --- --- zed, souviens-toi de ma dernière lettre. --- Rate ta musique
Reply

Marsh Posté le 11-05-2009 à 15:59:01    

http://static.ngcdn.net/data/seal-approval.png

Reply

Marsh Posté le 11-05-2009 à 15:59:58    

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


---------------
Contes de fées en yaourt --- --- zed, souviens-toi de ma dernière lettre. --- Rate ta musique
Reply

Marsh Posté le 11-05-2009 à 16:01:18    

Je rêve...

Reply

Marsh Posté le 11-05-2009 à 16:03:56    

guybrush02 a écrit :

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.


 [:prozac]  

guybrush02 a écrit :

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


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.

guybrush02 a écrit :

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


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


---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 11-05-2009 à 16:05:37    

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


---------------
Contes de fées en yaourt --- --- zed, souviens-toi de ma dernière lettre. --- Rate ta musique
Reply

Marsh Posté le 11-05-2009 à 16:07:53    

guybrush02 a écrit :

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.


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

Reply

Marsh Posté le 11-05-2009 à 16:08:11    

guybrush02 a écrit :

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.


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


---------------
Can't buy what I want because it's free -
Reply

Marsh Posté le 11-05-2009 à 16:08:17    

theredled a écrit :

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


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.

Not Amused a écrit :

Tu viens d'anéantir 20 ans d'abstraction et d'Object Design.


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

Message cité 2 fois
Message édité par masklinn le 11-05-2009 à 16:09:15

---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 11-05-2009 à 16:09:26    

guybrush02 a écrit :

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.


 
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.


---------------
Can't buy what I want because it's free -
Reply

Marsh Posté le 11-05-2009 à 16:11:45    

masklinn a écrit :


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


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

Reply

Marsh Posté le 11-05-2009 à 16:12:06    

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


---------------
Can't buy what I want because it's free -
Reply

Marsh Posté le 11-05-2009 à 16:13:40    

masklinn a écrit :


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.


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 :o)

 

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 :o

Message cité 1 fois
Message édité par theredled le 11-05-2009 à 16:16:33

---------------
Contes de fées en yaourt --- --- zed, souviens-toi de ma dernière lettre. --- Rate ta musique
Reply

Marsh Posté le 11-05-2009 à 17:56:56    

masklinn a écrit :

Le sacrifice d'espace pour un gain de temps est une optimisation.  


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

theredled a écrit :


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 :o)
 
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 :o


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.

Reply

Marsh Posté le 11-05-2009 à 18:08:36    

guybrush02 a écrit :

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


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


---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 11-05-2009 à 18:11:29    

guybrush02 a écrit :

- 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é


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é.

guybrush02 a écrit :

- 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).


Pardon [:petrus dei]

guybrush02 a écrit :

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 ?


Pas percuté ton problème.


---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 11-05-2009 à 18:20:29    

guybrush02 a écrit :

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


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.
 
 

guybrush02 a écrit :

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).


 
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.


---------------
Can't buy what I want because it's free -
Reply

Marsh Posté le 11-05-2009 à 18:21:16    

guybrush02 a écrit :


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).


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.

 
guybrush02 a écrit :

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.


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.


Message édité par theredled le 11-05-2009 à 18:35:57

---------------
Contes de fées en yaourt --- --- zed, souviens-toi de ma dernière lettre. --- Rate ta musique
Reply

Marsh Posté le 11-05-2009 à 18:22:36    

guybrush02 a écrit :

Est-ce que matcher "Paris - x 75056" quand on recherche "5056" a vraiment le sens de la recherche ?

 

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


Message édité par skeye le 11-05-2009 à 18:24:36

---------------
Can't buy what I want because it's free -
Reply

Marsh Posté le 11-05-2009 à 18:30:28    

On est gentil et on débat tranquillement, sinon je vais baffer [:shakalagoons]

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed