Per le risposte HTTP con tipi di contenuto che suggeriscono dati sui caratteri, quale set di caratteri dovrebbe essere assunto dal client se non ne viene specificato nessuno?
https://stackoverflow.com/questions/2325571
-
22-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
Se non è specificato alcun parametro del set di caratteri nell'intestazione Content-Type, RFC2616 sezione 3.7.1 sembra implicare che si dovrebbe assumere la norma ISO8859-1 per i tipi di media del sottotipo "testo":
Quando non è presente alcun parametro charset esplicito forniti dal mittente, sottotipi di supporti del tipo "testo" sono definiti in modo da avere un valore predefinito del set di caratteri di "ISO-8859-1" quando ricevuto tramite HTTP.
Dati in set di caratteri diversi da "ISO-8859-1" o i suoi sottoinsiemi DEVONO essere etichettato con un set di caratteri appropriato valore.
Tuttavia, vedo abitualmente applicazioni che forniscono file Javascript con valori di tipo contenuto come "application/x-javascript" (ad es.no charset param), anche quando questi script contengono caratteri non ASCII UTF-8, che verrebbero danneggiati se interpretati come ISO8859-1.
Ciò non sembra creare problemi ai clienti.Come fanno i client a interpretare i byte come UTF-8?Esiste una regola per altri sottotipi di dati di carattere che implica che UTF-8 dovrebbe essere l'impostazione predefinita?Dove è documentato questo?
Soluzione
Tutti i principali browser che ho controllato completamente (IE, FF e Opera). ignorare la specifica RFC in questa parte.
Se sei interessato all'algoritmo per rilevare automaticamente il set di caratteri in base ai dati, guarda Mozilla Firefox collegamento.
Solo una piccola nota sui tipi di contenuto: Solo il testo ha set di caratteri.È ragionevole supporre che i browser gestiscano application/x-javascript nello stesso modo in cui gestiscono text/javascript (eccetto IE6, ma questo è un altro argomento).
Internet Explorer utilizzerà il set di caratteri predefinito (probabilmente memorizzato nel registro), come notato:
Per impostazione predefinita, Internet Explorer utilizza l'attributo set di caratteri specificato nel file HTTP tipo di contenuto restituito dal server a determinare questa traduzione.Se questo parametro non è dato, Internet Explorer utilizza il set di caratteri specificato dall'elemento meta nel file documento. Utilizza il metodo dell'utente Preferenze se non c'è nessun elemento meta specificato.
Fonte: http://msdn.microsoft.com/en-us/library/ms537500%28VS.85%29.aspx
Mozilla Firefox tenta di rilevare automaticamente il set di caratteri, come indicato qui:
Questo documento presenta tre tipi di metodi di rilevamento automatico per determinare le codifiche dei documenti senza dichiarazione esplicita del set di caratteri.
Fonte: http://www.mozilla.org/projects/intl/UniversalCharsetDetection.html
musica lirica utilizza anche il rilevamento automatico, come documentato:
Se il protocollo di trasporto fornisce un nome di codifica, viene utilizzato quello.In caso contrario, Opera cercherà nella pagina una dichiarazione del set di caratteri. Se manca, Opera tenterà di rilevare automaticamente la codifica, utilizzando il nome di dominio per vedere se lo script è uno script CJK e, in caso affermativo, quale.Opera può anche rilevare automaticamente UTF-8.
Altri suggerimenti
Come descritto nella RFC 4329 , anche application/javascript può avere un parametro charset. L'altra questione è la gestione delle implementazioni dei browser. Ci dispiace, ma non testato.
Nel absense del parametro charset, la codifica dei caratteri può essere specificato nel contenuto . Ecco alcuni approcci presi da diversi tipi di contenuto:
HTML - Via il meta tag :
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
HTML5 variante:
<meta charset="utf-8">
<?xml version="1.0" encoding="UTF-8"?>
testo - Via le href="http://en.wikipedia.org/wiki/Byte_order_mark" byte order mark . Ad esempio, per UTF-8 i primi tre byte di un file in formato esadecimale:
EF BB BF
A differenza del set di caratteri associata al documento, nota anche che i caratteri non ASCII possono essere codificati con sequenze di caratteri ASCII utilizzando vari approcci:
&#nnnn;
&#xhhhh;
&
&defined-entity;
JSON - Via il meccanismo sfuggire :
\u005C
\uD834\uDD1E
Ora, per quanto riguarda il protocollo HTTP 1.1, RFC 2616 dice che questo su charset :
Il parametro "charset" è usato con alcuni tipi di supporto per definire il set di caratteri (punto 3.4) dei dati. Quando nessun charset esplicita parametro è fornito dal mittente, sottotipi multimediali di tipo "text" sono definiti per avere un valore charset di default di "ISO-8859-1" quando ricevuti via HTTP. I dati nel set di caratteri diverso da "ISO-8859-1" o suoi sottoinsiemi deve essere etichettato con un valore charset appropriato. Vedere sezione 3.4.1 per problemi di compatibilità.
Quindi, la mia interpretazione di quanto sopra è che uno non può assumere un carattere di default impostato tranne per i sottotipi dei media del tipo "testo". Naturalmente, noi viviamo nel mondo reale e gli esecutori non sempre seguono le regole. Come descritto nella risposta accettata , i vari fornitori di browser web hanno messo in atto le proprie strategie per determinare il set di caratteri del documento quando è non esplicitamente specificato. Si può presumere che i produttori di altri clienti (ad esempio, Google Earth) implementano anche le proprie strategie.
RFC 4329 definisce i media "application / javascript" tipo come una sostituzione per "text / javascript", "application / x-javascript", e altri tipi simili. Sezione 4.2 stabilisce la codifica dei caratteri di default per essere UTF-8 quando nessun parametro esplicito "charset" è disponibile e non Unicode BOM è presente nella parte anteriore dei dati.
E 'un po' speciale per XMLHttpRequest ed è descritta qui: http://www.w3.org / TR / XMLHttpRequest /
Sottolineando l'ovvio:. "Application / x-javascript" non è un sottotipo di "testo"
Inoltre, il testo in RFC 2616 è obsoleto. La prossima revisione di HTTP / 1.1 non definirà un default. Vedi RFC 6657 per ulteriori informazioni.
