[
https://issues.apache.org/jira/browse/CODEC-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18048557#comment-18048557
]
Gary D. Gregory edited comment on CODEC-333 at 12/31/25 1:24 PM:
-----------------------------------------------------------------
[~bsanchezb]
Thank you for contributing to Commons Codec!
The PR is merged, and I've made some adjustments to the Javadoc and updated
some of the new methods. Please verify git master and/or a snapshot build for
{{1.21.0-SNAPSHOT}} from
https://repository.apache.org/content/repositories/snapshots/
was (Author: garydgregory):
[~bsanchezb]
Thank you for contributing to Commons Codec!
The PR is merged, and I've made some adjustments to the Javadoc and updated
some of the new methods. Please verify git master and/or a snapshot build for
1.21.0 from https://repository.apache.org/content/repositories/snapshots/
> Add distinct Base64 decoding for standard and URL-safe
> ------------------------------------------------------
>
> Key: CODEC-333
> URL: https://issues.apache.org/jira/browse/CODEC-333
> Project: Commons Codec
> Issue Type: Improvement
> Affects Versions: 1.18.0
> Reporter: Aleksandr Beliakov
> Priority: Minor
> Fix For: 1.21.0
>
>
> The behavior applied in CODEC-75 does not distinguish between Base64 and
> Base64Url implementations within
> [isBase64|https://commons.apache.org/proper/commons-codec/apidocs/org/apache/commons/codec/binary/Base64.html#isBase64(java.lang.String)]
> and
> [decodeBase64|https://commons.apache.org/proper/commons-codec/apidocs/org/apache/commons/codec/binary/Base64.html#decodeBase64(java.lang.String)]
> methods. Nor, it does change the behavior, even if instantiating a class
> object using a Builder like below, explicitly stating that url-safe
> processing should not be used:
> {code:java}
> Base64 base64 = Base64.builder().setUrlSafe(false).get(); {code}
> with the method
> [isInAlphabet|https://commons.apache.org/proper/commons-codec/apidocs/org/apache/commons/codec/binary/Base64.html#isInAlphabet(byte)]
> still using the base64Url-safe decoding table.
>
> This causes some issues in the implementation, for instance inability to
> distinguish between Base64 and PEM encoded certificates, with Apache Codec
> accepting the latest as Base64. See a (chunked and dummy) example below (with
> _Base64.isBase64()_ method returning true):
> {code:java}
> -----BEGIN CERTIFICATE-----
> AQIDBAU=
> -----END CERTIFICATE-----{code}
>
> According to the [RFC 4648|https://datatracker.ietf.org/doc/html/rfc4648],
> handling of Base64 and Base64Url together should not be used:
> {panel:title=5. Base 64 Encoding with URL and Filename Safe Alphabet}
> This encoding may be referred to as "base64url". *This encoding should not
> be regarded as the same as the "base64" encoding* and should not be referred
> to as only "base64". Unless clarified otherwise, "base64" refers to the base
> 64 in the previous section.
> {panel}
> While same handling may be acceptable in some particular cases, we think a
> generic library like Apache Commons Codes shall make a clear separation
> between the two encodings and unless implementors explicitly state the
> support of url-safe characters, it should not be applied by default.
>
> This should also avoid potential errors within the implementations, when a
> system shall treat base64 and base64url encodings as two separate ones (for
> instance like in
> [standards|https://www.etsi.org/deliver/etsi_ts/119100_119199/11918201/01.02.01_60/ts_11918201v010201p.pdf]
> explicitly requiring one or another implementation, based on the usage).
>
> _FYI, Google Guava have two separate implementations
> [BaseEncoding.base64()|https://guava.dev/releases/17.0/api/docs/com/google/common/io/BaseEncoding.html#base64()]
> and
> [BaseEncoding.base64Url()|https://guava.dev/releases/17.0/api/docs/com/google/common/io/BaseEncoding.html#base64Url()]
> allowing implementors to explicitly choose one according to the project
> needs._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
