Est le charset de la balise meta nécessaire avec HTML5?

Le W3C "HTML5 différences de HTML4" de travail le projet d'états:

Pour la syntaxe HTML, les auteurs sont tenus de déclarer l'encodage des caractères.

Ce n'est "nécessaire" signifie?

Évidemment, un navigateur encore rendu HTML5 sans le charset de la balise meta. Si l'encodage n'est pas spécifié, qui l'encodage d'un navigateur à utiliser?

En gros, je veux savoir si c'est réellement nécessaire d'inclure <meta charset="">, ou si 99% du temps, les navigateurs utilisent l'encodage correct de toute façon.

Voici le lien: http://www.w3.org/TR/html5-diff/#character-encoding

  • Je suppose que jeu de caractères peut aussi être considéré ", a déclaré" si présent dans Content-Type en-tête de réponse.
  • Si quelqu'un est intéressé, j'ai aussi arrivé de tomber sur une page qui explique comment à l'exclusion de l'encodage peut entraîner une vulnérabilité XSS: openmya.hacker.jp/hasegawa/security/utf7cs.html
InformationsquelleAutor twiz | 2013-02-03
  1. 28

    Il n'est pas nécessaire d'inclure <meta charset="blah">. Comme la spécification dit, le jeu de caractères peut également être spécifié par le serveur à l'aide de la HTTP Content-Type en-tête ou en incluant une Unicode BOM au début du fichier téléchargé.

    La plupart des serveurs web aujourd'hui enverra en retour un ensemble de caractères dans le Content-Type en-tête de texte HTML de données si aucun n'est spécifié. Si le serveur web n'envoie pas le retour d'un jeu de caractères avec la Content-Type en-tête et le fichier ne comporte pas de NOMENCLATURE et la page ne comporte pas de <meta charset="blah"> déclaration, le navigateur aura un encodage par défaut qui est généralement basée sur les paramètres de langue de l'ordinateur hôte. Si cela ne correspond pas au caractère réel de l'encodage du fichier, puis certains caractères s'affichent mal.

    Seront les navigateurs utilisent le codage approprié 99% du temps? Si votre page est en UTF-8, sans doute. Si non, probablement pas.

    Le W3C propose un document décrivant le precendence règles pour les trois méthodes que dit la commande en-tête HTTP, BOM, suivie par la spécification de document (balise meta).

    • Donc, ce serait de l'ordre de priorité si le Content-type, BOM, et <meta charset=""> tous avaient des valeurs différentes?
    • L'en-tête HTTP, BOM, suivi par balise meta. Je vais mettre à jour la réponse avec un lien que j'ai trouvé du W3C, de répondre à cette question.
    • C'est vraiment intéressant. J'aurais pensé que le but de la balise meta serait de remplacer tout le reste. Il me semble qu'il serait assez difficile d'avoir une situation où la balise meta serait nécessaire. Ai-je raté quelque chose?
    • il est nécessaire d'utiliser un meta balise de déclarer l'encodage lorsque le serveur envoie un Content-Type de tête, sans charset paramètre et vous ne pouvez pas affecter de cela (et vous n'êtes pas l'utilisation de l'UTF-8). Ce n'est pas un scénario rare. En outre, la meta balise est pertinente si une page est enregistrée localement par un utilisateur. (Lorsqu'il est ouvert plus tard, il n'y aura pas d'en-têtes HTTP.)
    • Je ne sais pas beaucoup au sujet de l'encodage, donc je me demandais, quel serait un exemple d'un scénario commun, où le jeu de caractères peuvent être laissés de côté?
    • un scénario commun est codé en UTF-8 document avec la NOMENCLATURE.

    InformationsquelleAutor hrunting
  2. 4

    Selon Google PageSpeed extension de navigateur, déclarant un jeu de caractères dans un élément meta "désactive IE8 de l'anticipation à la fonctionnalité" qui, apparemment, l'oblige à télécharger tout dans la série.

    Ma compréhension était que <meta charset-"utf-8"> a été nécessaire pour HTML5 valide, mais c'est pourquoi j'ai commencé navigation ici.

    Que le projet de la spec semble assez clair pour moi et depuis que j'ai ajouter l'en-tête HTTP via .htaccess, je vais commencer à le laisser sortir...même si je suis tenté de ne pas, il suffit de faire IE8 utilisateurs de souffrir un peu plus.

    Grâce.

    @Jules Mazur avez-vous des références sur ces points? La plupart de ce que je fais, c'est le RÉFÉRENCEMENT et l'accessibilité est importante pour moi et si c'est le cas, je suis plus réceptif à quitter la méta déclaration.

    InformationsquelleAutor adam-asdf
  3. 1

    Il est important de spécifier un jeu de caractères du document en tant que plus tôt possible (que ce soit par le biais de la Content-Type en-tête ou le META tag), sinon le navigateur va être laissé pour déterminer l'encodage avant l'analyse du document et cela peut un impact négatif sur le temps de chargement de page.

    InformationsquelleAutor Anton Eprev
  4. 0

    Depuis 1999, lorsque la plupart de ces spécifications du w3C est sorti, les organismes de normalisation ont poussé les fournisseurs (fabricants de serveurs et les navigateurs et les applications de document) afin de suivre les règles de codage et l'utilisation de méta-balises pour aider à déterminer l'intention. Mais en raison de la cupidité, de la mauvaise conception de navigateur et d'autres facteurs, très peu ont suivi les spécifications de façon constante au fil des ans. En conséquence, nous avons une fragmentation du système. Certains fournisseurs comme Mozilla ont suivi les normes depuis 2001 pour les metatags, tandis que d'autres comme Microsoft et Google n'ont pas.

    Pour cette raison, tous les développeurs web doivent utiliser la contingence de la conception à la façon dont l'ensemble de leurs pages web sont construits, et d'utiliser les meta tags et autres balisage standard malgré l'incohérence de soutien. En d'autres termes utiliser à la fois les metatag types (<meta charset="UTF-8"> et <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />), mais dans la réalité de cette majoration ne sera pas décider de la façon dont vos pages sont codées ou interprété par les agents utilisateurs. Le principal moteur de ce codage est utilisé par le navigateur de la façon dont la page est codée par le logiciel, comme quelqu'un l'a mentionné ci-dessus, qui est de plus en plus UTF-8, ce qui est un juste un standard unicode qui est actuellement populaire. Le navigateur de l'utilisateur sera alors probablement sauter les metatags et consultez la page de deviner le codage de l'intention de l'auteur.

    En 2000, l'ensemble de cette balise meta débat était encore pire. L'utilisation de HTML4 incorporées des caractères unicode souvent conduit à des pages où ni codé correctement ou rendus correctement, malgré serveur les en-têtes HTTP, l'utilisation des entités de caractères, et metatags tout simplement parce que les navigateurs modernes de retour alors n' pas suivre les normes et ne regarde pas les métatags, le codage de la page, ou codée pour les entités de caractères. C'est pourquoi, à la bataille de toutes les combinaisons complexes de soutien et de systèmes à l'échec de normes de l'adoption, de son mieux pour utiliser toutes les combinaisons de technologies pour augmenter la "probabilité" de vos pages web en cours de rendu correctement.

    Nous avons appris à l'époque, un enseignement précieux: les Standards du Web ne sera jamais suivie par les entreprises. Lorsque les normes ne sont pas adoptées de façon constante par le secteur privé, il est toujours préférable d'utiliser toutes les formes et de la version de balisage, de tous les temps, sous toutes les formes possibles de façon à maximiser vos pages sont correctement visualisé à travers de nombreux périphériques à l'aide de diverses formes de ces normes, même si aujourd'hui, ils n'ont pas d'importance (comme les navigateurs maintenant analyser les pages et de déterminer l'encodage eux-mêmes).

    Que devrait être la stratégie utilisée pour tous les conception de page web jusqu'à ce que nous avons en quelque sorte de faire respecter l'adoption universelle des Standards du Web, qui est de plus en plus rare maintenant avec mobile user-agents et HTML5 qui nous ont contraint à abandonner encore une fois beaucoup des normes XML qui aurait forcée mieux balisage de la conception.

    InformationsquelleAutor Stokely