charset 参数可以与 http/1.1 中的 application/json 内容类型一起使用吗? [英] Can charset parameter be used with application/json content type in http/1.1?

问题描述

比如是否是有效的ajax请求:

$.ajax({类型:POST"，网址:SomePage.aspx/GetSomeObjects"，内容类型:应用程序/json；字符集=utf-8",...});

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

应用程序/json 媒体类型的 rfc 4627 说它不接受第 6 节中的任何参数:

JSON 文本的 MIME 媒体类型是 application/json.类型名称:应用子类型名称:json所需参数:不适用可选参数:不适用

可以解释为charset不应该与application/json一起使用.

第 3 节建议不需要指定字符集:

JSON 文本应以 Unicode 编码.默认编码是UTF-8.由于 JSON 文本的前两个字符将始终是 ASCII字符 [RFC0020]，可以确定一个八位字节通过查看流是 UTF-8、UTF-16(BE 或 LE)或 UTF-32(BE 或 LE)在前四个八位字节中的空值模式.00 00 00 xx UTF-32BE00 xx 00 xx UTF-16BExx 00 00 00 UTF-32LExx 00 xx 00 UTF-16LExx xx xx xx UTF-8

因为可以从内容中推断出 UTF-8,16,32 编码.为什么说 UTF-8 是默认的?rfc 中没有指定选择其他字符编码的方式，无论如何都可以确定性地找到编码.或者是否有其他(非 UTF-8、16、32)字符编码支持 Unicode?

有些人认为可以使用字符集:

<块引用>

我不同意你的评价，认为它必须被删除.RFC 2046文本"子类型以外的其他媒体类型"可能会选择使用此处定义的字符集参数，"这表明对 charset 参数的存在没有限制应用类型.此外，RFC 2045 声明MIME实现必须忽略其名称没有的任何参数认."所以，假设有任何伤害是不合理的由它的存在来完成.

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

解决方案

最近的json RFC 7159 说:

<块引用>

注意:没有字符集"；参数是为此注册定义的.
添加一个确实对合规的收件人没有影响.

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

它与 rfc 2045 一致:MIME 实现必须忽略其名称无法识别的任何参数." 因为 rfc 7159 仍然指定:必需参数:n/一个;可选参数:对于 application/json mime 媒体类型不适用(无参数).

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 标头的客户端，例如 通过将其与application/json" 或尝试使用 utf-8 以外的其他编码来解码 json 文本的客户端逐字比较.

<块引用>

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

没有.没有为 application/json 定义参数.

<块引用>

符合 rfc 的软件是否应该接受此类请求?

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

---

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

ECMA-262(ECMAScript 语言规范)还在 String(Unicode 类型)之上定义了 json 格式.

For example, is it valid ajax request:

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

It is used as an example sometimes, or software can break without explicit charset.

The rfc 4627 for application/json media type says that it doesn't accept any parameters in section 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

It can be interpreted that charset shouldn't be used with application/json.

And section 3 suggests that it is not necessary to specify charset:

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

because UTF-8,16,32 encodings can be infered from the content. Why does it say that UTF-8 is default? The way to choose other character encoding is not specified in the rfc and the encoding can be found deterministically anyway. Or are there other (not UTF-8,16,32) character encodings that support Unicode?

Some argue that charset can be used:

I disagree with your assessment that it must be dropped. RFC 2046 states that "other media types than subtypes of "text" might choose to employ the charset parameter as defined here," which indicates that there is no restriction on the presence of the charset parameter on application types. Additionally, RFC 2045 states that "MIME implementations must ignore any parameters whose names they do not recognize." So, it is not reasonable to assume that there is any harm being done by its presence.

May rfc-compliant software generate content type application/json with a charset parameter? Should rfc-compliant software accept such requests?

解决方案

The recent json rfc 7159 says:

Note: No "charset" parameter is defined for this registration.
Adding one really has no effect on compliant recipients.

i.e., charset must be ignored by compliant recipients.

It is consistent with rfc 2045: "MIME implementations must ignore any parameters whose names they do not recognize." because rfc 7159 still specifies: "Required parameters: n/a; Optional parameters: n/a" for application/json mime media type (no parameters).

The json text is no longer constrained to be an object or an array and the old section 3 that computes the character encoding based on the first two characters is gone in the new rfc. UTF-8, UTF-16, or UTF-32 are allowed but there is no way to specify the encoding (no BOM, UTF-8 is the default).

Can charset parameter be used with application/json content type in http/1.1?

There is no harm if charset="utf-8" is used -- utf-8 is the default encoding for json text but other values might be misleading because the value must be ignored by compliant recipients. It can only break clients that parse Content-Type header incorrectly e.g., by comparing it verbatim with "application/json" or clients that attempt to use some other than utf-8 encoding to decode the json text.

May rfc-compliant software generate content type application/json with a charset parameter?

no. No parameters are defined for application/json.

Should rfc-compliant software accept such requests?

yes, it should. The value of charset must be ignored.

---

ECMA-404 (The JSON Data Interchange Format) defines json text in terms of Unicode code points i.e., json itself specifies no behavior regarding encoding details.

ECMA-262 (ECMAScript Language Specification) also defines the json format on top of String (Unicode type).

这篇关于charset 参数可以与 http/1.1 中的 application/json 内容类型一起使用吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！