ContentType和MimeType有什麼區別

據我所知，它們是絕對平等的。然而，瀏覽一些Django文檔，我發現這段代碼：ContentType和MimeType有什麼區別

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

這讓我感到吃驚兩人相處對方得到。官方文檔能夠以實際的方式解決問題：

content_type是mimetype的別名。歷史上，這參數僅爲稱爲MIME類型，但由於這是實際包含在 HTTP Content-Type頭的值，它也可以包括的字符集編碼，這使得它不僅僅是一個MIME 類型規範。如果mimetype是（不是None），則使用該值。否則，使用content_type。如果沒有給出，則使用 DEFAULT_CONTENT_TYPE設置。

但是，我沒有發現它足夠闡明。爲什麼我們使用2個不同的命名（幾乎相同）？「Content-Type」僅僅是瀏覽器請求中使用的名稱，並且在其外部使用很少？

每一個之間的主要區別是什麼，什麼時候是正確調用mimetype而不是content-type？我是懦弱還是語法納粹？

來源

2010-08-10 Frangossauro

爲什麼我們使用2個不同的命名爲（幾乎相同）？是「Content-Type」只是一個名字，用在瀏覽器的請求中，並且很少用在外面使用它？

什麼是每一個之間的主要區別，而當有權要求 MIME類型的東西，而不是內容類型？我是不是很可疑，語法納粹？

原因不僅僅是向後兼容性，恐怕通常優秀的Django文檔對它有點手卷。 MIME（至少閱讀維基百科的條目確實值得）擴展Internet郵件，特別是SMTP。從那裏開始，MIME和MIME風格的擴展設計已經進入許多其他協議（例如HTTP），並且在現有協議中需要傳輸新類型的元數據或數據時仍在使用。有幾十個RFC討論用於過多目的的MIME。

具體而言，Content-Type:是幾個MIME頭文件之一。「Mimetype」的確聽起來已經過時了，但是對MIME本身的引用並非如此。如果您願意的話，請將該部分稱爲向後兼容性。

[順便說一下，這純粹是一個術語問題，與語法毫無關係。歸檔「語法」下的每個使用問題都是我的寵兒。 Grrrr。]

來源

2010-08-10 19:50:08 chryss

爲什麼我們使用2個不同的命名（幾乎相同）？

向後兼容性，基於您在文檔中的引用。

來源

2010-08-10 18:59:52

那好吧，我明白django上添加的實際原因。然而，問題的核心是爲什麼每個人都使用這兩個詞如此混雜，如果真的存在差異。 – Frangossauro 2010-08-10 19:06:30

如果您想知道詳情，請參閱票3526。

報價：

新增CONTENT_TYPE作爲 MIME類型到的HttpResponse 構造一個別名。這是一個更準確的名字。基於來自 Simon Willison的補丁。完全倒退兼容。

來源

2010-08-10 21:41:18

我一直將contentType看作是mimeType的超集。唯一的區別是可選的字符集編碼。如果contentType不包含可選的字符集編碼，則它與mimeType相同。否則，mimeType是字符集編碼序列之前的數據。

E.G. text/html; charset=UTF-8

text/html是將mimeType
;是附加參數指示器
charset=UTF-8被字符集編碼參數

E.G. application/msword

application/msword是將mimeType
它不能具有字符集編碼，因爲它直接描述了一種良好地形成octet-stream不包含的字符。

來源

2013-07-30 14:06:21

這是正確的答案。設置響應mime_type（不是content_type）不會覆蓋charset，它保持爲UTF-8。 – 2014-02-06 14:30:39

有時候簡單地稱爲「媒體類型」，MIME類型就像你說的媒體類型一樣。在某些規範中，我們將看到術語「可分析的MIME類型」，其中包括使用「Content-Type」頭中的屬性。 'Content-Type'的語法可以在這裏找到：https：//tools.ietf.org/html/rfc2045#section-5.1 – 2017-05-13 06:55:57

ContentType和MimeType有什麼區別

回答

相關問題