Cart
[Home] [By Thread] [By Date] [Recent Entries]
Rich Salz wrote:
>> Hmmm... BER is the simplest to implement, though, and it's not THAT
>> bad on the compactness front.
>
> Simplest for writers, maybe, but certainly hardest for readers.
No way! You can write a generic BER parser in... in... well, asndecode
is a 13KB binary under Linux, split down as:
text data bss dec hex filename
6272 220 4 6496 1960 asndecode
6KB of actual code, then, it would appear, and the rest being ELF overhead.
The generic BER reader goes something like:
1) Read a byte from the stream
2) Examine the lower 4 or so bits of the byte that indicate the type
code (string, integer, sequence, OID, etc)
3) Invoke the code for that type; in the case of sequences this will
recursively call the same code again
Eg, I happen to know off by heart that the three bytes 0x02, 0x01, 0x05
mean:
0x02: HERE BE AN INTEGER; LENGTH BYTE FOLLOWS
0x01: IT BE ONE BYTE LONG
0x05: IT BE THE NUMBER 5
> The
> biggest problem is that there's no unique way of representing a given
> BER stream, so you can't hash it, so you can't digitally sign it. DER
> is C14N for BER. :)
Yes, it is, but that's not a real difficulty in reading. There's no
unique way of representing a given XML document, either; you can add all
sorts of comments and whitespare and reorderings of attributes and so on :-)
A BER decoder is also a DER decoder - DER is just a profile of BER with
all the encoder's options removed!
> /r$
ABS
|
