Quelle est la différence entre ContentType et MimeType ?

Question

Pour autant que je sache, ils sont absolument égaux. Cependant, en parcourant certaines docs de django, j'ai trouvé ce morceau de code :

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

ce qui me surprend que les deux s'entendent bien. La documentation officielle a pu résoudre le problème de manière pratique :

content_type est un alias de mimetype. Historiquement, ce paramètre était seulement appelé mimetype, mais comme il s'agit de la en fait la valeur incluse dans le l'en-tête HTTP Content-Type, elle peut également inclure l'encodage du jeu de caractères, ce qui en fait plus qu'une simple spécification de type MIME ce qui en fait plus qu'une simple spécification de type MIME. Si mimetype est spécifié (pas None), cette valeur est valeur est utilisée. Sinon, c'est content_type qui est utilisé. Si aucun des deux n'est indiqué, le paramètre DEFAULT_CONTENT_TYPE est utilisé.

Cependant, je ne le trouve pas assez explicite. Pourquoi utiliser deux noms différents pour (presque la même) chose ? Est-ce que "Content-Type" est 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 d'entre eux, et quand est-il bon d'appeler quelque chose mimetype à l'opposé de content-type ? Suis-je en train de faire de la pitié et de la grammaire nazie ?

Answer 1

Pourquoi nous utilisons 2 dénominations différentes pour (presque la même) chose ? Est-ce que "Content-Type" est-il simplement un nom utilisé dans les 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 l chacun d'eux, et quand est-il bon d'appeler quelque chose de mimetype par opposition à type de contenu ? Est-ce que je suis pitoyable et grammaire nazie ?

La raison n'est pas seulement la rétrocompatibilité, et j'ai bien peur que la documentation de Django, habituellement excellente, ne soit un peu lourde à ce sujet. MIME (il vaut vraiment la peine de lire au moins l'entrée Wikipedia) trouve son origine dans l'extension du courrier Internet, et plus précisément du SMTP. À partir de là, la conception des extensions MIME et inspirées de MIME a trouvé son chemin dans beaucoup d'autres protocoles (comme HTTP ici), et est toujours utilisée 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 traitent de l'utilisation de MIME pour une multitude d'objectifs.

Plus précisément, Content-Type: est un en-tête MIME parmi d'autres. Le terme "Mimetype" semble en effet obsolète, mais une référence à MIME lui-même ne l'est pas. Appelez cette partie la rétrocompatibilité, si vous voulez.

(BTW, il s'agit d'un problème purement terminologique qui n'a absolument rien à voir avec la grammaire. Classer chaque question d'usage sous la rubrique "grammaire" est une de mes bêtes noires. Grrrr.]

Answer 2

J'ai toujours considéré le contentType comme un sur-ensemble du mimeType. La seule différence étant l'encodage optionnel du jeu de caractères. Si le contentType n'inclut pas un encodage de jeu de caractères optionnel, il est identique à un mimeType. Sinon, le mimeType est la donnée avant la séquence d'encodage du jeu de caractères.

E.G. text/html; charset=UTF-8

text/html est le mimeType
; est l'indicateur des paramètres supplémentaires
charset=UTF-8 est le paramètre d'encodage du jeu de caractères

E.G. application/msword

application/msword est le mimeType
Il ne peut pas avoir d'encodage de jeu de caractères puisqu'il décrit un fichier bien formé. octet-stream ne comprenant pas directement les caractères.

Answer 3

Si vous voulez connaître les détails, voir le billet 3526 .

Citation :

Ajout de content_type comme alias pour mimetype au constructeur HttpResponse au constructeur HttpResponse. C'est un nom un peu plus plus précis. Basé sur un patch de Simon Willison. Entièrement rétrocompatible rétrocompatible.

Answer 4

Pourquoi utilisons-nous deux noms différents pour une chose (presque identique) ?

La rétrocompatibilité, d'après votre citation de la documentation.