Подтвердить что ты не робот

Какая разница в ContentType и MimeType

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

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

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

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

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

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

4b9b3361

Ответ 1

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

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

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

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

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

Ответ 2

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

например. text/html; charset=UTF-8

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

например. application/msword

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

Ответ 3

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

Цитата:

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

Ответ 4

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

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