知识问答

ContentType和MimeType有什么区别

内容 隐藏
问题：ContentType和MimeType有什么区别
回答 0
回答 1
回答 2
回答 3

问题：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种不同的命名？“ Content-Type”只是浏览器请求中使用的名称，而在其外部很少使用吗？

两者之间的主要区别是什么，什么时候可以打电话给对方mimetype而不是content-type？我是卑鄙的语法纳粹吗？

点击查看英文原文

As far as I know, they are absolute equal. However, browsing some django docs, I’ve found this piece of code:

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

which surprise me the two getting along each other. The official docs was able to solve the issue in a pratical manner:

content_type is an alias for mimetype. Historically, this parameter was only called mimetype, but since this is actually the value included in the HTTP Content-Type header, it can also include the character set encoding, which makes it more than just a MIME type specification. If mimetype is specified (not None), that value is used. Otherwise, content_type is used. If neither is given, the DEFAULT_CONTENT_TYPE setting is used.

However, I don’t find it elucidating enough. Why we use 2 different naming for (almost the same) thing? Is “Content-Type” just a name used in browser requests, and with very little use outside it?

What’s the main difference between the each one, and when is right to call something mimetype as opposed to content-type ? Am I being pitty and grammar nazi?

回答 0

为什么我们为（几乎相同的）事物使用2种不同的命名？“ Content-Type”只是浏览器请求中使用的名称，而在其外部很少使用吗？

两者之间的主要区别是什么，何时称呼某种mimetype而不是content-type才是正确的？我是可怜的纳粹语法吗？

原因不仅是向后兼容，而且恐怕通常出色的Django文档对此有些不易理解。MIME（至少值得阅读Wikipedia条目确实很值得）起源于扩展Internet邮件，尤其是SMTP。从那里开始，MIME和受MIME启发的扩展设计已经在许多其他协议（例如此处的HTTP）中找到了应用，当需要在现有协议中传输新型元数据或数据时，它仍在使用。有数十个RFC讨论了用于多种目的的MIME。

具体来说，Content-Type:是几个MIME标头之一。“ Mimetype”确实确实过时了，但是对MIME本身的引用却不是。如果可以的话，将该部分称为后向兼容性。

[BTW，这纯粹是一个术语问题，与语法无关。提出“语法”下的每个用法问题都是我的宠儿。咕rr

点击查看英文原文

Why we use 2 different naming for (almost the same) thing? Is “Content-Type” just a name used in browser requests, and with very little use outside it?

What’s the main difference between the each one, and when is right to call something mimetype as opposed to content-type ? Am i being pitty and grammar nazi?

The reason isn’t only backward compatibility, and I’m afraid the usually excellent Django documentation is a bit hand-wavy about it. MIME (it’s really worth reading at least the Wikipedia entry) has its origin in extending internet mail, and specifically SMTP. From there, the MIME and MIME-inspired extension design has found its way into a lot of other protocols (such as HTTP here), and is still being used when new kinds of metadata or data need to be transmitted in an existing protocol. There are dozens of RFCs that discuss MIME used for a plethora of purposes.

Specifically, Content-Type: is one among several MIME headers. “Mimetype” does indeed sound obsolete, but a reference to MIME itself isn’t. Call that part backward-compatibility, if you will.

[BTW, this is purely a terminology problem which has nothing whatsoever to do with grammar. Filing every usage question under “grammar” is a pet peeve of mine. Grrrr.]

回答 1

我一直将contentType视为mimeType的超集。唯一的区别是可选字符集编码。如果contentType不包含可选字符集编码，则它与mimeType相同。否则，mimeType是字符集编码序列之前的数据。

例如 text/html; charset=UTF-8

text/html是mimeType
;是附加参数指示符
charset=UTF-8是字符集编码参数

例如 application/msword

application/msword是mimeType，
它不能具有字符集编码，因为它描述的格式octet-stream不直接包含字符。

点击查看英文原文

I’ve always viewed contentType to be a superset of mimeType. The only difference being the optional character set encoding. If the contentType does not include an optional character set encoding then it is identical to a mimeType. Otherwise, the mimeType is the data prior to the character set encoding sequence.

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

text/html is the mimeType
; is the additional parameters indicator
charset=UTF-8 is the character set encoding parameter

E.G. application/msword

application/msword is the mimeType
It cannot have a character set encoding as it describes a well formed octet-stream not comprising characters directly.

回答 2

如果您想了解详细信息，请参阅票证3526。

引用：

向HttpResponse构造函数添加了content_type作为mimetype的别名。这是一个稍微准确的名称。基于Simon Willison的补丁。完全向后兼容。

点击查看英文原文

If you want to know the details see ticket 3526.

Quote:

Added content_type as an alias for mimetype to the HttpResponse constructor. It’s a slightly more accurate name. Based on a patch from Simon Willison. Fully backwards compatible.

回答 3

为什么我们为（几乎相同的）事物使用2种不同的命名？

向后兼容性，基于您在文档中的报价。

点击查看英文原文

Why we use 2 different naming for (almost the same) thing?

Backwards compatibility, based on your quote from the documentation.