想知道如何强制 httpie 不更改 json 字段顺序?
curl -i http://localhost:8080/v1/notes/569766aed4c661fba8d85a12
{
"id": "569766aed4c661fba8d85a12",
"content": "hi"
}
与 httpie
http get :8080/v1/notes/569766aed4c661fba8d85a12
{
"content": "hi",
"id": "569766aed4c661fba8d85a12"
}
我更喜欢id
字段始终是第一个。 有什么想法吗?
请注意,在 json 格式化程序中,sort_keys=True
可以假设这就是原因
啊好的,谢谢。
使用以下内容,我可以禁用对键进行排序(不幸的是,还有缩进,但这不是什么大问题)
http --pretty=colors get :8080/v1/notes/569766aed4c661fba8d85a12
不客气,尽管我觉得这确实提出了一个问题,即排序是应该在一般情况下完成还是应该按照服务器的意图进行
是否可以为--pretty
引入另一个值以允许颜色和格式设置但不对响应中的键进行排序?
您可以将无序设置为默认值吗? 对于想要排序键行为的人,还有一个像--sort-keys
这样的选项; 见https://bugs.python.org/issue21650 json.tool 已经在 python3 中有一个选项
➸ python3 -m json.tool -h
usage: python -m json.tool [-h] [--sort-keys] [infile] [outfile]
A simple command line interface for json module to validate and pretty-print
JSON objects.
positional arguments:
infile a JSON file to be validated or pretty-printed
outfile write the output of infile to outfile
optional arguments:
-h, --help show this help message and exit
--sort-keys sort the output of dictionaries alphabetically by key
我失去的时间比我承认试图在我的服务器端 JSON 库中查找问题的时间要多得多,因为我无法弄清楚为什么它以错误的顺序发送数据。 我什至没有想到客户可能正在重新订购东西。
是否值得选择重新排序 JSON? 90% 的时间它会混淆而不是改善服务器输出。
我会提交一个拉取请求,但它只是将一个文件中的“真”更改为“假”。
完全同意@carlfish
@jkbrzt 对此有何想法?
在本地对此进行了测试,看起来如果您告诉格式化程序不要按字母顺序排列,您会以任意顺序获得对象键 - 我猜它是由无序字典支持的? 在这种情况下,字母排序可能比随机排序更好。
我猜它是由无序字典支持的?
是的,python json.loads
默认加载到一个dict中,这是不可预知的顺序(有点内部使用的哈希码),并不比字母顺序好;
但有解决方法,请使用object_pairs_hook=OrderedDict
; 并在调用json.dumps
sort_keys
#$
>>> import json
>>> from collections import OrderedDict
>>> data = json.loads('{"foo":1, "bar": 2}', object_pairs_hook=OrderedDict)
>>> print json.dumps(data, indent=4)
{
"foo": 1,
"bar": 2
}
>>>
两个剃光牦牛后:拉请求-> https://github.com/jkbrzt/httpie/pull/520
对于它的价值,我碰巧是一个喜欢看到我的 JSON 输出中的键排序的用户。 我的服务器没有定义输出键的顺序,如果我想查看我期望的键是否包含在 JSON 正文中,那么对它们进行排序会容易得多。 所以我想说不要只是随意删除排序功能,而是通过标志使其可配置或可切换。
ping 作者@jakubroztocil这是停止维护了吗?
在这个问题上有什么吸引力吗? 像@carlfish一样,我刚刚花了很长时间试图纠正我的服务器中的错误,却发现 httpie 是问题所在。
在没有用户明确启用它的情况下,它会重新排序/排序来自服务器的数据,这似乎非常不直观。
PR #520 中有一个解决方案,遗憾的是尚未合并。
这将非常有用。 当您不想要它时,排序并不是那么好。
整个 Python2 已弃用; 一些维护者可以查看待处理的 PR? 从贡献者图表看来, @jakubroztocil @msabramo仍然活跃?
有人在做这个吗? 我们可以期待这个问题得到解决吗?
@opensas对此一无所知,但可能的解决方案是使用jq
工具:
http https://jsonplaceholder.typicode.com/todos/1 | jq -C
非常感谢您的提示,已经在此线程中注意到了。
有什么方法可以在通过 jq 管道后保留其余的请求信息(状态和标头)?
我的意思是,httpie 返回这个:
HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 109
Content-Type: application/json; charset=utf-8
Date: Sat, 25 Apr 2020 11:14:32 GMT
ETag: W/"6d-wWZh31xOzPgYyzU23ihgZaW8KkI"
Strict-Transport-Security: max-age=15552000; includeSubDomains
X-Content-Type-Options: nosniff
X-DNS-Prefetch-Control: off
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
[
{
"id": 1,
"text": "Read the docs"
},
{
"id": 2,
"text": "Create my first application"
},
{
"id": 3,
"text": "Write tests"
}
]
但是http | jq -C 去掉第一部分,只返回:
[
{
"id": 1,
"text": "Read the docs"
},
{
"id": 2,
"text": "Create my first application"
},
{
"id": 3,
"text": "Write tests"
}
]
@opensas除非您编写自定义 bash 包装器,否则我认为这是不可能的
@opensas @nmtitov管道输出的副作用是将默认--print=hb
(打印标题和正文)更改--print=b
(仅打印正文,因为这是您在重定向输出时通常想要的)。 您可以明确要求将标头包含在--print=hb
中。
https://httpie.org/docs#output -options
@jakubroztocil这不起作用,因为jq
期望 JSON 正文作为输入
$ http --print=hb https://jsonplaceholder.typicode.com/todos/1 | jq -C
parse error: Invalid numeric literal at line 1, column 9
我知道了。 你可以使用http --download httpbin.org/get | jq
我找到了以下工作区,而不是使用 httpie 我发现curlie ,这似乎
与 curl 类似,但与 httpie 不同,标头写入 stderr 而不是 stdout。
所以我可以这样使用它:
$ curlie GET localhost:3000/tasks | jq -C
HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: application/json; charset=utf-8
Content-Length: 304
ETag: W/"130-ED1W4hQo1i7na7wy5Ewc7iKdoJc"
Date: Wed, 27 May 2020 06:28:26 GMT
Connection: keep-alive
[
{
"id": 2,
"title": "new task2",
"description": "description2",
"status": "OPEN"
},
{
"id": 3,
"title": "new task3",
"description": "description3",
"status": "OPEN"
}
]
与 httpie 一样,我会使用标题
顺便说一句,我创建了这个方便的脚本:
$ cat ~/bin/c
curlie "$@" | jq -C
刚刚发布的 v2.2.0 解决了这个问题。 在此处了解新的--unsorted
、 --sorted
和--format-options
:
https://httpie.org/docs#colors -and-formatting
最有用的评论
我失去的时间比我承认试图在我的服务器端 JSON 库中查找问题的时间要多得多,因为我无法弄清楚为什么它以错误的顺序发送数据。 我什至没有想到客户可能正在重新订购东西。
是否值得选择重新排序 JSON? 90% 的时间它会混淆而不是改善服务器输出。
我会提交一个拉取请求,但它只是将一个文件中的“真”更改为“假”。