Durante l'invio di contenuti e-mail, è necessario impostare l'intestazione "Content Transfer Encoding". Ho osservato molte intestazioni di messaggi di posta elettronica che ho ricevuto. Alcuni messaggi di posta elettronica utilizzano "7 bit" e alcuni utilizzano "8 bit".
Qual è la differenza tra questi due? Quale è consigliato? È richiesta una codifica speciale per il corpo dell'email per impostare queste intestazioni?
Risposte:
Può essere un po 'denso da leggere, ma la sezione "Content-Transfer-Encoding" di RFC 1341 ha tutti i dettagli:
http://www.w3.org/Protocols/rfc1341/5_Content-Transfer-Encoding.html
La situazione va di male in peggio. Ecco il mio riassunto:
SMTP, per definizione (RFC 821), limita la posta a righe di 1000 caratteri di 7 bit ciascuna. Ciò significa che nessuno dei byte inviati nella pipe può avere il bit più significativo ("ordine più elevato") impostato su "1".
Il contenuto che vogliamo inviare spesso non obbedirà intrinsecamente a questa restrizione. Pensa a un file immagine, o un file di testo che contiene caratteri Unicode: i byte di questi file avranno spesso il loro 8 ° bit impostato su "1". SMTP non lo consente, quindi è necessario utilizzare la "codifica di trasferimento" per descrivere come hai risolto la mancata corrispondenza.
I valori per l' Content-Transfer-Encodingintestazione descrivono la regola che hai scelto per risolvere questo problema.
7bitsignifica semplicemente "I miei dati sono costituiti solo da caratteri US-ASCII, che utilizzano solo i 7 bit inferiori per ogni carattere". In pratica stai garantendo che tutti i byte nel tuo contenuto aderiscano già alle restrizioni dell'SMTP, quindi non necessita di alcun trattamento speciale. Puoi semplicemente leggerlo così com'è.
Tieni presente che quando scegli 7bit, accetti che tutte le righe del tuo contenuto siano lunghe meno di 1000 caratteri.
Finché il tuo contenuto aderisce a queste regole, 7bitè la migliore codifica di trasferimento, poiché non è necessario alcun lavoro aggiuntivo; devi solo leggere / scrivere i byte non appena escono dal pipe. È anche facile osservare i 7bitcontenuti e dargli un senso. L'idea qui è che se stai scrivendo solo in "testo inglese normale" starai bene. Ma non era vero nel 2005 e non è vero oggi.
8bitsignifica "I miei dati possono includere caratteri ASCII estesi; possono utilizzare l'ottavo bit (il più alto) per indicare caratteri speciali al di fuori dei caratteri US-ASCII a 7 bit standard." Come con 7bit, c'è ancora un limite di righe di 1000 caratteri.
8bit, proprio come 7bit, in realtà non esegue alcuna trasformazione dei byte mentre vengono scritti o letti dal cavo. Significa solo che non stai garantendo che nessuno dei byte avrà il bit più alto impostato su "1".
Questo sembra un passo avanti 7bit, poiché ti dà più libertà nei tuoi contenuti. Tuttavia, RFC 1341 contiene questo bocconcino:
Al momento della pubblicazione di questo documento, non esistono trasporti Internet standardizzati per i quali è legittimo includere dati binari o a 8 bit non codificati nel corpo della posta. Quindi non ci sono circostanze in cui la codifica di trasferimento dei contenuti "a 8 bit" o "binaria" sia effettivamente legale su Internet.
RFC 1341 è uscito più di 20 anni fa. Da allora abbiamo ottenuto estensioni MIME a 8 bit in RFC 6152 . Ma anche in questo caso, i limiti di linea possono ancora essere applicati:
Notare che questa estensione NON elimina la possibilità che un server SMTP limiti la lunghezza della linea; i server sono liberi di implementare questa estensione, ma tuttavia impostano un limite di lunghezza della linea non inferiore a 1000 ottetti.
binaryè uguale a 8bit, tranne per il fatto che non ci sono restrizioni sulla lunghezza delle righe. Puoi comunque includere tutti i caratteri che desideri e non ci sono codifiche extra. Simile a 8bit, RFC 1341 afferma che non è realmente una codifica di trasferimento di codifica legittima. RFC 3030 lo ha esteso con BINARYMIME.
Prima 8BITMIMEdell'estensione, doveva esserci un modo per inviare contenuto che non poteva essere 7bittramite SMTP. I file HTML (che potrebbero contenere più di 1000 righe di caratteri) e i file con caratteri internazionali ne sono un buon esempio. La quoted-printablecodifica (definita nella sezione 5.1 della RFC 1341) è progettata per gestire questo problema. Fa due cose:
Quoted Printable, a causa dell'escape e delle linee brevi, è molto più difficile da leggere da un umano rispetto a 7bito 8bit, ma supporta una gamma molto più ampia di possibili contenuti.
Se i tuoi dati sono in gran parte non di testo (es: un file immagine), non hai molte opzioni. 7bitè fuori dal tavolo. 8bite binarynon erano supportati prima dell'estensione MIME RFC. quoted-printablefunzionerebbe, ma è davvero inefficiente (ogni byte sarà rappresentato da 3 caratteri).
base64è una buona soluzione per questo tipo di dati. Codifica 3 byte grezzi come 4 caratteri US-ASCII, il che è relativamente efficiente. RFC 1341 limita ulteriormente la lunghezza della base64riga dei dati codificati a 76 caratteri per adattarsi a un messaggio SMTP, ma è relativamente facile da gestire quando si suddividono o concatenano solo caratteri arbitrari a lunghezze fisse.
Il grande svantaggio è che i base64dati codificati sono praticamente del tutto illeggibili dagli esseri umani, anche se sotto è solo testo "normale".