The problem is that Javascript strings are encoded in UTF-16, and browsers do not offer very many good tools to deal with encodings. A great resource specifically for dealing with Base64 encodings and Unicode can be found at MDN: https://developer.mozilla.org/en-US/docs/Web/API/WindowBase64/Base64_encoding_and_decoding

Their suggested solution for encoding strings without using the often cited solution involving the deprecated unescape function is:

function b64EncodeUnicode(str) {
    return btoa(encodeURIComponent(str).replace(/%([0-9A-F]{2})/g, function(match, p1) {
        return String.fromCharCode('0x' + p1);
    }));
}

For further solutions and details I highly recommend you read the entire page.

These are url-quoted strings, so url-unquoting is the correct procedure. The first step is unquote them with urllib.parse.unquote. Only after that should you attempt base64-decoding and there's no need to manually mess around with the base64 padding character =.

The website you reference ignores invalid base64 characters and also infers the padding from the length of the base64-encoded data. So you give the website MTA0MzI%3D and it throws away the % because it's not valid base64 char, then processes MTA0MzI3D and returns 104327. Base64 padding is redundant and I'm not sure why some base64 encoding standards specify to have it in there but many do.

Example:

import base64
import urllib.parse

# List of string which we are trying to decode
encoded_text_list = ['MTA0MDI0', 'MTA0MDYw', 'MTA0MDgz', 'MTA0MzI%3D']

# Iterating and decoding string using base64
for k in encoded_text_list:
    url_unquoted = urllib.parse.unquote(k)
    print(k, base64.b64decode(url_unquoted).decode('utf-8'))

Output

MTA0MDI0 104024
MTA0MDYw 104060
MTA0MDgz 104083
MTA0MzI%3D 10432

and 10432 is the correct output, not 104327.

You can't Base64 has set 64 characters that can converted to binary and vice versa, characters like { and " is not in the 64 set of characters check this

Try using URLDecoder with UTF-8 or any other encoding method which support UTF-8

base64 encodes binary data to visible characters. If you decode it, the string will be turned back into the binary data, where some of the bytes won't have an ascii/unicode representation and will show as squares. This is normal behaviour. You should decode the data in the program you want to use the data in.

What's likely here is that you're in a UTF-8 locale but your terminal or terminal emulator is using a charset other than UTF-8.

To get that particular error, you must have the iconv from GNU libiconv as opposed to the one from GNU libc, and that Ç can't be encoded as 0xC7 as it is in a lot of single-byte encodings that have that character or you'd get iconv: (stdin):1:10: incomplete character or shift sequence instead.

I'd bet for IBM850 aka CP850 as that's still found on Microsoft Windows (and IIRC it's even the default in the "console" of English flavours of Windows believe it or not). In that charset, Ç is encoded as byte 0x80 (0200 in octal).

To confirm whether that's the case, enter:

printf %s 'Ç' | od -An -vto1

Which if I'm right should output 200.

$ locale charmap
UTF-8
$ printf 'FILE_DATE.\200' | iconv -t utf-8
FILE_DATE.
iconv: (stdin):1:10: cannot convert

Your locale uses UTF-8, so expects characters encoded in UTF-8. That iconv -t utf-8 would be a no-op as it's encoding from the locale's charmap (which is UTF-8) to UTF-8, except it still tries to decode that input expecting it to be UTF-8 encoded. But that 0x80 byte from that IBM850-encoded Ç is invalid in UTF-8, hence the error.

Here you'd want to fix your terminal emulator's encoding to UTF-8 (if it's indeed Microsoft Windows console, then maybe https://superuser.com/q/269818 is relevant) so it matches that of the locale. Then, when you type Ç, it would send the two bytes 0xc3 0x87 instead of 0xc7.

Then you'd just do:

printf %s 'FILE_DATE.Ç' | base64

To get the base64 encoding of the UTF-8 encoding of that string.

If you cannot change the encoding of your terminal, and you know which it is (here maybe IBM850 if that's Microsoft Windows), then:

printf %s 'FILE_DATE.Ç' | iconv -f IBM850 | base64

Would again give you the base64 encoding of the UTF-8 encoding of that string.

No, if you ask about the result of the base64 encoding.

you can search on wikipedia. https://en.wikipedia.org/wiki/Base64