On 10/13/2012 11:21 AM, Peter Levart wrote:
One way to do it without state in encoder is 1st as suggested to have
the 'endOfStream' flag and in addition when new-line breaks are
requested, to only encode "full lines" at each invocation. So If one
wants to use this line-breakage feature he/she must make sure that
there is enough space (line_size+2 at worst) left in destination buffer
...and (forgot to add) enough bytes remaining in source buffer or the
endOfStream==true...
to do any encoding or the encoder will not do anything (return 0 or
false).
Regards, Peter
On 10/12/2012 10:58 PM, Xueming Shen wrote:
Yes, I'm trying to figure out where to have this position info
stored...
On 10/12/2012 01:48 PM, Michael Schierl wrote:
Am 12.10.2012 22:12, schrieb Xueming Shen:
Hi,
It appears to be possible to do something like
boolean de/encode(ByteBuffer src, ByteBuffer dst);
returns true if all remaining bytes in src are en/decoded, false,
the dst
is not big enough for all output bytes, the src.position() will be
advanced
to the position of next un-en/decoded byte, dst.position() will be
updated
accordingly as well.
to avoid the en/decoder to hold an internal state.
If it was unclear, that was what I tried to suggest. I thought you
refered to the automatic adding of newlines when you said you'd need
internal state (although that state is small enough - how many encoded
bytes remaining before adding the next newline - so that it might be
possible to pass it as a parameter, too). I'm not sure how important
that adding of newlines really is (in all cases where I was guilty of
using sun.misc.Base64Encoder, I always replaced them out after
encoding), so maybe the ByteBuffer API could live without it.
Note that without an explicit end of stream flag, it might not be
easily
possible to encode the last block - if you have a 16 byte buffer
with 14
bytes filled, you cannot be sure whether you can encode the last two
bytes to XYZ= because it is end of stream or you have to wait for the
next byte. An option without the flag might be to assume when the input
is less than 3 bytes that it is the end of the stream. But I doubt it
will make the API easier to understand or use. :-)
Regards,
Michael
