6
votes

Problème UTF-8, aucune idée

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

Rezept: gem�se mal Anders (Gem�elaiibchen)

J'ai besoin d'¼ / ¼!

Contenu de la base de données est "Gemüse ..." ..

Les données brutes dans mon erreur_log ressemble à ceci < / p>

[Titre] => Rezept: Gemüse Mal Anders (Gemüselaiibchen)

L'en-tête de la page Web est le suivant: xxx


2 commentaires

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.


7 Réponses :


11
votes

Vous devez définir l'encodage de votre page Web. strong>

Il existe trois façons de définir le codage: p>

    "3">
  1. html / xhtml strong>: Utilisez un en-tête HTTP: P>

    <?xml version="1.0" encoding="UTF-8"?>
    
  2. html fort>: utilisez un élément méta: (également possible pour xhtml, mais quelque peu inhabituellement) p>

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    
  3. xhtml uniquement strong>: définissez le codage dans le préambule: ( préféré pour xhtml fort>) p>

    Content-Type: text/html; charset=UTF-8
    


5 commentaires

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.



2
votes

fais cela: xxx

avant de sortir tout contenu.


3 commentaires

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 , mais plutôt type de contenu .


@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



0
votes

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 ..


5 commentaires

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.



8
votes

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".

Envoyer la requête "SET NAMES UTF8" immédiatement après l'ouverture de la connexion MySQL ou modifiez la configuration (si possible).


0 commentaires

4
votes

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 ü codé dans ISO 8859-1 est 0xFC, mais c'est un octet invalide dans UTF-8.

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 ou Ce is_utf8 fonction .


0 commentaires

0
votes

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 Tag en tant que page HTML et WebServer diffèrent par cette valeur.


0 commentaires

1
votes

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.

Vous avez deux options:

1. Changer le jeu de caractères de connexion par défaut Pour être UTF-8

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.

2. Modifiez la connexion Charset après chaque connexion à la base de données

Si vous utilisez php5, vous pouvez utiliser la commande intégrée: xxx

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.

Si vous êtes sur PHP 4, vous pouvez le faire par une simple requête SQL comme: xxx < p> voir http://dev.mysql.com/doc /refman/5.0/fr/charset-connection.html Pour plus de détails.


0 commentaires