web-dev-qa-db-fra.com

"â €" montrant sur la page au lieu de "'"

’ s'affiche sur ma page au lieu de '.

J'ai le Content-Type réglé sur UTF-8 dans mes balises <head> et mes en-têtes HTTP:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

enter image description here

De plus, mon navigateur est réglé sur Unicode (UTF-8):

enter image description here

Alors, quel est le problème et comment puis-je le résoudre?

encodingutf-8mojibake
115
Jitendra Vyas

Assurez-vous que le navigateur et l'éditeur utilisent le codage UTF-8 au lieu de ISO-8859-1/Windows-1252.

Ou utilisez &rsquo;.

51
kennytm

Donc quel est le problème,

C’est un ’ ( (RIGHT SINGLE QUOTATION MARK)] - U + 2019) qui a été codé comme CP-1252 au lieu de TF-8 . Si vous cochez la table encodages , alors vous voyez que ce caractère est en UTF-8 composé d'octets 0xE2, 0x80 et 0x99. Si vous cochez la mise en page de code CP-1252 , vous verrez alors que chacun de ces octets représente les caractères individuels â, € et ™ .

et comment puis-je résoudre ce problème?

Utilisez UTF-8 au lieu de CP-1252 pour lire, écrire, stocker et afficher les caractères.

Le type de contenu défini sur UTF-8 est défini dans ma balise <head> et mes en-têtes HTTP:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

Ceci indique uniquement au client quel codage utiliser pour interpréter et afficher les caractères. Cela n'indique pas à votre propre programme quel codage utiliser pour lire, écrire, stocker et afficher les caractères. La réponse exacte dépend de la plate-forme/base de données/langage de programmation côté serveur utilisée. Notez que celui défini dans l'en-tête de réponse HTTP a la priorité sur la balise méta HTML. La balise méta HTML ne serait utilisée que lorsque la page est ouverte à partir du système de fichiers du disque local et non de HTTP.

De plus, mon navigateur est réglé sur Unicode (UTF-8):

Cela oblige uniquement le client à utiliser le codage pour interpréter et afficher les caractères. Mais le problème actuel est que vous envoyez déjà ’ (codé en UTF-8) au client au lieu de ’. Le client affiche correctement ’ en utilisant le codage UTF-8. Si le client avait été mal interprété, par exemple ISO-8859-1, vous auriez probablement vu ââ¬â¢ à la place.

J'utilise ASP.NET 2.0 avec une base de données.

C'est probablement là que réside votre problème. Vous devez vérifier à l'aide d'un outil de base de données indépendant à quoi ressemblent les données.

Si le caractère ’ est présent, vous ne vous connectez pas correctement à la base de données. Vous devez indiquer au connecteur de base de données d'utiliser UTF-8.

Si votre base de données contient ’, alors c'est votre base de données qui est foirée. Très probablement, les tables ne sont pas configurées pour utiliser UTF-8. Au lieu de cela, ils utilisent le codage par défaut de la base de données, qui varie en fonction de la configuration. Si tel est votre problème, il suffit généralement de modifier le tableau pour utiliser UTF-8. Si votre base de données ne prend pas cela en charge, vous devrez recréer les tables. Il est recommandé de définir le codage de la table lorsque vous la créez.

Vous utilisez probablement SQL Server, mais voici du code MySQL (copié de cet article ):

CREATE DATABASE db_name CHARACTER SET utf8;
CREATE TABLE tbl_name (...) CHARACTER SET utf8;

Si votre table est cependant déjà UTF-8, vous devez prendre du recul. Qui ou quoi y mettre les données. C'est où se situe le problème. Un exemple serait les valeurs soumises par le formulaire HTML mal codées/décodées.

Voici quelques liens supplémentaires pour en savoir plus sur le problème:

199
BalusC

J'ai quelques documents où … était affiché comme … et ê était affiché par ê. Voici comment cela est arrivé (code python):

# Adam edits original file using windows-1252
windows = '\x85\xea' 
# that is HORIZONTAL Ellipsis, LATIN SMALL LETTER E WITH CIRCUMFLEX

# Beth reads it correctly as windows-1252 and writes it as utf-8
utf8 = windows.decode("windows-1252").encode("utf-8")
print(utf8)

# Charlie reads it *incorrectly* as windows-1252 writes a twingled utf-8 version
twingled = utf8.decode("windows-1252").encode("utf-8")
print(twingled)

# detwingle by reading as utf-8 and writing as windows-1252 (it's really utf-8)
detwingled = twingled.decode("utf-8").encode("windows-1252")

assert utf8==detwingled

Pour résoudre le problème, j'ai utilisé le code python comme ceci:

with open("dirty.html","rb") as f:
    dt = f.read()
ct = dt.decode("utf8").encode("windows-1252")
with open("clean.html","wb") as g:
    g.write(ct)

