Come dire al browser la codifica dei caratteri di un sito Web HTML indipendentemente dall'intestazione del tipo di contenuto del server?


9

Ho una pagina HTML che correttamente (la codifica del fisico su disco corrisponde) annuncia che è Content-Type :

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta http-equiv="Content-Type" content=
    "text/html; charset=utf-8">
    <title> ...

L'apertura del file dal disco nel browser (Google Chrome, Firefox) funziona correttamente.

Richiedendolo tramite HTTP, il server web invia un'intestazione Content-Type diversa:

$ curl -I http://example.com/file.html
HTTP/1.1 200 OK
Date: Fri, 19 Oct 2012 10:57:13 GMT
...
Content-Type: text/html; charset=ISO-8859-1

(vedi ultima riga). Il browser utilizza quindi ISO-8859-1 per visualizzare il risultato indesiderato.

Esiste un modo comune per sovrascrivere le intestazioni del server inviate al browser dall'interno del documento HTML?

Risposte:


6

"Esiste un modo comune per sovrascrivere le intestazioni del server inviate al browser dall'interno del documento HTML?"

AFAIK no, fai già quello che puoi fare. Il set di caratteri definito tramite Header supera la tua definizione nel tag META.

Se hai accesso al server, ad esempio Apache, è configurato da questa istruzione (vedi le righe dei commenti):

# Read the documentation before enabling AddDefaultCharset.
# In general, it is only a good idea if you know that all your files
# have this encoding. It will override any encoding given in the files
# in meta http-equiv or xml encoding tags.

#AddDefaultCharset UTF-8

[Aggiornare]

Al secondo commento di w3d qui troverai alcuni modi per cambiare il set di caratteri tramite Direttive htaccess per il server Apache.


2
+1 Le intestazioni HTTP hanno la precedenza sui meta tag HTML. Se @hakre ha accesso al lato server, potrebbe anche sovrascrivere l'intestazione Content-Type su una base per pagina.
MrWhite,

3
Bene, ecco il riferimento normativo che specifica che le intestazioni HTTP vincono i
Jukka K. Korpela,

Grazie per la risposta. @Korpela: Sì, l'ho avuto in memoria con le specifiche HTML. È esattamente il contrario, poiché ne ho bisogno :(.
hakre,

Per quanto riguarda .htaccess (scusate, forse dovrebbe essere una nuova domanda), è possibile rimuovere anche l' ;charset=...intestazione http. Il sito funziona molto bene con Content-Type: text/htmldiversi file con codifiche diverse sul server. (Temo che ciò non sia possibile, anche perché penso di averlo cercato alcune settimane fa, ma il risultato non è stato del tutto definitivo). Nel caso in cui tu possa far luce un po 'avanti.
hakre,

@hakre Se la Direttiva ForceType di Apache funziona per te, inseriscila in un contenitore <Files> e dai un nome individuale ai file o ad alcune directory. Basta lasciare la parte "; charset =" dopo il tipo mime, quindi dovrebbe farlo.
initall

3

Dovresti impostare qualcosa del genere nel tuo .htaccess di root

<FilesMatch "\.(htm|html|xhtml|xml|php)$">
    AddDefaultCharset utf-8
</FilesMatch>

3

No, non è possibile all'interno dell'HTML. L'intestazione della risposta del server ha la precedenza sul meta-tag del documento. Come specificato in 5.2.2 Specifica della codifica dei caratteri - Specifica HTML 4.01 :

Per riassumere, gli user agent conformi devono osservare le seguenti priorità quando si determina la codifica dei caratteri di un documento (dalla priorità più alta alla più bassa):

  1. Un parametro "charset" HTTP in un campo "Tipo di contenuto".
  2. Una dichiarazione META con "http-equiv" impostato su "Content-Type" e un valore impostato per "charset".
  3. L'attributo charset impostato su un elemento che designa una risorsa esterna.

Quindi questo richiede una configurazione sul lato server. Tuttavia, come continua il capitolo:

I programmi utente possono fornire un meccanismo che consente agli utenti di sovrascrivere informazioni "charset" errate. Tuttavia, se un programma utente offre tale meccanismo, dovrebbe offrirlo solo per la navigazione e non per la modifica, per evitare la creazione di pagine Web contrassegnate con un parametro "charset" errato.

Nel mio caso, l' intestazione Content-Type del server contiene il giusto tipo MIME ma il set di caratteri sbagliato .

A quanto pare, la mia configurazione httpd di Apache aveva impostato l' AddDefaultCharsetaccensione che stava aggiungendo la ; charset=ISO-8859-1parte. Inserire nella directory principale dei siti Web .htaccessla seguente riga:

AddDefaultCharset Off

le informazioni sul set di caratteri sono state rimosse:

$ curl -I http://example.com/file.html
HTTP/1.1 200 OK
Date: Fri, 19 Oct 2012 15:07:52 GMT
...
Content-Type: text/html

(vedi ultima riga, nessuna ; charset=...parte). Questo in combinazione con il meta-tag html innesca la suddetta euristica del browser per assumere il set di caratteri dal meta-tag. Il sito Web è stato correttamente decodificato.

Testato con:

  • Google Chrome v. 22.0.1229.94
  • Firefox v. 16.0.1
  • Lynx versione 2.8.7rel.1 (05 lug 2009)

Questi tre browser hanno avuto problemi con la configurazione originale e funzionano ora (tutti su Fedora 17).

  • Opera 12.02
  • Internet Explorer 6 (Win XP SP3)

Non ho avuto il problema in primo luogo. Entrambi preferivano UTF-8 dal meta-tag rispetto all'impostazione ISO-8859-1 dal server.

  • Netscape 2.01 Gold

Non supporta UTF-8, quindi sceglie sempre Western (Latin1) indipendentemente dall'impostazione del server e dal meta-tag.


1

Oltre a quanto detto qui, proverei ad usare lo stesso set di caratteri in tutte le pagine - preferibilmente UTF-8(ma se quasi tutto è iso-8859-1, usalo).

Per controllare rapidamente il set di caratteri di un file, puoi provare:

file --mime-type --mime-encoding {filename}

Per controllare il set di caratteri di tutti i file nella struttura, puoi provare:

find . -type f -exec file --mime-type --mime-encoding '{}' \;

oppure (chiamando il filecomando una sola volta):

find . -type f -print | file --mime-type --mime-encoding -f-

Per ottenere un riepilogo, utilizzare l' -bopzione al filecomando (per omettere i nomi dei file) e reindirizzare il risultato sort | uniq -c.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.