例如，它是否是有效的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中未指定选择其他字符编码的方式，无论如何都可以确定地找到该编码。还是存在其他支持Unicode的字符编码（非UTF-8、16、32）？
有人认为可以使用字符集：
我不同意您的评估，认为 必须 将其删除。RFC 2046指出“除“文本”子类型以外的其他媒体类型可能选择采用此处定义的charset参数”，这表明在应用程序类型上对charset参数的存在没有限制。此外，RFC 2045指出“ MIME实现必须忽略其名称无法识别的任何参数”。因此，假设它的存在会造成任何伤害是不合理的。
兼容RFC的软件是否可以使用charset参数生成内容类型application / json？兼容RFC的软件是否应接受此类请求？
最近的json rfc 7159说：
注意：没有为该注册定义“字符集”参数。 确实添加一个对符合条件的收件人没有任何影响。
即，charset必须由符合条件的收件人忽略。
charset
它与rfc 2045一致： “ MIME实现必须忽略其无法识别其名称的任何参数。” 因为rfc 7159仍然为application / jsonmime媒体类型（无参数）指定： “必需参数：n / a；可选参数：n / a” 。
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文本的客户端。
charset="utf-8"
兼容RFC的软件是否可以使用charset参数生成内容类型application / json？
没有。没有为application / json定义任何参数。
兼容RFC的软件是否应接受此类请求？
是的，应该。的值charset必须忽略。
ECMA-404（JSON数据交换格式）以Unicode代码点的形式定义json文本，即json本身未指定有关编码详细信息的行为。
ECMA-262（ECMAScript语言规范）还在String（Unicode类型）的顶部定义了json格式。
