Concise Binary Object Representation
(require cbor) | package: cbor |
This library implements serialization and deserialization routines for Concise Binary Object Representation (CBOR), as defined in RFC 8949. The library takes in raw data in the form of Racket data structures, outputting a serialized binary stream, and vice versa.
1 Usage
procedure
(cbor-write config v [out]) → void?
config : cbor-config? v : any/c out : output-port? = (current-output-port)
Integers between -264 and 264 - 1, inclusive
#f and #t
Values equal? to the value of (cbor-config-null-value config)
Lists and vectors of any item accepted by cbor-write
Sequences of any item accepted by cbor-write
Hashes of items accepted by cbor-write (both the key and value)
Instances of cbor-tag
Instances of cbor-simple-value
Values which have an implementation for gen:cbor-custom-write. Note that this is checked last, after all of the above cases.
procedure
config : cbor-config? in : input-port? = (current-input-port)
Major type 0 (unsigned integer) and 1 (negative integer) are decoded as standard Racket integers
Major type 2 (byte string) and 3 (string) are decoded as Racket bytes? and string?, respectively
Major type 4 (list) is decoded as a Racket list? of the contained values
Major type 5 (map) is decoded as a Racket hash-equal? of the contained key-value pairs
Major type 6 (tag) is decoded according to the registered tag deserializers (see cbor-config). If no deserializer is registered, the contents are stored in cbor-tag.
Major type 7, additional data 20, 21, and 23 (false, true, and undefined) are decoded as #f, #t, and undefined, respectively
Major type 7, additional data 22 is decoded as the value of (cbor-config-null-value config)
Major type 7, additional data 25, 26, and 27 (half float, single float, and double float, respectively), are all decoded as Racket flonum?. Note that this library decodes all of these three types to Racket’s double-width floating point type.
Any other item with major type 7 and additional data matching cbor-unassigned-simple-value? is decoded as a cbor-simple-value
2 Configuration Options
struct
(struct cbor-config (tag-deserializers null-value sorted-map-keys) #:extra-constructor-name make-cbor-config) tag-deserializers : (hash/c cbor-valid-tag-number? (-> cbor-valid-tag-number? any/c any/c)) null-value : any/c sorted-map-keys : boolean?
tag-deserializers is a hash from CBOR tag numbers to a procedure that takes the CBOR tag number and a raw data value and produces the meaningful interpretation of that value.
null-value is the value that CBOR null will be encoded and decoded as.
sorted-map-keys determines whether or not map keys should be serialized in sorted order. This only affects encoding; unsorted map keys will still be decoded identically.
value
procedure
(with-cbor-tag-deserializer config id deserializer) → cbor-config? config : cbor-config? id : cbor-valid-tag-number? deserializer : (-> cbor-valid-tag-number? any/c any/c)
procedure
(with-cbor-null-value config v) → cbor-config?
config : cbor-config? v : any/c
procedure
(with-sorted-map-keys config v) → cbor-config?
config : cbor-config? v : boolean?
value
3 Auxiliary Items
procedure
v : any/c
procedure
v : any/c
struct
(struct cbor-tag (number content) #:extra-constructor-name make-cbor-tag) number : cbor-valid-tag-number? content : any/c
struct
(struct cbor-simple-value (inner) #:extra-constructor-name make-cbor-simple-value) inner : cbor-unassigned-simple-value?
4 Bugs
Some functions are currently too lax (indefinite-length objects can be nested in nonconforming ways).
There should be a config or parameter to specify maximum lengths for indefinite-length objects
More correctness-testing is needed.
Some recommended tag and simple values from the RFC are not supported yet.