什么"内容类型:application/json; charset = utf-8"真的意味着什么？

Question

什么"内容类型:application/json; charset = utf-8"真的意味着什么？

Den*_*ail 262 character-encoding mime-types

当我使用JSON主体向我的REST服务发出POST请求时,我将其包含Content-type: application/json; charset=utf-8在邮件头中.没有这个标题,我从服务中得到一个错误.我也可以成功使用Content-type: application/json没有;charset=utf-8部分.

到底是charset=utf-8做什么的？我知道它指定了字符编码,但没有它,服务工作正常.此编码是否限制可以在邮件正文中的字符？

Answer 1

dec*_*eze 263

标题只表示内容的编码内容.不一定可以从内容本身推断内容的类型,即您不一定只看内容并知道如何处理它.这就是HTTP标头的用途,它们告诉收件人他们(应该)正在处理什么样的内容.

Content-type: application/json; charset=utf-8将内容指定为JSON格式,以UTF-8字符编码进行编码.对于JSON来说,指定编码有点多余,因为JSON的默认(仅？)编码是UTF-8.因此,在这种情况下,接收服务器显然很高兴知道它正在处理JSON并且假设默认情况下编码是UTF-8,这就是它使用或不使用标头的原因.

此编码是否限制可以在邮件正文中的字符？

不可以.你可以在标题和正文中发送任何你想要的东西.但是,如果两者不匹配,您可能会得到错误的结果.如果您在标头中指定内容是UTF-8编码但实际上您正在发送Latin1编码内容,则接收方可能会生成垃圾数据,尝试将Latin1编码数据解释为UTF-8.当然,如果您指定发送Latin1编码数据并且实际上是在执行此操作,那么是的,您可以限制为可以在Latin1中编码的256个字符.

根据json的标准,实际上不允许使用latin1来编写内容.JSON内容必须编码为unicode,无论是UTF-8,UTF-16还是UTF-32(大端或小端). (29认同)
application/json上没有charset参数. (19认同)
@DanielLuna是对的,`application/json`必须采用其中一种ucs转换格式.此外,由于JSON的前四个字节是有限的,您可以随时判断它是8,16还是32*和*它的字节序. (7认同)
当然,在JSON中,您仍然可以使用诸如`\ u20AC`之类的转义序列来表示非Latin1字符. (4认同)
如果它是多余的事件你可能想要包含``charset = utf-8``出于安全原因:https://github.com/shieldfy/API-Security-Checklist/issues/25 (4认同)

Answer 2

Dre*_*kes 139

为了证实@deceze声称默认的JSON编码是UTF-8 ...

来自IETF RFC4627:

JSON文本应以Unicode编码.默认编码为UTF-8.

由于JSON文本的前两个字符将始终为ASCII字符[RFC0020],因此可以确定八位字节流是UTF-8,UTF-16(BE或LE)还是UTF-32(BE或LE)通过查看前四个八位字节中的空值模式.
      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
Run Code Online (Sandbox Code Playgroud)

将JSON视为二进制格式而不是文本格式总是有帮助的. (11认同)
@FabioBeltramini上面应该仍然存在,因为JSON中的字符串不包含任何文字空字符(JSON中的空值需要用数字转义序列编码,即`"\ u0000"`). (4认同)
实际上，在这种情况下，UTF-16xx中的第二个字符可能没有NULL，但是仍然可以从其他字节确定编码：`xx 00 00 00`仍然是UTF-32LE，`xx 00 xx xx是仍为UTF-16LE，“ 00 xx xx xx”仍为UTF-16BE。 (3认同)
现在RFC7159已被RFC4627淘汰，该RFC 7159指出根值可能是字符串（与以前的规范形成鲜明对比），现在如何实现呢？规范在这方面含糊不清，只是说允许使用三种编码，但不允许使用哪种编码来区分它们。 (2认同)

Answer 3

小智 19

请注意,IETF RFC4627已被IETF RFC7158取代.在[8.1]节中,它撤回了@Drew引用的文字:

Implementations MUST NOT add a byte order mark to the beginning of a JSON text.
Run Code Online (Sandbox Code Playgroud)

一个字符，因为单个数字是有效的 JSON 文件 (2认同)

Answer 4

sta*_*iet 13

JSON必须使用UTF-8编码，并且没有“ charset”参数。

RFC 8259：

IANA 考虑因素

JSON 文本的媒体类型是 application/json。
...
注意： 没有为此注册定义“charset”参数。 添加一项实际上对合规收件人没有任何影响。

还，

8.1. 字符编码

不属于封闭
生态系统的系统之间交换的 JSON 文本必须使用 UTF-8 [RFC3629] 进行编码。

以前的 JSON 规范并未要求在传输 JSON 文本时使用 UTF-8。然而，绝大多数
基于 JSON 的软件实现都选择使用 UTF-8 编码，在某种程度上它是实现
互操作性的唯一编码。

实现不得将字节顺序标记 (U+FEFF) 添加到
网络传输的 JSON 文本的开头。为了互
操作性，解析 JSON 文本的实现可以忽略
字节顺序标记的存在，而不是将其视为错误
。

（强调我的）

归档时间：	14 年，4 月前
查看次数：	428104 次
最近记录：	6 年，11 月前