[HN Gopher] From XML to JSON to CBOR
___________________________________________________________________
From XML to JSON to CBOR
Author : GarethX
Score : 68 points
Date : 2025-07-30 10:31 UTC (12 hours ago)
(HTM) web link (cborbook.com)
(TXT) w3m dump (cborbook.com)
| fjfaase wrote:
| This is a link to just one section of a larger book. The next
| section compare CBOR with a number of other binary storage
| format, such as protobuf.
| brookst wrote:
| Odd that the XML and JSON sections show examples of the format,
| but CBOR doesn't. I'm left with no idea what it looks like, other
| than "building on JSON's key/value format".
| account-5 wrote:
| I'm assuming, since it's a binary encoded, the textual output
| would not be something you'd like to look at.
| sam_lowry_ wrote:
| People look at TCP packets all the time.
| account-5 wrote:
| In which format? As a list of 1s and 0s; in hex? TCP or IP
| if I just pasted the textual version of any binary data id
| captured without some form of conversion it's not good to
| look at. Especially if it's not accompanied by the encoding
| schema so you can actually make sense of it.
| brookst wrote:
| The encoding schema are also present for XML and JSON,
| but not CBOR, so yes, that's another gap if the book is
| intended for a technical audience.
| brookst wrote:
| Why? I'm comfortable reading 0x48 0x65 0x78 0x61 0x64 0x65
| 0x63 0x69 0x6D 0x61 0x6C
| 8n4vidtmkvmk wrote:
| With a table explaining what the byte codes mean? Absolutely
| I want to see that.
| cbm-vic-20 wrote:
| There's an example in the "Putting it Together" section,
| showing JSON, a "human readable" representation of CBOR, and
| the hexidecimal bytes of CBOR.
|
| https://cborbook.com/part_1/practical_introduction_to_cbor.h...
| zbendefy wrote:
| How different is CBOR compared to BSON? Both seem to be binary
| json-like representations.
|
| Edit: BSON seems to contain more data types than JSON, and as
| such it is more complex, whereas CBOR doesn't add to JSON's
| existing structure.
| EdSchouten wrote:
| That's not entirely true: with CBOR you can add custom data
| types through custom tags. A central registry of them is here:
|
| https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml
|
| This is, for example, used by IPLD (https://ipld.io) to express
| references between objects through native types
| (https://github.com/ipld/cid-cbor/).
| maxbond wrote:
| I think parsing BSON is simpler than parsing JSON, BSON has
| additional types but the top level is always a document.
| Whereas the following are all valid JSON:
|
| - `null`
|
| - `"hello"`
|
| - `[1,2,NaN]`
|
| Additionally, BSON will just tell you what the type of a field
| is. JSON requires inferring it.
| zokier wrote:
| NaN is not part of JSON by any spec. Top level scalar values
| were disallowed by RFC 4627.
| maxbond wrote:
| Fair enough. I'm not sure how much JSON parsers in the wild
| care about that spec. I just tried with Python and it was
| happy to accept scalars and NaN. JavaScript rejected NaN
| but was happy to accept a scalar. But sure, compliant
| parsers can disregard those cases.
| mrbluecoat wrote:
| Feels like a CBOR ad to me. I agree that most techs are familiar
| with XML and JSON, but calling CBOR a "pivotal data format" is a
| stretch compared to Protobuf, Parquet, Avro, Cap'n Proto, and
| many others: https://en.m.wikipedia.org/wiki/Comparison_of_data-
| serializa...
| ognyankulev wrote:
| The fact that the long article misses to make the
| historical/continuation link to MessagePack is by itself a red
| flag signalling a CBOR ad.
|
| Edit: OK, actually there is a separate page for alternatives:
| https://cborbook.com/introduction/cbor_vs_the_other_guys.htm...
| mikepurvis wrote:
| Notably missing is a comparison to Cap'n Proto, which to me
| feels like the best set of tradeoffs for more binary
| interchange needs.
|
| I honestly wonder sometimes if it's held back by the name-- I
| love the campiness of it, but I feel like it could be a
| barrier to being taken seriously in some environments.
| kentonv wrote:
| > I feel like it could be a barrier to being taken
| seriously in some environments.
|
| Working as intended. ;)
| stronglikedan wrote:
| man I love HN lol
| kentonv wrote:
| In all seriousness: I develop Cap'n Proto to serve my own
| projects that use it, such at the Cloudflare Workers
| runtime. It is actually not my goal to see Cap'n Proto
| itself adopted widely. I mean, don't get me wrong, it'd
| be cool, but it isn't really a net benefit to me
| personally: _maybe_ people will contribute useful
| features, but mostly they will probably just want me to
| review their PRs adding features I don 't care about, or
| worse, demand I fix things I don't care about, and that's
| just unpaid labor for me. So mostly I'm happy with them
| _not_.
|
| It's entirely possible that this will change in the
| future: like maybe we'll decide that Cap'n Proto should
| be a public-facing part of the Cloudflare Workers
| platform (rather than just an implementation detail, as
| it is today), in which case adoption would then benefit
| Workers and thus me. At the moment, though, that's not
| the plan.
|
| In any case, if there's some company that fancies
| themselves Too Serious to use a technology with such a
| silly name and web site, I am perfectly happy for them to
| not use it! :)
| mikepurvis wrote:
| Ha, I wondered if you'd comment. Yeah that's a reasonable
| take.
|
| I think for me it would be less about locking out stodgy,
| boring companies, and perhaps instead it being an issue
| for emerging platforms that are themselves concerned with
| the optics of being "taken seriously". I'm specifically
| in the robotics space, and over the past ten years ROS
| has been basically rewritten to be based around DDS, and
| I know during the evaluation process for that there were
| prototypes kicked around that would have been more
| webtech type stuff, things like 0mq, protobufs, etc. In
| the end the decision for DDS was made on technical
| merits, but I still suspect that it being a thing that
| had preexisting traction in aerospace and especially NASA
| influenced that.
| aidenn0 wrote:
| Doesn't Cap'n Proto require the receiver to know the types
| for proper decoding? This wouldn't entirely disqualify it
| from comparison, since e.g. protobufs are that way as well,
| but they make it less interesting for comparing to CBOR,
| which is type-tagged.
| e_y_ wrote:
| There's quite a few formats that are self-describing
| already, so having a format that can skip the type and
| key tagging for that extra little bit of compactness and
| decoding efficiency is a unique selling point.
|
| There's also nothing stopping you from serializing
| unstructured data using an array of key/value structs,
| with a union for the value to allow for different value
| types (int/float/string/object/etc), although it probably
| wouldn't be as efficient as something like CBOR for that
| purpose. It could make sense if most of the data is well-
| defined but you want to add additional
| properties/metadata.
|
| Many languages take unstructured data like JSON and parse
| them into a strongly-typed class (throwing validation
| errors if it doesn't map correctly) anyways, so having a
| predefined schema is not entirely a bad thing. It does
| make you think a bit harder about backwards-compatibility
| and versioning. It also probably works better when you
| own the code for both the sender and receiver, rather
| than for a format that anyone can use.
|
| Finally, maybe not a practical thing and something that
| I've never seen used in practice: in theory you could
| send a copy of the schema definition as a preamble to the
| data. If you're sending 10000 records and they all have
| the same fields in the same order, why waste bits/bytes
| tagging the key name and type for every record, when you
| could send a header describing the struct layout. Or if
| it's a large schema, you could request it from the server
| on demand, using an id/version/hash to check if you
| already have it.
|
| In practice though, 1) you probably need to map the
| unknown/foreign schema into your own objects anyways, and
| 2) most people would just zlib compress the stream to get
| rid of repeated key names and call it a day. But the
| optimizer in me says why burn all those CPU cycles
| decompressing and decoding the same field names over and
| over. CBOR could have easily added optional support for a
| dictionary of key strings to the header, for applications
| where the keys are known ahead of time, for example. (My
| guess is that they didn't because it would be harder for
| extremely-resource-constrained microcontrollers to
| implement).
| abrookewood wrote:
| Have to agree. I've heard of every format you mentioned, but
| never heard of CBOR.
| pelagicAustral wrote:
| I first heard of it while developing a QR code travel
| passport during the Covid era... the technical specification
| included CBOR as part of the implementation requirement. Past
| this, I have not crossed path with it again...
| f_devd wrote:
| I would agree their claim is a bit early, but I think a key
| difference between those you mentioned and CBOR is the
| stability expectation. Protobuf/Parquet/etc are usually single-
| source libraries/frameworks, which can be changed quite
| quickly, while CBOR seems to be going for a spec-first
| approach.
| darthrupert wrote:
| CBOR is just a standard data format. Why would it need an ad?
| What are they selling here?
| Retr0id wrote:
| A lot of people (myself included) are working on tools and
| protocols that interoperate via CBOR. Nobody is selling CBOR
| itself, but I for one have a vested interest in promoting
| CBOR adoption (which makes it sound nefarious but in reality
| I just think it's a neat format, when you add
| canonicalization).
|
| CBOR isn't special here, similar incentives could apply to
| just about any format - but JSON for example is already so
| ubiquitous that nobody needs to promote it.
| 8n4vidtmkvmk wrote:
| If I adopt a technology, I probably don't want it to die out.
| Widespread support is generally good for all that use it.
| naikrovek wrote:
| people are just straight up afraid to write their own binary
| formats, aren't they.
|
| it's not hard, it's exactly like creating your own text format
| but you write binary data instead of text, and you can't read it
| with your eyes right away (but you can after you've looked at
| enough of it.) there is nothing to fear or to even worry about;
| just try it. look up how things like TLV work on wikipedia. you
| can do just about anything you would ever need with plain binary
| TLV and it's gonna perform like you wouldn't believe.
|
| https://en.wikipedia.org/wiki/Type%E2%80%93length%E2%80%93va...
|
| binary formats are always going to be 1-2 orders of magnitude
| faster than plain text formats, no matter which plain text format
| you're using. writing a viewer so you can easily read the data
| isn't zero-effort like it is for JSON or XML where any existing
| text editor will do, but it's not exactly hard, either. your
| binary format reading code is the core of what that viewer would
| be.
|
| once you write and use your own binary format, existing binary
| formats you come across become a lot less opaque, and it starts
| to feel like you're developing a mild superpower.
| hvb2 wrote:
| I assume you mean as an exercise? Not for actual use in any
| production system?
|
| If you did mean for production use, I assume you also implement
| your own encryption, encoding schemes and everything else?
| naikrovek wrote:
| i write my own binary formats because they're fast and small.
| yes, in production. partly because it's just as easy as
| anything else for me now, partly because it doesn't require
| any dependencies at all, and partly to show others just how
| easy it is, because i think people are unnecessarily afraid
| of this.
|
| no i don't write my own encoding or encryption.
|
| why the _hell_ would anyone use json for everything, and why
| would someone who doesn 't do that earn your derision?
| hvb2 wrote:
| I didn't say anywhere that we should use json for
| everything.
|
| I think most people would go with something standard and
| documented. If you work in a team it helps if you can hire
| people that are familiar with tech or can read up on it
| easily.
|
| And in general, unless you can show that your formatter is
| an actual hot path in need of optimization, you've just
| added another piece of code in need of care and feeding for
| no real gain.
|
| Most devs/applications are fine with protobuf or even Json
| performance. And solving that problem is not something they
| can or should do.
|
| If you write something like that just to prove a point,
| good for you. Also I would never want to be on the same
| team
| markisus wrote:
| CBOR has some stuff that is nice but would be annoying to
| reimplement. Like using more bytes to store large numbers than
| small ones. If you need a quick multipurpose binary format,
| CBOR is pretty good. The only alternative I'd make manually is
| just memcpy the bytes of a C struct directly to disk and hope
| that I won't encounter a system with different endianness.
| neutrinobro wrote:
| These days you don't have to worry about endianness much
| (unless you dealing with raw network packets). However, you
| do need to worry about byte-padding. Different
| compilers/systems will place byte padding between items in
| your struct differently (depending on the contents and
| ordering of items), and if you are not careful the in-memory
| or on-disk placement of struct data elements can be
| misaligned on different systems. Most systems align to a
| 8-byte boundary, but that isn't guaranteed.
| darthrupert wrote:
| CBOR has always seemed to me like the most promising data format
| for efficient data transfer. Somewhat weird how little use it
| has.
| otterley wrote:
| AWS is beginning to support it, starting with certain data-
| heavy APIs: https://aws.amazon.com/about-aws/whats-
| new/2025/07/amazon-cl...
| nabla9 wrote:
| CBOR is when you need option for very small code size. If you can
| always use compression, CBOR provides no significant data size
| improvement over JSON.
|
| With small code size it beats also BSON, EBML and others.
| surajrmal wrote:
| Or compute. Compression isn't free, especially on power
| constrained devices. At scale power and compute also have real
| cost implications. Most data centers have long been using
| binary encoding formats such as protobuf to save on compute and
| network bandwidth. cbor is nice because it's self describing so
| you can still understand it without a schema, which is a nice
| property people like about json.
| 8n4vidtmkvmk wrote:
| Doesn't capn proto win hands down on compute?
|
| I haven't used it, but I thought that was the big claim.
| kentonv wrote:
| Not necessarily.
|
| Cap'n Proto serialization can be a huge win in terms of
| compute _if_ you are communicating using shared memory or
| reading huge mmaped files, especially if the reader only
| cares to read some random subset of the message but not the
| whole thing.
|
| But in the common use case of sending messages over a
| network, Cap'n Proto probably isn't a huge difference.
| Pushing the message through a socket is still O(n), and the
| benefits of compression might outweigh the CPU cost.
| (Though at least with Cap'n Proto, you have the _option_ to
| skip compression. Most formats have some amount of
| compression baked into the serialization itself.)
|
| Note that benchmarks vary _wildly_ depending on the use
| case and the type of data being sent, so it 's not really
| possible to say "Well it's N% faster"... it really depends.
| Sometimes Protobuf wins! You have to test your use case.
| But most people don't have time to build their code both
| ways to compare.
|
| I actually think Cap'n Proto's biggest wins are in the RPC
| system, not the serialization. But these wins are much
| harder to explain, because it's not about speed, but
| instead expressiveness. It's really hard to understand the
| benefits of using a more expressive language until you've
| really tried it.
|
| (I'm the author of Cap'n Proto.)
| Zardoz84 wrote:
| gzip, deflate, brotli ?
| gethly wrote:
| I wish browsers would support CBOR natively so I could just
| return CBOR instead of JSON(++speed --size ==win) and not have to
| be concerned with decoding it or not being able to debug requests
| in dev console.
| dylan604 wrote:
| JSON + compression (++speed --size ==win)
|
| your server can do this natively for live data. your browser
| can decompress natively. and ++human-readable. if you're one of
| those that doesn't want the user to read the data, then maybe
| CBOR is attractive??? but why would you send data down the wire
| that you don't want the user to see? isn't the point of sending
| the data to the client is so the client can display that data?
| 8n4vidtmkvmk wrote:
| It's still not attractive to hide data from the user. Unless
| it's encrypted, the user can read it.
| dylan604 wrote:
| i think i'm using a different meaning of "seeing". to the
| user, it won't be plain text that is human readable.
| unencrypted CBOR byte data might as well be encrypted to
| the end user.
| gethly wrote:
| That is true. Basic content encoding works very well with
| json but that still means there is the compression step,
| which would not be necessary with CBOR as it is already a
| binary payload. It would allow faster response and delivery
| times natively. Of course, we are talking few ms, but I say
| why leave those ms on the floor?
|
| I guess i'm just shouting at the clouds :D
| makapuf wrote:
| ASN.1 while complex has really seems to be a step up from those
| (even if older) in terms of terseness (as binary encoding) and
| generality.
| jabl wrote:
| Yes, but that comes from the telecom world. Hence thanks to
| NIH, that wheel must be reinvented.
| kookamamie wrote:
| The article reads like a semi-slop with its numerous lists and
| overly long explanations of obvious things, such as how XML came
| to be.
| Jean-Papoulos wrote:
| Obligatory https://xkcd.com/927/
| glenjamin wrote:
| The only mention I can see in this document of compression is
|
| > Significantly smaller than JSON without complex compression
|
| Although compression of JSON could be considered complex, it's
| also extremely simple in that it's widely used and usually
| performed in a distinct step - often transparently to a user.
| Gzip, and increasingly zstd are widely used.
|
| I'd be interested to see a comparison between compressed JSON and
| CBOR, I'm quite surprised that this hasn't been included.
| dylan604 wrote:
| > I'm quite surprised that this hasn't been included.
|
| Why? That goes against the narrative of promoting one over the
| other. Nissan doesn't advertise that a Toyota has something
| they don't. They just pretend it doesn't exist.
| JimDabell wrote:
| Previously:
|
| CBOR - Concise Binary Object Representation -
| https://news.ycombinator.com/item?id=20603378 - Aug 2019 (71
| comments)
|
| Begrudgingly Choosing CBOR over MessagePack -
| https://news.ycombinator.com/item?id=43229259 - Mar 2025 (78
| comments)
| _the_inflator wrote:
| Love or hate JSON, the beauty and utility stem from the fact that
| you have only the fundamental datatypes as a requirement, and
| that's it.
|
| Structured data that, by nesting, pleases the human eye, reduced
| to the max in a key-value fashion, pure minimalism.
|
| And while you have to write type converters all the time for
| datetime, BLOBs etc., these converters are the real reasons why
| JSON is so useful: every OS or framework provides the heavy
| lifting for it.
|
| So any elaborated new silver bullet would require solving the
| converter/mapper problem, which it can't.
|
| And you can complain or explain with JSON: "Comments not a
| feature?! WTF!" - Add a field with the key "comment"
|
| Some smart guys went the extra mile and nevertheless demanded
| more, because wouldn't it be nice to have some sort of "strict
| JSON"? JSON schema was born.
|
| And here you can visibly experience the inner conflict of "on the
| one hand" vs "on the other hand". Applying schemas to JSON is a
| good cause and reasonable, but guess what happens to JSON? It
| looks like unreadable bloat, which means XML.
|
| Extensibility is fine, basic operations appeal to both demands,
| simple and sophisticated, and don't impose the sophistication on
| you just for a simple 3-field exchange about dog food
| preferences.
| sevensor wrote:
| My complaint about JSON is that it's not minimal enough. The
| receiver always has to validate anyway, so what has syntax
| typing done for us? Different implementations of JSON disagree
| about what constitutes a valid value. For instance, is
| {"x": NaN}
|
| valid JSON? How about 9007199254740993? Or -.053? If so, will
| that text round trip through your JSON library without loss of
| precision? Is that desirable if it does?
|
| Basically I think formats with syntax typed primitives always
| run into this problem: even if the encoder and decoder are
| consistent with each other about what the values are, the
| receiver still has to decide whether it can use the result.
| This after all is the main benefit of a library like Pydantic.
| But if we're doing all this work to make sure the object is
| correct, we know what the value types are supposed to be on the
| receiving end, so why are we making a needlessly complex
| decoder guess for us?
| aidenn0 wrote:
| NaN is _not_ a valid value in JSON. Neither are 0123 or .123
| (there must always be at least one digit before the decimal
| marker, but extraneous leading zeroes are disallowed).
|
| JSON was originally parsed in javascript with eval() which
| allowed many things that aren't JSON through, but that
| doesn't make JSON more complex.
| sevensor wrote:
| That's my point, though! I've run into popular JSON
| libraries that will emit all of those! 9007199254740993 is
| problematic because it's not representable as a 64 bit
| float. Python's JSON library is happy to write it, even
| though you need an int to represent it, and JSON doesn't
| have ints.
|
| Edit: I didn't see my thought all the way through here.
| Syntax typing invites this kind of nonconformity, because
| different programming languages mean different things by
| "number," "string," "date," or even "null." They will bend
| the format to match their own semantics, resulting in
| incompatibility.
| camgunz wrote:
| Oh good, another CBOR thread. Disclaimer: I wrote and maintain a
| MessagePack implementation. I've also bird dogged this for a
| while, HN search me.
|
| Mostly, I just want to offer a gentle critique of this book's
| comparison with MessagePack [0].
|
| > Encoding Details: CBOR supports indefinite-length arrays and
| maps (beneficial for streaming when total size is unknown), while
| MessagePack typically requires fixed collection counts.
|
| This refers to CBOR's indefinite length types, but awkwardly,
| streaming is a protocol level feature, not a data format level
| feature. As a result, there's many better options, ranging from
| "use HTTP" to "simply send more than 1 message". Crucially, CBOR
| provides no facility for re-syncing a stream in the event of an
| error, whether that's network or simply a bad encoding. "More
| features" is not necessarily better.
|
| > Standardization: CBOR is a formal IETF standard (RFC 8949)
| developed through consensus, whereas MessagePack uses a
| community-maintained specification. Many view CBOR as a more
| rigorous standard inspired by MessagePack.
|
| Well, CBOR _is MessagePack_. Carsten Bormann forked MessagePack,
| changed some of the tag values, wrote a standard around it, and
| submitted it to the IETF against the wishes of MessagePack 's
| creators.
|
| > Extensibility: CBOR employs a standardized semantic tag system
| with an IANA registry for extended types (dates, URIs, bignums).
| MessagePack uses a simpler but less structured ext type where
| applications define tag meanings.
|
| Warning: I have a big rant about the tag registry.
|
| The facilities are the same (well, the tag is 8 bytes instead of
| 1 byte, but w/e); it's TLV all the way down (Bormann ripped this
| also). Bormann's contribution is the registry, which is bonkers
| [1]. There's... dozens of extensions there? Hundreds? No CBOR
| implementation supports anywhere near all this stuff. "Universal
| Geographical Area Description (GAD) description of velocity"?
| "ur:request, Transaction Request identifier"?
|
| The registry isn't useful. Here are the possible scenarios:
|
| If something is in high demand and has good support across
| platforms, then it's a no-brainer to reserve a tag. MP does this
| with timestamps.
|
| If something is in high demand, but doesn't have good support
| across platforms, then you're putting extra burden on those
| platforms. Ex: it's not great if my tiny microcontroller now has
| to support bignums or 128-bit UUIDs. Maybe you do that, or you
| make them optional, but that leads us to...
|
| If something isn't in high demand or can't easily be supported
| across platforms, but you want support for it anyway, there's no
| need to tell anyone else you're using that thing. You can just
| use it. That's MP's ext types.
|
| CBOR seems to imagine that there's a hypothetical general purpose
| decoder out there that you can point to any CBOR API, but there
| isn't and there never will be. Nothing will support both "Used to
| mark pointers in PSA Crypto API IPC implementation" and
| "PlatformV_HAS_PROPERTY" (I just cannot get over this stuff).
| There is no world where you tell the IETF about your tags, define
| an API with them, and someone completely independently builds a
| decoder for them. It will always be a person who cares about your
| specific tags, in which case, why not just agree on the ext types
| ahead of time? A COSE decoder doesn't need also need to decode a
| "RAINS Message".
|
| > Performance and Size: Comparisons vary by implementation and
| data. CBOR prioritizes small codec size (for constrained devices)
| alongside message compactness, while MessagePack focuses
| primarily on message size and speed.
|
| I can't say I fully understand what this means, but CBOR and MP
| are equivalent here, because CBOR is MP.
|
| > Conceptual Simplicity: MessagePack's shorter specification
| appears simpler, but CBOR's unification of types under its major
| type/additional info system and tag mechanism offers conceptual
| clarity.
|
| Even if there's some subjectivity around "conceptual
| simplicity/clarity", again CBOR and MP are equivalent here
| because they're functionally the same format.
|
| ---
|
| I have some notes about the blurb above too:
|
| > MessagePack delivers greater efficiency than JSON
|
| I think it's probably true that the fastest JSON
| encoders/decoders are faster than the fastest MP
| encoders/decoders. Not that JSON performance has a higher
| ceiling, but it's got gazillions of engineering hours poured into
| it, and rightly so. JSON is also usually compressed, so space
| benefits only matter at the perimeters. I'm not saying there's no
| case for MP/CBOR/etc., just that the efficienty/etc. gap is a lot
| smaller than one would predict.
|
| > However, MessagePack sacrifices human-readability
|
| This, of course, applies to CBOR as well.
|
| > ext mechanism provides less structure than CBOR's IANA-
| registered tags
|
| Again the mechanism is the same, only the registry is different.
|
| [0]:
| https://cborbook.com/introduction/cbor_vs_the_other_guys.htm...
|
| [1]: https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml
| aidenn0 wrote:
| > ...awkwardly, streaming is a protocol level feature, not a
| data format level feature.
|
| Indeed. I recall that tnetstrings were intentionally made non-
| streamable to discourage people from trying to do so: "If you
| need to send 1000 DVDs, don't try to encode them in 1
| tnetstring payload, instead send them as a sequence of
| tnetstrings as payload chunks with checks and headers like most
| other protocols"
|
| > Warning: I have a big rant about the tag registry. > ...
|
| I completely agree with your rant w.r.t. automated decoding.
| However, a global tag registry can still potentially be useful
| in that, given CBOR encoded data with a tag that my decoder
| doesn't support, it may be easier for a human to infer the
| intended meaning. Some types may be very obvious, others less
| so.
|
| e.g. Standardized MIME types are useful even if no application
| supports every one of them.
| johnisgood wrote:
| Erlang / Elixir has amazing support for ASN.1! I love it.
|
| https://www.erlang.org/doc/apps/asn1/asn1_getting_started.ht...
|
| https://www2.erlang.org/documentation/doc-14/lib/asn1-5.1/do...
| (https://www2.erlang.org/documentation/doc-14/lib/asn1-5.1/do...)
|
| I am using ASN.1 to communicate between a client (Java / Kotlin)
| and server (Erlang / Elixir), but unfortunately Java / Kotlin has
| somewhat of a shitty support for ASN.1 in comparison to Erlang.
| aidenn0 wrote:
| I admit I got nerd-sniped here, but the table for floats[1]
| suggests that 10000.0 be represented as a float32. However, isn't
| it exactly representable as 0x70e2 in float16[2]? There are only
| 10 significant bits to the mantissa (including the implicit 1),
| while float16 has 11 so there's even an extra bit to spare.
|
| 1:
| https://cborbook.com/part_1/practical_introduction_to_cbor.h...
|
| 2: i.e. 1.220703125x213
| dang wrote:
| Related. Others?
|
| _Begrudgingly Choosing CBOR over MessagePack_ -
| https://news.ycombinator.com/item?id=43229259 - March 2025 (78
| comments)
|
| _MessagePack vs. CBOR (RFC7049)_ -
| https://news.ycombinator.com/item?id=23838565 - July 2020 (2
| comments)
|
| _CBOR - Concise Binary Object Representation_ -
| https://news.ycombinator.com/item?id=20603378 - Aug 2019 (71
| comments)
|
| _CBOR - Concise Binary Object Representation_ -
| https://news.ycombinator.com/item?id=10995726 - Jan 2016 (36
| comments)
|
| _Libcbor - CBOR implementation for C and others_ -
| https://news.ycombinator.com/item?id=9597198 - May 2015 (5
| comments)
|
| _CBOR - A new object encoding format_ -
| https://news.ycombinator.com/item?id=6932089 - Dec 2013 (9
| comments)
|
| _RFC 7049 - Concise Binary Object Representation (CBOR)_ -
| https://news.ycombinator.com/item?id=6632576 - Oct 2013 (52
| comments)
| JoelJacobson wrote:
| Fun fact: CBOR is used within the WebAuthn (Passkey) protocol.
|
| To do Passkey-verification server-side, I had to implement a
| pure-SQL/PLpgSQL CBOR parser, out of fear that a C-implementation
| could crash the PostgreSQL server: https://github.com/truthly/pg-
| cbor
| teatro wrote:
| That's why I'm wondering if there is an actual CBOR encoder in
| the browsers? I mean, there must be one, or am I wrong?
___________________________________________________________________
(page generated 2025-07-30 23:01 UTC)