You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
"Sort by key" causes the value type to change #221
Indeed, it won't pass, because it will output {"a": "30", "b": "valueB"}
The root cause is the line JsonHandler.h:29 constexpr auto flgBaseReader = rj::kParseEscapedApostropheFlag | rj::kParseNanAndInfFlag | rj::kParseNumbersAsStringsFlag;
Note rj::kParseNumbersAsStringsFlag
When JsonHandler.cpp:108SortJsonText read json it treats numbers as string (as an attempt to preserve whatever number there was even if it's too long to be parsed precisely) and outputs it as string.
I'm not a maintainer of this repo (just joined) and I didn't figure out a good and simple solution yet.
Since RapidJSON dependency come from a fork by @SinghRajenM (main maintainer)
I can suggest to fix this in this fork and keep a list of patches applied to keep track of this for future syncs with the main RapidJSON repo
The numbers are still read as strings (not interpreted, thus keeping the original text), but I also set a flag to say it was a raw number, so on output we can output it as RawNumber (instead of string).
I added the test for precision to the PR for rapidjson.
But on the plugin side, there is another issue with precision.
When it writes the json back (after sorting), it uses rj::kParseFullPrecisionFlag so it lose precision
Activity
AntonDevil commentedon Oct 13, 2025
I investigated the issue a little bit.
Here is the test for it (can be added to
JsonHandlerTest.cpp):Indeed, it won't pass, because it will output
{"a": "30", "b": "valueB"}The root cause is the line
JsonHandler.h:29constexpr auto flgBaseReader = rj::kParseEscapedApostropheFlag | rj::kParseNanAndInfFlag | rj::kParseNumbersAsStringsFlag;Note
rj::kParseNumbersAsStringsFlagWhen
JsonHandler.cpp:108SortJsonTextread json it treats numbers as string (as an attempt to preserve whatever number there was even if it's too long to be parsed precisely) and outputs it as string.I'm not a maintainer of this repo (just joined) and I didn't figure out a good and simple solution yet.
AntonDevil commentedon Oct 15, 2025
There was an attempt to support this:
RawNumber() inconsistent about quotes
But there were some problem about it Write RawNumber without quotes
Since RapidJSON dependency come from a fork by @SinghRajenM (main maintainer)
I can suggest to fix this in this fork and keep a list of patches applied to keep track of this for future syncs with the main RapidJSON repo
SinghRajenM commentedon Mar 19, 2026
@AntonDevil can you raise PR for this?
RapidJson is forked and part of this org now: https://github.com/NPP-JSONViewer/rapidjson
AntonDevil commentedon Mar 21, 2026
Hi @SinghRajenM
First, I need to merge this:
NPP-JSONViewer/rapidjson#1
SinghRajenM commentedon Mar 21, 2026
One QQ: does it retain the precision?
AntonDevil commentedon Mar 21, 2026
Inherently it does.
The numbers are still read as strings (not interpreted, thus keeping the original text), but I also set a flag to say it was a raw number, so on output we can output it as RawNumber (instead of string).
Do you have any test to try it?
SinghRajenM commentedon Mar 21, 2026
Currently, precision and format are not retained in RapidJson. There are few tests,
FormatJson_numbersis one of them.I've merged the NPP-JSONViewer/rapidjson#1
AntonDevil commentedon Mar 21, 2026
I added the test for precision to the PR for rapidjson.
But on the plugin side, there is another issue with precision.
When it writes the json back (after sorting), it uses
rj::kParseFullPrecisionFlagso it lose precisionAntonDevil commentedon Mar 21, 2026
@SinghRajenM if you like, you can merge followup with more tests:
NPP-JSONViewer/rapidjson#2
SinghRajenM commentedon Mar 21, 2026
Rather I will add these to Plugin instead of RapidJason
AntonDevil commentedon Mar 21, 2026
@SinghRajenM
1. Tests
My plan was to add to both (why not? more test the better =)),
These are two separate projects,
but it's your call.
2. Parse flags
BTW, why flgBaseWriter uses
rj::kParseFullPrecisionFlaginstead of
rj::kParseNumbersAsStringsFlagas in flgBaseReader?JSON-Viewer/src/NppJsonViewer/JsonHandler.h
Lines 29 to 30 in 095bf27
I guess this is exactly because of this issue of writing RawNumbers that I just fixed?
It used to convert raw numbers to strings, but now it won't
If so, I can unify both and there will be no precision loss.
AntonDevil commentedon Mar 21, 2026
@SinghRajenM
#240 fixes the subject issue
#241 fixes the rest like
FormatJson_numbersyou mentioned (built on top of the first PR)we taught rapidJSON to work with raw numbers properly =)
It also fixes a number of other issues related to precision accumulated through the years
SinghRajenM commentedon Mar 21, 2026
Fixed in #240