JSON round-tripping bugs

[Alex Rønne Petersen]

When trying to round-trip the MonoBehaviours in this file as JSON, everything works fine if I either don't touch the exported files, or only do simple modifications like changing strings.

But if I try to do jsonlint -q -i on all the exported files and then import them, the resulting file will crash the game.

I believe the issue here is that UABE outputs 64-bit integer fields as plain JSON numbers. This can never be truly correct since JS(ON) numbers are actually 64-bit floating point numbers. So some values will not be represented correctly when parsed by most JSON parsers. Example:

$ cat test.json
{ "value": 9999999999999999999 }
$ jsonlint test.json > test2.json
$ cat test2.json
{
  "value": 10000000000000000000
}

We can see that the underlying parser of jsonlint causes the value to overflow. This is expected behavior for JS(ON) and is probably why some of the files I pretty-printed no longer round-trip correctly.

So to be clear, this is not a bug in jsonlint. Even if UABE can parse such numbers back "correctly", the files it produces will be mangled by basically any other spec-compliant JSON tool. UABE should output 64-bit integer fields as strings.

(Note the believe above. I don't actually know if this is the real reason why round-tripping with pretty-printing fails, and it's very difficult to investigate further without UABE source code, but this is surely a bug in any case.)

[Alex Rønne Petersen]

I just tried pretty-printing with Python's simplejson module which can round-trip arbitrary integers, and compared to jsonlint output. There are indeed many m_PathID fields that get mangled, so no wonder the resulting file after an import is useless.

[Alex Rønne Petersen]

Another JSON bug: Newline escapes in strings get imported incorrectly, e.g. "text": "Foo\nBar" becomes "text": "Foo\nnBar" (note the extra n).

[DerPopo]

Thanks for the report! I'm using the JSMN library which just returns tokens and string positions, and read in the values based on the type specified along with the field name. The library is specifically written to work with non-conforming files, so it's not surprising I haven't noticed that bug.

The escape sequence bug will also be fixed.

[shukenmg]

Another JSON bug: Newline escapes in strings get imported incorrectly, e.g. "text": "Foo\nBar" becomes "text": "Foo\nnBar" (note the extra n).

@DerPopo
Yeah, this is an annoying issue, is there a fix for this?
Thanks.

[lucifering]

Another JSON bug: Newline escapes in strings get imported incorrectly, e.g. "text": "Foo\nBar" becomes "text": "Foo\nnBar" (note the extra n).

I replace all "\n" to "<br>".
it work.