Какая разница в 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? Я являюсь питти и грамматикой нацистов?
Ответы
Ответ 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 разных наименования для (почти такой же) вещи?
Обратная совместимость, основанная на вашей цитате из документации.
