What is the correct character encoding for HTML?

UTF-8. The HTML Living Standard requires that the document's actual encoding be UTF-8 and that any declaration use the utf-8 label.

Where should meta charset go?

As the first element inside head. The whole element must be within the first 1024 bytes of the document, so put it before the title, scripts and styles.

Is meta charset="utf-8" still needed with an HTTP header?

The W3C recommends declaring the encoding inside the document even when the server sends it, because the header is lost when the file is saved or opened locally. If you use both, they must say the same thing.

Why does my page show Ã© instead of é?

The text is UTF-8 but is being decoded as a legacy Western encoding such as Windows-1252. Usually the server header or meta tag declares the wrong charset. Make both say UTF-8.

What is the difference between ANSI and UTF-8?

ANSI usually refers to a Windows legacy code page such as Windows-1252, which covers only Western European characters. UTF-8 can represent every Unicode character in every language, and it is the only encoding the HTML standard allows for new documents.

Codage des caractères en HTML : méta-ensemble de caractères UTF-8 expliqué

Résumez ce post avec : 9 min de lecture

L'encodage des caractères d'une page HTML est la règle qui transforme les octets du fichier en lettres. Pour chaque page moderne, la réponse est la même : enregistrez le fichier en UTF-8 et déclarez-le avec <meta charset="utf-8"> comme premier élément à l'intérieur <head>, dans les 1024 premiers octets du document. La norme HTML nécessite UTF-8, et si votre serveur envoie également un Content-Type en-tête avec un jeu de caractères, les deux doivent être d'accord.

Principaux points à retenir

Utilisez UTF-8. La norme HTML indique que l'encodage réel du document “doit être UTF-8”, et W3Techs a rapporté en septembre 2026 que 99,1 % des sites Web avec un codage connu l'utilisent déjà.
Déclarez-le avec <meta charset="utf-8"> juste après <head>. Il doit tenir dans les 1024 premiers octets.
Déclarer ne suffit pas : le fichier lui-même, votre base de données et l'en-tête de votre serveur doivent également être en UTF-8.
Lorsque les déclarations ne sont pas d'accord, une marque d'ordre d'octets bat l'en-tête HTTP, qui bat le <meta> étiqueter.
Texte brouillé comme Ã© au lieu de é signifie presque toujours que les octets UTF-8 sont lus comme un codage hérité ou que le texte a été converti deux fois.

Qu'est-ce qu'un codage de caractères

Les ordinateurs stockent le texte sous forme de nombres. Un codage est le tableau qui mappe ces nombres à des caractères. Les codages plus anciens tels que ISO-8859-1 ou Windows-1252 couvrent un octet par caractère et seulement quelques centaines de caractères, ce qui est suffisant pour les langues d'Europe occidentale et rien d'autre. UTF-8 encode chaque caractère en Unicode, de sorte que l'anglais, l'arabe, l'hindi, le japonais et les emoji peuvent être placés sur la même page, en utilisant un à quatre octets par caractère.

Le W3C expose clairement le risque : si vous ne spécifiez pas l'encodage, “vous risquez que les caractères de votre contenu soient mal interprétés”, et il ajoute qu'une déclaration d'encodage est également nécessaire pour traiter le texte non ASCII que les utilisateurs saisissent dans les formulaires (Internationalisation du W3C).

La seule ligne dont vous avez besoin

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <title>…</title>
  </head>
</html>

Quelques détails que les gens se trompent :

Position. La norme HTML indique que l'élément contenant la déclaration “doit être entièrement sérialisé dans les 1024 premiers octets du document” (Norme de vie HTML). Mettez-le en premier <head>, avant le titre, les scripts et les longs commentaires.
Un seul. Un document ne peut en avoir qu'un seul <meta>-déclaration de codage basée.
L'affaire n'a pas d'importance. UTF-8 et utf-8 sont tous les deux bien. Le W3C note la forme plus longue, <meta http-equiv="Content-Type" content="text/html; charset=utf-8">, fonctionne de la même manière mais est plus à taper.
Aucune autre valeur n'est valable pour les nouvelles pages. La norme de codage stipule “Les auteurs doivent utiliser le codage UTF-8” et doivent l'étiqueter utf-8 (Norme de codage WHATWG). Des étiquettes plus anciennes comme iso-8859-1 fonctionnent toujours dans les navigateurs, mais ils ne sont pas conformes aux nouveaux documents.

