Pourquoi DOM Changer d'Encodage?

$string = file_get_contents('http://example.com');

if ('UTF-8' === mb_detect_encoding($string)) {
    $dom = new DOMDocument();
    //hack to preserve UTF-8 characters
    $dom->loadHTML('<?xml encoding="UTF-8">' . $string);
    $dom->preserveWhiteSpace = false;
    $dom->encoding = 'UTF-8';
    $body = $dom->getElementsByTagName('body');
    echo htmlspecialchars($body->item(0)->nodeValue);
}

Cela change tous les caractères UTF-8 ž, ¤ et autres ordures. Est-il un autre moyen de préserver les caractères UTF-8?

Ne poste pas de réponses à me dire pour m'assurer que je suis sortie en UTF-8, j'ai fait en sorte que je suis.

Merci d'avance 🙂

  • D'où les données ($string) vient-il?
  • J'ai mis à jour ma question 🙂
  • Pouvez-vous fournir un lien vers l'URL que vous les récupérer à l'aide de file_get_contents()? Comme je l'ai dit dans l'autre question, je suppose que vous êtes l'obtention de la norme ISO-8859-1 ou d'autres données, ce qui a pour obtenir tronqués lors de la sortie en UTF-8. Je ne voudrais pas compter sur mb_detect_encoding().
  • Bien sûr, voici le lien: futbalvsfz.sk/sutaze/sezona-2009-2010/dospeli/5.liga-jz
  • Bon, j'en suis convaincu 🙂 c'est vraiment étrange. Cependant, l'encodage par défaut à htmlspecialchars() est iso-8859-1. Pouvez-vous modifier que de l'UTF? Il ne devrait pas changer quoi que ce soit mais juste pour makr sûr. de3.php.net/htmlspecialchars
  • Votre navigateur est configuré pour UTF-8? 🙂
  • C'est sûrement pas le problème. J'ai aussi essayé de l'afficher sans htmlspecialchars() ou de le sauvegarder dans un fichier.
  • Peller Oui.
  • Donc, si vous sortie $string sans DOM traitement, il s'agit bien? C'est certainement le DOM de vissage vers le haut?
  • Btw, il fonctionne sur mon pc local avec WampServer sous Windows 7. Il ne fonctionne pas sur le serveur en ligne.
  • Oui. Si je mets de l'echo() avant le DOM traitement c'est ok avec tous Utf-8 caractères. Si je l'ai mis après le DOM de l'analyse, c'est tout foiré.
  • Vraiment, vraiment étrange. DOMDocument est censé être natif de l'utf-8... Essayez ma réponse ci-dessous, peut-être que ça aide.
  • Je pense toujours que le problème est le manque d'un jeu de caractères de la déclaration. php est probablement l'envoi de la valeur par défaut du content-type text/html, sans jeu de caractères. Cela rend le navigateur de deviner ce que le jeu de caractères est. si le code html contient une balise meta, il l'utilisera. le html à partir de l'url distante a une balise meta, donc echo $string; va à la sortie de la balise meta. Navigateur voit utf-8, et l'utilise, tout est bien. Mais quand echo $dombody, pas de balise meta est de sortie. navigateur trompe, jeu de caractères, et les mauvais caractères sont interprétés par le navigateur.
  • La page contient une balise meta avec l'encodage UTF-8 type de contenu.
  • Et le navigateur va ignorer la balise meta si un en-tête http est envoyée qui est spécifié pour l'encodage. Comme je l'ai dit, vous avez besoin d'envoyer un en-tête http de déclarer l'encodage. les en-têtes http ont préséance.
  • double possible de PHP DomDocument saveHTML pas de codage Japonais correctement
  • double possible de DOMDocument sauts de codage?

InformationsquelleAutor Richard Knop | 2010-02-10