jq：错误（在 <stdin>:0）：无法迭代 null（null）

Question

我一直在使用 API 调用以 JSON 格式对其进行结构化，以便稍后将其推送到数据库中。然后代码如下所示：

getPage() {
curl --fail -X GET 'https://api.app.com/v1/test?page=1&pageSize=1000&sort=desc' \
  -H 'Authorization: Bearer 123abc456pickupsticks789' \
  -H 'cache-control: no-cache'  
}

getPage \
| jq -c '.items | .[] | {landing_id: .landing_id, submitted_at: .submitted_at, answers: .answers, email: .hidden.email}' \
  > testpush.json

当我运行它时，它会产生这个错误：jq: error (at <stdin>:0): Cannot iterate over null (null)

我看过this one、or this one from this site和this response.等解决方案

常见的解决方案似乎是在[] 前面使用?，我在底部的jq 行中尝试了它，但它仍然不起作用。它只会生成一个空的 json 文件。

我是否误读了其他答案的要点，没有将我的 ? 放在正确的位置？>

Answer 1

为了防止.items 不是数组的可能性，您可以这样写：

.items | .[]?

甚至更强大：

try .items[]

相当于(.items[])?。

总结：

• try E 等价于 try E catch empty
• try E 等价于 (E)?

（请注意，.items[]? 和 (.items[])? 的表达式不相同。）

但是，这些都不能提供对无效 JSON 输入的保护。

---

附言今后，请遵循 mcve 指南 (http://stackoverflow.com/help/mcve)；在本例中，如果您根据curl 命令生成的输出提供说明性 JSON sn-p，将会有所帮助。

Answer 2

在解析该数组时，有必要让 JSON 知道它可以在出现意外值后继续。 try 或 ? 是完美的选择。

请记住，要么必须保证数据，要么让解释器知道可以继续。这听起来可能是多余的，但它类似于一种故障安全方法，可以防止难以跟踪/注意到的意外结果。 此外，有必要了解 之间的“测试”差异吗？ vs 试试。

假设 $sample 符合 JSON 标准，下面的代码将始终有效：

sample='{"myvar":1,"var2":"foo"}'
jq '{newVar: ((.op[]? | .item) // 0)}' <<< $sample

所以，$sample 的 op 数组是 null，但 jq 很清楚，它可以在不请求的情况下继续您的干预/修复。

---

但如果你确实假设 ? 与 try 相同，你可能会得到一个错误（花了我很多时间才知道这一点，并且在文档中并不清楚）。作为不当使用 ? 的一个例子，我们有：

sample='{"myvar":1,"var2":"foo"}'
jq '{newVar: (.op[].item? // 0)}' <<< $sample

因此，由于 op 为 null，它会导致错误，因为您告诉 jq 在检索 .item时忽略错误>，虽然提到了在尝试迭代 null（在本例中为 .op[]）期间可能出现错误，并且该尝试发生在该点之前检查 .item。 另一方面，try 在这种情况下可以工作：

sample='{"myvar":1,"var2":"foo"}'
jq '{newVar: (try .op[].item catch 0)}' <<< $sample

这是一个很小的使用差异，可能会导致结果的很大差异