为什么 JQ 接受前导零？答案

【问题标题】：Why does JQ accept leading zeros?为什么 JQ 接受前导零？
【发布时间】：2021-11-20 02:31:32
【问题描述】：

{"a" : 01} 或 {"a" : -000.1} 是无效的，但 JQ 可以接受并将其解释为 {"a" : 1} 和 {"a" : -0.1}。

这是设计使然还是错误？

【问题讨论】：

确实，根据RFC 7159: The JavaScript Object Notation (JSON) Data Interchange Format, Section 6 "一个数字用十进制数字表示，以10为基数。它包含一个整数部分，前面可以加上一个可选的减号，后面可以跟着一个减号由小数部分和/或指数部分。前导零是不允许的。”。所以，我想，严格来说，jq 不应该接受这一点。
RFC 7159 9. 解析器“JSON 解析器将 JSON 文本转换为另一种表示形式。JSON 解析器必须接受所有符合 JSON 语法的文本。JSON 解析器可以接受非 JSON 形式或扩展。”在 rfc8259 中相同

标签： jq

【解决方案1】：

由于 JSON 中不允许有多余的前导 0，因此“严格模式”可能对 jq 很好，但即使不调用 Postel's Law，对于像 jq 这样的工具来说接受它们显然是完全合理的（JSON，后all，应该是对人类友好的），只要应该是 JSON 的输出是有效的。

此外，还有很多不安全的短绒。

顺便说一句，FWIW、NaN 和 Infinite 也被接受为输入（并进行相应解释），因此很明显 jq 的创建者/维护者打算在读取 JSON 文本时使用“非严格”模式。

_{我看到的一个反对允许多余 0 的论点是，由于 00 不是有效的 JSON，一个声称读取 JSON 流的工具应该将 00 识别为两个 0。这确实是 gojq 的 JSON 解析器处理前导 0 的方式。}

【讨论】：

Linters 解决不了任何问题。假设我要创建另一个 JQ 实现。我应该故意接受前导零以符合原件吗？像 --strict 这样的额外参数会很好 IMO
@Jaro - jq 的另一个实现 - gojq；它试图坚持 jq 所宣传的显然是必不可少的功能。有很多预期的差异，如果作者选择将严格模式设为默认模式，我不会感到惊讶，但是：gojq -n '000.1, 003, 2.0E001' => 0.1 3 20
FWIW 在github.com/stedolan/jq/issues/1404 处有一个针对该问题的开放错误，维护者似乎支持修复的想法，但已经好几年没有得到解决了。
Re "“严格模式”可能对 jq 更好"，松散模式会更好:) [注释、尾随逗号、dict 键周围的可选引号（如果标识符） -like]
@ikegami 我完全赞同这一点。它应该只接受 JSON； --loose 将是附加选项