La déclaration doit correspondre aux octets

Le <meta> tag décrit le fichier. Il ne le convertit pas. Si votre éditeur enregistre le fichier sous Windows-1252 (que certains outils Windows appellent “ANSI”) et que la balise indique UTF-8, chaque caractère accentué ou non latin se brisera. Le W3C rappelle aux auteurs qu'utiliser UTF-8 signifie “que vous devez également enregistrer votre contenu en UTF-8” (W3C).

Vérifiez le format de sauvegarde de votre éditeur. Dans la plupart des éditeurs de code, l'encodage actuel est affiché dans la barre d'état, avec une option pour “Enregistrer avec encodage” ou “Rouvrir avec encodage”. Choisissez UTF-8.

ANSI contre UTF-8. “ANSI” n'est pas un codage unique. Sous Windows, cela signifie la page de codes héritée du système, qui sur les systèmes d'Europe occidentale est généralement Windows-1252. Il ne peut pas représenter l'arabe, le chinois ou la plupart des autres scripts, et les fichiers enregistrés de cette façon s'afficheront de manière incorrecte lorsque la page déclarera UTF-8. Pour le web, choisissez toujours UTF-8.

Quelle déclaration gagne lorsqu’ils ne sont pas d’accord

Un navigateur peut trouver l'encodage à trois endroits. Le W3C énumère la priorité :

Marque d'ordre d'octet (BOM). Quelques octets invisibles au tout début du fichier. S'il est présent, il remplace tout le reste “y compris l'en-tête HTTP”.
HTTP Content-Type en-tête, par exemple Content-Type: text/html; charset=utf-8. C'est mieux que les déclarations dans les documents.
Le <meta charset> élément.

Donc si votre serveur envoie charset=iso-8859-1 et votre page indique UTF-8, le serveur gagne et la page se casse. Le conseil du W3C est de déclarer l'encodage dans le document dans tous les cas, et si vous utilisez également l'en-tête, de vous assurer qu'il dit la même chose.

Comment définir l'en-tête sur les serveurs communs :

Apache: AddDefaultCharset utf-8 ajoute le jeu de caractères à text/html et text/plain réponses (Documents Apache). Apache note que vous ne devez l'utiliser que lorsque tous les fichiers concernés sont réellement dans cet encodage.
nginx: le charset utf-8; directive dans le http, server ou location le bloc ajoute le jeu de caractères au Content-Type en-tête (documents nginx).
PHP: header('Content-Type: text/html; charset=utf-8'); avant toute sortie.

Vous pouvez voir ce que votre serveur envoie avec curl -I https://your-site.example/ ou dans les outils de développement du navigateur sous Réseau, en-têtes de réponse.

Correction des caractères brouillés (mojibake)

Le texte brouillé suit des modèles reconnaissables. Voici comment les lire :

