Files
json/docs/mkdocs/docs/api/basic_json/from_bjdata.md
T
Niels Lohmann 60107eda3f Read BJData ND-arrays of float16, restrict ND-array char to 0..127, correct BJData docs (#5931)
* Read ND-arrays of half floats and enforce the char limit in ND-arrays

BJData N-dimensional arrays with element type 'h' (float16) failed to
read with a misleading parse_error.112, because the reader's dtype name
table lacked 'h'. It now maps to "half", the JData name. The writer still
does not pack "half"; such an object is written as a plain object and
reads back equal.

BJData limits 'C' (char) to 0..127 in Draft 2 and Draft 3, and the 1-D
reader enforces this, but ND-arrays with _ArrayType_ "char" wrote values
up to 255 as 'C' elements and read them back without a check. The writer
now only packs values in 0..127 (others fall back to a plain object that
round-trips), and the reader rejects 'C' elements above 127 with
parse_error.113 like the 1-D reader.

Signed-off-by: Niels Lohmann <mail@nlohmann.me>

* docs: correct and complete the BJData documentation

Verify the BJData chapter against the library and the Draft 2/3/4
specifications and fix what did not match:

- bjdata.md: correct the list of unused markers (N, not Z), the ND-array
  example (3x2, not 2x3), the conditions under which an object is packed
  as an ND-array (exactly three keys, row vectors, float-only elements for
  single/double, char 0..127, byte only in Draft 3), the binary table row
  and notes (which flag/draft combinations write [$B), the "$" type
  restriction (Draft 3, Z is excluded too), the H marker in the
  deserialization table, and the claim of a complete deserialization
  mapping. Document the supported drafts, that Draft 4 (SoA containers,
  extension type E) and column-major ND-arrays are rejected, ND-arrays of
  half floats, duplicate object keys, and link the Draft 3 specifications
  instead of master.
- Add an API page for basic_json::bjdata_version_t with an example, and
  link it from the nav, the API index and to_bjdata.
- Update binary_formats/index.md and binary_values.md, which still claimed
  that BJData has no binary type, and fix a wrong byte comment there.
- Document parse_error.115 and the out_of_range.408 cases for from_bjdata,
  the precise other_error.502 condition for to_bjdata, and reword the note
  on truncated unsigned integers in exceptions.md (only ND-array elements
  were truncated before 3.13.0).

Signed-off-by: Niels Lohmann <mail@nlohmann.me>

* Regenerate single_include and apply astyle

Result of make amalgamate (including make pretty) for the preceding changes.

Signed-off-by: Niels Lohmann <mail@nlohmann.me>

* Address review of the BJData documentation

The $ type restriction exists since Draft 2 (Draft 3 added B), $ requires a count, ND char above 127 is rejected on read, and the new API page is listed in alphabetical order in the nav.

Signed-off-by: Niels Lohmann <mail@nlohmann.me>

* docs: format tables, use the Oxford comma

Reformat the tables changed by this PR (BJData serialization and
deserialization mappings, completeness and binary-value tables) so all
rows are aligned, and add the Oxford comma to lists of three or more
items in the added text.

Signed-off-by: Niels Lohmann <mail@nlohmann.me>

---------

Signed-off-by: Niels Lohmann <mail@nlohmann.me>
2026-10-26 18:25:46 +01:00

5.6 KiB

nlohmann::basic_json::from_bjdata

// (1)
template<typename InputType>
static basic_json from_bjdata(InputType&& i,
                              const bool strict = true,
                              const bool allow_exceptions = true,
                              const error_handler_t error_handler = error_handler_t::keep);
// (2)
template<typename IteratorType, typename SentinelType = IteratorType>
static basic_json from_bjdata(IteratorType first, SentinelType last,
                              const bool strict = true,
                              const bool allow_exceptions = true,
                              const error_handler_t error_handler = error_handler_t::keep);

Deserializes a given input to a JSON value using the BJData (Binary JData) serialization format.

  1. Reads from a compatible input.
  2. Reads from an iterator range, or an iterator and a sentinel of a different type (C++20 ranges support).

The exact mapping and its limitations are described on a dedicated page.

Template parameters

InputType
A compatible input, for instance:
  • an std::istream object
  • a FILE pointer
  • a C-style array of characters
  • a pointer to a null-terminated string of single byte characters
  • a container obj for which begin(obj) and end(obj) produce a valid pair of iterators (as found via ADL or member functions, with semantics compatible to std::begin and std::end)
IteratorType
a compatible iterator type
SentinelType
defaults to IteratorType; may be a different type comparable to IteratorType via operator!=, for instance.
  • a custom sentinel type for C++20 ranges
  • std::default_sentinel_t, when IteratorType is std::counted_iterator

Parameters

i (in)
an input in BJData format convertible to an input adapter
first (in)
iterator to the start of the input
last (in)
iterator to the end of the input, or a sentinel value that compares equal to the end iterator with operator!=
strict (in)
whether to expect the input to be consumed until EOF (#!cpp true by default)
allow_exceptions (in)
whether to throw exceptions in case of a parse error (optional, #!cpp true by default)
error_handler (in)
how to treat a string value or object key that is not valid UTF-8; see error_handler_t. BJData does not require a decoder to reject ill-formed UTF-8, so checking is opt-in: the default, keep, does not check at all, as every binary reader did before this parameter was added; strict checks and throws; replace/ignore sanitize the string the same way dump would

Return value

deserialized JSON value; in case of a parse error and allow_exceptions set to #!cpp false, the return value will be value_t::discarded. The latter can be checked with is_discarded.

Exception safety

Strong guarantee: if an exception is thrown, there are no changes in the JSON value.

Exceptions

  • Throws parse_error.110 if the given input ends prematurely or the end of the file was not reached when strict was set to true
  • Throws parse_error.112 if a parse error occurs
  • Throws parse_error.113 if a string could not be parsed successfully, or if a string value or object key is not valid UTF-8 and error_handler is strict
  • Throws parse_error.115 if the text of a high-precision number (H) is not a valid number
  • Throws out_of_range.408 if the size of an optimized container cannot be represented by std::size_t or exceeds the container's max_size(), or if the product of the dimensions of an n-dimensional array overflows

Complexity

Linear in the size of the input.

Examples

??? example

The example shows the deserialization of a byte vector in BJData format to a JSON value.
 
```cpp
--8<-- "examples/from_bjdata.cpp"
```

Output:

```json
--8<-- "examples/from_bjdata.output"
```

See also

  • to_bjdata create a BJData serialization of a JSON value
  • from_cbor create a JSON value from an input in CBOR format
  • from_msgpack create a JSON value from an input in MessagePack format
  • from_bson create a JSON value from an input in BSON format
  • from_ubjson create a JSON value from an input in UBJSON format
  • from_bon8 create a JSON value from an input in BON8 format

Version history

  • Added in version 3.11.0.
  • Extended container support (1) to include types with lvalue-only ADL begin/end (matching std::begin/std::end semantics) in version 3.13.0.
  • Extended overload (2) to accept heterogeneous iterator+sentinel pairs (C++20 ranges support) in version 3.13.0.
  • Added error_handler parameter in version 3.13.0.

!!! warning "Deprecation"

- Overload (2) replaces calls to `from_bjdata` with a pointer and a length as first two parameters, which has been
  deprecated in version 3.13.0. In version 4.0.0, this overload
  will be deleted (`= delete`) rather than removed. Please replace all calls like
  `#!cpp from_bjdata(ptr, len, ...);` with `#!cpp from_bjdata(ptr, ptr+len, ...);`.

You should be warned by your compiler with a `-Wdeprecated-declarations` warning if you are using a deprecated
function.