[
https://issues.apache.org/jira/browse/CODEC-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13232023#comment-13232023
]
Thomas Neidhart commented on CODEC-130:
---------------------------------------
My example was maybe not so clear, but yes that's basically what I think
happens when skipping the underlying stream.
In case you have a 1:1 mapping (1 byte in the underlying stream refers to 1
byte in the filtered stream), it does not matter. For compressing or encoding
streams this may be different, so the skip method has to be adjusted imho.
After looking at the code of InflaterInputStream, I think we can do quite the
same here (and check also other filtered input streams).
> 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
