diff --git a/features/binary_formats/bjdata.md b/features/binary_formats/bjdata.md index 3e3d8e885..12ef19d59 100644 --- a/features/binary_formats/bjdata.md +++ b/features/binary_formats/bjdata.md @@ -141,8 +141,14 @@ The library uses the following mapping from JSON values types to BJData types ac parsed back as a regular array, - every entry of `"_ArraySize_"` is a positive integer, and their product is representable as a `std::size_t`, - `"_ArrayData_"` is an array holding exactly that many elements, and - - every element of `"_ArrayData_"` is a number of the kind named by `"_ArrayType_"` (a floating-point number for - `single` and `double`, an integer otherwise). + - every element of `"_ArrayData_"` is a number of the kind named by `"_ArrayType_"`: for the integer types, a + value that fits the named width; for `double`, any value; for `single`, a value that survives narrowing to + `float` and back without change (for instance, `0.1` does not, since it is not exactly representable as + `float`). + + An annotated object is always read back with its keys in the order shown above, `"_ArrayType_"`, `"_ArraySize_"`, + `"_ArrayData_"`, regardless of the order the ND-array's header stores them in on the wire. This matters for + `ordered_json`, whose comparison takes key order into account. The current version of this library does not yet support automatic detection of and conversion from a nested JSON array input to a BJData ND-array. diff --git a/features/binary_formats/bjdata/index.html b/features/binary_formats/bjdata/index.html index 626c64d3f..aebfd837a 100644 --- a/features/binary_formats/bjdata/index.html +++ b/features/binary_formats/bjdata/index.html @@ -3,7 +3,7 @@ "_ArraySize_": [2,3], "_ArrayData_": [1,2,3,4,5,6] } -
Likewise, when a JSON object in the above form is serialized using to_bjdata, it is automatically converted into a compact BJData ND-array.
When parsing, an ND-array whose dimension vector is empty, contains a single integer, contains two integers with the first being 1, or contains a 0 is returned as a regular (possibly empty) array rather than an annotated object.
An object is only converted if the annotation describes a packed array that is parsed back into the same annotated object; otherwise it is serialized as a regular JSON object, so the annotation is never lost in a round trip. This requires all of the following:
"_ArrayType_" is one of uint8, int8, uint16, int16, uint32, int32, uint64, int64, single, double, char, or byte,"_ArraySize_" is an array, since the dimensions are written as the ND-array header's length,"_ArraySize_" has at least two entries and is not a 1×N row vector (first entry 1), since other shapes are parsed back as a regular array,"_ArraySize_" is a positive integer, and their product is representable as a std::size_t,"_ArrayData_" is an array holding exactly that many elements, and"_ArrayData_" is a number of the kind named by "_ArrayType_" (a floating-point number for single and double, an integer otherwise).The current version of this library does not yet support automatic detection of and conversion from a nested JSON array input to a BJData ND-array.
Restrictions in optimized data types for arrays and objects
Due to diminished space saving, hampered readability, and increased security risks, in BJData, the allowed data types following the $ marker in an optimized array and object container are restricted to non-zero-fixed-length data types. Therefore, the valid optimized type markers can only be one of UiuImlMLhdDCB. This also means other variable ([{SH) or zero-length types (TFN) can not be used in an optimized array or object in BJData.
Binary values
BJData provides a dedicated B marker (defined in the BJData specification (Draft 3)) that is used in optimized arrays to designate binary data. This means that, unlike UBJSON, binary data can be both serialized and deserialized.
To preserve compatibility with BJData Draft 2, the Draft 3 optimized binary array must be explicitly enabled using the version parameter of to_bjdata.
In Draft2 mode (default), if the JSON data contains the binary type, the value stored as a list of integers, as suggested by the BJData documentation. In particular, this means that the serialization and the deserialization of JSON containing binary values into BJData and back will result in a different JSON object.
#include <iostream>
+Likewise, when a JSON object in the above form is serialized using to_bjdata, it is automatically converted into a compact BJData ND-array.
When parsing, an ND-array whose dimension vector is empty, contains a single integer, contains two integers with the first being 1, or contains a 0 is returned as a regular (possibly empty) array rather than an annotated object.
An object is only converted if the annotation describes a packed array that is parsed back into the same annotated object; otherwise it is serialized as a regular JSON object, so the annotation is never lost in a round trip. This requires all of the following:
"_ArrayType_" is one of uint8, int8, uint16, int16, uint32, int32, uint64, int64, single, double, char, or byte,"_ArraySize_" is an array, since the dimensions are written as the ND-array header's length,"_ArraySize_" has at least two entries and is not a 1×N row vector (first entry 1), since other shapes are parsed back as a regular array,"_ArraySize_" is a positive integer, and their product is representable as a std::size_t,"_ArrayData_" is an array holding exactly that many elements, and"_ArrayData_" is a number of the kind named by "_ArrayType_": for the integer types, a value that fits the named width; for double, any value; for single, a value that survives narrowing to float and back without change (for instance, 0.1 does not, since it is not exactly representable as float).An annotated object is always read back with its keys in the order shown above, "_ArrayType_", "_ArraySize_", "_ArrayData_", regardless of the order the ND-array's header stores them in on the wire. This matters for ordered_json, whose comparison takes key order into account.
The current version of this library does not yet support automatic detection of and conversion from a nested JSON array input to a BJData ND-array.
Restrictions in optimized data types for arrays and objects
Due to diminished space saving, hampered readability, and increased security risks, in BJData, the allowed data types following the $ marker in an optimized array and object container are restricted to non-zero-fixed-length data types. Therefore, the valid optimized type markers can only be one of UiuImlMLhdDCB. This also means other variable ([{SH) or zero-length types (TFN) can not be used in an optimized array or object in BJData.
Binary values
BJData provides a dedicated B marker (defined in the BJData specification (Draft 3)) that is used in optimized arrays to designate binary data. This means that, unlike UBJSON, binary data can be both serialized and deserialized.
To preserve compatibility with BJData Draft 2, the Draft 3 optimized binary array must be explicitly enabled using the version parameter of to_bjdata.
In Draft2 mode (default), if the JSON data contains the binary type, the value stored as a list of integers, as suggested by the BJData documentation. In particular, this means that the serialization and the deserialization of JSON containing binary values into BJData and back will result in a different JSON object.
#include <iostream>
#include <iomanip>
#include <nlohmann/json.hpp>
@@ -95,4 +95,4 @@
"compact": true,
"schema": 0
}
-