asymmetric Base64Decode -> Base64Encode

Common specs for Base64 indicate that the output character set is [a-zA-Z0-9+/]*=?=?, but MUSHclient Base64Decode("a+==") returns "k" which encodes to "aw==". Is your Base64Encode method guaranteed to produce alphanumeric(asymmetric from decode) results?

My bigger question is whether the result (with trailing equals stripped) is safe for naming aliases based on match pattern or if you have a better way.

According to this site, at least:

http://www.motobit.com/util/base64-decoder-encoder.asp

The correct encoding for "k" is indeed "aw==".

Your example of "a+==" contains a stray extra two bits (the difference between "w" and "+").

However as Wikipedia says:

http://en.wikipedia.org/wiki/Base64



So the trailing "==" overrides those stray bits, because they specify that the group only decodes to one byte.

---

Well you can't have "+" or "/" in names, so I guess not in any case.

I suggest you MD5 sum the match pattern, which will work for any length match pattern. Prepend a character (like "A") to the front in case the MD5 sum starts with a number, and "hey presto!" you are done!

Except that MD5, being a hash and not a byte conversion, does not prevent many-to-one matching.

And I'm wondering if this is a real problem, because I can't seem to find any Base64 output that actually contains them.

For a start, the base64 approach could give you very long labels, especially as the base64-encoded stuff is 4/3 times the size of the original.

Just because you haven't seen "+" or "/" in output doesn't mean it won't happen. It would require certain combinations of adjacent bits for that to occur.

Whilst MD5 can have collisions, and they can even be deliberately caused with carefully constructed text, the likelihood of them randomly occurring is very low.

Remember, Git uses filenames internally which are the MD5 sum of their contents, and they aren't too worried about name clashes.

You could reduce the chance of collisions by appending the size to the hash (extra numbers at the end won't hurt). That way, two match strings would have to be the same length, and have the same MD5 sum, but differ in content, to cause a problem. I doubt you need to worry about it.


http://stackoverflow.com/questions/1323013/what-are-the-chances-that-two-messages-have-the-same-md5-digest-and-the-same-sha

To be safer you could use: utils.sha256