The Java 8 Base64 library has two variants that can be used in URI building: the \"Basic\" one and the \"URL and Filename safe\". The documentation points to RFC 4648 Table 2 as
The easiest way is to provide an example(IMHO):
Base64.Encoder enc = Base64.getEncoder();
Base64.Encoder encURL = Base64.getUrlEncoder();
byte[] bytes = enc.encode("subjects?_d".getBytes());
byte[] bytesURL = encURL.encode("subjects?_d".getBytes());
System.out.println(new String(bytes)); // c3ViamVjdHM/X2Q= notice the "/"
System.out.println(new String(bytesURL)); // c3ViamVjdHM_X2Q= notice the "_"
Base64.Decoder dec = Base64.getDecoder();
Base64.Decoder decURL = Base64.getUrlDecoder();
byte[] decodedURL = decURL.decode(bytesURL);
byte[] decoded = dec.decode(bytes);
System.out.println(new String(decodedURL));
System.out.println(new String(decoded));
Notice how one is URL safe
and the other is not.
As a matter of fact if you look at the implementation, there are two look-up tables used for encoding: toBase64
and toBase64URL
. There are two characters only that differ for them:
+
and /
for toBase64
versus -
and _
for toBase64URL
.
So it seems that your question is one URI safe and should be used there?; the answer is yes.
Running some tests, encoding a data URI using base64 "URL and filename safe" produces URIs that are not recognised by Chrome.
Example: data:text/plain;base64,TG9yZW0/aXBzdW0=
is properly decoded to Lorem?ipsum
, while its URL-safe counterpart data:text/plain;base64,TG9yZW0_aXBzdW0=
is not (ERR_INVALID_URL).