<meta charset = "utf-8"> vs <meta http-equiv = "Content-Type">


1535

Per definire il set di caratteri per HTML5 Doctype , quale notazione dovrei usare?

  1. Corto:

    <meta charset="utf-8" /> 
  2. Lungo:

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

94
L'uso di un tag <meta> per qualcosa come il tipo di contenuto e la codifica è estremamente ironico, poiché senza conoscere queste cose, non è possibile analizzare il file per ottenere il valore del meta tag.
Segna il

321
Puoi analizzarlo come ASCII fino a quando non lo raggiungi. L'algoritmo di analisi HTML5 ne tiene conto.
Quentin,

41
Si noti che nessuno dei due è stato utilizzato per l'analisi quando la pagina viene pubblicata sul Web. Content-TypeVerrà invece utilizzato quello nell'intestazione della risposta HTTP . Il meta tag viene utilizzato solo quando la pagina viene caricata dal file system del disco locale.
BalusC

38
Il meta elemento viene utilizzato su HTTP in determinate condizioni (inclusa l'assenza dei dati nell'intestazione HTTP)
Quentin

78
È anche ironico che sia chiamato charset, quando serve per specificare una codifica. (il set di caratteri è Unicode, la codifica è UTF-8)
Ryan

Risposte:


1084

In HTML5, sono equivalenti. Usa quello più corto, è più facile da ricordare e digitare. Il supporto del browser va bene poiché è stato progettato per la compatibilità all'indietro.


23
Che dire del supporto del browser? Fa <meta charset='utf-8'>il lavoro in IE6?
Šime Vidas,

11
Per quanto ne so, sì.
Quentin,

4
Ecco un link aggiornato per la pagina del codice di Google menzionata da @ Šime Vidas. Dice, per quanto riguarda IE 6, 7 e 8, "Nei browser non IE, puoi usare document.characterSet. In IE, potresti pensare di poter document.getElementsByTagName ('meta') [0] .charset, ma questo restituisce solo la codifica dei caratteri specificata, non la codifica attualmente utilizzata da IE. "
hotshot309

7
So che questa discussione è vecchia, ma gtmetrix.com/specify-a-character-set-early.html indica che l'utilizzo <meta>della codifica dei caratteri disabilita il downloader lookahead in IE8, che può influire sui tempi di caricamento della pagina. Sì, sì, lo so ... lascia cadere IE8. @ MészárosLajos può tornare qui tra un paio d'anni e romperci le palle per supportare ancora IE8. ;-)
erturne

3
Oggi ho avuto un problema in cui i simboli coreani non apparivano in IE11. Eliminare la sintassi breve a favore della sintassi più lunga ha risolto il problema. Non so se ciò sia dovuto a qualche tipo di configurazione del server o se si tratta di un problema con IE11 e il set di caratteri. La combinazione esatta di simboli su cui stava fallendo era 베라.
James Donnelly,

250

Entrambe le forme della dichiarazione del meta charset sono equivalenti e dovrebbero funzionare allo stesso modo su tutti i browser. Tuttavia, ci sono alcune cose che è necessario ricordare quando si dichiarano i set di caratteri dei file Web come UTF-8:

  1. Salvare i file nella codifica UTF-8 senza il segno di ordine dei byte (BOM).
  2. Dichiara la codifica nei tuoi file HTML usando meta charset (come sopra).
  3. Il tuo server web deve servire i tuoi file, dichiarando la codifica UTF-8 nell'intestazione HTTP Content-Type.

I server Apache sono configurati per servire file in ISO-8859-1 per impostazione predefinita, quindi è necessario aggiungere la seguente riga al .htaccessfile:

AddDefaultCharset UTF-8

Questo configurerà Apache per servire i tuoi file dichiarando la codifica UTF-8 nell'intestazione della risposta Content-Type, ma per iniziare i tuoi file devono essere salvati in UTF-8 (senza BOM).

Blocco note non può salvare i file in UTF-8 senza la distinta componenti. Un editor gratuito che può essere Notepad ++ . Nella barra dei menu del programma, selezionare "Codifica> Codifica in UTF-8 senza DBA". Puoi anche aprire i file e salvarli nuovamente in UTF-8 usando "Codifica> Converti in UTF-8 senza BOM".

Maggiori informazioni sul Byte Order Mark (BOM) su Wikipedia .


