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

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

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

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

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

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

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

84
content-type django mime-types python

4 ответов

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

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

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

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

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

44

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

Г. Е. text/html; charset=UTF-8

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

Г. Е. application/msword

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

36

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

цитата:

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

4

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

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

0