In realtà non è nemmeno necessario un set di caratteri. 'text/plain' può essere sbagliato, perché non è proprio testo.
Anche se è compatibile con ascii, utf-8, latin1 (come menzionato da ruakh), dovresti trattarlo come un file binario.
Aggiornamento
ho voluto chiarire questo un po '(dopo tutti i downvotes, ragazzi comuni dammi una possibilità!)
@ dan04: UTF-8 è un testo, non ho detto non lo era. Base64 non lo è, base64 è anche una codifica, ma può codificare qualsiasi sequenza binaria. Base64 è codificato in modo tale da poterlo avvolgere in US-ASCII (e quindi anche UTF-8 e latin1/ISO-8859).
Base64 è ancora solo una sequenza binaria e non per testo di definizione. Il fatto che lo stesso intervallo di valori di ottetto sia usato come US-ASCII (e 'stampabile' da qualsiasi cosa che legga US-ASCII) non lo rende testo.
Questo è anche il motivo per cui Base64 non ha il proprio mimetype. È considerato una codifica per il trasferimento dei contenuti. (cercalo!)
Quindi il modo corretto di servire Base64 con il tipo MIME di ciò che contiene la stringa, insieme a un'intestazione Content-Transfer-Encoding. Ad esempio, se stai codificando un file jpeg, questo è il formato corretto.
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
Questo è anche il motivo per cui ritengo che se non voglio dire nulla circa il contenuto della stringa (o non hanno queste informazioni), è meglio trattarlo come 'binaria generica', es .:
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
Non si dovrebbe avere virgolette intorno al testo/plain o utf8 parti di quello. – Quentin
@quentin Grazie. Non lo sapevo davvero ... –
Continuo a ritenere che la risposta accettata sia sbagliata (anche se la mia è stata downvoted). Ho chiarito abbastanza bene la mia risposta, mi interessa riconsiderare? – Evert