hi guys!
i used many base64 libs when i was developing to android, windows ce and windows phone
some base64 don't work without == or = on the end of base64 encoded string
in that time i made a workaround with "=" at the end, based on the length() of the string

well direct to the point... 
base64_decode isn't ONE function, it could be implemented with many standards... check wikipedia for example:

1)Original Base64 for Privacy-Enhanced Mail (PEM) (RFC 1421, deprecated)
2)Base64 transfer encoding for MIME (RFC 2045)
3)Standard 'Base64' encoding for RFC 3548 or RFC 4648
4)'Radix-64' encoding for OpenPGP (RFC 4880)
5)Modified Base64 encoding for UTF-7 (RFC 1642, obsoleted)
6)Modified Base64 for filenames (non standard)
7)Base64 with URL and Filename Safe Alphabet (RFC 4648 'base64url' encoding)
8)Non-standard URL-safe Modification of Base64 used in YUI Library (Y64)
9)Modified Base64 for XML name tokens (Nmtoken)
10)Modified Base64 for XML identifiers (Name)
11)Modified Base64 for Program identifiers (variant 1, non standard)
12)Modified Base64 for Program identifiers (variant 2, non standard)
13)Modified Base64 for Regular expressions (non standard)

I think the most used standard is rfc2045 (at least php use it and i think perl and others script languages too), for rfc2045 we have:

Variant: Base64 transfer encoding for MIME (RFC 2045)
Char for index 62: +
Char for index 63: /
pad char: = (mandatory)
Fixed encoded line-length: No (variable)
Maximum encoded line length: 76
Line separators: CR+LF
Characters outside alphabet: Accepted (discarded)
Line checksum: (none)

in other words... the TO_BASE64 and FROM_BASE64, isn't a function with only one parameter... i think we could allow two parameters and the second parameters is "standard" default to RFC-2045, and we could accept: RFC1421, RFC2045, (RFC3545/RFC4648), RFC4880, RFC1642, "filenames", RFC4648, Y64, NMTOKEN, "name", "variant1", "variant2", "regexp"

what you think?
well with this we can report error, warning and others messages to help user selecting the right one
i had a problem with wince5 and php, the problem was the char at position 62 one function was using "-" and the other was using "+", well i think this 13 variants of base64 function could explain the problem to everyone, right?

thanks guys!


2013/9/23 Michael Widenius <monty@askmonty.org>

Hi!

>>>>> "Alexander" == Alexander Barkov <bar@mariadb.org> writes:

<cut>

>>> Should we allow not '=' padding in our decoder too?
>>> (I think it's best to always pad on encoding).

<cut>

Alexander> Just checked PostgreSQL. They also pad on encode,
Alexander> and do not accept non-properly padded values on decode:

<cut>

How about all the programs that don't padd with '='?
There was a list of these in the wiki link you gave me ...

Regards,
Monty

_______________________________________________
Mailing list: https://launchpad.net/~maria-developers
Post to     : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help   : https://help.launchpad.net/ListHelp



--
Roberto Spadim
SPAEmpresarial