tutorial libro example descargar curso completo books book python django content-type mime-types

python - libro - ¿Cuál es la diferencia entre ContentType y MimeType?



python web pdf (4)

Hasta donde yo sé, son absolutamente iguales. Sin embargo, al navegar por algunos documentos de django, encontré este fragmento de código:

HttpResponse.__init__(content='''', mimetype=None, status=200, content_type=''text/html'')

que me sorprende a los dos llevarse bien el uno al otro. Los documentos oficiales pudieron resolver el problema de manera práctica:

content_type es un alias para mimetype. Históricamente, este parámetro solo se llamaba mimetype, pero dado que este es realmente el valor incluido en el encabezado HTTP Content-Type, también puede incluir la codificación del conjunto de caracteres, lo que lo convierte en algo más que una especificación de tipo MIME. Si se especifica mimetype (no None), se usa ese valor. De lo contrario, se usa content_type. Si no se proporciona ninguno, se usa la configuración DEFAULT_CONTENT_TYPE.

Sin embargo, no lo veo aclarar lo suficiente. ¿Por qué usamos 2 nombres diferentes para (casi lo mismo) cosa? ¿Es "Content-Type" solo un nombre utilizado en las solicitudes del navegador y con muy poco uso fuera de él?

¿Cuál es la diferencia principal entre cada uno, y cuándo es correcto llamar algo tipo mimetype en lugar content-type ? ¿Estoy siendo ruin y gracioso nazi?


¿Por qué usamos 2 nombres diferentes para (casi lo mismo) cosa? ¿Es "Content-Type" solo un nombre utilizado en las solicitudes del navegador y con muy poco uso fuera de él?

¿Cuál es la diferencia principal entre cada uno, y cuándo es correcto llamar algo tipo MIME en lugar de tipo de contenido? ¿Estoy siendo ruin y gracioso nazi?

La razón no es solo la compatibilidad con versiones anteriores, y me temo que la documentación generalmente excelente de Django es un poco ondulada. MIME (realmente vale la pena leer al menos la entrada de Wikipedia) tiene su origen en la extensión de correo de Internet, y específicamente SMTP. A partir de ahí, el diseño de extensión inspirado en MIME y MIME ha encontrado su camino en muchos otros protocolos (como HTTP aquí) y todavía se usa cuando se deben transmitir nuevos tipos de metadatos o datos en un protocolo existente. Hay docenas de RFC que discuten MIME utilizado para una plétora de propósitos.

Específicamente, Content-Type: es uno entre varios encabezados MIME. "Mimetype" realmente suena obsoleto, pero una referencia a MIME no lo es. Llame a esa parte de compatibilidad hacia atrás, si lo desea.

[Por cierto, este es un problema puramente terminológico que no tiene nada que ver con la gramática. Presentar todas las preguntas de uso bajo "gramática" es una de mis preocupaciones. Grrrr.]


¿Por qué usamos 2 nombres diferentes para (casi lo mismo) cosa?

Compatibilidad con versiones anteriores, según su cita de la documentación.


Si desea conocer los detalles, vea el ticket 3526 .

Citar:

Se agregó content_type como alias para mimetype al constructor HttpResponse. Es un nombre un poco más preciso. Basado en un parche de Simon Willison. Completamente compatible con versiones anteriores.


Siempre he visto contentType como un superconjunto de mimeType. La única diferencia es la codificación del juego de caracteres opcional. Si contentType no incluye una codificación de juego de caracteres opcional, entonces es idéntico a un mimeType. De lo contrario, mimeType es la información anterior a la secuencia de codificación del juego de caracteres.

EG text/html; charset=UTF-8 text/html; charset=UTF-8

text/html es el mimeType
; es el indicador de parámetros adicionales
charset=UTF-8 es el parámetro de codificación de conjunto de caracteres

application/msword EG application/msword

application/msword es el mimeType
No puede tener una codificación de conjunto de caracteres, ya que describe una octet-stream bien formada que no comprende caracteres directamente.