Je reçois cette erreur dans mon site local.htmlspecialchars(): séquence multi-octets non valide dans l'argument
Warning (2): htmlspecialchars(): Invalid multibyte sequence in argument in [/var/www/html/cake/basics.php, line 207]
Est-ce que quelqu'un sait, quel est le problème ou quelle devrait être la solution pour cela?
Merci.
Assurez-vous de spécifier l'encodage UTF-8 si vos fichiers sont encodés en tant que tels:
htmlspecialchars($str, ENT_COMPAT, 'UTF-8');
Le jeu de caractères par défaut pour htmlspecialchars ISO-8859-1 (PHP v5.4 par défaut le jeu de caractères a été tourné à 'UTF-8'), ce qui pourrait expliquer pourquoi les choses tournent mal quand il rencontre des caractères multi-octets.
Ligne 207 est ici. $ charset = 'UTF-8'; htmlspecialchars ($ text, ENT_QUOTES, $ charset); // Ligne 207 – gautamlakum
Pour moi, ce problème a fini par être l'inverse, que le jeu de caractères de mes données était en fait 'ISO-8859-1' quand j'essayais de l'encoder en 'UTF-8' dans htmlspecialchars. J'ai changé l'argument charset en 'ISO-8859-1' et cela a résolu le problème. Au moins, jusqu'à ce que je puisse entièrement mettre à jour tout à «UTF-8». – Kzqai
À partir de PHP 5.4.0, la valeur par défaut du troisième paramètre de 'htmlspecialchars()' est '' UTF-8'' - cette réponse devrait être mise à jour. –
Vous alimentez des données de caractère corrompues dans la fonction ou vous ne spécifiez pas le bon codage.
J'ai eu ce problème il y a un certain temps, l'ancien comportement (avant PHP 5.2.7 je crois) était de retourner la chaîne malgré la corruption, mais depuis cette version, elle va lancer cette erreur à la place.
Ma solution consistait à écrire un script pour alimenter mes chaînes via iconv en utilisant le modificateur // IGNORE pour supprimer les données corrompues. (Nous avions une base de données corrompue qui contenait certaines chaînes en UTF-8, certaines en latin-1 avec des types de caractères mal définis dans les colonnes).
(Regarder le commentaire à la réponse de Tatu, je commencerais en regardant (et jouer avec) le contenu de la variable $ charset.
Je suis d'accord. J'ai transmis des données utilisateur via iconv ou mb_convert_encoding(), les jeux de caractères 'from' et 'to' étant identiques. Il y a généralement une option pour supprimer les caractères invalides. –
Les données corrompues ici aussi, mb_convert_encoding ($ var, 'UTF-8') ont fait le travail. –
C'est en fait l'une des erreurs les plus fréquentes que je reçois.
Parfois, je ne l'utilise __() traduction -. juste du texte allemand contenant AOU Là, il est particulièrement important à l'esprit l'encodage des fichiers
donc, assurez-vous correctement enregistrer les fichiers qui contiennent des caractères spéciaux comme UTF8..
Le lien est rompu. – billynoah
j'ai couru pour cette erreur sur la production et trouvé ce grand message à ce sujet -
http://insomanic.me.uk/post/191397106/php-htmlspecialchars-htmlentities-invalid
Il semble être un bogue dans PHP (pour CentOS au moins) qui affiche cette erreur lorsque des erreurs d'affichage est De!
Le code correct pour ne pas obtenir une erreur est:
htmlentities($string, ENT_IGNORE, 'UTF-8') ;
A côté de cela, vous pouvez également utiliser str_replace pour remplacer certains mauvais caractères à vos besoins, puis utilisez la fonction htmlentities.
Jetez un oeil à ce rss feed il a remplacé le grand signe html à gt; tag qui pourrait ne pas avoir l'air bien en lisant le flux rss thee. Vous pouvez le remplacer par quelque chose comme "-" signe ou ")" et etc.
Avait le même problème parce que j'utilisais substr sur la chaîne utf-8.
L'erreur était rare et apparemment aléatoire. Une erreur est survenue seulement si la chaîne a été coupée en caractères multi-octets!
mb_substr résolu le problème :)
ligne Post 207 s'il vous plaît –