I got a problem with an atob that throws an exception

The string to be decoded is not correctly encoded.

There are already some questions like this on stack overflow but they deal about "plex" issues (file and/or URL encoding) my code is far simpler:

atob("MC4wNTgxMzA0OTg5OCAwLjA1NTU0MTg5OTA2IDEAA");

as the string length is 41 I tried to add 0,1,2 or 3 "=" with no luck.
The expected result (returned by any online base64 decoder I tested) is a plain string:

0.05813049898 0.05554189906 1

I tried dGVzdA== or dGVzdA and it is correctly decoded as "test".

So what's the obvious issue I should be ashamed of?

If this matters, I'm running Chromium 81.

PS: I just encoded the string back (Why I didn't think of it first?). And it looks like the encoded string should be

MC4wNTgxMzA0OTg5OCAwLjA1NTU0MTg5OTA2IDE=

which is decoded just fine.

atob("MC4wNTgxMzA0OTg5OCAwLjA1NTU0MTg5OTA2IDE=");

PS2: atob works just fine. It's juste the input string (and Apple) which is to blame according to .html. So if ile file.length %4 == 1, I guess the answer is just to strip the last char. For 2 or 3 I don't know

I got a problem with an atob that throws an exception

The string to be decoded is not correctly encoded.

There are already some questions like this on stack overflow but they deal about "plex" issues (file and/or URL encoding) my code is far simpler:

atob("MC4wNTgxMzA0OTg5OCAwLjA1NTU0MTg5OTA2IDEAA");

as the string length is 41 I tried to add 0,1,2 or 3 "=" with no luck.
The expected result (returned by any online base64 decoder I tested) is a plain string:

0.05813049898 0.05554189906 1

I tried dGVzdA== or dGVzdA and it is correctly decoded as "test".

So what's the obvious issue I should be ashamed of?

If this matters, I'm running Chromium 81.

PS: I just encoded the string back (Why I didn't think of it first?). And it looks like the encoded string should be

MC4wNTgxMzA0OTg5OCAwLjA1NTU0MTg5OTA2IDE=

which is decoded just fine.

atob("MC4wNTgxMzA0OTg5OCAwLjA1NTU0MTg5OTA2IDE=");

PS2: atob works just fine. It's juste the input string (and Apple) which is to blame according to http://www.monobjc/xib-file-format.html. So if ile file.length %4 == 1, I guess the answer is just to strip the last char. For 2 or 3 I don't know

• javascript
• base64

• 1 Glad you found a solution. Suggestion: perhaps you could post that as an answer? That way the question doesn't show up for future searches as unanswered. – David784 Commented May 2, 2020 at 21:09
• 2 well, atob('MC4wNTgxMzA0OTg5OCAwLjA1NTU0MTg5OTA2IDEA'); seems to work, so instead of adding a =, you needed to remove the last char. – Luka M Commented May 2, 2020 at 21:12
• This is not a solution. The input IS "MC4wNTgxMzA0OTg5OCAwLjA1NTU0MTg5OTA2IDEAA" and it should be correctly decoded. Now I need to understand what are those extra "AA" and why they are correctly decoded by some base64 decoder but not by atob – v1nce Commented May 2, 2020 at 21:12
• 2 why they are correctly decoded by some base64 decoder - no decoder can decode it correctly. The 41st character represents just 6 bits. Some decoders are just a bit more tolerant and decode the input as far as possible and ignore the missing end. Some explanation in an answer I wrote recently – jps Commented May 3, 2020 at 8:53
• 1 Luka M was right, I just discarded the last char and it worked. I guess this is what base64.guru and base64decode are doing. I thought that by adding "=" I'll get a valid b64 string. But I guess the "=" is a 'non coding' character so there are still missing 2 bits (like jps pointed). For those asking where this es from : it's from a xib file and according to monobjc/xib-file-format.html Apple is to blame for the non standard behaviour – v1nce Commented May 3, 2020 at 13:52

1 Answer 1

If you btoa your expected result, you get:

console.log(btoa("0.05813049898 0.05554189906 1"));

which is different from your original string.