Add encode & decode operations to base62 helper

[sgmiller]

Implement Decode operations in the base62 helper by treating the []byte as a big.Int and then then doing a general base conversion using div/remainder.

Implement Encode as the inverse, using Mul/Add.

[kalafut]

This seems like a caution that will be a) unknown to the user, b) leave them stuck if they do know about it. Is there an alternative but safe/stable version of these processes such that maybe we conditionally use one or the other alg based on input size?

[sgmiller]

Apparently not. There seems to be no solution to 62^a = 256^b unlike with say base64, so you can't iteratively process the input to keep the number sizes small. Base62 is in short pretty weird. I've found other implementations on the web that do strange things to make it work, but they don't decode in a way that's compatible with what we produce in Random*

[sgmiller]

We could certainly rename the functions or even have an arbitrary limit (or both). Say EncodeSmall, with a 1000 character limit or something.

[jefferai]

FWIW somewhere else we are using base58. Since it's used for cryptocurrency it's much more standardized (so you can encode and decode with different libraries) and disambiguates characters that otherwise look alike. If this had existed at the time we may have used this instead. But for some of the open questions some inspiration might be found there. Or that may be an existing, tested alternative.

[sgmiller]

FWIW somewhere else we are using base58. Since it's used for cryptocurrency it's much more standardized (so you can encode and decode with different libraries) and disambiguates characters that otherwise look alike. If this had existed at the time we may have used this instead. But for some of the open questions some inspiration might be found there. Or that may be an existing, tested alternative.

Thanks. Lifted the changes from base58 for efficiency into this PR, but between 58 and 62 it really doesn't make much difference for tokenization. I'll leave this PR open as a nice bit of additional functionality for our use, but 58 seems like a winner for transform, so I'll switch to that tomorrow. Both still have the problem of being unsuitable for encoding/decoding large values.

[aphorise]

I was curious what's the status with this request or when it may be released?