On Nov 22, 2003, at 6:46 PM, Peter Gatti wrote:
Ah, I think this is the real reason for my problem. I didn't include
the Encoding parameter because I really don't understand what it is or
why there is even a need for it. In my mind every character in an edit
field has an ASCII number and that's what is being save to a file. And
when I read back the file, I don't expect extra characters thrown in
that presumably defines the following character as being an option key
character... as in the example I gave, '©' where the added character
¬ presumably says something about the © character in my text.
Except that © isn't an ASCII character, so there's no ASCII code that
can be written to the file that is that character. Most likely the
string is UTF8 and that character requires two bytes to represent. It's
amusing that one of the UTF8 bytes happens to itself be © in a
different text encoding. Probably intentional on some level but I think
we should pretend it is just a funny accident.
As for the parameter you pass to Read, it is indeed a byte count, not a
character count. So if you string is in an encoding that requires two
(or more) bytes to indicate some characters, then you aren't writing
the correct number of bytes and when you go to read it you aren't
reading enough bytes back in, which is why things get goofed up. This
*just* came up on the list a few days ago and Joe was quite adamant
that Read takes bytes not characters.
- - -
Unsubscribe or switch delivery mode:
<http://support.realsoftware.com/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
|