Values with large numbers getting changed

[medigvijay]

The following sample
{"abc":8143661439548533232}

is getting changed to following in the right panel

{"abc": 8143661439548533000}

[josdejong]

Thanks, this is a limitation in the Number format of JavaScript, which has a precision of about 16 digits.

Solving this is not so trivial but interesting. It would require wirting our own JSON parser which keeps numbers in some string format instead of parse them as regular numbers.

[aadrian]

Any chance of supporting the "transit" format? https://github.com/cognitect/transit-format
It is a JSON encoding of extra meta-data, adding types where it's necessary, so that such truncation (and other too) do not happen.

Of course, there are libraries for many languages, including JS :) https://github.com/cognitect/transit-js

Because transit has much more "semantic types" than "raw JSON", it could offer more "cell editors", making it much more usable for end users.

[josdejong]

@aadrian this feature request has nothing to do with this issue, should be in it's own issue instead. Anyway, adding support for other data formats is not on the roadmap for JSONEditor, sorry.

[josdejong]

A short update on this topic: I've written a JavaScript a library which can handle large values without losing precision, see: https://github.com/josdejong/lossless-json I was planning on integrating this in the JSONEditor.

Please note that relying on JSON objects containing for example 64bit long numbers may be tricky, since for example web applications cannot handle long values and will truncate some digits.

[crazier]

That's great news!
I also need the ability to handle 64bits int.
So when this feature will release?

[josdejong]

Yeah, still need to work that out. I'm focusing on a completely new version lately (see #337).

[epoberezkin]

@josdejong I've added BigInt support to json-source-map

[josdejong]

Cool 😎. I hadn't seen json-source-map before I think? Having big integers solves most practical use cases, thanks for sharing.

[epoberezkin]

You use it here it seems :)

[epoberezkin]

https://github.com/josdejong/jsoneditor/blob/develop/package.json#L31

[josdejong]

Ah 😂 you're right. The code using json-source-map was implemented by @meirotstein, I didn't recall that we started using this specific library then.

[meirotstein]

@josdejong correct, this library is used by the selection api.
A great library @epoberezkin !

[wilddylan]

this project now use json-source-map or lossless-json?

i just want to upgrade jsoneditor version .... only use jsoneditor lib;

[wilddylan]

upgrade jsoneditor to the latest version can fix the big int issue ?

[josdejong]

json-source-map is used to generate helpful error messages and JSON schema warnings, and to be able to click on the error message and go to the related line. The core of JSONEditor uses regular JSON and regular numbers though, we still need to replace this with a custom parser, see #231 (comment).

[wilddylan]

json-source-map is used to generate helpful error messages and JSON schema warnings, and to be able to click on the error message and go to the related line. The core of JSONEditor uses regular JSON and regular numbers though, we still need to replace this with a custom parser, see #231 (comment).

what's the time (milestone) for fix this issue in jsoneditor project?

[josdejong]

Not anytime soon I expect.

[wilddylan]

Not anytime soon I expect.

can you fix that now ? out project use this library... and we want to fix that;

[josdejong]

can you fix that now ?

I would love to but there are simply so much things that I would like to address "now". I simply have a limited amount of spare time that I can spend on open source projects.

If it's this important to you, you could implement it yourself and create a PR to get it merged into the project.

Alternatively, you could try a workaround like adding a pre-processing step where you replace all long values in your JSON with strings before opening it in the JSONEditor, and a post-processing step where you do the opposite.

[wilddylan]

let me try; or use string

[DannyL9143]

I am having this same issue. The program is converting an id 10120124111101040103 to a number 10120124111101040000. wilddynlan commented to use a string, how do you do that? I tried enclosing the number in double quotes, but that just makes the value "\"10120124111101040103\"".

[josdejong]

This is indeed still an open issue.

The trick is to load JSON containing the large value as a string, so instead of:

{
  "large value": 10120124111101040103 
}

You provide the following document:

{
  "large value": "10120124111101040103"
}

[josdejong]

FYI: the successor of this library, svelte-jsoneditor, now supports lossless-json or other JSON parsers, and https://jsoneditoronline.org/ now uses this parser to handle large values.

You can read more in the following article: https://jsoneditoronline.org/indepth/parse/why-does-json-parse-corrupt-large-numbers/