View Single Post
Old 01-07-2009, 07:03 PM   #49
llasram
Reticulator of Tharn
llasram ought to be getting tired of karma fortunes by now.llasram ought to be getting tired of karma fortunes by now.llasram ought to be getting tired of karma fortunes by now.llasram ought to be getting tired of karma fortunes by now.llasram ought to be getting tired of karma fortunes by now.llasram ought to be getting tired of karma fortunes by now.llasram ought to be getting tired of karma fortunes by now.llasram ought to be getting tired of karma fortunes by now.llasram ought to be getting tired of karma fortunes by now.llasram ought to be getting tired of karma fortunes by now.llasram ought to be getting tired of karma fortunes by now.
 
llasram's Avatar
 
Posts: 618
Karma: 400000
Join Date: Jan 2007
Location: EST
Device: Sony PRS-505
Quote:
Originally Posted by tompe View Post
The extra data flag is set to 0x31 for this file. So the extra characters are probably something from the unpacking of the data. The unpacking does not know about the extra data.
If the '1' bit is set, and there are no actual multibyte characters in the text, then each record will end with a NUL byte indicating 0 overlaping bytes. (Well, unless bits one of bits 4-8 is set on the "size & flags" byte.)

Quote:
Originally Posted by tompe View Post
Concerning multibyte character overlap. How do you know which byte is the size byte?
It's the last byte of that trailing entry.

Quote:
Originally Posted by tompe View Post
Are these characters and the trailing data part of the record size or are they outside the specified record size?
As I understood it, the "record size" was just the distance to the next record. In which case yes, they are part of the record they follow.
llasram is offline   Reply With Quote