14

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

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

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

application/json 媒体类型的 rfc 4627表示它不接受第 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 的字符编码？

有人认为可以使用字符集：

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

符合 rfc 的软件可以生成带有字符集参数的内容类型 application/json 吗？符合 rfc 的软件应该接受这样的请求吗？

4

3 回答 3

8

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

于 2012-10-27T09:00:22.670 回答
7

最近的json rfc 7159 说：

注意：没有为此注册定义“charset”参数。
添加一个确实对合规收件人没有影响。

即，charset必须被合规的收件人忽略。

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

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

charset 参数可以与 http/1.1 中的 application/json 内容类型一起使用吗？

如果charset="utf-8"使用它没有任何害处——utf-8 是 json 文本的默认编码，但其他值可能会产生误导，因为该值必须被兼容的接收者忽略。它只能破坏不正确解析 Content-Type 标头的客户端，例如，通过逐字将其与“application/json”进行比较，或者尝试使用非 utf-8 编码来解码 json 文本的客户端。

符合 rfc 的软件可以生成带有字符集参数的内容类型 application/json 吗？

不。没有为 application/json 定义参数。

符合 rfc 的软件应该接受这样的请求吗？

是的，它应该。的值charset必须被忽略。

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

ECMA-262（ECMAScript 语言规范）还在 String（Unicode 类型）之上定义了 json 格式。

于 2014-10-05T20:32:43.530 回答
0

符合 rfc 的软件应该接受这样的请求吗？

根据 Julian Reschke 的回答，显然不是。但是，正如您所指出的，如果您想与那些不符合 rfc 的主机交谈，您可能会在野外遇到它，然后必须应对它。

一方面，如果你有代码Accept-Charset可以在你的 HTTP 框架中处理基于文本的消息的内容类型和字符集部分，为什么不把它也用于 JSON 呢？编程方面，它既更容易（对 json 没有特殊规则）也更通用。

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

附带说明一下，HTTP 2.0目前正在制定中，如果这些人希望创建一个严格遵守的标准，他们将不得不编写验收测试。如果规则不能偶尔弯曲，这当然也可能意味着排除上述遗留客户。

如果除了你之外没有其他人，那么顺从又有什么意义呢？我想知道 evenOpera是否兼容，或者，就此而言，它实现的所有 RFC 是否可以一开始就被明确解释。我不这么认为，尤其是在较大的情况下，例如HTTP.

如果这听起来像是对 HTTP 的抨击，让我这样说：HTTP 是一个伟大的标准，它的概念不仅彻底改变了互联网。指定资源的方式（无状态）或完成缓存的方式已经建立了良好的模式，这些模式已经渗透到许多应用程序的实现中。HTTP 2 可以在 1.1 中断的地方继续。让我们只希望SPDY不会被一对一地采用。我不想这么说，但在这种情况下，看起来微软的HTTP Speed+Mobility在很多方面都比谷歌的PUSHy（以及unRESTy）SPDY更多。

于 2012-10-29T00:40:27.273 回答