Ce que tu vois	Ce qui s'est passé	Réparer
`cafÃ©` au lieu de `café`	Octets UTF-8 lus comme Windows-1252 ou ISO-8859-1	Faites en sorte que l'en-tête et la méta indiquent tous deux UTF-8
`caf�` (un diamant avec un point d'interrogation)	Les octets hérités sont lus en UTF-8	Réenregistrez le fichier ou convertissez les données en UTF-8
`cafÃƒÂ©`	Texte converti en UTF-8 deux fois	Recherchez la double conversion, généralement lors de l'importation ou dans la connexion à la base de données
`???` à la place de chaque caractère non latin	Personnages perdus lorsqu'ils sont enregistrés dans une colonne ou un fichier qui ne peut pas les contenir	Changez le stockage en UTF-8 et réimportez à partir de la source

Travaillez sur la chaîne dans l'ordre : le fichier sur le disque, la base de données, la connexion entre eux, l'en-tête HTTP et le <meta> étiqueter. Chaque lien doit être UTF-8.

Bases de données. Dans MySQL, l'ancien utf8 le jeu de caractères est un alias pour utf8mb3, qui stocke au plus trois octets par caractère et ne peut donc pas contenir de caractères “supplémentaires” tels que la plupart des emoji. Documents MySQL utf8mb3 comme obsolète (Manuel de référence MySQL). Utiliser utf8mb4 pour les tables et pour la connexion.

Entités HTML : quand vous en avez encore besoin

Avec UTF-8, vous pouvez taper é, ü, ж ou 中 directement dans la source. Vous n'avez besoin que de références de caractères telles que &, < et > pour les caractères qui ont une signification dans le balisage HTML. Les entités sont également pratiques pour les caractères invisibles difficiles à repérer dans la source, comme un espace sans interruption ( ) ou des marques directionnelles dans le texte de droite à gauche.

Codage sur des sites multilingues

Des problèmes d'encodage apparaissent dès qu'un site ajoute des langues. Une page qui n'affiche que l'anglais peut masquer une déclaration erronée pendant des années, car les lettres anglaises simples sont les mêmes dans UTF-8 et dans les anciens codages occidentaux. La première traduction polonaise, grecque ou japonaise le révèle.

Avant d’ajouter des langues, vérifiez trois choses :

Chaque modèle et fichier statique est enregistré en UTF-8 et déclare <meta charset="utf-8">.
Le lang l'attribut est défini par langue, par exemple <html lang="ja">, et les pages de droite à gauche obtiennent également dir="rtl". L'encodage indique comment lire les octets ; lang indique dans quelle langue se trouve le texte, ce qui est important pour les polices, la césure et les lecteurs d'écran.
Les URL avec des caractères non latins sont codées en UTF-8 et en pourcentage. Les conseils de Google sur les sites multilingues indiquent que les mots localisés dans les URL sont acceptables, mais pour “utiliser l'encodage UTF-8 dans l'URL (en fait, nous recommandons d'utiliser UTF-8 dans la mesure du possible)” et pour échapper correctement aux URL lors de la liaison (Recherche Google Central).

ConveyThis traduit le texte de vos pages dans l'une de ses 210 langues prises en charge, y compris des scripts tels que l'arabe, le chinois, l'hindi et l'hébreu, et sert des pages traduites à partir de leurs propres URL linguistiques. Cependant, il ne peut pas corriger un modèle qui déclare un codage incorrect, alors exécutez d'abord les vérifications ci-dessus. Pour les langues de droite à gauche, il existe un paramètre pour changer la direction du texte sur les pages traduites; notre Guide de conception RTL couvre le côté mise en page. Voir l'intégralité liste des fonctionnalités et comment les pages traduites sont traitées référencement multilingue, ou comparer plans et tarifs.

Liste de contrôle rapide

Fichier enregistré en UTF-8 (sans BOM, sauf si vous avez une raison d'en conserver un)
<meta charset="utf-8"> est le premier élément dans <head>
L'en-tête du serveur dit charset=utf-8, ou rien, jamais un jeu de caractères différent
Tables de base de données et utilisation des connexions utf8mb4 (MySQL/MariaDB)
Les formulaires et les API envoient et acceptent UTF-8
lang (et dir pour les langues RTL) défini sur chaque version linguistique

Questions fréquemment posées

Quel est le codage de caractères correct pour HTML ?

UTF-8. Le HTML Living Standard exige que l'encodage réel du document soit UTF-8 et que toute déclaration utilise l'étiquette utf-8.

Où doit aller le méta-charset ?

Comme premier élément à l'intérieur de la tête. L'élément entier doit se trouver dans les 1024 premiers octets du document, placez-le donc avant le titre, les scripts et les styles.

Meta charset=“utf-8” est-il toujours nécessaire avec un en-tête HTTP ?

Le W3C recommande de déclarer l'encodage à l'intérieur du document même lorsque le serveur l'envoie, car l'en-tête est perdu lorsque le fichier est enregistré ou ouvert localement. Si vous utilisez les deux, ils doivent dire la même chose.

Le texte est en UTF-8 mais est décodé en tant qu'encodage occidental hérité tel que Windows-1252. Habituellement, l'en-tête du serveur ou la balise méta déclare le mauvais jeu de caractères. Faites dire aux deux UTF-8.

Quelle est la différence entre ANSI et UTF-8 ?

ANSI fait généralement référence à une page de code héritée de Windows telle que Windows-1252, qui couvre uniquement les caractères d'Europe occidentale. UTF-8 peut représenter chaque caractère Unicode dans chaque langue, et c'est le seul codage que la norme HTML permet pour les nouveaux documents.

Prêt à ajouter des langues ?

Une fois que vos pages sont propres en UTF-8, l'ajout de langues est principalement une tâche de contenu. Tu peux créer un compte ConveyThis pour traduire votre site et publier chaque langue sur sa propre URL.

Codage des caractères en HTML : utilisation correcte du méta-jeu de caractères UTF-8