’ s'affiche sur ma page au lieu de ' .
J'ai le Content-Type fixé à UTF-8 dans mes deux <head> et mes en-têtes HTTP :
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
En outre, mon navigateur est réglé sur Unicode (UTF-8) :
Quel est donc le problème et comment puis-je le résoudre ?
Quel est le problème ?
Il s'agit d'un ’ ( RIGHT SINGLE QUOTATION MARK - U+2019) qui est décodé en tant que CP-1252 au lieu de UTF-8 . Si vous vérifiez le encodages vous voyez que ce caractère est en UTF-8 composé d'octets 0xE2 , 0x80 y 0x99 . Si vous vérifiez le Mise en page du code CP-1252 Vous verrez alors que chacun de ces octets représente les caractères individuels â , € y ™ .
et comment puis-je y remédier ?
Utilisez UTF-8 au lieu de CP-1252 pour lire, écrire, stocker et afficher les caractères.
Le type de contenu (Content-Type) est défini sur UTF-8 dans mes deux fichiers
<head>et mes en-têtes HTTP :<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
Il indique seulement au client le codage à utiliser pour interpréter et afficher les caractères. Cela n'indique pas à votre propre programme quel encodage utiliser pour lire, écrire, stocker et afficher les caractères. La réponse exacte dépend de la plate-forme du serveur, de la base de données et du langage de programmation utilisés. Il convient de noter que l'encodage défini dans l'en-tête de la réponse HTTP a la priorité sur la balise HTML meta. La métabalise HTML n'est utilisée que lorsque la page est ouverte à partir du système de fichiers du disque local plutôt qu'à partir du protocole HTTP.
En outre, mon navigateur est réglé sur
Unicode (UTF-8):
Cela oblige seulement le client à choisir le codage à utiliser pour interpréter et afficher les caractères. Mais le problème réel est que vous envoyez déjà ’ (encodé en UTF-8) au client au lieu de ’ . Le client affiche correctement ’ en utilisant l'encodage UTF-8. Si l'on avait demandé au client d'utiliser, par exemple, ISO-8859-1, on aurait probablement vu ââ¬â¢ au lieu de cela.
J'utilise ASP.NET 2.0 avec une base de données.
C'est probablement là que se situe 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 ’ est présent, vous ne vous connectez pas correctement à la base de données. Vous devez indiquer au connecteur de la base de données d'utiliser UTF-8.
Si votre base de données contient des ’ alors c'est votre base de données qui est défectueuse. Il est fort probable que les tables ne soient 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 le cas, il suffit généralement de modifier la table pour qu'elle utilise UTF-8. Si votre base de données ne le prend pas en charge, vous devrez recréer les tables. Une bonne pratique consiste à définir l'encodage de la table lorsque vous la créez.
Vous utilisez probablement SQL Server, mais voici un peu de code MySQL (copié de cet article ):
CREATE DATABASE db_name CHARACTER SET utf8;
CREATE TABLE tbl_name (...) CHARACTER SET utf8;Si votre tableau est cependant déjà en UTF-8, vous devez faire un pas en arrière. Qui ou ce que y placer les données. C'est où se situe le problème. Un exemple serait les valeurs soumises dans un formulaire HTML qui sont incorrectement encodées/décodées.
Voici quelques liens supplémentaires pour en savoir plus sur le problème :
’ (point de code Unicode U+2019 RIGHT SINGLE QUOTATION MARK ) est encodé en UTF-8 sous forme d'octets :
0xE2 0x80 0x99 .
’ (points de code Unicode U+00E2 U+20AC U+2122 ) est encodé en UTF-8 sous forme d'octets :
0xC3 0xA2 0xE2 0x82 0xAC 0xE2 0x84 0xA2 .
Il s'agit des octets que votre navigateur reçoit réellement pour produire les données suivantes ’ lorsqu'il est traité en UTF-8.
Cela signifie que vos données sources passent par deux avant d'être envoyé au navigateur :
La source ’ caractère ( U+2019 ) est d'abord encodé sous forme d'octets UTF-8 :
0xE2 0x80 0x99
ces octets individuels étaient alors en train d'être mal interprété et décodé en points de code Unicode U+00E2 U+20AC U+2122 par l'un des Windows-125X (1252, 1254, 1256 et 1258 tous les jeux de caractères mappent 0xE2 0x80 0x99 à U+00E2 U+20AC U+2122 ), et ces points de code sont encodés en tant qu'octets UTF-8 :
0xE2 -> U+00E2 -> 0xC3 0xA20x80 -> U+20AC -> 0xE2 0x82 0xAC0x99 -> U+2122 -> 0xE2 0x84 0xA2
Vous devez trouver l'endroit où la conversion supplémentaire de l'étape 2 est effectuée et la supprimer.
J'ai quelques documents où … se montrait en tant que … y ê se montrait en tant 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==detwingledPour résoudre le problème, j'ai utilisé un code python comme celui-ci :
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)(Comme quelqu'un avait inséré la version dédoublée dans un document UTF-8 correct, j'ai dû extraire uniquement la partie dédoublée, la découper et la 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 configuration du serveur web soit erronée. Vous pouvez également forcer votre navigateur à déformer la page en sélectionnant l'encodage Windows-1252 pour un document utf-8. Votre navigateur web ne peut pas déchiffrer le document que Charlie a enregistré.
Note Le même problème peut se produire avec n'importe quelle autre page de code à un octet (par exemple, latin-1) au lieu de Windows-1252.
Cela se produit parfois lorsqu'une chaîne de caractères est convertie de Windows-1252 à UTF-8 deux fois .
Nous avons rencontré ce problème dans une application Zend/PHP/MySQL où des caractères de ce type 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û :
S'assurer que Zend et PHP communiquent avec la base de données en UTF-8 (was pas par défaut)
Réparez les caractères brisés à l'aide de 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);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 qu'étant donné que les caractères ont été encodés deux fois Nous devons en fait procéder à une conversion inverse de UTF-8 à Windows-1252, ce qui m'a d'abord déconcerté.
mb_convert_encoding('’', 'Windows-1252', 'UTF-8'); // returns ’ Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
