在http/1.1中，charset参数是否可以与application/json内容类型一起使用？

Question

例如，它是否是有效的ajax请求：

$.ajax({
    type: "POST",
    url: "SomePage.aspx/GetSomeObjects",
    contentType: "application/json; charset=utf-8",
    ...
});

它有时被用作示例，或者软件可以在没有显式字符集的情况下中断。

rfc 4627 for application/json媒体类型表示不接受第6节中的任何参数：

The MIME media type for JSON text is application/json.

Type name: application

Subtype name: json

Required parameters: n/a

Optional parameters: n/a

可以这样解释，charset不应该与Application/json一起使用。

第3节建议无需指定字符集：

JSON text SHALL be encoded in Unicode.  The default encoding is
UTF-8.

Since the first two characters of a JSON text will always be ASCII
characters [RFC0020], it is possible to determine whether an octet
stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking
at the pattern of nulls in the first four octets.

        00 00 00 xx  UTF-32BE
        00 xx 00 xx  UTF-16BE
        xx 00 00 00  UTF-32LE
        xx 00 xx 00  UTF-16LE
        xx xx xx xx  UTF-8

因为UTF-8,16,32编码可以从内容中感染。为什么说UTF-8是默认的？rfc中没有指定选择其他字符编码的方式，无论如何都可以确定地找到编码。或者还有其他（不是UTF-8,16,32）支持Unicode的字符编码？

一些人认为charset可以用于：

我不同意你的评估，那就是必须放弃。RFC 2046声明“除“文本”子类型之外的其他媒体类型可能选择使用此处定义的字符集参数”，这表明对应用程序类型上字符集参数的存在没有限制。此外，RFC 2045声明“MIME实现必须忽略其名称不可识别的任何参数。”因此，假设它的存在会造成任何伤害是不合理的。

兼容rfc的软件可以生成带有charset参数的内容类型应用程序/json吗？符合rfc的软件应该接受这样的请求吗？

Answer 1

rfc兼容软件是否应接受此类请求？

根据朱利安·雷什克的回答，显然不是。但是，正如您所指出的，如果您想与那些不符合rfc的主机交谈，您可能会在野外遇到它，然后必须处理它。

首先，如果您有代码来处理HTTP框架中基于文本的消息的Accept-Charset和内容类型的charset部分，为什么不把它也用于JSON呢？在编程方面，它更容易（json没有特别的规则），也更通用。

就个人而言，我会说让我们对每一位文本使用Unicode（使用您引用的编码检测）。不幸的是，有些客户端设备，例如日本手机，不处理Unicode，而只处理Shift\u-JIS。否则他们会很高兴成为消费者（和付费客户）。那你打算怎么办？在我的特殊情况下，为了让这些客户机加入，我通过标准HTTP机制配置了字符集。

顺便说一下，HTTP 2.0正在开发中，如果这些人希望创建一个严格遵守的标准，他们将不得不编写验收测试。当然，这也可能意味着如果规则不能偶尔改变，则排除上述遗留客户。

如果除了你没有其他人是顺从的，那么顺从又有什么意义呢？我想知道，即使是Opera是否符合要求，或者，就这一点而言，它实现的所有rfc是否都可以在一开始就得到明确的解释。我不这么认为，尤其是在像HTTP这样的大型应用程序中。

如果这听起来像是对超文本传输协议的抨击，让我这么说吧：超文本传输协议是一个伟大的标准，它的概念不仅彻底改变了互联网。例如，指定资源的方式（无状态）或缓存的方式已经建立了良好的模式，这些模式已经渗透到许多应用程序的实现中。HTTP 2可以从1.1中断的地方开始。让我们只希望SPDY不会1比1被采用。我不想这么说，但在这种情况下，微软的超文本传输协议速度移动性在许多方面比谷歌的PUSHy（而且迄今为止还不稳定）SPDY更有超文本传输协议。

Answer 2

最近的json rfc 7159表示：

注意：没有为此注册定义“字符集”参数
添加一个确实对符合要求的收件人没有影响。

i、 例如，字符集必须被符合要求的收件人忽略。

这与rfc 2045一致：“MIME实现必须忽略其名称不可识别的任何参数。”因为rfc 7159仍然为application/json mime媒体类型指定：“必需参数：n/a；可选参数：n/a”（无参数）。

json文本不再被约束为对象或数组，基于前两个字符计算字符编码的旧的第3节在新的rfc中消失了。允许使用UTF-8、UTF-16或UTF-32，但无法指定编码（无BOM，默认为UTF-8）。

在http/1.1中，charset参数是否可以与application/json内容类型一起使用？

如果使用charset="utf-8"也没有什么坏处-utf-8是json文本的默认编码，但是其他值可能会误导，因为合规的收件人必须忽略该值。它只能中断不正确解析Content-Type标头的客户端，例如，通过将其逐字与“应用程序/json”进行比较，或者尝试使用utf-8编码以外的其他编码来解码json文本的客户端。

符合rfc的软件是否可以使用字符集参数生成内容类型application/json？

否。没有为application/json定义任何参数。

rfc兼容软件是否应接受此类请求？

是的，应该是这样。必须忽略charset的值。

ECMA-404（JSON数据交换格式）根据Unicode代码点定义json文本，即json本身没有指定关于编码细节的行为。

ECMA-262（ECMAScript语言规范）还定义了字符串（Unicode类型）之上的json格式。

Answer 3

Application/json没有定义charset参数，所以包含一个是不正确的。RFC2046所说的是，应用程序类型通常可以有一个字符集参数，如Application/xml。但是JSON没有。