<meta charset = "utf-8"> vs <meta http-equiv = "Content-Type">

1535

Afin de définir le jeu de caractères pour HTML5 Doctype , quelle notation dois-je utiliser?

  1. Court:

    <meta charset="utf-8" /> 
  2. Longue:

    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
CuriousMind
la source
94
L'utilisation d'une balise <meta> pour quelque chose comme le type de contenu et l'encodage est très ironique, car sans connaître ces choses, vous ne pouvez pas analyser le fichier pour obtenir la valeur de la balise meta.
Mark
321
Vous pouvez l'analyser en ASCII jusqu'à ce que vous y parveniez. L'algorithme d'analyse HTML5 prend cela en compte.
Quentin
41
Il convient de noter qu'aucun des deux n'est utilisé pour l'analyse lorsque la page est diffusée sur le Web. À la place, celui de l'en- Content-Typetête de réponse HTTP sera utilisé. La balise META n'est utilisée que lorsque la page est chargée à partir du système de fichiers de disque local.
BalusC
38
L'élément méta est utilisé sur HTTP dans certaines conditions (y compris l'absence de données dans l'en-tête HTTP)
Quentin
78
Il est également ironique qu'il soit nommé charset, alors qu'il s'agit vraiment de spécifier un encodage. (le jeu de caractères est Unicode, l'encodage est UTF-8)
Ryan

Réponses:

1084

En HTML5, ils sont équivalents. Utilisez le plus court, il est plus facile à retenir et à taper. La prise en charge du navigateur est correcte car elle a été conçue pour une compatibilité descendante.

Quentin
la source
23
Qu'en est-il de la prise en charge du navigateur? Fonctionne-t-il <meta charset='utf-8'>dans IE6?
Šime Vidas
11
Pour autant que je sache, oui.
Quentin
4
Voici un lien mis à jour pour la page de code Google mentionnée par @ Šime Vidas. Il dit, concernant IE 6, 7 et 8, "Dans les navigateurs non IE, vous pouvez utiliser document.characterSet. Dans IE, vous pourriez penser que vous pourriez document.getElementsByTagName ('meta') [0] .charset, mais cela renvoie uniquement le codage de caractères que vous avez spécifié, pas le codage qu'IE utilise réellement. "
hotshot309
7
Je sais que ce fil est ancien, mais gtmetrix.com/specify-a-character-set-early.html indique que l'utilisation <meta>de la définition du codage des caractères désactive le téléchargeur de lookahead dans IE8, ce qui peut avoir un impact sur les temps de chargement de votre page. Ouais, ouais, je sais ... laissez tomber IE8. @ MészárosLajos peut revenir ici dans quelques années et casser nos couilles pour toujours soutenir IE8. ;-)
erturne
3
Aujourd'hui, j'ai eu un problème où les symboles coréens n'apparaissaient pas dans IE11. La suppression de la syntaxe courte au profit de la syntaxe plus longue a résolu le problème. Je ne sais pas si cela est dû à une sorte de configuration du serveur ou s'il s'agit d'un problème avec IE11 et le jeu de caractères. La combinaison de symboles exacte sur laquelle il échouait était 베라.
James Donnelly
250

Les deux formes de la déclaration meta charset sont équivalentes et devraient fonctionner de la même manière entre les navigateurs. Mais, vous devez vous souvenir de certaines choses lorsque vous déclarez le jeu de caractères de vos fichiers Web en UTF-8:

  1. Enregistrez vos fichiers dans le codage UTF-8 sans la marque d'ordre des octets (BOM).
  2. Déclarez l'encodage dans vos fichiers HTML à l'aide du méta charset (comme ci-dessus).
  3. Votre serveur Web doit servir vos fichiers, déclarant l'encodage UTF-8 dans l'en-tête HTTP Content-Type.

Les serveurs Apache sont configurés pour servir les fichiers en ISO-8859-1 par défaut, vous devez donc ajouter la ligne suivante à votre .htaccessfichier:

AddDefaultCharset UTF-8

Cela configurera Apache pour servir vos fichiers déclarant le codage UTF-8 dans l'en-tête de réponse Content-Type, mais vos fichiers doivent être enregistrés dans UTF-8 (sans BOM) pour commencer.

Le Bloc-notes ne peut pas enregistrer vos fichiers en UTF-8 sans la nomenclature. Un éditeur gratuit qui peut être Notepad ++ . Dans la barre de menus du programme, sélectionnez "Encodage> Encoder en UTF-8 sans BOM". Vous pouvez également ouvrir des fichiers et les réenregistrer dans UTF-8 en utilisant "Encodage> Convertir en UTF-8 sans BOM".

Plus d'informations sur le Byte Order Mark (BOM) sur Wikipedia .

