Quelle est la différence entre le type de contenu et le type MIME
Pour autant que je sache, ils sont absolument égaux. Cependant, en parcourant certains Django documents, j'ai trouvé ce morceau de code:
HttpResponse.__init__(content='', mimetype=None, status=200, content_type='text/html')
ce qui m'étonne que les deux s'entendent. Les documents officiels ont pu résoudre le problème de manière pratique:
content_type est un alias pour mimetype. Historiquement, ce paramètre était uniquement appelé mimetype, mais comme il s'agit en fait de la valeur incluse dans l'en-tête HTTP Content-Type, il peut également inclure le codage du jeu de caractères, ce qui en fait plus qu'une simple spécification de type MIME. Si mimetype est spécifié (pas None), cette valeur est utilisée. Sinon, content_type est utilisé. Si aucun n'est donné, le paramètre DEFAULT_CONTENT_TYPE est utilisé.
Cependant, je ne le trouve pas suffisamment élucidant. Pourquoi utilisons-nous 2 noms différents pour (presque la même) chose? "Content-Type" est-il juste un nom utilisé dans les requêtes du navigateur, et avec très peu d'utilisation en dehors de celui-ci?
Quelle est la principale différence entre chacun et quand est-il juste d'appeler quelque chose mimetype par opposition à content-type? Suis-je pitoyable et grammaire nazie?
Pourquoi utilisons-nous 2 noms différents pour (presque la même) chose? "Content-Type" est-il juste un nom utilisé dans les requêtes du navigateur, et avec très peu d'utilisation en dehors de celui-ci?
Quelle est la principale différence entre chacun et quand est-il juste d'appeler quelque chose de type MIME par opposition à type de contenu? Suis-je pitoyable et grammaire nazie?
La raison n'est pas seulement la compatibilité descendante, et je crains que la documentation généralement excellente Django soit un peu vague à ce sujet. MIME (ça vaut vraiment la peine de lire au moins l'entrée Wikipedia) a son origine dans l'extension de la messagerie Internet, et en particulier SMTP. comme HTTP ici), et est toujours utilisé lorsque de nouveaux types de métadonnées ou de données doivent être transmis dans un protocole existant. Il existe des dizaines de RFC qui discutent du MIME utilisé à une multitude de fins.
Plus précisément, Content-Type: est l'un des en-têtes MIME. "Mimetype" semble en effet obsolète, mais une référence à MIME lui-même ne l'est pas. Appelez cette partie rétrocompatibilité, si vous voulez.
[BTW, c'est purement un problème de terminologie qui n'a rien à voir avec la grammaire. Déposer chaque question d'utilisation sous "grammaire" est une bête noire. Grrrr.]
J'ai toujours considéré contentType comme un surensemble de mimeType. La seule différence étant l'encodage optionnel du jeu de caractères. Si le contentType n'inclut pas de codage de jeu de caractères facultatif, il est identique à un mimeType. Sinon, le mimeType correspond aux données antérieures à la séquence de codage du jeu de caractères.
PAR EXEMPLE. text/html; charset=UTF-8
text/html est le mimeType; est l'indicateur de paramètres supplémentairescharset=UTF-8 est le paramètre de codage du jeu de caractères
PAR EXEMPLE. application/msword
application/msword est le mimeType
Il ne peut pas avoir de codage de jeu de caractères car il décrit un _ bien formé octet-stream ne comprenant pas directement les caractères.
Si vous voulez connaître les détails, voir ticket 526 .
Citation:
Content_type ajouté en tant qu'alias pour mimetype au constructeur HttpResponse. C'est un nom un peu plus précis. Basé sur un patch de Simon Willison. Entièrement rétrocompatible.
Pourquoi utilisons-nous 2 noms différents pour (presque la même) chose?
Compatibilité descendante, basée sur votre devis de la documentation.