У чому різниця ContentType і MimeType

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

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

що мене здивувало, як двоє вживаються один з одним. Офіційні документи змогли вирішити проблему в докладному порядку:

content_type - псевдонім для mimetype. Історично цей параметр називався лише mimetype, але оскільки це фактично значення, включене в заголовок HTTP Content-Type, він також може включати кодування набору символів, що робить його більш ніж просто специфікацією типу MIME. Якщо вказано mimetype (немає None), використовується це значення. В іншому випадку використовується content_type. Якщо не вказано жодне, використовується налаштування DEFAULT_CONTENT_TYPE.

Однак я не вважаю це достатньо з'ясованим. Чому ми використовуємо 2 різні імена для (майже однакової) речі? Чи "Тип вмісту" - це лише ім'я, яке використовується в запитах браузера, і поза ним дуже мало?

У чому головна відмінність кожного з них, і коли правильно називати щось mimetypeна противагу content-type? Чи я буду питком і граматикою нацистами?

Чому ми використовуємо 2 різні імена для (майже однакової) речі? Чи "Тип вмісту" - це лише ім'я, яке використовується в запитах браузера, і поза ним дуже мало?

У чому головна відмінність кожного з них, і коли правильно називати щось міметиком на відміну від контент-типу? Чи я буду питком і граматикою нацистами?

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

Зокрема, Content-Type:це один із декількох заголовків MIME. "Mimetype" справді звучить застарілим, але посилання на сам MIME не є. Назвіть цю частину зворотною сумісністю, якщо хочете.

[BTW, це суто термінологічна проблема, яка не має нічого спільного з граматикою. Подача кожного запитання щодо використання під "граматику" - це моє домашнє тварина. Grrrr.]

Я завжди вважав, що contentType є сукупністю mimeType. Єдина відмінність - необов'язкове кодування набору символів. Якщо contentType не включає необов'язкове кодування набору символів, то він ідентичний mimeType. В іншому випадку mimeType - це дані до послідовності кодування набору символів.

EG text/html; charset=UTF-8

text/htmlє mimeType
;- додатковий параметр, індикатор
charset=UTF-8- це параметр кодування набору символів

EG application/msword

application/mswordце mimeType У
ньому не може бути кодування набору символів, оскільки він описує добре сформовану форму, що octet-streamне містить символів безпосередньо.

Якщо ви хочете дізнатися деталі, дивіться квиток 3526 .

Цитата:

Доданий content_type як псевдонім для mimetype конструктору HttpResponse. Це трохи точніша назва. На основі латки від Саймона Віллісона. Повністю назад сумісні.

Чому ми використовуємо 2 різні імена для (майже однакової) речі?

Зворотна сумісність, виходячи з вашої цитати з документації.