В чем разница между 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
? Я что, жалкий нацист?
4 ответов
почему мы используем 2 разных имен (почти то же самое)? Есть "Content-Type" - только имя, используемое в запросы браузера, и с очень небольшим использования вне его?
в чем основная разница между каждый из них, и когда правильно позвонить что-то типа в отличие от контент-тип ? Я Питти и грамматика нацистская?
причина не только в обратной совместимости, и я боюсь, что обычно отличная документация Django немного волнистая рука об этом. МИМ (это действительно стоит прочитать, по крайней мере, запись Википедии) имеет свое происхождение в расширении интернет-почты, и в частности SMTP. Оттуда дизайн расширения MIME и MIME-inspired нашел свой путь во многие другие протоколы (например, HTTP здесь) и по-прежнему используется, когда новые виды метаданных или данных должны быть переданы в существующем протоколе. Есть десятки RFCs, которые обсуждают MIME, используемый для множества цели.
в частности, Content-Type:
является одним из нескольких заголовков MIME. "Mimetype" действительно звучит устаревшим, но ссылка на MIME сама по себе не является. Назовите эту часть обратной совместимостью, если хотите.
[кстати, это чисто терминологическая проблема, которая не имеет ничего общего с грамматикой. Подача каждого вопроса об использовании в разделе "грамматика" - это мой питомец. Гррр.]
Я всегда рассматривал contentType как надмножество mimeType. Единственным отличием является необязательная кодировка набора символов. Если contentType не включает необязательную кодировку набора символов, то он идентичен типу mimeType. В противном случае mimeType-это данные, предшествующие последовательности кодирования набора символов.
Г. Е. text/html; charset=UTF-8
text/html
является mimeType;
индикатор дополнительных параметровcharset=UTF-8
- это набор символов параметр кодирования
Г. Е. application/msword
application/msword
является mimeType
Он не может иметь кодировку набора символов, поскольку он описывает хорошо сформированный octet-stream
не содержит символов напрямую.
Если вы хотите узнать подробности, см. ticket 3526.
цитата:
добавил content_type в качестве псевдонима для тип mimetype для HttpResponse конструктор. Это немного больше точное название. На основе патча от Саймон Уиллисон. Полностью назад совместимый.
почему мы используем 2 разных имени для (почти одного и того же)?
обратная совместимость, на основе вашей цитаты из документации.