Interface EncodeOptions

Encode all integers as floating point numbers of the correct size.

Turn on options for draft-ietf-cbor-cde-05.

Should bigints that can fit into normal integers be collapsed into normal integers?

Turn on options for draft-mcnally-deterministic-cbor-11.

When writing floats, always use the 64-bit version. Often combined with avoidInts.

When writing floats, first flush any subnormal numbers to zero before decising on encoding.

How to write TypedArrays? Null to use the current platform's endian-ness. True to always use little-endian. False to always use big-endian.

Ignore sizes on boxed numbers; they might be overly-large.

Do not encode numbers in the range [CBOR_NEGATIVE_INT_MAX ... STANDARD_NEGATIVE_INT_MAX - 1] as MT 1.

Per dcbor:

"MUST check whether floating point values to be encoded have the numerically equal value in DCBOR_INT = [-2^63, 2^64-1]. If that is the case, it MUST be converted to that numerically equal integer value before encoding it. (Preferred encoding will then ensure the shortest length encoding is used.) If a floating point value has a non-zero fractional part, or an exponent that takes it out of DCBOR_INT, the original floating point value is used for encoding. (Specifically, conversion to a CBOR bignum is never considered.)"

This should only apply to "integers" that are outside the JS safe range of [-(2^53 - 1), 2^53-1].

Do not encode bigints that cannot be reduced to integers.

If true, error instead of encoding an instance of Simple.

Check that Maps do not contain keys that encode to the same bytes as one another. This is possible in a Map with object keys.

Do not encode floating point numbers that cannot be reduced to integers.

If true, error instead of encoding undefined.

If true, encode -0 as 0.

How should the key/value pairs be sorted before an object or Map gets created? If null, no sorting is performed.

If specified, normalize strings on encoding. 'NFD' may optimize for CPU, 'NFC' may optimize for size. Don't use this without Unicode expertise. In particular, the 'K' forms are really unlikely to be useful.

If specified, override how these types are encoded for this call to encode.

Allow non-wellformed strings (strings containing unpaired surrogates) to be encoded as tag 273. This is optional since a) most protocol use cases should use string UTF8 and b) this adds a potentially-slow for large strings check for well-formedness. You may want this if you are storing test inputs or outputs and want to ensure that you have the full range of JS strings as possibilities. Note: I doubt that tag 273 is widely-implemented at this time, so this is another reason you should not use this if you are trying to interoperate.