Questa sezione costituisce un riepilogo delle intestazioni MIME comuni ed è utile come guida di riferimento rapida. Non si tratta di una specifica definitiva di MIME. In alcuni casi, nel programma di analisi MIME è possibile utilizzare documenti non del tutto conformi agli standard. Ad esempio, non insiste sulla presenza di un'intestazione MIME-Version. Tutti i campi di intestazione MIME standard vengono scritti nell'albero logico con la stessa modalità con cui vengono visualizzati nel documento MIME. Il programma di analisi MIME annota solo il campo dell'intestazione Content-Type.
E' possibile che in tutte le intestazioni MIME siano inclusi commenti tra parentesi come visualizzato nell'esempio per l'intestazione MIME-Version.
Esempio:
MIME-Version: 1.0 (generated by my-application 1.2)
Perché un documento MIME sia conforme allo standard RFC 2045, è necessario immettere in tale campo nell'intestazione principale un valore di 1.0. Non è necessario specificare MIME-Version nelle singole parti.
Il campo Content-Type non è richiesto perché un documento sia conforme allo standard RFC 2045, ma è necessario un Content-Type principale nel programma di analisi MIME. Il valore predefinito di Content-Type è text/plains. Content-Type definisce il tipo di dati in ogni parte come tipo o tipo secondario. Il programma di analisi MIME accetta la maggior parte dei valori nel campo Content-Type e li memorizza nell'albero logico. Di seguito vengono riportate le sole eccezioni.
Sintassi:
Content-Type: type/subtype;parameter
Dove il tipo e il tipo secondario definiscono Content-Type e qualsiasi parametro facoltativo è delimitato da punti e virgola.
Esempio 1:
Content-Type: multipart/related;type=text/xml
Nell'esempio 1 Content-Type è definito come Multipart/related e dispone inoltre di una definizione del parametro facoltativa (type=text/xml). Anche se corretto dal punto di vista sintattico, poiché non è presente alcun parametro di limite valido, il messaggio verrà rifiutato.
Esempio 2:
Content-Type: multipart/related;boundary=Boundary;type=text/xml
Nell'esempio 2 è visualizzata una definizione Content-Type valida in termini di sintassi e di semantica. E' possibile che il valore di limite sia racchiuso tra parentesi. Quando viene visualizzato nel contenuto MIME, il valore viene preceduto dalla sequenza '--' ed è necessario accertarsi che il valore risultante (nell'esempio, --Boundary) non venga visualizzato nel contenuto del messaggio. Se i dati del messaggio sono codificati come tra virgolette o stampabili, è necessario disporre di un limite che includa una sequenza come "=_", impossibile da visualizzare in un contenuto tra virgolette o stampabile.
Di seguito sono riportati alcuni valori Content-Type comuni. Qualsiasi altro valore è consentito e viene memorizzato nell'albero logico.
Content-Type | Descrizione |
---|---|
text/plain | Di solito viene utilizzato per un messaggio di news o di posta elettronica classico. E' comune inoltre il valore text/richtext. |
text/xml | Di solito viene utilizzato con SwA (SOAP with Attachments). |
application/octet-stream | Viene utilizzato quando il messaggio è di tipo sconosciuto e contiene qualsiasi tipo di dati, ad esempio byte. |
application/xml | Viene utilizzato per dati xml specifici dell'applicazione. |
x-type | Viene utilizzato per tipo di contenuto non standard. E' necessario che inizi con x-. |
image/jpeg | Viene utilizzato per le immagini. I formati comuni utilizzati per le immagini sono image/jpeg e image/gif. |
Multipart/related | Viene utilizzato per più parti correlate in un messaggio. In modo specifico, viene utilizzato con SwA (SOAP with Attachments). |
Multipart/signed | Viene utilizzato per più parti correlate in un messaggio, inclusa la firma. In modo specifico, viene utilizzato con S/MIME. |
Multipart/mixed | Viene utilizzato per più parti indipendenti in un messaggio. |
Facoltativo. Numerosi Content-Type sono rappresentati come dati binari o a caratteri a 8 bit. E' possibile che sia incluso il formato XML, che di solito utilizza la codifica UTF-8 o UTF-16. Non è possibile trasmettere tale tipo di dati su alcuni protocolli di trasporto ed è possibile che siano codificati a 7 bit.
Il campo di intestazione Contenuto-Trasferimento-Codifica è utilizzato per indicare il tipo di trasformazione utilizzato per la codifica di questo tipo di dati in un formato a 7 bit.
Di seguito sono riportati gli unici valori consentiti da WS-I Basic Profile.
I valori 7bit, 8bit e binary indicano in realtà che non si verifica alcuna codifica. E' possibile che un gateway di posta conforme MIME utilizzi tale valore per controllare la modalità di gestione del messaggio. Ad esempio, è possibile che si verifichi la codifica a 7 bit prima del trasferimento mediante l'instradamento su SMTP.
I valori base64 e quoted-printable indicano che il contenuto è codificato. Il valore quoted-printable indica che sono codificati solo i caratteri diversi dai caratteri a 7 bit nell'originale e viene utilizzato per verificare che un documento sia leggibile. Tale impostazione viene utilizzata di solito insieme a un Content-Type con valore text/plain.
Facoltativo. Abilita le parti da etichettare e alle quali fare riferimento da altre parti del messaggio. A tali parti si fa riferimento di solito dalla parte 0 (la prima) del messaggio.
Facoltativo. Abilita le parti da descrivere.
La sezione seguente costituisce una guida di base per le codifiche base64 e quoted-printable. Fare riferimento a RFC 1521 per una specifica più completa delle codifiche MIME.
I dati originali sono suddivisi in gruppi di 3 ottetti. Ciascun gruppo è considerato come un insieme di quattro gruppi a 6 bit concatenati, ognuno dei quali viene convertito in una cifra singola nell'alfabeto base64. I caratteri dell'alfabeto base64 comprendono le lettere tra A e Z, a e z, 0 e 9 e il simbolo "/" (con A=0 e /=63).
Se alla fine dei dati sono disponibili meno di 24 bit, i dati codificati sono riempiti mediante il carattere "=". La lunghezza massima della riga nei dati codificati è di 76 caratteri e le interruzioni di riga (e altri caratteri non compresi nell'alfabeto indicato sopra) sono ignorate in fase di decodifica.
Esempi:
Input | Output |
---|---|
Some data encoded in base64. | U29tZSBkYXRhIGVuY29kZWQgaW4gYmFzZTY0Lg== |
life of brian | bGlmZSBvZiBicmlhbg==\012 |
what | d2hhdA== |
Tale tipo di codifica è appropriato solo se la maggior parte dei dati è composta da caratteri stampabili. In modo specifico, i caratteri compresi tra 33 e 60 e 62 e 126 sono rappresentati di solito dai caratteri ASCII corrispondenti. E' necessario rappresentare i caratteri di controllo e i dati a 8 bit con la sequenza = seguita da una coppia di cifre esadecimali.
Lo spazio ASCII standard <SP> e il carattere di tabulazione orizzontale <HT> rappresentano i caratteri stessi, a meno che non siano visualizzati alla fine di una riga codificata (senza un'interruzione di riga); in tal caso, è necessario utilizzare il formato esadecimale equivalente (rispettivamente =09 e =20).
Le interruzioni di riga nei dati sono rappresentate dalla sequenza di interruzione di riga RFC 822 <CR><LF> ed è necessario codificare tali interruzioni come "=0D=0A" se i dati binari sono codificati.
Come per la codifica base64, la lunghezza massima di una riga nei dati codificati è di 76 caratteri. Un simbolo "=" alla fine della riga codificata (un'interruzione di riga) viene utilizzato per comunicare al programma di decodificazione che la riga continua.