JSON规范和BOM/charset编码的使用

Question

我一直在阅读RFC-4627规范,我来解释一下:

将有效负载通告为application/jsonmime-type时,

1. 有必须是没有BOM在正确编码JSON流(基于部分"3.编码")的开始s和
2. 没有媒体参数也被支持,从而一个的mime类型报头application/json; charset=utf-8并不符合RFC-4627(基于部分"6. IANA考虑").

这些是正确的扣除吗？在实施遵循这种解释的Web服务或Web客户端时,我会遇到问题吗？我是否应该针对违反上述两个属性的Web浏览器提交错误？

Answer 1

你是对的

1. BOM字符在JSON中是非法的(并且不需要)
2. MIME字符集在JSON中是非法的(并且也不需要)

RFC 7159,第8.1节:

实现绝不能在JSON文本的开头添加字节顺序标记.

尽可能清楚地说明这一点.这是整个RFC中唯一的"绝不".

RFC 7159,第11节:

JSON文本的MIME媒体类型是application/json.
类型名称:application
子类型名称:json
必需参数:n/a
可选参数:n/a
[...]
注意: 没有为此注册定义"charset"参数.

JSON编码

JSON唯一有效的编码是UTF-8,UTF-16或UTF-32,因为第一个字符(如果有多个字符,前两个字符)将始终具有低于128的Unicode值(没有有效的JSON)可以包含前两个字符的较高值的文本)通过查看字节流,始终可以知道使用了哪些有效编码和哪个字节序.

RFC推荐

JSON RFC说前两个字符总是低于128,你应该检查前4个字节.

我会换一种说法:因为字符串"1"也是有效的JSON,所以不能保证你有两个字符 - 更不用说4个字节了.

我的推荐

我对确定JSON编码的建议会略有不同:

快速方法:

1. 如果你有1个字节并且它不是NUL - 它是UTF-8
   (实际上这里唯一有效的字符是ASCII数字)
2. 如果你有2个字节而且它们都不是NUL - 它是UTF-8
   (那些必须是ASCII数字,没有前导'0' {},[]或者"")
3. 如果你有2个字节,只有第一个是NUL - 它是UTF-16BE
   (它必须是编码为UTF-16,大端的ASCII数字)
4. 如果你有2个字节,只有第二个是NUL - 它是UTF-16LE
   (它必须是编码为UTF-16的ASCII数字,小端)
5. 如果你有3个字节且它们不是NUL - 它是UTF-8
   (同样,ASCII数字没有前导'0' "x",[1]等等)
6. 如果你有4个字节或更多的RFC方法工作:
   • 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

但它只有在它确实是任何这些编码中的有效字符串时才有效,它可能不是.此外,即使您在5个有效编码之一中有一个有效字符串,它仍可能不是有效的JSON.

我的建议是使用比RFC中包含的更严格的验证来验证您是否具有:

1. UTF-8,UTF-16或UTF-32(LE或BE)的有效编码
2. 一个有效的JSON

只查看NUL字节是不够的.

话虽如此,在任何时候你都不需要有任何BOM字符来确定编码,你也不需要MIME字符集 - 两者都不需要而且在JSON中无效.

使用UTF-16和UTF-32时,您只需使用二进制内容传输编码,因为它们可能包含NUL字节.UTF-8没有那个问题,8bit内容传输编码很好,因为它在字符串中不包含NUL(虽然它仍然包含字节> = 128所以7位传输不起作用 - 有UTF- 7适用于此类传输,但它不是有效的JSON,因为它不是唯一有效的JSON编码之一).

有关更多详细信息,请参阅此答案.

回答你的后续问题

这些是正确的扣除吗？

是.

在实施遵循这种解释的Web服务或Web客户端时,我会遇到问题吗？

可能,如果您与不正确的实现交互.为了与不正确的实现进行互操作,您的实现可能会忽略BOM - 请参阅RFC 7159,第1.8节:

为了互操作性,解析JSON文本的实现可以忽略字节顺序标记的存在,而不是将其视为错误.

此外,忽略MIME字符集是兼容JSON实现的预期行为 - 请参阅RFC 7159,第11节:

注意:没有为此注册定义"charset"参数.添加一个对合规收件人没有任何影响.

安全考虑

我个人并不认为总是需要默默地接受不正确的JSON流.如果您决定接受带有BOM和/或MIME字符集的输入,那么您将不得不回答这些问题:

• 如果MIME字符集和实际编码不匹配,该怎么办？
• 如果BOM和MIME字符集不匹配,该怎么办？
• 如果BOM与实际编码不匹配,该怎么办？
• 当所有这些都不同时该怎么办？
• 如何处理UTF-8/16/32以外的编码？
• 您确定所有安全检查都能按预期工作吗？

将编码定义在三个独立的位置 - 在JSON字符串本身,BOM和MIME字符集中使得问题不可避免:如果他们不同意该怎么办.除非你拒绝这样的输入,否则没有一个明显的答案.

例如,如果您有一个验证JSON字符串的代码,以查看在JavaScript中评估它是否安全 - 它可能被MIME字符集或BOM误导,并且视为与实际不同的编码并且不检测字符串它会检测它是否使用了正确的编码.(HTML的类似问题在过去导致了XSS攻击.)

每当您决定接受具有多个且可能存在冲突的编码指示符的错误JSON字符串时,您必须为所有这些可能性做好准备.这并不是说你永远不应该这样做,因为你可能需要消耗不正确的实现产生的输入.我只是说你需要彻底考虑其含义.

不合规的实施

我是否应该针对违反上述两个属性的Web浏览器提交错误？

当然 - 如果他们称之为JSON并且实现不符合JSON RFC那么它就是一个bug,应该这样报告.

您是否发现了任何不符合JSON规范的特定实现,但他们做了广告宣传？