2012-03-05 10 views
5

Estoy exportando datos a través de archivos. El resultado es datos codificados en base64.¿Es utf-8 adecuado para texto/tipo MIME simple?

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

lo que resulta en algo como:

bGFzcyI6MTp7czo1OiJzZXR1cCI7YTo3Mzp7czoyNToicGFnZXNfY29udGFjdF91c19oZWFkbGlu 

Así que me pregunto qué juego de caracteres es más adecuado para estos datos (texto sin formato). us-ascii parece suficiente, pero utf-8 siempre parece un defecto a prueba de errores.

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

No debe haber comillas alrededor de las partes text/plain o utf8 de eso. – Quentin

+0

@quentin Gracias. Realmente no lo sabía ... –

+0

Todavía siento que la respuesta aceptada es incorrecta (a pesar de que la mía votó negativamente). Aclaré mi respuesta un poco, ¿me importa reconsiderar? – Evert

Respuesta

7

Realmente no importa; su contenido es válido US-ASCII, válido UTF-8, válido ISO-8859-1 (o, creo, cualquieraISO-8859-x), válido Windows-1252, y así sucesivamente. Simplemente no ponga UTF-16 o EBCDIC o algo así.

(Por si sirve de algo, me gustaría ir con US-ASCII, porque es totalmente compatible con incluso ordenadores pre-Unicode sin ser tan explícitamente un pre-Unicode del juego de caracteres como ISO-8859-1 o lo que sea, pero eso es realmente una preferencia subjetiva.)

+0

En algún lugar hay una especificación que dice que debe indicar el juego de caracteres como el más pequeño que lo describe correctamente. Por lo tanto, si es estrictamente ASCII, debe llamarse que en lugar de ISO-8859-1 o UTF-8, o si es el subconjunto ISO-8859-1 de Windows-1252, debe decir eso también. Creo que esto es por correo electrónico, sin embargo, puede que no se aplique en este caso. – tchrist

+1

@tchrist: Estás 90% correcto. Las RFC actualmente relevantes (2046 y 2616) sí hacen esa recomendación, pero usan "debería" en lugar de "debe", lo que en las RFC es una distinción significativa. Además, curiosamente, RFC 2616 dice que "no se prefiere etiquetar a la entidad antes que etiquetar a la entidad con las etiquetas US-ASCII o ISO-8859-1", pero en mi humilde opinión es obsoleta cuando se trata de ISO-8859-1, ya que muchos usuarios los agentes ahora suponen, desafiando al estándar, un juego de caracteres predeterminado de UTF-8. (Y me doy cuenta de que el IETF sirve algunas páginas con 'charset = ISO-8859-1'.) Pero aún puede aplicarse a US-ASCII. – ruakh

+0

Pero a pesar de que es compatible con US-ASCII, eso no lo convierte en US-ASCII :) Aclaré mi propia respuesta, ¿todavía está en desacuerdo? – Evert

19

Ni siquiera necesitará un juego de caracteres. 'text/plain' puede ser incorrecto, porque tampoco es realmente texto.

Aunque es compatible con ascii, utf-8, latin1 (como se menciona en ruakh), simplemente debe tratarlo como un archivo binario.

actualización

quería aclarar esto un poco (después de todas las downvotes, chicos comunes Dame una oportunidad!)

@ dan04: UTF-8 es texto, no he dicho no fue Base64 no lo es, base64 también es una codificación, pero puede codificar cualquier secuencia binaria. Base64 está codificado de tal manera que es posible envolverlo en US-ASCII (y por lo tanto también UTF-8 y latin1/ISO-8859).

Base64 sigue siendo una secuencia binaria, y no por texto de definición. El hecho de que el mismo rango de valores de octetos se utilice como US-ASCII (e "imprimible" por cualquier cosa que lea US-ASCII) no lo convierte en texto.

Esta es también la razón por la cual Base64 no tiene su propio tipo mimetype. Se considera una codificación de transferencia de contenido. (¡Búscalo!)

Así que la forma correcta de servir Base64 es con el tipo mimet de lo que contiene la cadena, junto con un encabezado Content-Transfer-Encoding. Por ejemplo, si está codificando un jpeg, este es el formato correcto.

Content-Type: image/jpeg 
Content-Transfer-Encoding: base64 

Ésta es la razón por la que siento que si no quiero decir nada sobre el contenido de la cadena (o no tiene esta información), lo mejor es tratarlo como 'binario genérico', por ejemplo:

Content-Type: application/octet-stream 
Content-Transfer-Encoding: base64 
+0

¿Cómo es el texto UTF-8 no texto? – dan04

+1

@ dan04: actualicé mi respuesta. Espero que esto tenga más sentido – Evert

+2

+1 Lo que mencionas es realmente interesante. Lo tendré en cuenta en el futuro. En mi caso, utilicé 'US-ASCII' porque de hecho es un objeto serializado var. Gracias por tu contribución. –

Cuestiones relacionadas