If we assume that --
represents padding, and the fact that the encoded data can have :
and .
characters in it, one might first jump to the conclusion that it could be a modified base64 variant. But the length of the encoded data is <= the length of the input data (depending on whether &
really is &
or is actually &
before encoding), so it can't be based on base64, which always produces encoded data that is longer than the input data. So there is either a simple replacement algorithm in play, or some amount of bit compression is being used. Either way, without more context about what kind of format/protocol this encoded data is actually being used in, there is simply no way to answer this question as-is. There are simply too many data-to-text encoding algorithms used in the real world to narrow this down by trial-an-error.