为非文本媒体类型发送带有 Content-Type 标头的字符集参数是否绝对错误？答案

【问题标题】：Is it categorically wrong to send a charset parameter with a Content-Type header for non-text media types?为非文本媒体类型发送带有 Content-Type 标头的字符集参数是否绝对错误？
【发布时间】：2011-10-18 07:26:39
【问题描述】：

我发现了两个软件之间的一个错误，其中一个是发出标头

Content-Type: application/x-bittorrent; charset=utf-8

另一个处理不正确，但如果删除了 charset 参数，则处理正确。我需要知道要为哪个软件编写补丁！

根据W3C's website：

使用HTTP传输的文本类型的文档，如text/html、text/plain等，可以在HTTP头中发送一个charset参数来指定文档的字符编码。

我认为这意味着非文本类型的文档不应发送此标头。但是，RFC 2068 指出：

“charset”参数与一些媒体类型一起使用来定义数据的字符集（第 3.4 节）

我在规范中找不到向文本以外的媒体类型添加字符集参数不正确的任何地方，所以我的问题是：发出此标头的软件不正确，还是使用它的软件？

【问题讨论】：

我发现第二个软件在消费端“错误地”处理它，所以我倾向于将字符集包含在文本以外的类型中是不正确的。 W3C 语言可能打算这样做，特别是如果您将其视为证明规则的例外情况。不过我不确定。

标签： http http-headers content-type

【解决方案1】：

(1) 如果是 RFC 2616，而不是 2068，则为相关规范。

(2) HTTP 规范是正确的，它取决于媒体类型。例如，您可以为 application/xml 发送一个字符集参数。

(3) 不知道关于 application/x-bittorrent - 它有规范吗？

【讨论】：

糟糕，阅读了错误的规范！不过，他们在这个问题上是一样的。 bittorrent 文件格式确实有一个规范（可能不是官方的），但我想知道任何非文本媒体类型的更一般情况。我认为您的第二点是我正在寻找的答案，但它是在任何可以具有字符集的类型中定义的，还是全部定义？
它取决于媒体类型，例如 RFC 3023 指定 application/xml。

【解决方案2】：

我认为为 text/* 媒体类型以外的任何内容添加字符集参数是不正确的，因为规范只允许为此添加字符集。

【讨论】：

指向一个权威规范，该规范禁止在非文本类型上使用字符集。