В чем разница между ContentType и MimeType

Question

Насколько я знаю, они абсолютно равны. Тем не менее, просматривая некоторые документы Django, я нашел этот кусок кода:

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

, что удивляет меня, когда они ладят друг с другом. Официальные документы смогли решить проблему практически:

content_type - это псевдоним для mimetype. Исторически этот параметр был только называется mimetype, но так как это на самом деле значение, включенное в Заголовок HTTP Content-Type, он также может включить кодировку набора символов, что делает его больше, чем просто MIME спецификация типа. Если mimetype это указано (не None), это значение используемый. В противном случае используется content_type. Если ни то, ни другое не дано, Используется настройка DEFAULT_CONTENT_TYPE.

Однако я не нахожу это достаточно выясняющим. Почему мы используем 2 разных наименования для (почти одинаковых) вещей? Является ли «Content-Type» просто именем, используемым в запросах браузера, и мало используемым за его пределами?

В чем основное различие между каждым и когда правильно называть что-то mimetype, а не content-type? Я жалкий и нацистский по грамматике?

Answer 1

Почему мы используем 2 разных наименования для (почти то же самое) вещь? Является «Content-Type» просто имя, используемое в запросы браузера, и очень мало использовать вне его?

В чем главное отличие каждый, и когда это правильно позвонить что-то подражание в отличие от Тип содержимого ? Я жалкий и грамматика нацистов?

Причина не только в обратной совместимости, и я боюсь, что обычно превосходная документация по Django немного волнистая. MIME (действительно стоит прочитать хотя бы статью в Википедии) берет свое начало в расширении интернет-почты и, в частности, SMTP. С этого момента дизайн расширений, основанный на MIME и MIME, вошел во многие другие протоколы (например, HTTP здесь) и все еще используется, когда новые виды метаданных или данных необходимо передавать в существующем протоколе. Существуют десятки RFC, в которых обсуждается MIME, используемый для множества целей.

В частности, Content-Type: является одним из нескольких заголовков MIME. «Mimetype» действительно кажется устаревшим, но ссылка на сам MIME - нет. Если хотите, назовите эту часть обратной совместимостью.

[Кстати, это чисто терминологическая проблема, которая не имеет никакого отношения к грамматике. Заполнение каждого вопроса об использовании под "грамматикой" - моя любимая мозоль. Grrrr.]

Answer 2

Я всегда рассматривал contentType как расширенный набор mimeType.Единственная разница заключается в дополнительной кодировке набора символов.Если contentType не включает необязательную кодировку набора символов, тогда он идентичен mimeType.В противном случае mimeType - это данные, предшествующие последовательности кодирования набора символов.

EG text/html; charset=UTF-8

text/html - это mimeType
; - индикатор дополнительных параметров
charset=UTF-8 - это параметр кодировки набора символов

EG application/msword

application/msword - это mimeType
Он не может иметь кодировку набора символов, поскольку он описывает правильно сформированный octet-stream не содержит символы напрямую.

Answer 3

Если вы хотите узнать подробности см. Билет 3526 .

Цитата:

Добавлен content_type в качестве псевдонима для подражать HttpResponse конструктор. Это немного больше точное имя. На основе патча от Саймон Уиллисон. Полностью назад совместимый.

Answer 4

Почему мы используем 2 разных наименования для (почти одинаковых) вещей?

Обратная совместимость, основанная на вашей цитате из документации.