J'ai un problème étrange avec certains documents sur ma page Web.
Mes données sont stockées dans une base de données MySQL, UTF8 codée. Si vous lisez les valeurs mon webbpage affiche P>
Rezept: gem�se mal Anders (Gem�elaiibchen) P> blockQuote>
J'ai besoin d'¼ / ¼! p>
Contenu de la base de données est "Gemüse ..." .. p>
Les données brutes dans mon erreur_log ressemble à ceci < / p>
[Titre] => Rezept: Gemüse Mal Anders (Gemüselaiibchen) P> blockQuote>
L'en-tête de la page Web est le suivant: p>
xxx pré> p>
7 Réponses :
Il existe trois façons de définir le codage: p> html / xhtml strong>: Utilisez un en-tête HTTP: P>
html fort>: utilisez un élément méta: (également possible pour xhtml, mais quelque peu inhabituellement) p>
xhtml uniquement strong>: définissez le codage dans le préambule: ( préféré pour xhtml fort>) p>
"3">
<?xml version="1.0" encoding="UTF-8"?>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Content-Type: text/html; charset=UTF-8
Merci, quand je passe à "iso" dans mon navigateur, il a l'air bien, mais je veux UTF-8 Wich est détecté par le navigateur (;
Dans ce cas, veuillez ajouter des informations supplémentaires à votre question. Le plus important: quelle langue et les déclarations d'impression / d'écriture. On dirait qu'il y a une couche supplémentaire d'encodage dans votre application.
Depuis quand PHP a-t-il une connaissance des codages, en dehors des fonctions MB_ *? J'étais sous l'impression que ce ne serait pas là avant PHP6.
Vous devez modifier la commande: premier HTTP, puis la Déclaration XML, puis la méta-Déclaration.
Aussi avec la base de données, assurez-vous que le côté client et le serveur diffèrent de l'UTF8 ainsi que du champ de données.
fais cela: avant de sortir tout contenu. p> p> p>
Notez que, selon la spécification, les noms d'en-tête HTTP sont séparés par un trait d'union et la première lettre de chaque mot est capitalisée. Donc, pas type de contenu code>, mais plutôt
type de contenu code>.
@Geert: "Les noms de champ sont insensibles de cas." w3.org/protocols/rfc2616/rfc2616-sec4.html# SEC4.2
@Geert, @gumbo: Vous avez tous les deux raison. "Soyez libéral dans ce que vous acceptez et conservateur dans ce que vous envoyez." - Jon posel
utf8_encode corrigé mon problème. Je ne sais pas pourquoi (; les données de la base de données sont UTF8, le site Web est UTF8 .. p>
Avez-vous vu l'ajout à ma réponse?
Voir ma réponse pour la raison pour laquelle vous devez faire du travail supplémentaire et quoi faire à ce sujet. Devoir UTF8 Encode tout à partir de la base de données manuellement n'est pas une solution appropriée.
@Annerie: S'il vous plaît supprimer cela. Utilisez des commentaires pour faire un commentaire ou modifier votre question pour ajouter des détails. La partie inférieure de la page concerne uniquement les réponses réelles, ne l'utilisez pas comme un forum. Merci.
@Tomalak: D'une manière c'est une réponse valide. Pas le meilleur, cependant, voir Michale Madsens Commenter et répondre.
Il suffit de dire que les données sont UTF-8 ne rend pas les données UTF-8.
MySQL doit savoir que vous souhaitez que la sortie UTF-8 - il est probablement configuré d'envoyer en latin1, votre navigateur voit donc les séquences d'octets UTF-8 non valides et génère le glyphe "non un caractère". P>
Envoyer la requête "SET NAMES UTF8" immédiatement après l'ouverture de la connexion MySQL ou modifiez la configuration (si possible). P>
Ce caractère de remplacement Unicode n'apparaît que lorsque le codage est incorrect. Donc, dans votre cas, vous avez déclaré vos données en tant que UTF-8 codées, mais ce n'était pas (au moins la partie que vous avez citée). Le ü em> codé dans ISO 8859-1 est 0xFC, mais c'est un octet invalide dans UTF-8. P>
Vous devez donc vous assurer que vos données sont en fait codées avec UTF-8. Il existe des fonctions pouvant vérifier si une chaîne donnée est UTF-8, par ex. mb_detect_encoding code>
ou Ce is_utf8 code> fonction
. p>
Vous devez également vérifier les en-têtes HTML, en particulier (si faux) comment votre serveur Web est configuré. J'ai eu un problème similaire dans le passé, ce qui a été causé par la configuration d'Apache - il a été configuré pour toujours envoyer le codage dans le type de contenu et qui a écrasé le codage passé via le
Le problème est probablement que la connexion à la base de données utilise latin1. Cela provient de ce que je connais la valeur par défaut dans de nombreuses configurations MySQL.
Cela signifie, même si vous stockez les données comme UTF-8 dans la base de données, vous l'obtiendrez comme latin1 lorsque vous le récupérez, car le Charset est converti sur le Volez pour faire correspondre la connexion. P>
Vous avez deux options: p>
Ceci pourrait signifier des problèmes si vous avez d'autres applications hébergées sur le même serveur de base de données qui attendent ISO-8859-1 de la base de données comme lorsque vous Modifiez la configuration Vous modifierez le comportement de tous les utilisateurs du serveur MySQL. P> Si vous utilisez php5, vous pouvez utiliser la commande intégrée: p> voir < un href = "http://php.net/manual/fr/funcunction.mysql-set-charset.php" rel = "nOfollow noreferrer"> http://php.net/manual/fr/function.mysql-set -Charset.php pour plus de détails. p> Si vous êtes sur PHP 4, vous pouvez le faire par une simple requête SQL comme: p>
Pour tous les intervenants: dans la question initiale, seul le Doctype était visible en raison de la synchronisation du code. Je l'ai corrigé. Toutes les autres choses étaient là dans la question initiale!
La balise Meta a l'air inversée.