J'ai rencontré un problème similaire décrit ici (et ailleurs) - Où, comme sur un rappel ajax, j'obtiens un xmlhttp.responseText qui semble correct (lorsque je l'alerte - il affiche le texte correct) - mais lorsque vous utilisez une instruction 'if' pour la comparer à la chaîne, elle renvoie false.
(Je suis aussi celui qui a écrit le code côté serveur renvoyant cette chaîne) - après avoir beaucoup étudié la chaîne -, j'ai découvert que la chaîne avait un "caractère invisible" comme premier caractère. Un personnage qui n'a pas été montré. Si je l'ai copié dans le Bloc-notes - puis supprimé le premier caractère - il ne sera supprimé que si vous appuyez à nouveau sur Supprimer.
J'ai fait un charCodeAt (0) pour la chaîne retournée dans xmlhttp.responseText. Et il est revenu 65279.
Googler révèle qu'il s'agit d'une sorte de caractère de contrôle UTF-8 censé définir un codage "big-endian" ou "small-endian".
Donc, maintenant je connais la cause du problème - mais ... pourquoi ce personnage est-il répercuté? Dans la source php, j'utilise simplement
echo 'the string'...
et apparemment, il sort en quelque sorte [chr (65279)] la chaîne ...
Pourquoi? Et comment puis-je l'éviter?
Pour conclure et préciser la solution:
Le Bloc-notes Windows ajoute le caractère de nomenclature (les 3 octets: EF BB BF) aux fichiers enregistrés avec le codage utf-8.
PHP ne semble pas en être dérangé - à moins d’inclure un fichier php dans un autre - .__, alors tout devient brouillon et les chaînes s'affichent avec le caractère (65279) ajouté à eux.
Vous pouvez éditer le fichier avec un autre éditeur de texte tel que Notepad ++ et utiliser le codage.
"Encoder en UTF-8 sans BOM",
.__ et cela semble résoudre le problème.
En outre, vous pouvez enregistrer l'autre fichier php avec l'encodage ANSI dans le bloc-notes - et cela semble également fonctionner (c'est-à-dire, si vous n'utilisez pas de caractères étendus dans le fichier, je suppose ...)
Si vous souhaitez imprimer une chaîne contenant le ZERO WIDTH NO-BREAK SPACE char (par exemple, en incluant un fichier externe non PHP), essayez le code suivant:
echo preg_replace("/\xEF\xBB\xBF/", "", $string);
Si vous utilisez Linux ou Mac, voici une solution élégante pour vous débarrasser du caractère en PHP.
Si vous utilisez WordPress (25% des sites Web sont alimentés par WordPress), il est probable qu'un plugin ou le thème actif introduise le caractère de nomenclature à cause d'un fichier contenant une nomenclature (ce fichier a peut-être été modifié sous Windows). Si tel est le cas, accédez à votre dossier wp-content/themes/et exécutez la commande suivante:
grep -rl $'\xEF\xBB\xBF' .
Cela recherchera des fichiers avec BOM. Si vous avez des résultats .php dans la liste, procédez comme suit:
Si vous traitez cela localement, vous devrez éventuellement télécharger à nouveau les nouveaux fichiers sur le serveur.
Si vous n'obtenez aucun résultat après l'exécution de la commande grep et que vous utilisez WordPress, le dossier/wp-content/plugins est un autre emplacement pour vérifier les fichiers de nomenclature. Allez-y et exécutez la commande à nouveau. Alternativement, vous pouvez commencer à désactiver tous les plugins, puis vérifier si le problème est résolu pendant que vous réactivez les plugins.
Si vous n'utilisez pas WordPress, allez à la racine du dossier de votre projet et exécutez la commande pour rechercher des fichiers avec BOM. Si un fichier est trouvé, exécutez la procédure en quatre étapes décrite ci-dessus.
J'ai eu ce problème et changé mon encodage à utf-8 sans nom, Ansi, etc. sans chance. Mon problème a été causé par l'utilisation d'une fonction d'inclusion php dans le corps html. Le déplacement de la fonction d'inclusion au-dessus de mon code HTML (au-dessus de la balise! DOCTYPE) a résolu le problème.
Après avoir connu mon problème, j'ai testé include, include_once et requiert des fonctions. Toutes les tentatives d’inclusion d’un fichier à partir du corps html ont créé le caractère extra très différent à l’endroit où le code PHP serait créé.
J'ai aussi essayé d'assigner le résultat de l'inclusion à une variable ... c'est-à-dire $ result = include ("myfile.txt"); avec le même caractère supplémentaire ajouté
Veuillez noter que déplacer l’inclusion au-dessus du code HTML ne supprime pas le caractère supplémentaire, mais le supprime de mes données et de la zone de contenu.
J'utilise "Dreamweaver CC 2015". Par défaut, cette option est activée: "inclure la signature de nomenclature" ou quelque chose du genre lorsque vous cliquez sur l'option Enregistrer sous du menu Fichier. Dans la fenêtre qui s’affiche, vous pouvez voir "Options Unicode ..". Vous pouvez désactiver l'option de nomenclature. Et rappelez-vous de changer tous vos fichiers comme ça. Ou vous pouvez simplement aller dans les préférences et désactiver l'option de nomenclature et enregistrer tous vos fichiers.
En plus de ce qui précède, je viens de rencontrer ce problème lors de l'extraction de données d'une base de données MySQL (charset est défini sur UTF-8). Le problème étant les balises HTML, j'ai autorisé certaines balises de base telles que <p> et <a> lorsque Je l’ai affichée sur la page. Le personnage & # 65729 a regardé à travers Outils de développement dans Chrome.
J'ai donc supprimé les balises du tableau et le problème & # 65729 (ainsi que la ligne vide au-dessus de l'emplacement où le texte devait être affiché).
Je voulais simplement ajouter quelque chose, car mon représentant n’est pas assez élevé pour commenter la réponse.
EDIT: En utilisant VIM, j'ai pu supprimer la nomenclature avec :set nobomb
et vous pouvez confirmer la présence de la nomenclature avec :set bomb?
qui affichera soit bomb
ou nobomb
Une solution Linux pour trouver et supprimer ce caractère d'un fichier consiste à utiliser sed -i 's/\xEF\xBB\xBF//g' your-filename-here
Lorsque vous utilisez atom, il s’agit d’un espace avant le <?php
au début du document.