2012-03-05 10 views
5

Sto esportando i dati attraverso i file. L'output è dati codificati in base64.E 'utf-8 adatto per testo/plain mime type?

$data = base64_encode(serialize($data)); 

che si traduce in qualcosa di simile a:

bGFzcyI6MTp7czo1OiJzZXR1cCI7YTo3Mzp7czoyNToicGFnZXNfY29udGFjdF91c19oZWFkbGlu 

Quindi mi chiedo che cosa charset è più adatto a questi dati (solo testo). us-ascii sembra abbastanza ma utf-8 sembra sempre un default a prova di errore.

header('content-type: text/plain; charset=utf-8'); 
+3

Non si dovrebbe avere virgolette intorno al testo/plain o utf8 parti di quello. – Quentin

+0

@quentin Grazie. Non lo sapevo davvero ... –

+0

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

risposta

7

Non importa; il tuo contenuto è valido US-ASCII, valido UTF-8, valido ISO-8859-1 (o, credo, qualsiasiISO-8859-x), valido Windows-1252 e così via. Basta non mettere UTF-16 o EBCDIC o qualcosa del genere.

(per quello che vale, mi piacerebbe andare con US-ASCII, perché è pienamente supportato da anche i computer pre-Unicode, senza essere esplicitamente un pre-Unicode character-set come ISO-8859-1 o roba del genere, ma questo è davvero una preferenza soggettiva.)

+0

Da qualche parte c'è una specifica che dice che devi specificare il set di caratteri come il più piccolo che lo descrive correttamente. Quindi se è rigorosamente ASCII, deve essere chiamato che invece di ISO-8859-1 o UTF-8, o se è il sottoinsieme ISO-8859-1 di Windows-1252, devi dirlo anche tu. Penso che questo sia per la posta elettronica, quindi potrebbe non essere applicabile in questo caso, comunque. – tchrist

+1

@tchrist: sei corretto al 90%. Le RFC attualmente rilevanti (2046 e 2616) fanno questa raccomandazione, ma usano "dovrebbe" piuttosto che "devono", che in RFC è una distinzione significativa. Inoltre, interessante, RFC 2616 dice che "non etichettare l'entità è preferibile rispetto all'etichettatura con le etichette US-ASCII o ISO-8859-1", ma IMHO è obsoleto quando si tratta di ISO-8859-1, poiché molti utenti gli agenti ora assumono, a dispetto dello standard, un set di caratteri predefinito di UTF-8. (E noto che IETF stesso serve alcune pagine con 'charset = ISO-8859-1'.) Ma può ancora essere applicato a US-ASCII. – ruakh

+0

Ma anche se è compatibile con US-ASCII, questo non lo rende US-ASCII :) Ho chiarito la mia risposta, non sei ancora d'accordo? – Evert

19

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 
+0

In che modo il testo UTF-8 non è testo? – dan04

+1

@ dan04: ho aggiornato la mia risposta. Spero che questo abbia più senso – Evert

+2

+1 Quello che citi è davvero interessante. Lo terrò conto in futuro. Nel mio caso ho usato 'US-ASCII' perché in effetti è un oggetto serializzato var. Grazie per il tuo contributo. –