Codifica trasferimento contenuto 7 bit o 8 bit

Question

Durante l'invio di contenuto di posta elettronica, è necessario impostare l'intestazione "Content Transfer Encoding". Ho osservato molti messaggi di posta elettronica che ho ricevuto. Alcune e-mail che usano "7bit" e altre usano "8bit".

Qual è la differenza tra questi due? Quale è raccomandato? C'è qualche codifica speciale richiesta per il corpo dell'email per impostare queste intestazioni?

Answer 1

può essere un po 'denso di 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 un pò di male in peggio. Ecco la mia sintesi:

Sfondo

SMTP, per definizione (RFC 821), limita mail a righe di 1000 caratteri di 7 bit ciascuno. Ciò significa che nessuno dei byte che invii lungo la pipe può avere il bit più significativo ("più alto") impostato su "1".

Il contenuto che si desidera inviare spesso non rispetta questa restrizione intrinsecamente. Pensa a un file immagine o a un file di testo che contiene caratteri Unicode: i byte di questi file avranno spesso il loro ottavo bit impostato su "1". SMTP non consente questo, quindi è necessario utilizzare "trasferimento codifica" per descrivere come hai lavorato intorno alla mancata corrispondenza.

I valori per l'intestazione Content-Transfer-Encoding descrivono la regola che si è scelto di risolvere questo problema.

7bit codifica

7bit significa semplicemente "miei dati consiste solo di caratteri US-ASCII, che utilizzano solo 7 bit inferiori per ciascun carattere." In pratica stai garantendo che tutti i byte dei tuoi contenuti rispettano già le restrizioni di SMTP e quindi non ha bisogno di cure particolari. Puoi solo leggerlo così com'è.

Si noti che quando si seleziona 7bit, si accetta che tutte le linee del contenuto siano lunghe meno di 1000 caratteri.

Fintanto che il contenuto è conforme a queste regole, 7bit è la migliore codifica di trasferimento, poiché non è necessario alcun lavoro aggiuntivo; basta leggere/scrivere i byte mentre escono dalla pipa. È anche facile da eyeballare il contenuto 7bit e dargli un senso. L'idea è che se stai scrivendo semplicemente "testo inglese" starai bene. Ma quello wasn't true in 2005 e non è vero oggi.

8Bit codifica

8bit significa "I miei dati possono includere caratteri ASCII estesi e possono usare l'8 ° (più alto) bit per indicare i caratteri speciali al di fuori degli US-ASCII caratteri standard a 7 bit." Come con 7bit, c'è ancora un limite di 1000 caratteri.

8bit, proprio come 7bit, in realtà non esegue alcuna trasformazione dei byte mentre vengono scritti o letti dal filo. Significa solo che non stai garantendo che nessuno dei byte abbia il bit più alto impostato su "1".

Questo sembra un passaggio da 7bit, poiché ti dà più libertà nei tuoi contenuti.Tuttavia, RFC 1341 contiene questo bocconcino:

A partire dalla pubblicazione di questo documento, non ci sono Internet standardizzati trasporti per cui è legittimo includere non codificata a 8-bit o dati binari nei corpi di posta. Quindi non ci sono circostanze in cui la codifica del trasferimento dei contenuti "8bit" o "binario" sia effettivamente legale su Internet.

RFC 1341 è uscito più di 20 anni fa. Da allora abbiamo ottenuto in RFC 6152. Ma anche in questo caso, i limiti di riga possono ancora essere applicati:

Si noti che questa estensione NON elimina la possibilità di un server SMTP che limita la lunghezza della linea; i server sono liberi di implementare questa estensione, ma stabiliscono un limite di lunghezza della linea non inferiore a 1000 ottetti.

codifica binaria

binary è lo stesso di 8bit, tranne che non c'è alcuna restrizione lunghezza della linea. Puoi comunque includere qualsiasi carattere che desideri e non c'è alcuna codifica aggiuntiva. Analogamente a 8bit, RFC 1341 afferma che non si tratta di una codifica di trasferimento di codifica legittima. RFC 3030 esteso con BINARYMIME.

Citato stampabile

prima dell'estensione 8BITMIME, ci doveva essere un modo per inviare contenuti che non poteva essere 7bit tramite SMTP. File HTML (che potrebbero avere più di 1000 caratteri) e file con caratteri internazionali sono buoni esempi di questo. La codifica quoted-printable (definita nella Sezione 5.1 di RFC 1341) è progettata per gestire questo problema. Fa due cose:

• Definisce come eseguire il escape dei caratteri non US-ASCII in modo che possano essere rappresentati solo con caratteri a 7 bit. (Versione breve: vengono visualizzati come segno di uguale più due caratteri a 7 bit.)
• Definisce che le linee non superino i 76 caratteri e che le interruzioni di riga vengano rappresentate utilizzando caratteri speciali (che vengono quindi sfuggiti).

Quoted Printable, a causa delle linee di fuga e brevi, è molto più difficile da leggere da un essere umano che 7bit o 8bit, ma supporta una gamma molto più ampia di possibili contenuti.

Base64 Encoding

Se i dati sono in gran parte non di testo (es: un file di immagine), non si hanno molte opzioni. 7bit è fuori dal tavolo. 8bit e binary non sono stati supportati prima delle RFC di estensione MIME. quoted-printable funzionerebbe, 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, che è relativamente efficiente. La RFC 1341 limita ulteriormente la lunghezza della linea di dati codificati base64 a 76 caratteri per adattarsi a un messaggio SMTP, ma è relativamente facile da gestire quando si suddividono o concatenano caratteri arbitrari a lunghezze fisse.

Il grande lato negativo è che i dati codificati base64 sono quasi completamente illeggibili dagli esseri umani, anche se si tratta semplicemente di testo "semplice" sotto.