Closed a85 closed 11 years ago
Well... bad news: it is kernel level issue and cannot be fixed without complete redesigning of the vkbeautify.json() part of the plugin. The matter is: the values exceed the range of "integral precision". They are longer than 16 digits. Current version of the vkbeautify plugin uses native JSON object to beautify text. And when we process these long data with JSON object, some of the least-significant bits are lost.
Now good news: originally, json beautifying was done with regexp technique, which doesn't have "precision" restrictions. I think I can restore this version. But I don't have time right now, so it'll take one or two weeks. If it's urgent, you can do it yourself. All changes are in git. Clone it and customize as you need. Or, wait a little, and I'll do it for you.
Best regards,
--Vadim
Ah. Was thinking the same but rather weird that the native JSON object would fail at big numbers. The next release of Postman is still some time away so if you can do it in a week or two that would be great. :)
Hi,
Was just wondering if you got the time to look into this. :)
Thanks!
Not yet. Maybe I work on this on weekend. One question to you: do you pass argument as an object or as a text? If text, it's fine. If object, regexp approach will not help, as I need to convert object in text first, which brings the same "precision restriction" issue.
Thanks. I pass the argument as text.
Hi Abhinav,
I've implemented regexp version on json and created json_regexp branch. Please take a look. It would be nice if you test it in your environment. I did brief testing, everything looked OK. But another round of testing would be useful.
Thank you,
--Vadim
Awesome! Thanks. I will run some tests here and update the issue.
Just tested. The big number issue is gone but a couple of things are different:
form: {
}
it is pretty printed as
form:
{
}
This makes the string rather big to glance through. Would be great if there was an option to toggle it's behavior
Hey Abhinav,
I've fixed the bug and improved formatting "key : {"
Please re-test it.
One known problem: it formats content inside a quoted string. For example, value part in the statement "key": "abc : [ 1,2,3 ]" will be formatted. So, if your users get complex stuff like regexp as a string value, it can be issue. If it is important, please let me know. Everything else looks OK.
--Vadim
Hey Vadim,
The big int numbers bug is gone and the formatting looks better. The string issue does seem to be a problem though. The commas get split into new lines and that makes the JSON string look buggy. Would be good to have that as v0.98.
Hey Abhinav,
I've fixed "comma in string" issue, as well as other unwanted in-string formatting cases. Please test it in your environment. Not sure what you meant, asking for v0.98. Do you want I set this particular number as the version? Current version I set is "1.1.00.regexp", but I can set anything :) Just let me know. Thank you,
--Vadim
Thanks Vadim! Testing it out. I meant the comma issue to work as version 0.98 which I was using. That's all. :)
Seeing slightly weird behavior. The string below was pretty printed like this:
{
"origin": "127.0.0.1",
"files": {
},
"form": {
},
"url": "http: //localhost: 5000/post",
"args": {
},
"headers": {
"Origin": "chrome-extension: //aglpidefogoeiamaehklpfoafichfmdk",
"Content-Length": "29",
"Accept-Language": "en-US,
en;q=0.8,
pt;q=0.6,
af;q=0.4,
mo;q=0.2,
zh;q=0.2",
"Accept-Encoding": "gzip,
deflate,
sdch",
"Host": "localhost: 5000",
"Accept": "*/*",
"User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/30.0.1599.10 Safari/537.36",
"Connection": "keep-alive",
"Cache-Control": "no-cache",
"Content-Type": "application/json",
"Postman-Token": "ebaf1ba5-a819-1655-263b-f16d11d1eed6"
},
"json": {
"json": "is quite cool"
},
"data": "{
\n \"json\": \"is quite cool\"\n}"
}
However with some responses the "Accept-Language" key was not split into different lines.
can you please send me the data before formatting?
Yep. Here it is. This is formatted already from the server side but the same kind of response might be minified too.
{
"origin": "127.0.0.1",
"files": {},
"form": {},
"url": "http://localhost:5000/post",
"args": {},
"headers": {
"Origin": "chrome-extension://aglpidefogoeiamaehklpfoafichfmdk",
"Content-Length": "31",
"Accept-Language": "en-US,en;q=0.8,pt;q=0.6,af;q=0.4,mo;q=0.2,zh;q=0.2",
"Accept-Encoding": "gzip,deflate,sdch",
"Host": "localhost:5000",
"Accept": "*/*",
"User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.10 Safari/537.36",
"Connection": "keep-alive",
"Cache-Control": "no-cache",
"Content-Type": "application/xml",
"Postman-Token": "fab24b79-fe62-09dd-f573-bd435d5fc09d"
},
"json": null,
"data": "<html>\n XML not so much\n</html"
}
well... this stupid '\n' breaks my smart regexp construction :) Gonna to try completely different approach.
OK, finally, this version works as expected. I refused regexp technique, as it is unreliable and use "template-style" approach. In this version I replace long (> 16 chars) numbers with valid delimiter and let JSON to beautify text, then take formatted string and replace delimiters with original numbers. That's it :) Please test it.
Awesome. Seems to be working well!
For example,
Raw:
Pretty printed:
I am using vkbeautify with Postman and this bug was submitted here. https://github.com/a85/POSTMan-Chrome-Extension/issues/316. Would be great to see this fixed.