java.util.Base64 decode then encode yields different string

Question

The issue: decoding Fz+= then encoding it back yields Fz8=

The following code:

new String(Base64.getEncoder().encode(Base64.getDecoder().decode("Fz+=".getBytes("UTF-8"))))

Gives the following String: Fz8=

How did the + become an 8?

I must be missing something here.

Fz+= in bit pattern: 000101 110011 111110 000000

rearranged in 8bit groups: 00010111 00111111 10000000

In decimal: 23 63 128

which would need 3 bytes to represent it.

However when I try just this code:

Base64.getDecoder().decode("Fz+=".getBytes("UTF-8"))

I get the following array in decimal:

 [23, 63]

Where did the last byte (1000 0000) go ? It's the reason the + turned into an 8 when we encoded it.

Seems like round-trip data loss stemming from the UTF-8 conversion? Not entirely sure but this article might be helpful. Looks like it has to do with how the 128 is expanded to multiple bytes. — ztaylor54
– ztaylor54, Commented Jan 2, 2018 at 19:55

Jim Garrison · Accepted Answer · 2018-01-02 20:27:39Z

4

The input string Fz+= is not a valid Base64 encoding.

By definition, if the encoded string ends with a single padding character, the input that resulted in that encoding quartet contained only two bytes. When encoding, the two-byte input was supposed to be padded with 0x00 to make a full 3-byte unit that was then encoded to 4 Base64 code bytes.

Whatever produced the string Fz+= incorrectly padded the 2-byte input with 0x80. Alternatively, the encoder mistook the 0x80 for 0x00 possibly because it was expecting pure 7-bit ASCII.

Regardless of the reason, the Fz+= input is invalid, and the decoder just ignored the extra two bits.

If the input really was 00010111 00111111 10000000, then the proper encoding is Fz+A with no padding and the A code representing 000000. Again, this is likely due to a bug in whatever originally did the encoding.

edited Jan 2, 2018 at 20:27

answered Jan 2, 2018 at 20:20

Jim Garrison

87k20 gold badges162 silver badges197 bronze badges

Sign up to request clarification or add additional context in comments.

2 Comments

user39950 Over a year ago

Thanks a lot for the answer! I was not aware of that. Does that mean that the correct base64 encoding of 00010111 00111111 10000000 for example would be Fz+A ?

user39950 Over a year ago

Thanks, yes I edited my answer shortly after posting. Makes a lot of sense.

Collectives™ on Stack Overflow

java.util.Base64 decode then encode yields different string

1 Answer 1

2 Comments

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

2 Comments

Your Answer

Sign up or log in

Post as a guest

Related