CodeBoy
la source
20
@CodeBoy Je voudrais modifier votre réponse pour dire "Vous devriez enregistrer ... sans nomenclature". La page suivante indique "... il est généralement préférable pour l'interopérabilité d'omettre la nomenclature ..." indiquant une meilleure pratique, mais pas une exigence: w3.org/International/questions/qa-byte-order-mark
Johann
3
Dans IIS, vous pouvez définir le jeu de caractères dans les en-têtes HTTP avec <mondialisation fileEncoding = "utf-8" responseEncoding = "utf-8" /> dans Web.Config - ajoutez-le à <system.web>
Chris Moschini
3
si je comprends bien les choses, peu importe si vous enregistrez avec ou sans nomenclature.
David 天宇 Wong
3
Pourquoi dites-vous que le HTML UTF-8 devrait être sans nomenclature. Avoir une nomenclature devrait fonctionner correctement. De plus, vous n'avez pas besoin d' metaun en-tête HTTP. Vous avez juste besoin d'un metaen-tête BOM ou HTTP.
hsivonen
5
Summing up: don't use BOM for UTF-8Je ne suis pas d'accord avec ça. La nomenclature en UTF-8 est très utile pour signaler le type de codage. Sinon, nous devons deviner ou utiliser des choses comme les balises META auxquelles cette question se réfère. La chose intéressante à propos de la nomenclature est qu'elle fait partie de la spécification Unicode et peut donc être utilisée pour toutes les données encodées en Unicode, pas seulement HTML. Ce que nous devons faire, c'est utiliser les nomenclatures partout, laisser exploser les logiciels hérités, signaler ces bogues et les corriger.
Stijn de Witt
82

Une autre raison d'aller avec le court est qu'il correspond à d'autres instances où vous pouvez spécifier un jeu de caractères dans le balisage. Par exemple:

<script type="javascript" charset="UTF-8" src="/script.js"></script>

<p><a charset="UTF-8" href="http://example.com/">Example Site</a></p>

La cohérence aide à réduire les erreurs et à rendre le code plus lisible.

Notez que l'attribut charset n'est pas sensible à la casse. Vous pouvez utiliser UTF-8 ou utf-8, mais UTF-8 est plus clair, plus lisible et plus précis.

De plus, il n'y a absolument aucune raison d'utiliser une valeur autre que UTF-8 dans l'attribut meta charset ou l'en-tête de page. UTF-8 est l'encodage par défaut des documents Web depuis HTML4 en 1999 et le seul moyen pratique de créer des pages Web modernes.

Vous ne devez pas non plus utiliser d'entités HTML dans UTF-8. Les caractères comme le symbole du droit d'auteur doivent être saisis directement. Les seules entités que vous devez utiliser sont pour les 5 caractères de balisage réservés: inférieur à, supérieur à, esperluette, premier, double premier. Les entités ont besoin d'un analyseur HTML, que vous ne voudrez peut-être pas toujours utiliser à l'avenir, elles introduisent des erreurs, rendent votre code moins lisible, augmentent la taille de vos fichiers et décodent parfois incorrectement dans divers navigateurs selon les entités que vous avez utilisées. Apprenez à taper / insérer des droits d'auteur, des marques, des guillemets ouverts, des guillemets fermés, une apostrophe, un tiret, un tiret, un tiret, un euro, et tout autre caractère que vous rencontrez dans votre contenu, et utilisez ces caractères réels dans votre code. Le Mac dispose d'une visionneuse de caractères que vous pouvez activer dans les préférences du système de clavier, et vous pouvez trouver, puis faire glisser et déposer les caractères dont vous avez besoin, ou utiliser la visionneuse de clavier correspondante pour voir quelles touches saisir. Par exemple, la marque est Option + 2. UTF-8 contient tous les caractères et symboles de chaque langue humaine écrite. Il n'y a donc aucune excuse pour utiliser - au lieu d'un tiret cadratin. Ce n'est pas une mauvaise idée d'apprendre les règles de ponctuation et de typographie aussi ... par exemple, sachant qu'une période va à l'intérieur d'une citation proche, pas à l'extérieur.

L'utilisation d'une balise pour quelque chose comme le type de contenu et l'encodage est très ironique, car sans savoir ces choses, vous ne pouvez pas analyser le fichier pour obtenir la valeur de la balise META.

Non, ce n'est pas vrai. Le navigateur commence par analyser le fichier comme encodage par défaut du navigateur, soit UTF-8 ou ISO-8859-1. Étant donné que US-ASCII est un sous-ensemble de ISO-8859-1 et UTF-8, le navigateur peut très bien lire dans les deux cas ... c'est la même chose. Lorsque le navigateur rencontre la balise meta charset, si l'encodage est différent de ce que le navigateur utilise déjà, le navigateur recharge la page dans l'encodage spécifié. C'est pourquoi nous avons placé la balise meta charset en haut, juste après la balise head, avant toute autre chose, même le titre. De cette façon, vous pouvez utiliser des caractères UTF-8 dans votre titre.

