Was ist der Unterschied zwischen ContentType und MimeType?

Soweit ich weiß, sind sie absolut gleich. Beim Durchsuchen einiger Django-Dokumente habe ich jedoch diesen Code gefunden:

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

was mich überrascht, dass die beiden miteinander auskommen. Die offiziellen Dokumente konnten das Problem auf praktische Weise lösen:

content_type ist ein Alias ​​für mimetype. In der Vergangenheit wurde dieser Parameter nur als Mimetyp bezeichnet. Da dies jedoch der Wert ist, der im HTTP-Inhaltstyp-Header enthalten ist, kann er auch die Zeichensatzcodierung enthalten, wodurch er mehr als nur eine MIME-Typspezifikation ist. Wenn ein Mimetyp angegeben ist (nicht Keine), wird dieser Wert verwendet. Andernfalls wird content_type verwendet. Wenn beides nicht angegeben ist, wird die Einstellung DEFAULT_CONTENT_TYPE verwendet.

Ich finde es jedoch nicht aufschlussreich genug. Warum verwenden wir 2 verschiedene Namen für (fast das gleiche) Ding? Ist "Content-Type" nur ein Name, der in Browser-Anfragen verwendet wird und außerhalb davon nur sehr wenig verwendet wird?

Was ist der Hauptunterschied zwischen den einzelnen und wann ist es richtig, etwas zu nennen, mimetypeim Gegensatz zu content-type? Bin ich schade und Grammatik-Nazi?

Warum verwenden wir 2 verschiedene Namen für (fast das gleiche) Ding? Ist "Content-Type" nur ein Name, der in Browser-Anfragen verwendet wird und außerhalb davon nur sehr wenig verwendet wird?

Was ist der Hauptunterschied zwischen den einzelnen und wann ist es richtig, einen Mimetyp im Gegensatz zum Inhaltstyp zu nennen? Bin ich schade und Grammatik-Nazi?

Der Grund ist nicht nur die Abwärtskompatibilität, und ich befürchte, dass die normalerweise ausgezeichnete Django-Dokumentation etwas handgewellt ist. MIME (es lohnt sich wirklich, zumindest den Wikipedia-Eintrag zu lesen) hat seinen Ursprung in der Erweiterung der Internet-Mail und insbesondere von SMTP. Von dort aus hat das von MIME und MIME inspirierte Erweiterungsdesign Eingang in viele andere Protokolle gefunden (z. B. HTTP hier) und wird immer noch verwendet, wenn neue Arten von Metadaten oder Daten in einem vorhandenen Protokoll übertragen werden müssen. Es gibt Dutzende von RFCs, die sich mit MIME befassen, das für eine Vielzahl von Zwecken verwendet wird.

Insbesondere Content-Type:ist einer von mehreren MIME-Headern. "Mimetype" klingt zwar veraltet, ein Verweis auf MIME selbst jedoch nicht. Nennen Sie diesen Teil Abwärtskompatibilität, wenn Sie so wollen.

[Übrigens, dies ist ein reines Terminologieproblem, das überhaupt nichts mit Grammatik zu tun hat. Das Einreichen jeder Verwendungsfrage unter "Grammatik" ist ein Liebling von mir. Grrrr.]

Ich habe contentType immer als eine Obermenge von mimeType angesehen. Der einzige Unterschied besteht in der optionalen Zeichensatzcodierung. Wenn der contentType keine optionale Zeichensatzcodierung enthält, ist er mit einem mimeType identisch. Andernfalls sind die mimeType die Daten vor der Zeichensatz-Codierungssequenz.

Z.B text/html; charset=UTF-8

text/htmlist der mimeType
;ist der zusätzliche Parameter Indikator
charset=UTF-8ist der Zeichensatz-Codierungsparameter

Z.B application/msword

application/mswordist der mimeType
Es kann keine Zeichensatzcodierung geben, da es eine wohlgeformte Form beschreibt, die octet-streamkeine direkten Zeichen enthält.

Wenn Sie die Details wissen möchten, siehe Ticket 3526 .

Zitat:

Content_type als Alias ​​für den Mimetyp zum HttpResponse-Konstruktor hinzugefügt. Es ist ein etwas genauerer Name. Basierend auf einem Patch von Simon Willison. Vollständig abwärtskompatibel.

Warum verwenden wir 2 verschiedene Namen für (fast das gleiche) Ding?

Abwärtskompatibilität, basierend auf Ihrem Zitat aus der Dokumentation.