[
https://issues.apache.org/jira/browse/CODEC-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17027952#comment-17027952
]
Larry West edited comment on CODEC-263 at 2/1/20 3:56 AM:
----------------------------------------------------------
I'm seeing the same issue (likely on bogus test data).
FWIW, in response to [~aherbert]'s final question:
{quote}The question is should {{Base64.isBase64(String)}} do the same
validation on the final character of the string?
{quote}
Background: the javadoc for {{isBase64(String)}} says: "returns true if all
characters in the String are valid characters in the Base64 alphabet...".
My answer is that {{isBase64()}} still fulfills that contract, and that because
there _could be_ people using it for purposes other than testing for
decodability – _i.e.,_ avoiding the IllegalArgumentException – (perhaps on a
partial buffer), the best way forward is to add an "{{isCompleteBase64()}}" or
"{{isDecodableBase64()}}" that matches "{{decodeBase64()}}" exactly.
h3. Postscript
This is actually mentioned in [the 1.13 release
notes|https://github.com/apache/commons-codec/blob/master/RELEASE-NOTES.txt],
but it somehow didn't register with me when I read
bq. CODEC-134: Reject any decode request for a value that is impossible to
encode to for Base32/Base64 rather than blindly decoding.
h3. Addendum
Yes, I may be able to take a stab at such a method if it's deemed helpful and
no one better equipped is available.
was (Author: larry_west):
I'm seeing the same issue (likely on bogus test data).
FWIW, in response to [~aherbert]'s final question:
{quote}The question is should {{Base64.isBase64(String)}} do the same
validation on the final character of the string?
{quote}
Background: the javadoc for {{isBase64(String)}} says: "returns true if all
characters in the String are valid characters in the Base64 alphabet...".
My answer is that {{isBase64()}} still fulfills that contract, and that because
there _could be_ people using it for purposes other than testing for
decodability – _i.e.,_ avoiding the IllegalArgumentException – (perhaps on a
partial buffer), the best way forward is to add an "{{isCompleteBase64()}}" or
"{{isDecodableBase64()}}" that matches "{{decodeBase64()}}" exactly.
h3. Postscript
This is actually mentioned in [the 1.13 release
notes|https://github.com/apache/commons-codec/blob/master/RELEASE-NOTES.txt],
but it somehow didn't register with me when I read
* CODEC-134: Reject any decode request for a value that is impossible to
encode to for Base32/Base64 rather than blindly decoding.
> Base64.decodeBase64 throw exception
> -----------------------------------
>
> Key: CODEC-263
> URL: https://issues.apache.org/jira/browse/CODEC-263
> Project: Commons Codec
> Issue Type: Bug
> Affects Versions: 1.13
> Environment: JDK 7/JDK 8
> commons-codec 1.13
> Reporter: xie tao
> Priority: Critical
> Attachments: image-jpg-01-big.base64.txt
>
>
> Codec upgrade to 1.13, code throw exception as follows：
> {code:java}
> @Test
> public void test(){
> Base64.decodeBase64("publishMessage");
> }
> {code}
> exception like：
> {code:java}
> java.lang.IllegalArgumentException: Last encoded character (before the
> paddings if any) is a valid base 64 alphabet but not a possible value
> at
> org.apache.commons.codec.binary.Base64.validateCharacter(Base64.java:798)
> at org.apache.commons.codec.binary.Base64.decode(Base64.java:472)
> at
> org.apache.commons.codec.binary.BaseNCodec.decode(BaseNCodec.java:412)
> at
> org.apache.commons.codec.binary.BaseNCodec.decode(BaseNCodec.java:395)
> at org.apache.commons.codec.binary.Base64.decodeBase64(Base64.java:694)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