20
@CodeBoy vorrei modificare la tua risposta a dire "Si dovrebbe risparmiare ... senza BOM". La pagina seguente dice "... di solito è meglio che l'interoperabilità ometta la distinta base ..." che indica una migliore pratica, ma non un requisito: w3.org/International/questions/qa-byte-order-mark
Johann

3
In IIS è possibile impostare il set di caratteri nelle intestazioni HTTP con <globalization fileEncoding = "utf-8" responseEncoding = "utf-8" /> in Web.Config - aggiungerlo a <system.web>
Chris Moschini

3
come capisco le cose, non importa affatto se si salva con la nostra senza distinta base.
David 天宇 Wong,

3
Perché dici che UTF-8 HTML dovrebbe essere senza BOM. Avere una DBA dovrebbe funzionare bene. Inoltre, non è necessario metae un'intestazione HTTP. Hai solo bisogno di una DBA metao intestazione HTTP.
hsivonen,

5
Summing up: don't use BOM for UTF-8Non posso essere d'accordo con questo. La distinta base in UTF-8 è molto utile per segnalare il tipo di codifica. Altrimenti dobbiamo indovinare o usare cose come i meta tag a cui fa riferimento questa domanda. Il bello della distinta componenti è che fa parte delle specifiche Unicode e quindi può essere utilizzato per tutti i dati codificati in Unicode, non solo HTML. Quello che dovremmo fare è usare le distinte materiali ovunque, lasciare che il software legacy esploda su di esso, segnalare quei bug e risolverli.
Stijn de Witt,

82

Un altro motivo per scegliere quello breve è che corrisponde ad altri casi in cui è possibile specificare un set di caratteri nel markup. Per esempio:

<script type="javascript" charset="UTF-8" src="/script.js"></script>

<p><a charset="UTF-8" href="http://example.com/">Example Site</a></p>

La coerenza aiuta a ridurre gli errori e a rendere il codice più leggibile.

Si noti che l'attributo charset non fa distinzione tra maiuscole e minuscole. Puoi usare UTF-8 o utf-8, tuttavia UTF-8 è più chiaro, più leggibile, più preciso.

Inoltre, non vi è assolutamente alcun motivo per utilizzare qualsiasi valore diverso da UTF-8 nell'attributo meta charset o nell'intestazione della pagina. UTF-8 è la codifica predefinita per i documenti Web da HTML4 nel 1999 e l'unico modo pratico per creare pagine Web moderne.

Inoltre non dovresti usare entità HTML in UTF-8. Personaggi come il simbolo del copyright devono essere digitati direttamente. Le uniche entità che dovresti usare sono per i 5 caratteri di markup riservati: minore di, maggiore di, e commerciale, primo, doppio primo. Le entità necessitano di un parser HTML, che potresti non voler sempre utilizzare in futuro, introducono errori, rendono il codice meno leggibile, aumentano le dimensioni del file e talvolta decodificano in modo errato in vari browser a seconda delle entità utilizzate. Scopri come digitare / inserire copyright, marchio commerciale, citazione aperta, citazione chiusa, apostrofo, trattino, trattino, pallottola, Euro e qualsiasi altro personaggio che incontri nei tuoi contenuti e come usare quei caratteri reali nel tuo codice. Il Mac ha un Visualizzatore caratteri che puoi attivare in Preferenze di Sistema tastiera, e puoi trovare e quindi trascinare e rilasciare i caratteri necessari o utilizzare il Visualizzatore tastiera corrispondente per vedere quali tasti digitare. Ad esempio, il marchio commerciale è Opzione + 2. UTF-8 contiene tutti i caratteri e i simboli di ogni linguaggio umano scritto. Quindi non ci sono scuse per l'uso, invece di un trattino. Non è una cattiva idea imparare anche le regole di punteggiatura e tipografia ... per esempio, sapendo che un punto va dentro una citazione stretta, non fuori.

L'uso di un tag per qualcosa di simile al tipo di contenuto e alla codifica è estremamente ironico, poiché senza conoscere queste cose, non è possibile analizzare il file per ottenere il valore del metatag.

No, questo non è vero. Il browser inizia ad analizzare il file come codifica predefinita del browser, UTF-8 o ISO-8859-1. Poiché US-ASCII è un sottoinsieme di ISO-8859-1 e UTF-8, il browser può leggere bene in entrambi i modi ... è lo stesso. Quando il browser rileva il tag meta charset, se la codifica è diversa da quella già utilizzata dal browser, il browser ricarica la pagina nella codifica specificata. Ecco perché mettiamo il tag meta charset in alto, subito dopo il tag head, prima di ogni altra cosa, persino il titolo. In questo modo puoi usare i caratteri UTF-8 nel tuo titolo.

