MacOS resource data in general is binary data. All byte values from 0x00 to
0xff can be used. As mentioned above, RBL is a text based file format.
So, before storage, the resource data needs to be converted from binary data to
text data.
This conversion scheme is simple yet well suited for our purpose. Suppose you want to
encode a block of n raw data bytes. Step one is to chop the data block into
7 bit wide chunks.
The lower significant 7 bits of the first byte are the first chunk. The highest significant
bit is carried on to the next chunk. All further seven bit
wide chunks are built by taking the carried bits from the previous byte, shifting them to the
right, and filling them on the left to the width of 7 with the lower significant bits of the
current byte. Leftover high significant bits are carried on. This goes on until there are no
data bits left. The high significant bits of the last seven bit chunk (which might consist
of the carried bits only) might stay unused and default to zero.
Now, we have a row of seven bit chunks in the range of 0x00 to 0x7f ---
still binary. Step two is to fold every 7 bit raw data chunk to 8 bit text by adding
0x3f (character '?').
Let's call this data encoding scheme RBL7.
RBL7 encoding is robust to everything CVS might do to it. All RBL7 encoded bytes have codes
equal to or higher than 0x3f (character '?'). The '$' sign does not show up there, so
we're safe agaist CVS keyword substitution. The characters '>', '=', and '<'
don't show up in RBL7 encoded data. Thus, CVS conflict markers can be recognized and do not
interfere with RBL7 encoded data.
If it turns out that using 8 bit text is a problem, the RBL7 conversion can optionally
be replaced by an
analogous RBL6 conversion which groups 6 bit chunks. Doing that results in 7 bit encoded text.
In that case, the file size is getting bigger though. At this moment, only the RBL7
encoding is supported.
|