MIME type

Un MIME type (Multipurpose Internet Mail Extensions, ora formalmente solo «media type» per RFC 6838) è un identificatore in due parti nel formato tipo/sottotipo che dice a un client che tipo di dati sta guardando.

Esempi comuni:

• text/html — documento HTML
• application/json — dati JSON
• image/png, image/jpeg, image/webp — formati immagine
• application/pdf — documento PDF
• multipart/form-data — payload di caricamento file
• application/octet-stream — binario opaco; il fallback «solo byte, scopri tu cos’è»

Le risposte HTTP portano i MIME type nell’intestazione Content-Type. I Data URI (usati dal nostro strumento immagine-in-Base64) incorporano il MIME type direttamente: data:image/png;base64,iVBOR.... I browser usano il MIME type dichiarato per decidere come renderizzare o scaricare una risorsa.

Nota storica: il MIME è stato originariamente definito per gli allegati email. Lo stesso registro ora definisce i tipi di media per il web, l’IM, RSS e la maggior parte dei protocolli moderni.

Il Registro dei Media Type IANA: ogni MIME type legittimo è registrato presso la Internet Assigned Numbers Authority. I tipi di primo livello sono fissi (text, image, audio, video, application, multipart, message, model, font, example, più il prefisso legacy X-). I sottotipi vengono aggiunti attraverso un processo di registrazione IETF o vendor-tree; application/vnd.openxmlformats-officedocument.wordprocessingml.document (il MIME type formale per .docx) è un esempio del vendor-tree. I sottotipi sconosciuti tornano a application/octet-stream, che di solito attiva un prompt di download del browser piuttosto che il rendering inline.

MIME sniffing — il problema di sicurezza: se un server restituisce il Content-Type sbagliato, i browser storicamente cercavano di indovinare dai primi byte della risposta. Questo «content sniffing» permetteva attacchi cross-site in cui un’immagine caricata dall’utente poteva essere reinterpretata come HTML o JavaScript. La soluzione è X-Content-Type-Options: nosniff, che forza il browser a rispettare il tipo dichiarato e a rifiutarsi di eseguire contenuto non corrispondente. I moderni framework web spediscono questa intestazione per impostazione predefinita. Riferimento: RFC 6838 — Media Type Specifications and Registration Procedures.

Parametri: charset, boundary, profile

Un MIME type può portare parametri dopo un punto e virgola. Il più comune è charset: Content-Type: text/html; charset=utf-8 dice al browser che la risposta è HTML codificata come UTF-8. Senza di esso, i browser tornano alle codifiche legacy (Windows-1252 in molti casi) che storpiano il testo non-ASCII. Per i caricamenti multipart/form-data, il parametro boundary specifica il delimitatore tra le parti: multipart/form-data; boundary=---WebKitFormBoundary7MA4YWxkTrZu0gW. JSON-LD usa un parametro profile: application/ld+json; profile="https://www.w3.org/ns/activitystreams". I parametri non fanno distinzione tra maiuscole e minuscole per i nomi; i valori non fanno distinzione per la maggior parte dei parametri noti ma fanno distinzione per il boundary multipart.

La convenzione del suffisso +

RFC 6839 ha aggiunto una convenzione di suffisso a sintassi strutturata che consente ai nuovi media type di dichiarare quale formato generico analizzano: application/atom+xml, application/vnd.api+json, image/svg+xml. Il suffisso dice a un parser generico (una libreria XML o JSON) come leggere i byte anche se non riconosce il tipo specifico del vendor. Gli standard web moderni si basano molto su questo — ogni media type API basato su JSON termina in +json; ogni media type basato su XML termina in +xml. Al 2026 il registro IANA elenca più di 2.300 media type registrati in tutte le categorie di primo livello, con l’albero application/ (oltre 1.800 voci) di gran lunga il più grande. Riferimento: IANA Media Types Registry.