Jaka jest różnica między ContentType i MimeType

O ile wiem, są absolutnie równi. Jednak przeglądając niektóre dokumenty django, znalazłem ten fragment kodu:

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

co mnie zaskakuje, kiedy się dogadują Oficjalna dokumentacja była w stanie rozwiązać problem w praktyczny sposób:

content_type to alias dla typu MIME. W przeszłości ten parametr był nazywany tylko typem MIME, ale ponieważ w rzeczywistości jest to wartość zawarta w nagłówku HTTP Content-Type, może również zawierać kodowanie zestawu znaków, co czyni go czymś więcej niż tylko specyfikacją typu MIME. Jeśli określono typ MIME (a nie Brak), używana jest ta wartość. W przeciwnym razie używany jest content_type. Jeśli nie podano żadnego, używane jest ustawienie DEFAULT_CONTENT_TYPE.

Jednak nie wydaje mi się to wystarczająco wyjaśniające. Dlaczego używamy dwóch różnych nazw (prawie tego samego)? Czy „Content-Type” to tylko nazwa używana w żądaniach przeglądarki, która jest bardzo rzadko używana poza nią?

Jaka jest główna różnica między każdym z nich i kiedy należy nazywać coś mimetypeprzeciwnego content-type? Czy jestem nazistą żałosnym i gramatycznym?

Dlaczego używamy dwóch różnych nazw (prawie tego samego)? Czy „Content-Type” to tylko nazwa używana w żądaniach przeglądarki, która jest bardzo rzadko używana poza nią?

Jaka jest główna różnica między każdym z nich i kiedy można nazywać coś typu MIME, a kiedy typu zawartości? Czy jestem nazistą żałosnym i gramatycznym?

Powodem jest nie tylko kompatybilność wsteczna i obawiam się, że zazwyczaj doskonała dokumentacja Django jest nieco zawrotna. MIME (naprawdę warto przeczytać chociażby wpis w Wikipedii) ma swój początek w rozszerzaniu poczty internetowej, a konkretnie SMTP. Stamtąd projekt rozszerzenia inspirowany MIME i MIME trafił do wielu innych protokołów (takich jak HTTP tutaj) i jest nadal używany, gdy nowe rodzaje metadanych lub danych muszą być przesyłane w istniejącym protokole. Istnieją dziesiątki dokumentów RFC, które omawiają MIME używane do wielu celów.

W szczególności Content-Type:jest jednym z kilku nagłówków MIME. „Typ MIME” rzeczywiście brzmi przestarzale, ale samo odniesienie do MIME takie nie jest. Nazwij tę część kompatybilnością wsteczną, jeśli chcesz.

[Przy okazji, jest to problem czysto terminologiczny, który nie ma nic wspólnego z gramatyką. Umieszczanie każdego pytania w rubryce „gramatyka” jest moim ulubionym drażnieniem. Grrrr.]

Zawsze uważałem, że contentType jest nadzbiorem mimeType. Jedyną różnicą jest opcjonalne kodowanie zestawu znaków. Jeśli contentType nie zawiera opcjonalnego kodowania zestawu znaków, jest identyczny z mimeType. W przeciwnym razie mimeType to dane poprzedzające sekwencję kodowania zestawu znaków.

NA PRZYKŁAD text/html; charset=UTF-8

text/htmlto mimeType
;to dodatkowe parametry, wskaźnik
charset=UTF-8to parametr kodowania zestawu znaków

NA PRZYKŁAD application/msword

application/mswordjest typem mimeType
Nie może mieć kodowania zestawu znaków, ponieważ opisuje dobrze sformułowany, octet-streamnie zawierający bezpośrednio znaków.

Jeśli chcesz poznać szczegóły, zobacz bilet 3526 .

Zacytować:

Dodano content_type jako alias dla typu MIME do konstruktora HttpResponse. To nieco dokładniejsza nazwa. Na podstawie poprawki Simona Willisona. W pełni kompatybilny wstecz.

Dlaczego używamy dwóch różnych nazw (prawie tego samego)?

Zgodność wsteczna, na podstawie Twojej oferty z dokumentacji.