(Étant donné que quelqu'un avait inséré la version twingled dans un document UTF-8 correct, j'ai dû extraire uniquement la partie twingled, le detwingle et le réinsérer. J'ai utilisé BeautifulSoup pour cela.)

Il est beaucoup plus probable que vous ayez un Charlie dans la création de contenu que la mauvaise configuration du serveur Web. Vous pouvez également forcer votre navigateur Web à modifier la page en sélectionnant le codage Windows-1252 pour un document utf-8. Votre navigateur Web ne peut pas combiner le document que Charlie a enregistré.

Note: le même problème peut survenir avec n'importe quelle page de code à un octet (par exemple, latin-1) au lieu de windows-1252.

14
Terrel Shumway

’ (Le code Unicode U+2019 RIGHT SINGLE QUOTATION MARK) est codé dans UTF-8 sous forme d'octets:

0xE2 0x80 0x99.

’ (Les points de code Unicode U+00E2 U+20AC U+2122) est codé dans UTF-8 sous forme d'octets:

0xC3 0xA20xE2 0x82 0xAC0xE2 0x84 0xA2.

Ce sont les octets que votre navigateur reçoit actuellement afin de produire ’ lorsqu’il est traité en UTF-8.

Cela signifie que vos données source sont en cours de conversion deux charset avant d'être envoyées au navigateur:

  1. Le caractère source ’ (U+2019) est d'abord codé sous forme d'octets UTF-8:

    0xE2 0x80 0x99

  2. ces octets individuels étaient alors interprétés de manière erronée et décodés en points de code Unicode U+00E2 U+20AC U+2122 par l'un des Windows-125X jeux de caractères (1252, 1254, 1256 et 1258, tous les mappages 0xE2 0x80 0x99 à U+00E2 U+20AC U+2122), puis ces points de code sont codés sous forme d'octets UTF-8:

    0xE2 -> U+00E2 -> 0xC3 0xA2
    0x80 -> U+20AC -> 0xE2 0x82 0xAC
    0x99 -> U+2122 -> 0xE2 0x84 0xA2

Vous devez rechercher où la conversion supplémentaire de l'étape 2 est effectuée et la supprimer.

11
Remy Lebeau

Cela se produit parfois lorsqu'une chaîne est convertie de Windows-1252 à UTF-8 deux fois .

Nous avions cela dans une application Zend/PHP/MySQL où des caractères tels que ceux-ci apparaissaient dans la base de données, probablement parce que la connexion MySQL ne spécifiait pas le bon jeu de caractères. Nous devions:

  1. Assurez-vous que Zend et PHP communiquent avec la base de données en UTF-8 (était pas par défaut)

  2. Réparez les caractères brisés avec plusieurs requêtes SQL comme celle-ci ...

    UPDATE MyTable SET 
MyField1 = CONVERT(CAST(CONVERT(MyField1 USING latin1) AS BINARY) USING utf8),
MyField2 = CONVERT(CAST(CONVERT(MyField2 USING latin1) AS BINARY) USING utf8);

    Faites cela pour autant de tables/colonnes que nécessaire.

Vous pouvez également corriger certaines de ces chaînes dans PHP si nécessaire. Notez que comme les caractères ont été encodés deux fois , nous devons en fait effectuer une conversion inverse à partir de UTF-8 vers Windows-1252, qui m'a confondu au début.

mb_convert_encoding('’', 'Windows-1252', 'UTF-8');    // returns ’
8
Simon East

Vous avez une mauvaise correspondance dans l'encodage de votre personnage; votre chaîne est encodée dans un encodage (UTF-8) et ce qui interprète cette page en utilise un autre (par exemple, ASCII).

Indiquez toujours votre codage dans vos en-têtes http et assurez-vous qu'il correspond à la définition de votre infrastructure.

Exemple d'en-tête http:

Content-Type    text/html; charset=utf-8

Réglage de l'encodage en asp.net

<configuration>
  <system.web>
    <globalization
      fileEncoding="utf-8"
      requestEncoding="utf-8"
      responseEncoding="utf-8"
      culture="en-US"
      uiCulture="de-DE"
    />
  </system.web>
</configuration>

Réglage de l'encodage en jsp

8
David Waters

Si votre type de contenu est déjà UTF8, il est probable que les données arrivent déjà dans le mauvais codage. Si vous obtenez les données d'une base de données, assurez-vous que la connexion à la base de données utilise UTF-8.

S'il s'agit de données d'un fichier, assurez-vous que le fichier est correctement codé au format UTF-8. Vous pouvez généralement le définir dans la boîte de dialogue "Enregistrer sous ..." de l'éditeur de votre choix.

Si les données sont déjà cassées lorsque vous les visualisez dans le fichier source, il y a des chances pour que ce soit un fichier UTF-8, mais qu'il ait été enregistré dans un mauvais codage quelque part au cours du processus.

7
Pekka 웃

Si quelqu'un reçoit cette erreur sur le site Web WordPress, vous devez modifier le jeu de caractères de la base de données wp-config:

define('DB_CHARSET', 'utf8mb4_unicode_ci');

au lieu de:

define('DB_CHARSET', 'utf8mb4');
4
Goran Jakovljevic