Known issues of ArduinoJson 7
This page lists the known issues and limitations of ArduinoJson 7.
They are all compromises made to reduce the size of the library and are, therefore, unlikely to be fixed in the future.
Known issue 1: the parser isn’t strict
ArduinoJson’s parser is relatively lax and accepts some invalid inputs.
For example, it doesn’t reject malformed UTF-16 surrogate pairs, like \ud83d\ud83d
.
For that reason, you should not use ArduinoJson to validate JSON documents.
Known issue 2: keys containing NUL characters gets truncated
ArduinoJson 7 doesn’t not support keys containing NUL characters (ASCII code 0, or \u0000
).
If you try to insert a key containing a NUL character, the key will be truncated.
I added support for NULs at some point but ended up removing it because it was too expensive in terms of code size.
Known issue 3: the string-to-float conversion is not perfect
ArduinoJson 7’s string-to-float conversion is good but not perfect.
For example, if the input is "0.123"
, you’ll get 0.1230000000000001
.
You can find details about this algorithm in my article Lightweight float to string conversion.
Known issue 4: the float-to-string conversion is not perfect either
ArduinoJson 7’s serializes 1.7976931348623147e308
into "1.797693135e308"
.
The rounding is correct, but the value exceeds double
’s range.
This can be an issue because when we deserialize the document, we get inf
.
Known issue 5: a JsonDocument
is limited to 255
, 64K
, or 4M
nodes depending on the architecture
ArduinoJson 7 uses integers instead of pointers to locate the nodes in the JsonDocument
.
The width of the integers depends on the CPU architecture.
CPU architecture | Bits for node id | Max nodes |
---|---|---|
8-bit | 8 | 255 |
32-bit | 16 | 65635 |
64-bit | 32 | 4294967294 |
This should be enough for most applications, but if you need more, you can change the width of the node id by setting ARDUINOJSON_SLOT_ID_SIZE
to the desired number of bits.