Per risposte HTTP con tipi di contenuto che suggeriscono dati di carattere, quale set di caratteri deve essere assunto dal client se non viene specificato nessuno?

Question

Se nessun parametro charset viene specificato nell'intestazione Content-Type, RFC2616 section 3.7.1 sembra implicare ISO8859-1 deve essere assunto per i tipi di media di sottotipo "testo":

Quando nessun parametro esplicito charset è fornito dal mittente, i sottotipi di supporti del tipo "testo" sono definiti per avere un valore di charset predefinito di "ISO-8859-1" se ricevuto tramite HTTP.

dati in set di caratteri diversi "ISO-8859-1" o dei suoi sottoinsiemi DEVE essere etichettati con un valore charset appropriato.

Tuttavia, ho regolarmente vedere le applicazioni che servono i file JavaScript con valori Content-Type come "application/x-javascript" (vale a dire senza charset param), anche quando questi script contengono non-ASCII caratteri UTF-8, che sarebbe corrotto se interpretato come ISO8859-1.

Questo non sembra porre problemi ai clienti. Come sanno i client interpretare i byte come UTF-8? Esiste una regola per altri sottotipi di dati carattere che implica che UTF-8 dovrebbe essere l'impostazione predefinita? Dove è documentato?

Answer 1

Tutti i principali browser che ho controllato (IE, FF e Opera) completamente ignorano la specifica RFC in questa parte.

Se si è interessati all'algoritmo per rilevare automaticamente il set di caratteri in base ai dati, consultare il collegamento Mozilla Firefox.

Solo una piccola nota sui tipi di contenuto: Solo il testo ha set di caratteri. È ragionevole presumere che i browser gestiscano application/x-javascript allo stesso modo in cui gestiscono testo/javascript (tranne IE6, ma questo è un altro argomento).

Internet Explorer utilizzerà il set di caratteri di default (probabilmente conservato a Registro di sistema), come indicato:

Per impostazione predefinita, Internet Explorer utilizza il set di caratteri specificato nel tipo di contenuto HTTP restituito dal server a determinare questa traduzione. Se questo parametro non viene fornito, Internet Explorer utilizza il set di caratteri specificato dal meta elemento nel documento . Utilizza le preferenze dell'utente se nessun elemento meta è specificato .

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

Mozilla Firefox tentativi di rilevare automaticamente il set di caratteri, come sottolineato qui:

Questo documento presenta tre tipi di metodi di auto-rilevamento per determinare codifiche di documenti senza la dichiarazione di set di caratteri esplicita.

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

Opera utilizza il rilevamento automatico anche, come documentato:

Se il protocollo di trasporto fornisce un nome di codifica, che viene utilizzato. Altrimenti, Opera guarderà la pagina per una dichiarazione di charset. Se questo manca, Opera tenterà di rilevare automaticamente la codifica, utilizzando il nome di dominio per vedere se lo script è uno script CJK e, in tal caso, quale. Opera può anche rilevare automaticamente UTF-8.

Fonte: http://www.opera.com/docs/specs/opera9/

Answer 2

E 'un po' speciale per XMLHttpRequest ed è descritta qui: http://www.w3.org/TR/XMLHttpRequest/

Answer 3

Sottolineando l'ovvio: "/ x-javascript applicazione" non è un sottotipo di "testo".

Inoltre, il testo in RFC 2616 non è aggiornato. La prossima revisione di HTTP/1.1 non definirà un valore predefinito. Vedi RFC 6657 per ulteriori informazioni.

Answer 4

Come descritto nel RFC 4329, anche application/javascript può avere un parametro charset. L'altra domanda è la gestione delle implementazioni del browser. Ci dispiace, ma non testato.

Answer 5

RFC 4329 definisce il tipo di supporto "application/javascript" in sostituzione di "text/javascript", "application/x-javascript" e altri tipi simili. La Sezione 4.2 stabilisce la codifica dei caratteri di default per essere UTF-8 quando nessun parametro "charset" esplicito è disponibile e nessuna BOM Unicode è presente nella parte anteriore dei dati.

Answer 6

In assenza del parametro charset, la codifica dei caratteri può essere specificata nel contenuto . Ecco alcuni approcci presi da diversi tipi di contenuto:

HTML - Via del meta tag:

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

HTML5 variante:

<meta charset="utf-8"> 

XML (XHTML, KML) - Via XML declaration:

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

Testo - Via del Byte order mark.Ad esempio, per UTF-8 i primi tre byte di un file in esadecimale:

EF BB BF 

A differenza del set di caratteri associata al documento, nota anche che i caratteri non ASCII possono essere codificati con caratteri ASCII sequenze utilizzando diversi approcci:

HTML - Via character references:

&#nnnn; 
&#xhhhh; 

XML - Via character references:

& 
&defined-entity; 

JSON - Via del escaping mechanism:

\u005C 
\uD834\uDD1E 

Ora, per quanto riguarda l'HTTP 1.1 protocollo, RFC 2616 says this about charset:

Il "charset" parametro viene utilizzato con alcuni tipi di media per definire il set di caratteri (sezione 3.4) dei dati. Se il mittente non fornisce alcun parametro set di caratteri esplicito , i tipi di sottotipo di tipo "testo" devono avere un valore charset predefinito di "ISO-8859-1" quando ricevuto tramite HTTP. I dati in set di caratteri diversi da "ISO-8859-1" o i relativi sottoinsiemi DEVONO essere etichettati con un valore di set di caratteri appropriato. Vedere la sezione 3.4.2 per problemi di compatibilità.

Quindi, la mia interpretazione di quanto sopra è che si non si può assumere set di caratteri di default tranne per i sottotipi dei media del tipo "testo". Certo, viviamo nel mondo reale e gli implementatori non sempre seguono le regole. Come descritto nello accepted answer, i vari fornitori di browser Web hanno implementato le proprie strategie per determinare il set di caratteri del documento quando non è specificato esplicitamente. Si può presumere che anche i fornitori di altri clienti (ad es. Google Earth) implementino le proprie strategie.