[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Property objects bug fix
--On Sun, Mar 5, 2000 8:28 PM +0100 Falko Braeutigam
<falko@softwarebuero.de> wrote:
> On Sun, 05 Mar 2000, William Uther wrote:
> [snip - encoding problem]
> A Base64 encode would produce a 7 bit stream but we have 8 bit bytes
> available. Stuffing two bytes in one char should be possible.
[snip - sample code]
> and reverse when decoding. This should prevent the string from being
> encoded using one of Javas encoding styles and it is memory efficient. I
> did not test it yet. Other ideas?
So I was thinking about this some more. You are converting bytes into
chars, storing the chars in a property file, then reading them back in as
chars and converting back to bytes. This expands to the following:
1) bytes into chars (using whatever encoding Ozone uses)
2) chars into bytes (using the default encoding. The happens when the
property file is written out.)
3) bytes into chars AND TRIM (conversion is using the default encoding as
the property file is read back in. The trim is because I believe leading
spaces are ignored in a property file, but I'm not sure. Certainly, if the
string of chars contains '\r' or '\n' then there'll be problems.)
4) chars back into bytes (using whatever encoding Ozone uses)
Disk space: I think we can rely on the default encoding to encode the 0x00
- 0xFF chars efficiently, so I don't think that is a concern. It might be
more of a concern in memory, but I'm not too worried by it.
The advantage of Base64 encoding is that
- it is standard,
- we know it avoids whitespace and other problematic characters.
We could do something fancier, but it is going to have to avoid problem
chars. Also, anything that uses the high-order byte might be encoded
relativly inefficiently using the default encoding. In fact, are the
encodings guaranteed to encode all characters? Or can they skip some?
I'm leaning more and more towards Base64 as it avoids these problems.
later,
\x/ill :-}