Vous devez enregistrer vos fichiers au format UTF-8 sans BOM

Ce n'est pas strictement vrai. Si vous n'avez que des caractères US-ASCII dans votre document, vous pouvez l'enregistrer en US-ASCII et le servir en UTF-8, car il s'agit d'un sous-ensemble. Mais s'il y a des caractères Unicode, vous avez raison, vous devez enregistrer en UTF-8 sans BOM.

Si vous voulez un bon éditeur de texte qui enregistrera vos fichiers en UTF-8, je recommande Notepad ++.

Sur le Mac, utilisez Bare Bones TextWrangler (gratuit) du Mac App Store, ou Bare Bones BBEdit qui est sur le Mac App Store pour 39,99 $ ... très bon marché pour un si bon outil. Dans les deux applications, il y a un menu en bas de la fenêtre du document où vous spécifiez l'encodage du document et vous pouvez facilement choisir "UTF-8 no BOM". Et bien sûr, vous pouvez définir cela comme valeur par défaut pour les nouveaux documents dans les Préférences.

Mais si votre serveur Web sert l'encodage dans l'en-tête HTTP, ce qui est recommandé, les deux [balises META] sont inutiles.

C'est incorrect. Vous devez bien sûr définir l'encodage dans l'en-tête HTTP, mais vous devez également le définir dans l'attribut meta charset afin que la page puisse être enregistrée par l'utilisateur, hors du navigateur sur le stockage local, puis rouverte plus tard, auquel cas la seule indication du codage qui sera présent est l'attribut meta charset. Vous devez également définir une balise de base pour la même raison ... sur le serveur, la balise de base n'est pas nécessaire, mais lorsqu'elle est ouverte à partir du stockage local, la balise de base permet à la page de fonctionner comme si elle se trouvait sur le serveur, avec toutes les actifs en place et ainsi de suite, pas de liens rompus.

AddDefaultCharset UTF-8

Ou vous pouvez simplement changer l'encodage de types de fichiers particuliers comme ceci:

AddType text/html;charset=utf-8 html

Une astuce pour servir les fichiers UTF-8 et Latin-1 (ISO-8859-1) consiste à donner aux fichiers UTF-8 une extension "texte" et des fichiers Latin-1 "txt".

AddType text/plain;charset=iso-8859-1 txt
AddType text/plain;charset=utf-8 text

Enfin, pensez à enregistrer vos documents avec des fins de ligne Unix, pas des fins de ligne DOS ou Mac classiques, ce qui n'aide pas et peut nuire, en particulier sur la ligne à mesure que nous nous éloignons de plus en plus de ces systèmes hérités. Un document HTML avec un HTML5 valide, un encodage UTF-8 et des fins de ligne Unix est un travail bien fait. Vous pouvez partager et éditer et stocker et lire et récupérer et utiliser ce document dans de nombreux contextes. C'est de la lingua franca. C'est du papier numérique.

Simon White
la source
20
"Si vous n'avez que des caractères ISO-8859-1 dans votre document, vous pouvez l'enregistrer en ISO-8859-1 et le servir en UTF-8, car il s'agit d'un sous-ensemble" - incorrect. Ce serait correct si vous changez "ISO-8859-1" en "US-ASCII". US-ASCII est compatible avec UTF-8 car il s'agit d'un sous-ensemble, ISO-8859-1 ne l'est pas. Pour convertir ISO-8859-1 (contenant des caractères non ASCII) en UTF-8, vous devez coder les caractères non ASCII. Les points de code pour ISO-8859-1 existent en Unicode, mais UTF-8 code ceux en dehors de US-ASCII différemment de ISO-8859-1.
thomasrutter
2
Votre point sur les entités HTML est bon. Dans le passé, j'ai utilisé des entités uniquement pour découvrir qu'elles ont été converties en leurs caractères UTF-8 après avoir été enregistrées sur différents systèmes et / ou ouvertes dans différents éditeurs. Il convient de noter, cependant, que les espaces insécables (& nbsp;) peuvent produire des résultats déroutants car vous ne les verrez généralement pas dans votre éditeur, il est donc préférable de les conserver en tant qu'entités pour plus de clarté (d'après mon expérience).
squidbe
"You should also set a base tag..."devrait venir avec les mises en garde décrites ici .
Mafuba
Une autre raison pour laquelle vous pourriez préférer les entités HTML est si vous utilisez quelque chose comme des ionicons . Je préfère voir &#xf101;le glyphe par défaut ou un personnage étrange que je ne reconnais pas.
Daniel Lubarov
30

<meta charset="utf-8"> a été introduit avec / pour HTML5.

