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

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

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

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

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

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

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

4 84
python django-models content-type mime-types

4 ответа:

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

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

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

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

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

44

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

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

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

Например application/msword

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

36

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

цитата:

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

4

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

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

0