È necessario salvare i file nella codifica UTF-8 senza distinta base

Questo non è strettamente vero. Se nel documento sono presenti solo caratteri US-ASCII, è possibile salvarlo come US-ASCII e servirlo come UTF-8, poiché è un sottoinsieme. Ma se ci sono caratteri Unicode, hai ragione, devi salvare come UTF-8 senza DBA.

Se vuoi un buon editor di testo che salverà i tuoi file in UTF-8, ti consiglio Notepad ++.

Sul Mac, usa Bare Bones TextWrangler (gratuito) dal Mac App Store o Bare Bones BBEdit, che si trova sul Mac App Store per $ 39,99 ... molto economico per uno strumento così eccezionale. In entrambe le app, c'è un menu nella parte inferiore della finestra del documento in cui si specifica la codifica del documento e si può facilmente scegliere "UTF-8 no BOM". E ovviamente puoi impostarlo come predefinito per i nuovi documenti in Preferenze.

Ma se il tuo server web serve la codifica nell'intestazione HTTP, che è raccomandato, entrambi i [meta tag] sono inutili.

Questo non è corretto Ovviamente dovresti impostare la codifica nell'intestazione HTTP, ma dovresti anche impostarla nell'attributo meta charset in modo che la pagina possa essere salvata dall'utente, fuori dal browser nella memoria locale e quindi riaperta più tardi, nel qual caso l'unica indicazione della codifica che sarà presente è l'attributo meta charset. Dovresti anche impostare un tag base per lo stesso motivo ... sul server, il tag base non è necessario, ma quando aperto dalla memoria locale, il tag base consente alla pagina di funzionare come se fosse sul server, con tutti i risorse in atto e così via, nessun collegamento interrotto.

AggiungiDefaultCharset UTF-8

Oppure puoi semplicemente modificare la codifica di determinati tipi di file in questo modo:

AddType text/html;charset=utf-8 html

Un suggerimento per servire sia i file UTF-8 che i file Latin-1 (ISO-8859-1) è quello di dare ai file UTF-8 un'estensione "text" e i file Latin-1 "txt".

AddType text/plain;charset=iso-8859-1 txt
AddType text/plain;charset=utf-8 text

Infine, considera la possibilità di salvare i tuoi documenti con terminazioni di linea Unix, non legacy DOS o terminazioni di linea (classiche) per Mac, che non aiutano e potrebbero danneggiare, specialmente lungo la linea man mano che andiamo sempre più lontano da quei sistemi legacy. Un documento HTML con HTML5 valido, codifica UTF-8 e terminazioni di riga Unix è un lavoro ben fatto. È possibile condividere e modificare e archiviare e leggere e recuperare e fare affidamento su quel documento in molti contesti. È lingua franca. È carta digitale.


20
"Se hai solo caratteri ISO-8859-1 nel tuo documento, puoi salvarlo come ISO-8859-1 e servirlo come UTF-8, perché è un sottoinsieme" - errato. Sarebbe corretto se si cambia "ISO-8859-1" in "US-ASCII". US-ASCII è compatibile con UTF-8 perché è un sottoinsieme, ISO-8859-1 non lo è. Per convertire ISO-8859-1 (contenente caratteri non ASCII) in UTF-8, è necessario codificare i caratteri non ASCII. I punti di codice per ISO-8859-1 esistono in Unicode, ma UTF-8 codifica quelli al di fuori di US-ASCII in modo diverso da ISO-8859-1.
thomasrutter,

2
Il tuo punto sulle entità HTML è buono. In passato, ho usato entità solo per scoprire che erano state convertite nei loro caratteri UTF-8 dopo essere state salvate su sistemi diversi e / o aperte in diversi editor. Vale la pena notare, tuttavia, che spazi non interrompibili (& nbsp;) possono produrre risultati confusi poiché in genere non li vedrai nel tuo editor, quindi di solito è meglio tenerli come entità per chiarezza (nella mia esperienza).
Squidbe,

"You should also set a base tag..."dovrebbe venire con le avvertenze qui descritte .
Mafuba,

Un altro motivo per cui potresti preferire entità HTML è se stai usando qualcosa come gli ioniconi . Preferirei vedere &#xf101;il glifo predefinito, o qualche strano personaggio che non riconosco.
Daniel Lubarov,

30

