Vu ce qui as été dit, d'ici il semble que ce soit toi qui ait un point de vue biaisé. Ce que tu dis est correct à chaque fois lorsque du parles de théorie, au sens "il y a au moins un cas ou ton affirmation est vrai".

Ce qui t'es opposé en face c'est l'usage, les attentes et pratiques de diverses personnes utilisant (et ré-utilisant) du code et des bases de données régulièrement. Ils ne peuvent te prouver qu'il vaut mieux faire ce qu'ils te disent, sauf s'ils trouvaient par exemple :
- Une étude sur le %age de bases pré-encodées et le %age de gens qui s'attendent ou non à du pré-encodé, dans ce cas tu peut faire un bayésien pour savoir quel comportement décevra le moins de personnes.
- Ou alors du coté perf, si on compare le tradeof du coût cpu de l'encodage à la sortie vs. l'augmentation du remplissage du cache à cause des champs plus gros vs. le ratio lecture écriture.
- Ou alors si on regarde combien de fois on a finalement besoin d'envoyer un fragment de données text ou html via du javascript, ce qui interfère sur l'encoding, et si on est vraiment précis on peut ajouter le problème du code inséré dans un cdata ou non, plus quelques trucs bizarres avec les commentaires html qui dépendent du contexte.
- On peut aussi regarder si les gens s'énervent quand ils ne peuvent pas explorer de manière pratique dans une GUI la base de donnée...

Au final on peut prendre tout ces paramètres, les mesurer, tenter d'évaluer leur importance et conclure quelque chose aussi précisément que possible, mais c'est chiant et c'est pas le comportement qu'on a l'habitude d'employer en tant qu'humains.
On fait cette évaluation à l'arrache, de tête et sans même s'en rendre compte et on arrive à un tel haut score d'emmerdement prévu qu'on réponds "Il ne faut JAMAIS le faire, c'est stupide" (ce qui est à strictement parler, faux, on arrive à trouver des contre-exemples). C'est faux, mais c'est plus simple, ça couvre 99% des cas actuels, et le jour suivant on se sera économisé tout le raisonnement en se basant directement sur cette conclusion.
Ça a un risque, les points qui nous ont fait se décider peuvent changer d'importance avec le temps, ou cesser d'exister, d'autres peuvent apparaitre, et on finit par ne plus être en phase avec la réalité, c'est vers là qu'on tombe dans le Cargo-cultisme par exemple. Normalement si on est pas trop stupide, on finit par remarquer que son taux de succès baisse, et on prends le temps de faire une ré-évaluation pifométrique. Si on a trop souvent de baisse de taux de succès, on fait une évaluation complète scientifique, et on ponds une théorie.

Ta vision théorique n'est pas inutile, mais les batailles d'arguments que tu peut gagner (ou dumoins qu'en face on ne peut qu'éviter de perdre en avortant le débat avec un smiley) ne servent à rien, on ne cherche pas ce qui est strictement vrai ou faux, on cherche ce qui est le moins souvent faux et le plus facile à décider, on cherche l'usage commun (et à partir de là, on peut recommencer à se battre parcequ'on a tous une expérience limitée, donc une vision biaisée de l'usage commun).

J'ai l'impression que ce topic est parti rapidement en vrille par amalgame entre d'un coté la solution proposée, et de l'autre la discussion qui en a découlé...
 
Si je suis tout à fait d'accord que pré-escaper n'est pas (du tout) une solution idéale en général, je maintiens que si son usage est uniquement d'afficher ce morceau, ça l'est.  
Je ne vois pas ce qui pose problème avec ça.  
 
Maintenant, venir dire que c'est l'usage, les attentes et la pratique qui font que typage et sémantique, c'est la même chose, j'avoue que j'ai du mal à suivre le raisonnement.

Ce n'est jamais le cas. Si c'est de l'usage unique non modifiable, tu fais du web statique...
Effectivement depuis le début les personnes qui te critiquent ici présupposent un usage "classique" des données, pas un usage limité à de l'affichage.
Type d'usage qui d'ailleurs s'auto-contredit : les bases de données n'apparaissent pas de manière spontanée, il a bien fallu la remplir à un moment...

Et personne n'a dit nulle part (ou alros je l'ai raté) que typage et sémantique sont la même chose...ça c'est l'interprétation que tu fais de ce qu'on te dit depuis le début, à savoir qu'aucun développeur/concepteur de base de données qui connait son boulot ne mettrait du contenu html dans la base de données.

L'usage, les attentes et la pratique font que typage et sémantique, dans le contexte de cette discussion, on s'en fout
(Du coup, ça peut être la même chose, une chose différente, ne pas exister, ou être largement supérieur à un canard en plastique rose, ça n'entrera pas en compte dans le choix d'une solution au problème initial).

Bonjour
 
j'ai un probleme tres similaire : j'utlise PHP pour creer des données XML utilisées par un programme en OpenLazslo : dans ma base de données je stocke des descriptions avec des '&', des apostrophes et autres caracteres speciaux.
 
dans le php  

 
le probleme est que les apostrophes sont interpretes comme des fins de champs (exactement le meme probleme que sur ce post) et les & sont interpretés par openlazslo ... bref ca fout le bordel !    
y a t il un moyen d'encapsuler les données definies comme valeur (ShortDescription dans mon exemple) entre les ' pour que ca ne soit pas interprété ?
 

il faut les échapper à l'affichage...

ok, la solution s'est un peu perdue dans le debat philosophico-technique
 
donc je fait un htmlspecialchars() dans mon php, je vais essayer ca

j'ai essayé ca :  
 

 
le code XML a l'air bien, mais OpenLazslo est pas content, il affiche rien. Je suis pas trop sur de mon UTF-8 : j'ai encodé ma base en UTF-8 donc j'ai pris ca, mais je sais pas si c'est judicieux ou s'il vaut mieux prendre un iso-8859-15 ou autre.
 
d'autant plus que mon site devra etre multilingue (avec aussi des caracteres asiatiques...) ...

j'ai utilisé un utf8_encode  () devant le htmlspecialchars ... marche pô non plus ...

bon en fait ca marche tres bien, c'est moi qui ait fait le boulet ailleurs dans le code....