diff --git a/docs/mkdocs/docs/community/quality_assurance.md b/docs/mkdocs/docs/community/quality_assurance.md index d55d32c16..6c8046964 100644 --- a/docs/mkdocs/docs/community/quality_assurance.md +++ b/docs/mkdocs/docs/community/quality_assurance.md @@ -188,10 +188,13 @@ Note: Some modern features (like C++20 ranges or filesystem support) may be disa ``` - [x] The code is checked with the latest [Cppcheck](https://cppcheck.sourceforge.io) with all warnings enabled. -- [x] The code is checked with the latest [Clang Static Analyzer](https://clang-analyzer.llvm.org) with 89 enabled - rules. +- [x] The code is checked with the latest [Clang Static Analyzer](https://clang-analyzer.llvm.org) with 52 enabled + checkers. - [x] The code is checked with [Infer](https://fbinfer.com). - [x] The code is checked with [Codacy](https://app.codacy.com/gh/nlohmann/json/dashboard). +- [x] The code is scanned with [CodeQL](https://codeql.github.com), [Semgrep](https://semgrep.dev), and + [Flawfinder](https://dwheeler.com/flawfinder/) on every push and pull request and on a schedule; the findings are + reported to GitHub's code scanning. ## Dynamic analysis @@ -204,6 +207,8 @@ Note: Some modern features (like C++20 ranges or filesystem support) may be disa - [x] The test suite is executed with [Valgrind](https://valgrind.org) (Memcheck) to detect memory leaks. - [x] The test suite is executed with [Sanitizers](https://github.com/google/sanitizers) (address sanitizer, undefined behavior sanitizer, integer overflow detection, nullability violations). +- [x] The fuzz targets are run with [CIFuzz](https://google.github.io/oss-fuzz/getting-started/continuous-integration/) + on every pull request to catch regressions before they are merged. ## Dependencies @@ -223,6 +228,8 @@ Note: Some modern features (like C++20 ranges or filesystem support) may be disa No release is made while such an alert is open. - [x] Third-party code included in the repository for testing, such as [doctest](https://github.com/doctest/doctest), is updated manually. +- [x] The repository is evaluated with the [OpenSSF Scorecard](https://securityscorecards.dev) on a schedule and on + every push to the default branch, and the results are reported to GitHub's code scanning. ## Style check @@ -258,4 +265,21 @@ Note: Some modern features (like C++20 ranges or filesystem support) may be disa - [x] The library is tested against relevant CMake versions: - CMake 3.5 (the earliest supported) - CMake 3.31.6 (the latest 3.x release) - - CMake 4.0.0 (a very recent release) + - CMake 4.0.0 (the first 4.x release) +!!! success "Requirement: Other build systems" + + The library can be used with build systems and package managers other than CMake. + +- [x] The library can be consumed with [Meson](https://json.nlohmann.me/integration/package_managers/) and the Swift + Package Manager; the installation with Meson and the resolution of `Package.swift` are tested in the CI. + +!!! success "Requirement: Reproducible and verifiable builds" + + The library can be built and tested without network access or a Git checkout, and its licensing is machine-readable. + +- [x] The test suite is executed from an exported source tree without the `.git` directory and with the test data + being available offline. +- [x] The test suite is executed without the tests that change installed files to check that builds are reproducible. +- [x] The repository is checked for compliance with the [REUSE specification](https://reuse.software) so that the + license and copyright of every file is machine-readable. +- [x] The documentation is built with warnings treated as errors, and its links are checked regularly. diff --git a/docs/mkdocs/docs/features/binary_formats/bjdata.md b/docs/mkdocs/docs/features/binary_formats/bjdata.md index 4591652eb..3a7a1798a 100644 --- a/docs/mkdocs/docs/features/binary_formats/bjdata.md +++ b/docs/mkdocs/docs/features/binary_formats/bjdata.md @@ -17,6 +17,39 @@ simple processing. - [BJData Specification](https://neurojson.org/bjdata/draft2) +## Byte layout + +BJData follows the structure of UBJSON: a one-byte, human-readable ASCII *type marker* followed by the payload of that type, with strings prefixed by a length that is itself an integer value. In contrast to UBJSON, numbers are stored in little-endian byte order, and additional markers cover unsigned 16/32/64-bit integers, half-precision floats, and bytes. Containers can be written unoptimized (opened with `[` or `{`, closed with `]` or `}`) or optimized with a declared element type (`$`) and/or count (`#`). BJData extends the optimized form: the count can be a list of dimensions, which stores an N-dimensional packed array as a flat sequence of values without any per-element markers. + +Consider the following JSON value (shown formatted for readability): + +```json +{ + "id": 300, + "name": "json", + "pi": 3.14, + "tags": [ + "a", + "b" + ] +} +``` + +`to_bjdata` encodes it to 51 bytes (shown in hexadecimal; the encoding contains no whitespace). The colors mark the role of each byte: type/marker length/count/size data. + +
+ + + + + + + + + + +
JSONBytesMeaning
{7Bobject start ({)
"id": 300,69 02 69 64 49 2C 01key: length 2 as int8 (i), then UTF-8 bytes; value: int16 (I), little-endian
"name": "json",69 04 6E 61 6D 65 53 69 04 6A 73 6F 6Ekey: length 4; value: string (S), length 4 as int8, UTF-8 bytes
"pi": 3.14,69 02 70 69 44 1F 85 EB 51 B8 1E 09 40key: length 2; value: float64 (D), little-endian
"tags": [69 04 74 61 67 73 5Bkey: length 4; value: array start ([)
"a",53 69 01 61string, length 1
"b"53 69 01 62string, length 1
]5Darray end (])
}7Dobject end (})
+ ## Serialization The library uses the following mapping from JSON values types to BJData types according to the BJData specification: @@ -190,41 +223,6 @@ The library uses the following mapping from JSON values types to BJData types ac --8<-- "examples/to_bjdata.output" ``` - - - - -### Byte layout - -Consider the following JSON value (shown formatted for readability): - -```json -{ - "id": 300, - "name": "json", - "pi": 3.14, - "tags": [ - "a", - "b" - ] -} -``` - -`to_bjdata` encodes it to 51 bytes (shown in hexadecimal; the encoding contains no whitespace). The colors mark the role of each byte: type/marker length/count/size data. - -
- - - - - - - - - - -
JSONBytesMeaning
{7Bobject start ({)
"id": 300,69 02 69 64 49 2C 01key: length 2 as int8 (i), then UTF-8 bytes; value: int16 (I), little-endian
"name": "json",69 04 6E 61 6D 65 53 69 04 6A 73 6F 6Ekey: length 4; value: string (S), length 4 as int8, UTF-8 bytes
"pi": 3.14,69 02 70 69 44 1F 85 EB 51 B8 1E 09 40key: length 2; value: float64 (D), little-endian
"tags": [69 04 74 61 67 73 5Bkey: length 4; value: array start ([)
"a",53 69 01 61string, length 1
"b"53 69 01 62string, length 1
]5Darray end (])
}7Dobject end (})
- ## Deserialization The library maps BJData types to JSON value types as follows: diff --git a/docs/mkdocs/docs/features/binary_formats/bon8.md b/docs/mkdocs/docs/features/binary_formats/bon8.md index 555942def..b972dc035 100644 --- a/docs/mkdocs/docs/features/binary_formats/bon8.md +++ b/docs/mkdocs/docs/features/binary_formats/bon8.md @@ -10,6 +10,39 @@ values -1.0, 0.0, and 1.0 take a single byte, and arrays and objects with up to - [BON8 specification](https://github.com/hikoworks/hikogui/blob/main/docs/BON8.md) - [Reference implementation](https://github.com/hikoworks/hikogui/blob/main/src/hikogui/codec/BON8.hpp) in HikoGUI +## Byte layout + +BON8 exploits the fact that some byte values can never start a UTF-8 character. These bytes serve as *type markers*, so strings can be stored as plain UTF-8 without a length prefix: a string ends at the first byte that cannot continue it (often the marker of the next value). Small integers, `true`, `false`, `null`, and a few common floats are a single byte. Arrays and objects are introduced by a marker; those with up to four elements encode their size in the marker and need no terminator, while larger ones are closed by the end marker `0xFE`. + +Consider the following JSON value (shown formatted for readability): + +```json +{ + "id": 300, + "name": "json", + "pi": 3.14, + "tags": [ + "a", + "b" + ] +} +``` + +`to_bon8` encodes it to 35 bytes (shown in hexadecimal; the encoding contains no whitespace). The colors mark the role of each byte: type/marker length/count/size data. + +
+ + + + + + + + + + +
JSONBytesMeaning
{8Aobject with 4 members
"id": 300,69 64 C4 04key: UTF-8 bytes; the string ends at the next byte, which cannot continue a UTF-8 character; value: 2-byte positive integer (lead byte, then a byte below 0x80)
"name": "json",6E 61 6D 65 FF 6A 73 6F 6E FFkey: UTF-8 bytes; 0xFF terminates the string as another string follows; value: UTF-8 bytes; terminated as a string key follows
"pi": 3.14,70 69 8F 40 09 1E B8 51 EB 85 1Fkey: UTF-8 bytes; value: binary64 (IEEE 754, big-endian); its marker also ends "pi"
"tags": [74 61 67 73 82key: UTF-8 bytes; value: array with 2 elements; its marker also ends "tags"
"a",61 FFUTF-8 bytes; terminated as a string follows
"b"62 FFUTF-8 bytes; terminated as nothing follows
]no end marker: the element count was given up front
}no end marker: the member count was given up front
+ ## Serialization The library uses the following mapping from JSON values types to BON8 types according to the BON8 specification: @@ -105,41 +138,6 @@ serialized as 0x81 0x65 0xFF, but `[1,2,3,4,"e"]` as 0x85 0x91 0x92 0x93 0x94 0x --8<-- "examples/to_bon8.output" ``` - - - - -### Byte layout - -Consider the following JSON value (shown formatted for readability): - -```json -{ - "id": 300, - "name": "json", - "pi": 3.14, - "tags": [ - "a", - "b" - ] -} -``` - -`to_bon8` encodes it to 35 bytes (shown in hexadecimal; the encoding contains no whitespace). The colors mark the role of each byte: type/marker length/count/size data. - -
- - - - - - - - - - -
JSONBytesMeaning
{8Aobject with 4 members
"id": 300,69 64 C4 04key: UTF-8 bytes; the string ends at the next byte, which cannot continue a UTF-8 character; value: 2-byte positive integer (lead byte, then a byte below 0x80)
"name": "json",6E 61 6D 65 FF 6A 73 6F 6E FFkey: UTF-8 bytes; 0xFF terminates the string as another string follows; value: UTF-8 bytes; terminated as a string key follows
"pi": 3.14,70 69 8F 40 09 1E B8 51 EB 85 1Fkey: UTF-8 bytes; value: binary64 (IEEE 754, big-endian); its marker also ends "pi"
"tags": [74 61 67 73 82key: UTF-8 bytes; value: array with 2 elements; its marker also ends "tags"
"a",61 FFUTF-8 bytes; terminated as a string follows
"b"62 FFUTF-8 bytes; terminated as nothing follows
]no end marker: the element count was given up front
}no end marker: the member count was given up front
- ## Deserialization The library maps BON8 types to JSON value types as follows: diff --git a/docs/mkdocs/docs/features/binary_formats/bson.md b/docs/mkdocs/docs/features/binary_formats/bson.md index 7a9f78d9a..9c82594dd 100644 --- a/docs/mkdocs/docs/features/binary_formats/bson.md +++ b/docs/mkdocs/docs/features/binary_formats/bson.md @@ -10,6 +10,39 @@ representation of data types that are not part of the JSON spec. For example, BS - [BSON Specification](http://bsonspec.org/spec.html) - the specification +## Byte layout + +A BSON document is a length-prefixed sequence of *elements*. The first four bytes hold the total size of the document (little-endian int32), followed by the elements, and a final `0x00` byte ends the document. Each element starts with a one-byte type, followed by its key as a NUL-terminated string and the value, whose encoding depends on the type. Arrays are documents whose keys are the decimal indices `"0"`, `"1"`, ...; nesting is expressed by embedding documents. Because every document announces its size, a reader can skip over it without parsing its content. The top level of a BSON value is always a document, which is why only JSON objects can be serialized. + +Consider the following JSON value (shown formatted for readability): + +```json +{ + "id": 300, + "name": "json", + "pi": 3.14, + "tags": [ + "a", + "b" + ] +} +``` + +`to_bson` encodes it to 69 bytes (shown in hexadecimal; the encoding contains no whitespace). The colors mark the role of each byte: type/marker length/count/size data. + +
+ + + + + + + + + + +
JSONBytesMeaning
{45 00 00 00document size: 69 bytes (int32, little-endian)
"id": 300,10 69 64 00 2C 01 00 00int32 element; key as NUL-terminated string; value (little-endian)
"name": "json",02 6E 61 6D 65 00 05 00 00 00 6A 73 6F 6E 00string element; key; length incl. NUL (int32); NUL-terminated UTF-8 bytes
"pi": 3.14,01 70 69 00 1F 85 EB 51 B8 1E 09 40double element; key; value (little-endian)
"tags": [04 74 61 67 73 00 17 00 00 00array element; key; embedded document of 23 bytes (keys are the indices)
"a",02 30 00 02 00 00 00 61 00string element; key "0"; length 2; a + NUL
"b"02 31 00 02 00 00 00 62 00string element; key "1"; length 2; b + NUL
]00end of the array document
}00end of the document
+ ## Serialization The library uses the following mapping from JSON values types to BSON types: @@ -60,42 +93,6 @@ The library uses the following mapping from JSON values types to BSON types: --8<-- "examples/to_bson.output" ``` - - - - - -### Byte layout - -Consider the following JSON value (shown formatted for readability): - -```json -{ - "id": 300, - "name": "json", - "pi": 3.14, - "tags": [ - "a", - "b" - ] -} -``` - -`to_bson` encodes it to 69 bytes (shown in hexadecimal; the encoding contains no whitespace). The colors mark the role of each byte: type/marker length/count/size data. - -
- - - - - - - - - - -
JSONBytesMeaning
{45 00 00 00document size: 69 bytes (int32, little-endian)
"id": 300,10 69 64 00 2C 01 00 00int32 element; key as NUL-terminated string; value (little-endian)
"name": "json",02 6E 61 6D 65 00 05 00 00 00 6A 73 6F 6E 00string element; key; length incl. NUL (int32); NUL-terminated UTF-8 bytes
"pi": 3.14,01 70 69 00 1F 85 EB 51 B8 1E 09 40double element; key; value (little-endian)
"tags": [04 74 61 67 73 00 17 00 00 00array element; key; embedded document of 23 bytes (keys are the indices)
"a",02 30 00 02 00 00 00 61 00string element; key "0"; length 2; a + NUL
"b"02 31 00 02 00 00 00 62 00string element; key "1"; length 2; b + NUL
]00end of the array document
}00end of the document
- ## Deserialization The library maps BSON record types to JSON value types as follows: diff --git a/docs/mkdocs/docs/features/binary_formats/cbor.md b/docs/mkdocs/docs/features/binary_formats/cbor.md index 20f9230fc..8933630da 100644 --- a/docs/mkdocs/docs/features/binary_formats/cbor.md +++ b/docs/mkdocs/docs/features/binary_formats/cbor.md @@ -9,6 +9,39 @@ extremely small code sizes, fairly small message size, and extensibility without - [CBOR Playground](http://cbor.me) - an interactive webpage to translate between JSON and CBOR - [RFC 8949](https://www.rfc-editor.org/rfc/rfc8949.html) - the CBOR specification +## Byte layout + +CBOR encodes every data item as a *head* followed by optional content. The first byte of the head holds the *major type* in its upper three bits (unsigned integer, negative integer, byte string, text string, array, map, tag, or simple/float) and an *additional information* value in its lower five bits. Additional information below 24 is the argument itself (for example, a small integer or a short length); the values 24 to 27 announce that the argument follows in 1, 2, 4, or 8 big-endian bytes. Strings, arrays, and maps are prefixed with their length (or count of elements/pairs), and content follows directly, so a reader always knows how many items to expect without a terminator. + +Consider the following JSON value (shown formatted for readability): + +```json +{ + "id": 300, + "name": "json", + "pi": 3.14, + "tags": [ + "a", + "b" + ] +} +``` + +`to_cbor` encodes it to 39 bytes (shown in hexadecimal; the encoding contains no whitespace). The colors mark the role of each byte: type/marker data. + +
+ + + + + + + + + + +
JSONBytesMeaning
{A4map with 4 key/value pairs
"id": 300,62 69 64 19 01 2Ckey: text string of length 2, then its UTF-8 bytes; value: unsigned integer, 2 bytes follow (big-endian)
"name": "json",64 6E 61 6D 65 64 6A 73 6F 6Ekey: text string of length 4; value: text string of length 4
"pi": 3.14,62 70 69 FB 40 09 1E B8 51 EB 85 1Fkey: text string of length 2; value: double-precision float (IEEE 754, big-endian)
"tags": [64 74 61 67 73 82key: text string of length 4; value: array with 2 elements
"a",61 61text string of length 1
"b"61 62text string of length 1
]no end marker: the element count was given up front
}no end marker: the member count was given up front
+ ## Serialization The library uses the following mapping from JSON values types to CBOR types according to the CBOR specification @@ -110,41 +143,6 @@ see "binary" cells in the table above. --8<-- "examples/to_cbor.output" ``` - - - - -### Byte layout - -Consider the following JSON value (shown formatted for readability): - -```json -{ - "id": 300, - "name": "json", - "pi": 3.14, - "tags": [ - "a", - "b" - ] -} -``` - -`to_cbor` encodes it to 39 bytes (shown in hexadecimal; the encoding contains no whitespace). The colors mark the role of each byte: type/marker length/count/size data. - -
- - - - - - - - - - -
JSONBytesMeaning
{A4map with 4 key/value pairs
"id": 300,62 69 64 19 01 2Ckey: text string of length 2, then its UTF-8 bytes; value: unsigned integer, 2 bytes follow (big-endian)
"name": "json",64 6E 61 6D 65 64 6A 73 6F 6Ekey: text string of length 4; value: text string of length 4
"pi": 3.14,62 70 69 FB 40 09 1E B8 51 EB 85 1Fkey: text string of length 2; value: double-precision float (IEEE 754, big-endian)
"tags": [64 74 61 67 73 82key: text string of length 4; value: array with 2 elements
"a",61 61text string of length 1
"b"61 62text string of length 1
]no end marker: the element count was given up front
}no end marker: the member count was given up front
- ## Deserialization The library maps CBOR types to JSON value types as follows: diff --git a/docs/mkdocs/docs/features/binary_formats/messagepack.md b/docs/mkdocs/docs/features/binary_formats/messagepack.md index 3bdd1a1be..90e4c295e 100644 --- a/docs/mkdocs/docs/features/binary_formats/messagepack.md +++ b/docs/mkdocs/docs/features/binary_formats/messagepack.md @@ -9,6 +9,39 @@ extra byte in addition to the strings themselves. - [MessagePack website](https://msgpack.org) - [MessagePack specification](https://github.com/msgpack/msgpack/blob/master/spec.md) +## Byte layout + +MessagePack encodes each value as a one-byte *format marker*, optionally followed by a length or the payload. The marker range is partitioned to keep common values small: small non-negative integers (0 to 127) and small negative integers (-32 to -1) are the marker byte itself; short strings, arrays, and maps (up to 31 or 15 elements) hide their length in the marker's lower bits. Larger values use dedicated markers that announce the width (8, 16, 32, or 64 bits) of the length or number that follows, in big-endian byte order. Like CBOR, containers are length-prefixed, so no terminator is needed. + +Consider the following JSON value (shown formatted for readability): + +```json +{ + "id": 300, + "name": "json", + "pi": 3.14, + "tags": [ + "a", + "b" + ] +} +``` + +`to_msgpack` encodes it to 39 bytes (shown in hexadecimal; the encoding contains no whitespace). The colors mark the role of each byte: type/marker data. + +
+ + + + + + + + + + +
JSONBytesMeaning
{84map with 4 key/value pairs
"id": 300,A2 69 64 CD 01 2Ckey: fixstr of length 2, then its UTF-8 bytes; value: uint 16 (big-endian)
"name": "json",A4 6E 61 6D 65 A4 6A 73 6F 6Ekey: fixstr of length 4; value: fixstr of length 4
"pi": 3.14,A2 70 69 CB 40 09 1E B8 51 EB 85 1Fkey: fixstr of length 2; value: float 64 (IEEE 754, big-endian)
"tags": [A4 74 61 67 73 92key: fixstr of length 4; value: fixarray with 2 elements
"a",A1 61fixstr of length 1
"b"A1 62fixstr of length 1
]no end marker: the element count was given up front
}no end marker: the member count was given up front
+ ## Serialization The library uses the following mapping from JSON values types to MessagePack types according to the MessagePack @@ -91,41 +124,6 @@ specification: --8<-- "examples/to_msgpack.output" ``` - - - - -### Byte layout - -Consider the following JSON value (shown formatted for readability): - -```json -{ - "id": 300, - "name": "json", - "pi": 3.14, - "tags": [ - "a", - "b" - ] -} -``` - -`to_msgpack` encodes it to 39 bytes (shown in hexadecimal; the encoding contains no whitespace). The colors mark the role of each byte: type/marker length/count/size data. - -
- - - - - - - - - - -
JSONBytesMeaning
{84map with 4 key/value pairs
"id": 300,A2 69 64 CD 01 2Ckey: fixstr of length 2, then its UTF-8 bytes; value: uint 16 (big-endian)
"name": "json",A4 6E 61 6D 65 A4 6A 73 6F 6Ekey: fixstr of length 4; value: fixstr of length 4
"pi": 3.14,A2 70 69 CB 40 09 1E B8 51 EB 85 1Fkey: fixstr of length 2; value: float 64 (IEEE 754, big-endian)
"tags": [A4 74 61 67 73 92key: fixstr of length 4; value: fixarray with 2 elements
"a",A1 61fixstr of length 1
"b"A1 62fixstr of length 1
]no end marker: the element count was given up front
}no end marker: the member count was given up front
- ## Deserialization The library maps MessagePack types to JSON value types as follows: diff --git a/docs/mkdocs/docs/features/binary_formats/ubjson.md b/docs/mkdocs/docs/features/binary_formats/ubjson.md index 6b7973627..ba12ee4f6 100644 --- a/docs/mkdocs/docs/features/binary_formats/ubjson.md +++ b/docs/mkdocs/docs/features/binary_formats/ubjson.md @@ -7,6 +7,39 @@ achieve the generality of JSON, combined with being much easier to process than - [UBJSON Website](http://ubjson.org) +## Byte layout + +UBJSON is built from just a one-byte, human-readable ASCII *type marker* (for example, `i` for int8, `S` for string, `[` for array) followed by the payload of that type. Strings and the like are prefixed with their length, which is itself a UBJSON integer value including its marker. Numbers are stored in big-endian byte order. Containers can be written in two ways: as an *unoptimized* container that is opened with `[` or `{` and closed with `]` or `}`, or as an *optimized* container that declares an element type (`$`) and/or a count (`#`) after the opening marker, which saves per-element markers and (for a count) the closing marker. + +Consider the following JSON value (shown formatted for readability): + +```json +{ + "id": 300, + "name": "json", + "pi": 3.14, + "tags": [ + "a", + "b" + ] +} +``` + +`to_ubjson` encodes it to 51 bytes (shown in hexadecimal; the encoding contains no whitespace). The colors mark the role of each byte: type/marker length/count/size data. + +
+ + + + + + + + + + +
JSONBytesMeaning
{7Bobject start ({)
"id": 300,69 02 69 64 49 01 2Ckey: length 2 as int8 (i), then UTF-8 bytes; value: int16 (I), big-endian
"name": "json",69 04 6E 61 6D 65 53 69 04 6A 73 6F 6Ekey: length 4; value: string (S), length 4 as int8, UTF-8 bytes
"pi": 3.14,69 02 70 69 44 40 09 1E B8 51 EB 85 1Fkey: length 2; value: float64 (D), big-endian
"tags": [69 04 74 61 67 73 5Bkey: length 4; value: array start ([)
"a",53 69 01 61string, length 1
"b"53 69 01 62string, length 1
]5Darray end (])
}7Dobject end (})
+ ## Serialization The library uses the following mapping from JSON values types to UBJSON types according to the UBJSON specification: @@ -103,41 +136,6 @@ The library uses the following mapping from JSON values types to UBJSON types ac --8<-- "examples/to_ubjson.output" ``` - - - - -### Byte layout - -Consider the following JSON value (shown formatted for readability): - -```json -{ - "id": 300, - "name": "json", - "pi": 3.14, - "tags": [ - "a", - "b" - ] -} -``` - -`to_ubjson` encodes it to 51 bytes (shown in hexadecimal; the encoding contains no whitespace). The colors mark the role of each byte: type/marker length/count/size data. - -
- - - - - - - - - - -
JSONBytesMeaning
{7Bobject start ({)
"id": 300,69 02 69 64 49 01 2Ckey: length 2 as int8 (i), then UTF-8 bytes; value: int16 (I), big-endian
"name": "json",69 04 6E 61 6D 65 53 69 04 6A 73 6F 6Ekey: length 4; value: string (S), length 4 as int8, UTF-8 bytes
"pi": 3.14,69 02 70 69 44 40 09 1E B8 51 EB 85 1Fkey: length 2; value: float64 (D), big-endian
"tags": [69 04 74 61 67 73 5Bkey: length 4; value: array start ([)
"a",53 69 01 61string, length 1
"b"53 69 01 62string, length 1
]5Darray end (])
}7Dobject end (})
- ## Deserialization The library maps UBJSON types to JSON value types as follows: diff --git a/docs/mkdocs/includes/glossary.md b/docs/mkdocs/includes/glossary.md index 86fbe313e..b84567b14 100644 --- a/docs/mkdocs/includes/glossary.md +++ b/docs/mkdocs/includes/glossary.md @@ -1,5 +1,7 @@ +*[AArch64]: 64-bit execution state of the Arm architecture +*[ABI]: Application Binary Interface *[ADL]: Argument-dependent lookup *[API]: Application Programming Interface *[ASCII]: American Standard Code for Information Interchange @@ -10,28 +12,51 @@ *[CBOR]: Concise Binary Object Representation *[CC0]: Creative Commons Zero *[CI]: Continuous Integration +*[CPU]: Central Processing Unit +*[CUDA]: Compute Unified Device Architecture +*[CVE]: Common Vulnerabilities and Exposures *[DOM]: Document Object Model *[EOF]: End of File *[FAQ]: Frequently Asked Questions *[GCC]: GNU Compiler Collection +*[GDB]: GNU Debugger +*[GiB]: Gibibyte (2^30 bytes) *[HTTP]: Hypertext Transfer Protocol *[ICC]: Intel C++ Compiler +*[IDE]: Integrated Development Environment *[IEEE]: Institute of Electrical and Electronics Engineers *[ISO]: International Organization for Standardization +*[IWYU]: Include What You Use *[JSON]: JavaScript Object Notation +*[JSONC]: JSON with Comments +*[JWCC]: JSON With Commas and Comments +*[LLDB]: LLVM Debugger +*[LTS]: Long-Term Support +*[MinGW]: Minimalist GNU for Windows *[MIT]: Massachusetts Institute of Technology -*[MSVC]: Microsoft Visual C++ *[MsgPack]: MessagePack +*[MSVC]: Microsoft Visual C++ +*[NaN]: Not a Number *[NASA]: National Aeronautics and Space Administration *[NDK]: Native Development Kit -*[NaN]: Not a Number +*[NEON]: Arm SIMD instruction set extension +*[NUL]: Null character (U+0000, byte value 0) +*[ODR]: One Definition Rule +*[REUSE]: Software licensing specification by the Free Software Foundation Europe *[RFC]: Request for Comments *[RTTI]: Runtime Type Information *[SAX]: Simple API for XML *[SDK]: Software Development Kit *[SFINAE]: Substitution failure is not an error +*[SGX]: Software Guard Extensions *[SHA]: Secure Hash Algorithm +*[SIMD]: Single Instruction, Multiple Data *[SPDX]: Software Package Data Exchange +*[SSE2]: Streaming SIMD Extensions 2 +*[SSSE3]: Supplemental Streaming SIMD Extensions 3 *[STL]: Standard Template Library *[UBJSON]: Universal Binary JSON +*[UDL]: User-defined literal +*[UDLs]: User-defined literals +*[URL]: Uniform Resource Locator *[UTF]: Unicode Transformation Format