Deserialisation of maps does not parse string keys to integers

[Timmmm]

This is one of those issues where it's not exactly clear what the correct thing to do is, but I feel like CBOR is mostly used as a compact version of JSON, so I think you should be able to write JSON using serde_json, convert it to CBOR, read it in using serde_cbor and it should give the same result.

This doesn't work for something like HashMap<u32, String>. The only key type that JSON supports is String, so when serde_json reads or writes that type it converts the integers to/from strings. The code to do this is MapKey. serde_cbor doesn't have the same code, presumably because CBOR does support integer keys.

The CBOR authors did consider this issue. The spec has this to say about map keys:

The encoding and decoding applications need to agree on what types of
keys are going to be used in maps. In applications that need to
interwork with JSON-based applications, keys probably should be
limited to UTF-8 strings only; otherwise, there has to be a specified
mapping from the other CBOR types to Unicode characters, and this
often leads to implementation errors. In applications where keys are
numeric in nature and numeric ordering of keys is important to the
application, directly using the numbers for the keys is useful.

If multiple types of keys are to be used, consideration should be
given to how these types would be represented in the specific
programming environments that are to be used. For example, in
JavaScript objects, a key of integer 1 cannot be distinguished from a
key of string "1". This means that, if integer keys are used, the
simultaneous use of string keys that look like numbers needs to be
avoided. Again, this leads to the conclusion that keys should be of
a single CBOR type.