Je reçois l'erreur:
parser error : Input is not proper UTF-8, indicate encoding ! Bytes: 0xED 0x6E 0x2C 0x20
Lorsque vous essayez de traiter une réponse XML en utilisant simplexml_load_string
à partir d'une source tierce. La réponse XML brute déclare le type de contenu:
<?xml version="1.0" encoding="UTF-8"?>
Pourtant, il semble que le XML ne soit pas vraiment UTF-8. La langue du contenu XML est l'espagnol et contient des mots tels que Dublín
dans XML.
Je ne parviens pas à faire en sorte que la 3ème partie trie son XML.
Comment pré-traiter le XML et corriger les incompatibilités d'encodage?
Existe-t-il un moyen de détecter le codage correct pour un fichier XML?
Vos octets 0xED 0x6E 0x2C 0x20 correspondent à "ín" dans ISO-8859-1. Il semble donc que votre contenu est en ISO-8859-1 et non en UTF-8. Parlez-en à votre fournisseur de données et demandez-lui de le réparer, car si cela ne fonctionne pas pour vous, cela ne fonctionnera probablement pas non plus pour les autres personnes.
Maintenant, il existe plusieurs façons de le contourner, que vous ne devriez utiliser que si vous ne pouvez pas charger le XML normalement. L'un d'eux serait d'utiliser utf8_encode()
. L'inconvénient est que si ce XML contient à la fois des fichiers UTF-8 et ISO-8859-1 valides, le résultat contient mojibake . Ou vous pouvez essayer de convertir la chaîne de UTF-8 à UTF-8 en utilisant iconv()
ou mbstring et en espérant qu’ils la répareront. (ils ne le feront pas, mais vous pouvez au moins ignorer les caractères non valides pour pouvoir charger votre XML)
Ou vous pouvez prendre le long chemin et valider/corriger les séquences par vous-même. Cela vous prendra un certain temps en fonction de votre familiarité avec UTF-8. Peut-être y a-t-il des bibliothèques qui feraient cela, même si je n'en connais aucune.
Dans les deux cas, informez votre fournisseur de données qu'il envoie des données non valides afin qu'il puisse les réparer.
Voici une solution partielle. Cela ne va certainement pas tout réparer, mais en réparera une partie. J'espère que vous en aurez assez pour vous en sortir jusqu'à ce que votre fournisseur répare ses problèmes.
function fix_latin1_mangled_with_utf8_maybe_hopefully_most_of_the_time($str)
{
return preg_replace_callback('#[\\xA1-\\xFF](?![\\x80-\\xBF]{2,})#', 'utf8_encode_callback', $str);
}
function utf8_encode_callback($m)
{
return utf8_encode($m[0]);
}
J'ai résolu cela en utilisant
$content = utf8_encode(file_get_contents('http://example.com/rss.xml'));
$xml = simplexml_load_string($content);
Si vous êtes sûr que votre xml est encodé en UTF-8 mais qu'il contient des caractères incorrects, vous pouvez utiliser cette fonction pour les corriger:
$content = iconv('UTF-8', 'UTF-8//IGNORE', $content);
Nous avons récemment rencontré un problème similaire et avons été incapables de trouver quoi que ce soit d’évident comme cause. Il s'est avéré qu'il y avait un caractère de contrôle dans notre chaîne, mais lorsque nous avons envoyé cette chaîne au navigateur, ce caractère n'était visible que si nous copions le texte dans un IDE.
Nous avons réussi à résoudre notre problème grâce à ce post et ceci:
preg_replace ('/ [\ x00-\x1F\x7F] /', '', $ input);
Au lieu d'utiliser javascript, vous pouvez simplement mettre cette ligne de code après votre phrase mysql_connect:
mysql_set_charset('utf8',$connection);
À votre santé.
Pouvez-vous ouvrir la source XML tierce dans Firefox et voir ce qu’elle détecte automatiquement comme encodage? Peut-être utilisent-ils la vieille norme ISO-8859-1, UTF-16 ou autre chose.
S'ils déclarent qu'il s'agit du format UTF-8 et servent autre chose, leur alimentation est clairement interrompue. Travailler autour d'un aliment si brisé me semble horrible (même si parfois inévitable, je le sais).
S'il s'agit d'un cas simple comme "UTF-8 versus ISO-8859-1", vous pouvez également tenter votre chance avec mb_detect_encoding () .
Si vous téléchargez un fichier XML et que vous l'ouvrez par exemple dans Notepad ++, vous verrez que l'encodage est défini sur autre chose que UTF8.
La chaîne <?xml version="1.0" encoding="UTF-8"?>
ne configure pas l'encodage du document, il ne s'agit que d'informations pour le validateur ou une autre ressource.
Après plusieurs essais, j’ai trouvé que la fonction htmlentities fonctionnait.
$value = htmlentities($value)
Lors de la génération de fichiers de mappage à l'aide de la doctrine, j'ai rencontré le même problème. Je l'ai corrigé en supprimant tous les commentaires que certains champs avaient dans la base de données.
Je viens d'avoir ce problème. Il s'avère que le fichier XML (pas le contenu) n'a pas été encodé dans utf-8, mais dans ISO-8859-1. Vous pouvez vérifier cela sur un Mac avec file -I xml_filename
.
J'ai utilisé Sublime pour changer l'encodage du fichier en utf-8, et LXML ne l'a pas importé.