Pour les réponses HTTP avec types de contenu suggérant des données de caractère qui charset doit être assumée par le client si aucun n'est spécifié?

Question

Si aucun paramètre charset est spécifié dans l'en-tête Content-Type, RFC2616 section 3.7 .1 semble impliquer ISO8859-1 devrait supposer pour les types de médias de sous-type « texte »:

  

Si aucun paramètre charset explicite est   fournies par l'expéditeur, des sous-types de médias   du type « texte » sont définis avoir   une valeur charset par défaut   "ISO-8859-1" lors de la réception via HTTP.

     

Les données de jeux de caractères autres que   « ISO-8859-1 » ou ses sous-ensembles DOIVENT être   marqué avec un jeu de caractères approprié   valeur.

Cependant, je vois régulièrement des applications qui servent les fichiers Javascript avec des valeurs Content-Type comme "application / x-javascript" (pas de charset param), même lorsque ces scripts contiennent UTF-8 caractères non-ASCII, qui serait corruption si elle est interprétée comme ISO8859-1.

Cela ne semble pas poser de problèmes aux clients. Comment les clients savent interpréter les octets en UTF-8? Y at-il une règle pour les autres sous-types de caractères données qui implique doit être la valeur par défaut UTF-8? Où est ce documenté?

Answer 1

Tous les principaux navigateurs que j'ai vérifié (FF et Opera) complètement ignorer la spécification RFC dans cette partie.

Si vous êtes intéressé par l'algorithme charset de détection automatique des données, regardez Mozilla lien de Firefox.

Juste une petite note sur les types de contenu: Seul le texte a des jeux de caractères . Il est raisonnable de supposer que les navigateurs gèrent application / x-javascript même qu'ils gèrent text / javascript (sauf IE6, mais c'est un autre sujet).

Internet Explorer utilisera le jeu de caractères par défaut (probablement stocké au registre), comme il est indiqué:

  

Par défaut, Internet Explorer utilise la   jeu de caractères spécifié dans le HTTP   le type de contenu renvoyé par le serveur   déterminer cette traduction. Si cela   paramètre est pas donné, Internet   Explorer utilise le jeu de caractères   spécifié par l'élément meta dans le   document. Il utilise de l'utilisateur   préférences si aucun élément meta est   spécifié.

Source : http : //msdn.microsoft.com/en-us/library/ms537500%28VS.85%29.aspx

Mozilla Firefox tentatives de détecter automatiquement le jeu de caractères, comme indiqué ici:

  

Ce document présente trois types de méthodes de détection automatique pour déterminer les codages de documents sans déclaration charset explicite .

Source : http://www.mozilla.org /projects/intl/UniversalCharsetDetection.html

Opera utilise trop d'auto-détection, comme indiqué:

  

Si le protocole de transport fournit un nom d'encodage, qui est utilisé. Sinon, Opera se penchera sur la page pour une déclaration charset. Si ce manque, Opera tentera de détecter automatiquement l'encodage , en utilisant le nom de domaine pour voir si le script est un script CJK, et si oui, lequel. Opera peut également détecter automatiquement UTF-8.

Source : http://www.opera.com/ docs / spécifications / Opera9 /

Answer 2

Comme décrit dans RFC 4329 , également application/javascript peut avoir un paramètre charset. L'autre question est la gestion des implémentations du navigateur. Désolé, mais pas testé.

Answer 3

Dans le absense du paramètre charset, le codage de caractères peut être spécifié dans le contenu . Voici quelques approches prises par plusieurs types de contenu:

HTML - Par le :

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

HTML5 variante:

<meta charset="utf-8">

XML (XHTML, KML) - Via le :

<?xml version="1.0" encoding="UTF-8"?>

Texte - Via les Byte marque ordre . Par exemple, pour UTF-8 les trois premiers octets d'un fichier en hexadécimal:

EF BB BF

A la différence du jeu de caractères associé au document, notez que les caractères non-ASCII peuvent être codées par des séquences de caractères ASCII à l'aide de différentes approches:

HTML - Via :

&#nnnn;
&#xhhhh;

XML - Via :

&
&defined-entity;

JSON - Via le mécanisme d'échappement :

\u005C
\uD834\uDD1E

Maintenant, en ce qui concerne le protocole HTTP 1.1, RFC 2616 dit ceci A propos de charset :

  

Le paramètre « charset » est utilisé avec certains types de médias pour définir la   jeu de caractères (section 3.4) des données. En l'absence charset explicite   paramètre est fourni par l'expéditeur, les sous-types de médias du type « texte »   sont définis pour avoir une valeur charset par défaut de « ISO-8859-1 » lorsque   reçu via HTTP. Les données de jeux de caractères autres que « ISO-8859-1 » ou   ses sous-ensembles doivent être étiquetés avec une valeur de jeu de caractères approprié. Voir   section 3.4.1 pour des problèmes de compatibilité.

Alors, mon interprétation de ce qui précède est que l'on ne peut pas prendre un caractère par défaut défini sauf pour les sous-types de médias du type « texte ». Bien sûr, nous vivons dans le monde réel et ne implémenteurs suivent pas toujours les règles. Comme cela est décrit dans la réponse acceptée , les différents éditeurs de navigateurs Web ont mis en œuvre leurs propres stratégies pour déterminer le caractère de documents jeu quand il est pas explicitement spécifié. On peut supposer que les fournisseurs d'autres clients (par exemple Google Earth) mettent également en œuvre leurs propres stratégies.

Answer 4

RFC 4329 définit les médias "application / javascript" le type en remplacement de "text / javascript", "application / x-javascript", et d'autres types similaires. L'article 4.2 établit le caractère par défaut de codage pour être paramètre UTF-8 en l'absence explicite « charset » est disponible et aucune nomenclature Unicode est présent à l'avant des données.

Answer 5

Il est un peu spécial pour XMLHttpRequest et est décrit ici: http://www.w3.org / TR / XMLHttpRequest /

Answer 6

Montrer du doigt l'évidence:. "Application / x-javascript" n'est pas un sous-type de "texte"

En outre, le texte dans la RFC 2616 est obsolète. La prochaine révision du protocole HTTP / 1.1 ne définit pas un défaut. Voir pour plus d'informations RFC 6657.