Attributo HTML accept-charset
L'attributo HTML accept-charset specifica la codifica dei caratteri da usare nell'invio del modulo. Scopri come usarlo sull'elemento <form>.
L'attributo HTML accept-charset specifica la codifica dei caratteri (charset) che il browser deve utilizzare quando invia un modulo al server.
Questo attributo può essere usato soltanto sull'elemento <form> — non ha alcun significato su input, pulsanti o qualsiasi altro tag. Il suo valore è un elenco separato da spazi o virgole di una o più codifiche di caratteri. Il valore predefinito è UNKNOWN, che indica al browser di usare la stessa codifica del documento che contiene il modulo. Non è mai necessario scrivere accept-charset="UNKNOWN" esplicitamente: quel comportamento predefinito è quello che si ottiene omettendo completamente l'attributo.
Perché esiste questo attributo
Per comprendere accept-charset, bisogna immaginare il web prima che UTF-8 diventasse universale. Alla fine degli anni '90 e nei 2000, i documenti venivano comunemente serviti con codifiche a byte singolo come ISO-8859-1 (Europa occidentale), Shift_JIS (giapponese) o windows-1251 (cirillico). Una pagina in una codifica poteva inviare dati a un server che ne attendeva un'altra, e un campo del modulo contenente caratteri non rappresentabili dalla codifica di destinazione sarebbe arrivato al server come byte illeggibili (mojibake). accept-charset era la via di fuga: permetteva all'autore di specificare "codifica l'invio di questo modulo come questo charset, indipendentemente dalla codifica usata dalla pagina stessa".
Questa incompatibilità è l'unica situazione in cui l'attributo abbia mai avuto importanza — una pagina con una codifica legacy che alimentava un backend che ne richiedeva un'altra. Una volta che l'intero stack si è standardizzato su UTF-8, il problema è scomparso.
Importante — oggi questo attributo è di fatto un no-op. In pratica, ogni moderno browser invia i dati del modulo usando la codifica del documento stesso — UTF-8 per qualsiasi pagina moderna — indipendentemente da
accept-charset. (L'algoritmo HTML di invio dei moduli definisce come verrebbe selezionata una codifica elencata, ma poiché le pagine e i browser moderni sono UTF-8 da cima a fondo, l'attributo non cambia nulla.) Per le nuove pagine, il modo affidabile per controllare la codifica è servire il documento in UTF-8 (con<meta charset="UTF-8">) e lasciare che il browser invii in UTF-8 — nella quasi totalità dei casiaccept-charsetnon è necessario.
Sintassi
<form accept-charset="character_set"></form>Valori comuni del set di caratteri
| Valore | Descrizione |
|---|---|
UTF-8 | Codifica Unicode universale. Il comportamento predefinito di ogni moderno browser e il valore consigliato per praticamente tutti i moduli. |
ISO-8859-1 | Latin-1, una codifica legacy a 8 bit per le lingue dell'Europa occidentale. Non può rappresentare la maggior parte dei caratteri non latini; rilevante solo per sistemi obsoleti. |
UNKNOWN | Il valore predefinito. Indica al browser di usare la stessa codifica del documento che contiene il modulo. |
È possibile elencare più di una codifica (ad esempio accept-charset="UTF-8 ISO-8859-1"); il browser dovrebbe scegliere la prima che riesce a supportare. Nei browser moderni questo elenco viene di fatto ignorato.
Utilizzo moderno e corretto
Per praticamente ogni modulo che si scrive oggi, l'approccio corretto è non fare nulla di speciale: servire la pagina in UTF-8 e omettere accept-charset. Il modulo invierà automaticamente in UTF-8, che è ciò che il server dovrebbe aspettarsi.
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8" />
<title>Contact form</title>
</head>
<body>
<!-- No accept-charset needed: UTF-8 page submits as UTF-8 -->
<form action="/contact" method="post">
<input type="text" name="name" placeholder="Your name" />
<input type="email" name="email" placeholder="Your email" />
<input type="submit" value="Send" />
</form>
</body>
</html>Se si preferisce essere espliciti, scrivere accept-charset="UTF-8" è innocuo e documenta l'intenzione — ma non cambia nulla, poiché UTF-8 è già il comportamento predefinito.
Esempio dell'attributo HTML accept-charset
L'esempio seguente imposta accept-charset="ISO-8859-1", una codifica legacy, per illustrare la sintassi dell'attributo. Si noti che i browser attuali invieranno comunque questo modulo in UTF-8 — si tratta di una dimostrazione, non di una raccomandazione.
<!DOCTYPE html>
<html>
<head>
<title>Title of the document</title>
<style>
input {
display: block;
margin-bottom: 10px;
}
</style>
</head>
<body>
<form action="/form/submit" accept-charset="ISO-8859-1" method="post">
<input type="text" name="name" placeholder="Enter your Name" />
<input type="text" name="surname" placeholder="Enter your Surname" />
<input type="number" name="age" placeholder="Enter your Age" />
<input type="submit" value="Send" />
</form>
</body>
</html>Attributi del modulo correlati
L'attributo accept-charset opera insieme agli altri attributi impostati su un <form>:
action— l'URL a cui vengono inviati i dati del modulo.method— il metodo HTTP (GEToPOST) usato per l'invio del modulo.- Tag
<form>— l'elemento contenitore a cui appartengono questi attributi.
L'attributo correlato enctype (impostato sul <form>) controlla come i dati del modulo vengono codificati (ad esempio multipart/form-data per i caricamenti di file), il che è una questione separata dalla codifica dei caratteri descritta da accept-charset. Consulta il capitolo HTML Forms per il quadro completo, incluso enctype.
Cosa fare se si deve davvero supportare un server legacy non-UTF-8?
Poiché i browser ignorano accept-charset, non è possibile forzare una pagina UTF-8 a inviare ISO-8859-1 (o qualsiasi altro charset) semplicemente impostando l'attributo — quella strada è un vicolo cieco. Se si è vincolati a un vecchio backend che comprende soltanto una codifica a byte singolo, la soluzione corretta si trova sul server, non nell'HTML:
- Convertire sul server. Ricevere l'invio in UTF-8 e trascriverlo nella codifica legacy richiesta dall'applicazione (ad esempio con
mb_convert_encodingdi PHP,bytes.decode/encodedi Python, o l'equivalente della propria piattaforma). Questo è l'approccio moderno e consigliato. - Migrare il backend a UTF-8 ovunque sia possibile — elimina definitivamente l'intera categoria di problemi.
Trattare l'invio come UTF-8 sul canale e convertire al confine è affidabile; affidarsi a accept-charset per farlo non lo è.