<meta charset="utf-8"> è stato introdotto con / per HTML5.

Come indicato nella documentazione, entrambi sono validi. Tuttavia, <meta charset="utf-8">è solo per HTML5 (e più facile da scrivere / ricordare).

A tempo debito, il vecchio stile è destinato a diventare deprecato nel prossimo futuro. Attaccherei al nuovo <meta charset="utf-8">.

C'è solo un modo, ma in alto. Nel caso della tecnologia, questo sta gradualmente eliminando il vecchio (davvero, DAVVERO veloce)

Documentazione: attributo HTML meta charset — W3Schools



18

Pur non contestando le altre risposte, penso che sia degno di nota quanto segue.

  1. La http-equivnotazione "long" ( ) e quella "short" sono uguali, qualunque sia la prima vittima;
  2. Le intestazioni del server Web sovrascriveranno tutti i <meta>tag;
  3. BOM (Byte order mark) sovrascriverà tutto e in molti casi influenzerà l'html 4 (e probabilmente anche altre cose);
  4. Se non dichiari alcuna codifica, probabilmente otterrai il tuo testo in "codifica del testo di fallback" che è definita dal tuo browser. Né in Firefox né in Chrome è utf-8;
  5. In assenza di altri indizi, il browser tenterà di leggere il documento come se fosse in ASCII per ottenere la codifica, quindi non è possibile utilizzare strane codifiche (utf-16 con BOM dovrebbe fare, però);
  6. Mentre le specifiche indicano che la dichiarazione di codifica deve trovarsi entro i primi 512 byte del documento, la maggior parte dei browser proverà a leggere di più.

È possibile eseguire il test eseguendo echo 'HTTP/1.1 200 OK\r\nContent-type: text/html; charset=windows-1251\r\n\r\n\xef\xbb\xbf<!DOCTYPE html><html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta charset="windows-1251"><title>привет</title></head><body>привет</body></html>' | nc -lp 4500e puntando il browser verso localhost:4500. (Naturalmente vorrai cambiare o rimuovere parti. La parte DBA è \xef\xbb\xbf. Diffida della codifica della tua shell.)

Tieni presente che è molto importante dichiarare esplicitamente la codifica. Lasciare indovinare i browser può portare a problemi di sicurezza.


1
Aspetti positivi, ma puoi specificare a quali problemi di sicurezza ti riferisci?
Armfoot,

1
La notazione lunga non dovrebbe sovrascrivere quella breve: semplicemente la prima nel documento dovrebbe vincere.
gsnedders il

1
@Armfoot In passato c'erano problemi con UTF-7ciò che ricordo. Anche annusare sul web è generalmente negativo, ad esempio quando carichi un'immagine che viene annusata come contenuto dello script.
phk,

@gsnedders testato in Chrome e Firefox, hai ragione. modificato la risposta di conseguenza. Armfoot: si trattava di una codifica a 7 bit, non ricordo esattamente cosa.
scoiattolo,

1
@CraigMcQueen è abbastanza sicuro che il fallback del browser sia ancora (nel 2018) predefinito in Europa occidentale nell'Europa occidentale, quindi immagino che sia impostato su qualsiasi codifica pre-unicode sia stata dominante in ogni regione. Gli utenti possono impostare il fallback su utf-8, ma questo espone semplicemente tutte le codificazioni scadenti che migliaia di siti usano ancora come caratteri ASCII glitchy high byte dappertutto, quindi non è ancora comune. Più è un peccato. Non riesco a vedere come questo cambierà senza un po 'di coercizione da parte dei venditori di browser e non sono entusiasti di rompere cose legacy.
brennanyoung,

13

Utilizzare <meta charset="utf-8" />per i browser Web quando si utilizza HTML5.

Utilizzare <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />quando si utilizza HTML4 o XHTML o per parser dom obsoleti, come DOMDocumentin php 5.3


2

Ci sono alcune notizie basate su Mozilla Foundation e sitepoint

Non utilizzare questo valore ( http-equiv=content-type) poiché è obsoleto. Preferisce l' charsetattributo sull'elemento < meta>. inserisci qui la descrizione dell'immagine


oh, finalmente, qualcosa di un po 'più recente
Ayyash,

1

Per incorporare una firma in un'e-mail, vorrei utilizzare la versione lunga:

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

Il motivo è che non molti lettori di e-mail usano html5, quindi è sempre meglio usare i vecchi stili html. In realtà, è meglio usare le tabelle che anche divs + css.

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.