’ est affiché sur ma page au lieu de '."" s'affiche sur la page au lieu de "'"
J'ai l'Content-Type ensemble à UTF-8 à la fois mon tag <head> et mes en-têtes HTTP:
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
En outre, mon navigateur est configuré pour Unicode (UTF-8):
Alors, quel est le problème, et comment puis-je le réparer?
Assurez-vous que le navigateur et l'éditeur utilisent le codage UTF-8 au lieu de ISO-8859-1/Windows-1252.
Ou utilisez ’.
Si votre type de contenu est déjà UTF8, il est probable que les données arrivent déjà dans le mauvais encodage. 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 codé correctement en UTF-8. Vous pouvez généralement définir ceci dans la boîte de dialogue "Enregistrer sous ..." de l'éditeur de votre choix.
Si les données sont déjà rompues lorsque vous les affichez dans le fichier source, il est probable que ce fichier soit un fichier UTF-8 mais qu'il ait été enregistré dans le mauvais encodage quelque part en cours de route.
Alors, quel est le problème,
Il est un ’ (RIGHT SINGLE QUOTATION MARK - U + 2019) caractère qui a été codé comme CP-1252 au lieu de UTF-8. Si vous vérifiez la table encodings, vous voyez que ce caractère est en UTF-8 composé des octets 0xE2, 0x80 et 0x99. Si vous vérifiez le CP-1252 code page layout, vous verrez 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 du CP-1252 pour lire, écrire, stocker et afficher les caractères.
Je le Content-Type en UTF-8 dans les deux mon tag
<head>et mes en-têtes HTTP:<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
Cela indique que le client qui le codage à utiliser pour interpréter et affiche 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 serveur/base de données/langage de programmation utilisé.Notez que celui défini dans l'en-tête de réponse HTTP a la priorité sur la balise META HTML. La méta-balise HTML ne sera utilisée que lorsque la page est ouverte à partir du système de fichiers du disque local au lieu de HTTP. De plus, mon navigateur est configuré pour Unicode (UTF-8)
:
Cela force que le client qui le codage à utiliser pour interpréter et afficher les caractères. Mais le vrai problème est que vous envoyez déjà ’ (codé en UTF-8) au client au lieu de ’. Le client affiche correctement ’ en utilisant l'encodage UTF-8. Si le client a été misinstructed à utiliser, par exemple ISO-8859-1, vous auriez probablement vu ââ¬â¢ à la place.
J'utilise ASP.NET 2.0 avec une base de données.
Ceci est le plus probable où votre problème réside. Vous devez vérifier avec 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 ’, votre base de données est en panne. Les tables ne sont probablement pas configurées pour utiliser UTF-8. Au lieu de cela, ils utilisent l'encodage par défaut de la base de données, qui varie en fonction de la configuration. Si c'est votre problème, il suffit généralement de modifier la table pour utiliser UTF-8. Si votre base de données ne supporte pas cela, vous devrez recréer les tables. Il est recommandé de définir l'encodage de la table lorsque vous la créez.
Vous utilisez probablement SQL Server, mais voici un code MySQL (copié à partir this article):
CREATE DATABASE db_name CHARACTER SET utf8;
CREATE TABLE tbl_name (...) CHARACTER SET utf8;
Si votre table est cependant déjà UTF-8, alors vous devez prendre un pas en arrière . Qui ou ce mettre les données là. C'est où le problème est. Un exemple serait des valeurs soumises sous forme HTML qui sont incorrectement codées/décodées.
Voici quelques liens pour en savoir plus sur le problème:
Vous avez une incohérence dans le codage de votre caractère; votre chaîne est encodée en un encodage (UTF-8) et tout ce qui est en train d'interpréter cette page en utilise une autre (disons ASCII).
Toujours spécifier votre encodage dans vos en-têtes http et assurez-vous que cela correspond à la définition d'encodage de votre framework.
échantillon en-tête http:
Content-Type text/html; charset=utf-8
<configuration>
<system.web>
<globalization
fileEncoding="utf-8"
requestEncoding="utf-8"
responseEncoding="utf-8"
culture="en-US"
uiCulture="de-DE"
/>
</system.web>
</configuration>
La même chose est arrivé à moi avec le caractère '-' (à long signe moins).
J'ai utilisé cette simple remplacement résoudre il:
htmlText = htmlText.Replace('–', '-');
Le problème de l'OP est mojibake, pas caractères Unicode similaires. –
J'ai quelques documents où … montrait que … et ê montrait que ê. Voici comment il est arrivé là (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, je 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)
(Parce que quelqu'un avait inséré la version twingled dans une UTF- correcte 8 document, je devais extraire seulement la partie twedled, detwingle il et réinsérer dedans. J'ai utilisé BeautifulSoup pour cela.)
Il est beaucoup plus probable que vous avez un Charlie dans la création de contenu que le serveur Web la configuration est incorrecte. Vous pouvez également forcer votre navigateur à twinder la page en sélectionnant l'encodage windows-1252 pour un document utf-8. Votre navigateur Web ne peut pas detwingle le document que Charlie a enregistré.
Remarque: le même problème peut se produire avec toute autre page de code à octet unique (par exemple latin-1) au lieu de windows-1252.
Ceci est une excellente explication sur la façon dont cela se produit en premier lieu –
Au lieu du signe Pound j'ai utilisé: & pound; sans espace. Cela a résolu ce problème pour moi.
Pour l'euro: & euro; sans espace.
’ (Unicode codet U+2019 RIGHT SINGLE QUOTATION MARK) est codé en UTF-8 octets:
0xE2 0x80 0x99.
’ (Unicode codets U+00E2 U+20AC U+2122) est codé en UTF-8 octets:
0xC3 0xA2 0xE2 0x82 0xAC 0xE2 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 passe par deux conversions de charset avant d'être envoyé au navigateur:
Le caractère source de ’ (U+2019) est d'abord encodées en UTF-8 octets:
0xE2 0x80 0x99
ces octets individuels étaient alors mal interprété et décodé en Unicode codets U+00E2 U+20AC U+2122 par l'un des Windows 125X jeux de caractères (1252, 1254, 1256 et 1258 tout plan 0xE2 0x80 0x99-U+00E2 U+20AC U+2122), puis les points de code sont en cours de codage UTF-8 octets:
0xE2 ->U+00E2 ->0xC3 0xA2
0x80 ->U+20AC ->0xE2 0x82 0xAC
0x99 ->U+2122 ->0xE2 0x84 0xA2
Vous devez trouver où la conversion supplémentaire à l'étape 2 est effectuée et retirez-le.
La réponse la plus utile pour moi est naturellement d'un expert Pascal! – Slashback
Vous devez avoir un copier/coller du texte de Word Document. Le document Word utilise Smart Quotes. Vous pouvez le remplacer par Caractère spécial (& rsquo;) ou simplement taper votre éditeur HTML ('). Je suis sûr que cela va résoudre votre problème.
Si quelqu'un obtient cette erreur sur le site WordPress, vous devez changer wp-config db charset:
define('DB_CHARSET', 'utf8mb4_unicode_ci');
au lieu de:
define('DB_CHARSET', 'utf8mb4');
Cela arrive 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 comme ça apparaissaient dans la base de données, probablement parce que la connexion MySQL ne spécifiait pas le bon jeu de caractères. Nous avons dû:
et PHP Zend S'assurer communiquaient avec la base de données en UTF-8 (était pas par défaut)
Réparer les caractères cassés avec plusieurs requêtes SQL comme celui-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);
Procédez ainsi pour autant de tables/colonnes que nécessaire.
Vous pouvez également corriger certaines de ces chaînes en PHP si nécessaire.Notez que parce que les caractères ont été codés deux fois, nous avons effectivement besoin de faire une conversion inverse de UTF-8 retour à Windows-1252, ce qui m'a troublé au premier abord.
mb_convert_encoding('’', 'Windows-1252', 'UTF-8'); // returns ’
"Ou utilisez ’". problème résolu. –
Non, ce n'est pas résolu. Il y a toujours une incohérence dans l'encodage des caractères dans votre application. Vous retrouverez le même problème dans le futur pour d'autres caractères non-CP1252. Et il y en a beaucoup ... – BalusC
Exemples de caractères que vous continuerez à rencontrer: http://www.i18nqa.com/debug/utf8-debug.html – Zoot