Comment les navigateurs/PHP gèrent-ils les caractères en dehors du jeu de caractères défini ?

Question

Je cherche à savoir comment sont gérés les caractères qui ne font pas partie du jeu de caractères défini pour une page.

Dans ce cas, la page est configurée en iso-8859-1, et le programmeur précédent a décidé d'échapper l'entrée en utilisant htmlentities($string,ENT_COMPAT). Ces données sont ensuite stockées dans des tables Latin1 dans Mysql.

Comme le tableau est défini avec le même jeu de caractères que la page, je me demande si l'étape htmlentities est nécessaire. J'ai fait quelques expériences sur http://floris.workingweb.nl/experiments/characters.php et il semble que pour les choses à l'intérieur de Latin1, certains caractères sont échappés, mais par exemple avec un nom tchèque, ils ne le sont pas.

Est-ce parce que ces caractères ne font pas partie de Latin1 ? Si c'est le cas, les htmlentities peuvent être supprimées, car elles ne sont d'aucune utilité pour les caractères en dehors de Latin1, et pour ceux en Latin1, elles ne sont pas nécessaires d'après ce que j'ai pu voir...

Answer 1

Htmlentities ne traduit que les caractères qu'il connaît ( get_html_translation_table(HTML_ENTITIES) renvoie toute la liste), et laisse le reste tel quel. Vous avez donc raison, l'utiliser pour des données non latines n'a aucun sens. De plus, le codage html des entrées de la base de données et l'utilisation de latin1 ne sont pas non plus de bonnes idées, et je suggérerais de les supprimer tous les deux.

Un mot d'avertissement : après avoir supprimé htmlentities(), rappelez-vous que vous devez toujours échapper les guillemets pour les données que vous allez insérer dans la base de données (mysql_escape_string ou similaire).

Answer 2

Il aurait pu l'utiliser comme mesure de sécurité de base, c'est-à-dire pour empêcher les utilisateurs d'insérer du HTML/du javascript dans l'entrée (parce que les caractères < et > seront également échappés).

btw Si vous souhaitez prendre en charge les langues d'Europe de l'Est et de l'Ouest, je vous suggère d'utiliser UTF-8 comme encodage de caractères par défaut.

Answer 3

Oui
non pas parce que les caractères tchèques ne font pas partie de Latin1, mais parce qu'ils partagent les mêmes places dans le tableau. La base de données considère donc qu'il s'agit de caractères latins1 correspondants.

l'utilisation des htmlentities est toujours mauvaise. la seule solution correcte pour stocker différentes langues est d'utiliser le jeu de caractères UTF-8.

Answer 4

Il est à noter que htmlentités / htmlspecialchars ont un troisième paramètre (depuis PHP 4.1.0) pour le jeu de caractères. ISO-8859-1 est la valeur par défaut, donc si vous appliquez htmlentities sans 3ème paramètre à une chaîne UTF-8 par exemple, la sortie sera corrompue.

Vous pouvez détecter et convertir la chaîne d'entrée avec mb_detect_encoding y mb_convert_encoding pour s'assurer que la chaîne d'entrée correspond au jeu de caractères souhaité.