Comme mentionné dans la documentation, les deux sont valides. Cependant, <meta charset="utf-8">c'est uniquement pour HTML5 (et plus facile à taper / à mémoriser).

En temps voulu, l'ancien style devrait devenir obsolète dans un avenir proche. Je m'en tiendrai au nouveau <meta charset="utf-8">.

Il n'y a qu'une seule façon, mais vers le haut. Dans le cas de la technologie, cela élimine progressivement l'ancien (vraiment, VRAIMENT rapide)

Documentation: Attribut HTML meta charset - W3Schools

Omar
la source
2
Concernant le lien, veuillez consulter meta.stackoverflow.com/questions/280478/why-not-w3schools-com
tripleee
18

Sans contester les autres réponses, je pense que ce qui suit mérite d'être mentionné.

  1. La http-equivnotation «long» ( ) et la notation «short» sont égales, selon la première éventualité.
  2. Les en-têtes de serveur Web remplaceront toutes les <meta>balises;
  3. BOM (marque d'ordre des octets) remplacera tout , et dans de nombreux cas, cela affectera le HTML 4 (et probablement d'autres choses aussi);
  4. Si vous ne déclarez aucun encodage, vous obtiendrez probablement votre texte dans un "encodage de texte de secours" défini par votre navigateur. Ni dans Firefox ni dans Chrome, c'est utf-8;
  5. En l'absence d'autres indices, le navigateur tentera de lire votre document comme s'il était en ASCII pour obtenir le codage, vous ne pouvez donc pas utiliser de codages étranges (utf-16 avec BOM devrait le faire, cependant);
  6. Bien que les spécifications indiquent que la déclaration d'encodage doit se trouver dans les 512 premiers octets du document, la plupart des navigateurs essaieront de lire plus que cela.

Vous pouvez tester en exécutant echo 'HTTP/1.1 200 OK\r\nContent-type: text/html; charset=windows-1251\r\n\r\n\xef\xbb\xbf<!DOCTYPE html><html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta charset="windows-1251"><title>привет</title></head><body>привет</body></html>' | nc -lp 4500et en pointant votre navigateur sur localhost:4500. (Bien sûr, vous voudrez changer ou supprimer des pièces. La pièce de nomenclature est \xef\xbb\xbf. Méfiez-vous du codage de votre shell.)

Veuillez noter qu'il est très important de déclarer explicitement l'encodage. Laisser les navigateurs deviner peut entraîner des problèmes de sécurité.

écureuil
la source
1
Bon point, mais pouvez-vous détailler à quels problèmes de sécurité faites-vous référence?
Armfoot
1
La notation longue ne doit pas l'emporter sur la notation courte - simplement la première du document devrait l'emporter.
gsnedders
1
@Armfoot Dans le passé, il y avait des problèmes avec UTF-7ce dont je me souviens. Renifler également sur le Web est généralement mauvais, par exemple lorsque vous téléchargez une image quelque chose qui est reniflé comme contenu de script.
phk
@gsnedders testé en chrome et firefox, vous avez raison. modifié la réponse en conséquence. Armfoot: il s'agissait d'un encodage 7 bits, je ne me souviens pas exactement.
écureuil
1
@CraigMcQueen est presque sûr que le repli du navigateur (en 2018) est par défaut en Europe de l'Ouest en Europe de l'Ouest, donc j'imagine qu'il est par défaut quel que soit l'encodage pré-unicode dominant dans chaque région. Les utilisateurs peuvent définir le repli sur utf-8, mais cela expose simplement tous les milliers de sites de codage merdiques encore utilisés comme des caractères ascii à octets élevés glitchy partout, donc ce n'est toujours pas courant. Plus c'est dommage. Je ne vois pas comment cela va changer sans un peu de coercition de la part des fournisseurs de navigateurs, et ils ne souhaitent pas rompre avec l'héritage.
brennanyoung
13

À utiliser <meta charset="utf-8" />pour les navigateurs Web lors de l'utilisation de HTML5.

À utiliser <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />lors de l'utilisation de HTML4 ou XHTML, ou pour les analyseurs dom obsolètes, comme DOMDocumentdans php 5.3

Timo Huovinen
la source
2

Il y a des nouvelles basées sur Mozilla Foundation et sitepoint

N'utilisez pas cette valeur ( http-equiv=content-type) car elle est obsolète. Préférez l' charsetattribut sur l' metaélément < >. entrez la description de l'image ici

user10089632
la source
oh enfin, quelque chose d'un peu plus récent
Ayyash
1

Pour intégrer une signature sur un e-mail, j'utiliserais la version longue:

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

La raison en est que peu de lecteurs de messagerie utilisent html5, il est donc toujours préférable d'utiliser les anciens styles html. En fait, il vaut mieux utiliser des tables que divs + css.

chelder
la source