[
https://issues.apache.org/jira/browse/CODEC-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231614#comment-13231614
]
Gary D. Gregory commented on CODEC-130:
---------------------------------------
Hm. I am almost sold on this. Nice job to all posters for clarifying the
requirements and implementations.
My question is: what do we want to be skipping? underlying bytes or decoded
chars?
InflaterInputStream for example says:
{quote}
* Skips specified number of bytes of uncompressed data.
* @param n the number of bytes to skip
* @return the actual number of bytes skipped.
{quote}
If we do that on a B64 and B32 stream, will skipping underlying bytes risk of
messing up further decoding? Can you prove that it will not?
:)
> Base64InputStream.skip skips underlying stream, not output
> ----------------------------------------------------------
>
> Key: CODEC-130
> URL: https://issues.apache.org/jira/browse/CODEC-130
> Project: Commons Codec
> Issue Type: Bug
> Affects Versions: 1.5
> Reporter: James Pickering
> Priority: Minor
> Attachments: base64snippet.java
>
>
> Base64InputStream.skip() skips within underlying stream, leading to
> unexpected behaviour.
> The following code will reproduce the issue:
> @Test
> public void testSkip() throws Throwable {
> InputStream ins =
> new
> ByteArrayInputStream("AAAA////".getBytes("ISO-8859-1"));//should decode to
> {0, 0, 0, 255, 255, 255}
> Base64InputStream instance = new Base64InputStream(ins);
> assertEquals(3L, instance.skip(3L)); //should skip 3 decoded characters,
> or 4 encoded characters
> assertEquals(255, instance.read()); //Currently returns 3, as it is
> decoding "A/", not "//"
> }
> The following code, if added to Base64InputStream, or (BaseNCodecInputStream
> in the dev build) would resolve the issue:
> @Override
> public long skip(long n) throws IOException {
> //delegate to read()
> long bytesRead = 0;
> while ((bytesRead < n) && (read() != -1)) {
> bytesRead++;
> }
> return bytesRead;
> }
> More efficient code may be possible.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
