Bonjour,

Dans le livre http://www.eyrolles.com/Informatique/Li ... 2212121148,
dans le chapitre 2, page 24, les auteurs indiquent que les fonctiosn htmlspecialchars et htmlentities ne sont pas efficaces si le paramètre indiquant le jeu de caractères n'est pas renseigné.

Il est indiqué que le jeu de caractère à mettre en paramètre est celui utilisé par PHP. Donc si j'ai bien compris ça n'a rien à voir avec l'encodage du fichier php ou indiqué dans la balise meta du html ?
Si c'est le cas comment savoir exactement quel est le jeu utilisé par PHP. Les auteurs proposent aussi d'utiliser iconv si on est pas sur, mais comment être sur que le jeu utilisé est un de ceux testés par iconv (dans leur exemple il vérifie si c'est iso ou utf-8).

Aussi les risques encourus si on ne spécifie pas le jeu de caractère en paramètre restent très flous pour moi (problème avec certains caractères chinois ?)
Cette partie du livre est un peu énigmatique , pourriez-vous me donner quelques précisions ?

Tu as trois charsets différent lors du développement.
Celui de ton fichier.
Celui de l'entête HTML.
Celui du serveur.

PHP propose de définir le charset dans le php.ini

Merci pour ta réponse.

Donc, c'est bien le charset du serveur qui est à spécifier à htmlspecialchar/entities

J'ai un abonnement chez ovh, en regardant le phpinfo() d'ovh : http://1000gp.ovh.net/test.php5
il y a default_charset = no value

c'est cette ligne qui deffinie le charset ?
si oui comment savoir le jeu de caractère utilisé ?

Spécifies le charset toi même en modifiant le php.ini ou bien avec ini_set('default_charset',$charset) pour le script courant.

Un tuto sur l'encodage ici

A noter que pour htmlspecialchars tu n'es pas obligé d'indiquer le charset pour l'iso ou l'utf-8, c'est une des raisons pour lesquelles on préfère souvent utiliser cette fonction de préférence à htmlentities.

Merci pour ces précisions !

Apparemment pour changer le charset sur ovh mutualisé il faut faire ça avec htacces

Donc le principe c'est de mettre partout le même charset, c'est bien ça ?

Je ne vois pas trop par contre de quelle façon il peut y avoir une faille de sécurité en fonction de ces réglages ?

Donc le principe c'est de mettre partout le même charset, c'est bien ça ?

Oui il faut que tout soit cohérent : fichier, base de donnée, entêtes serveur et html, utilisation des fonctions php pour les caractères multi octets (pour l'utf-8).

Je ne vois pas trop par contre de quelle façon il peut y avoir une faille de sécurité en fonction de ces réglages ?

Moi non plus

Moi non plus

Dans le livre Sécurité Php 5 (p 24), ils disent : "Les protections qui sont appliquées à une chaîne de caractères dépendent directement du jeu de caractères utilisé.",
donc apparemment il peut bien y avoir un problème de sécurité, mais ils ne donnent pas d'exemples précis, à part faire voir qu'une chaine n'est pas transformée de la même façon en fonction du charset indiqué dans htmlentities :

print htmlentities('Damien Séguy & Philippe Gamache');
Damien Séguy & Philippe Gamache

print htmlentities(iconv('UTF-8','ISO-88590-1','Damien Séguy & Philippe Gamache'));
Damien Séguy & Philippe Gamache

(ps: pour les caractères chinois, c'est avec addslaches qu'il y a une faille)

il faut utiliser le paramètre charset de htmlentities (d'ailleurs c'est mieux de faire htmlspecialchars)

il faut utiliser le paramètre charset de htmlentities (d'ailleurs c'est mieux de faire htmlspecialchars)

bin, j'ai bien compris qu'apparemment ça avait une importance, par contre je cherche toujours à savoir exactement pourquoi (surtout en terme de sécurité) ?

htmlspecialchars fait comme son l'indique que les caractères spéciaux, le entities fait tout mais y'a des risque incompatibilité au niveau du charset donc il faut être plus vigilant, c'est pour ca que je conseil plus htmlspecialchars, niveau sécurité les deux sont pareil

bon, merci pour vos conseils, alors pour l'instant je vais me contenter d'appliquer ça, sans savoir exactement le risque encouru avec htmlentities (hormis, ce qui est évident, les problèmes d'affichages...)