When I tried to encode a YouTube URL to base64 again, the value after the =
sign didn't change, except for the first two letters. Is the last portion already in base64?
Minus the =
sign being translated into %3D
, yes, CvUN8qg9lsk
is already encoded in Base64.
Why are they the same?
As @LPChip points out, the function you are using is a URL encoder which is translating only special characters in the URL (:
, /
, ?
, +
and =
) into their hexadecimal equivalents (not normal letters).
Base64 includes other encoding too, right?
While URL encoding is considered a form of Base64 encoding, it is worthwhile to note that that term is potentially overloaded. Per Wikipedia (emphasis added):
"Base64 is a group of similar binary-to-text encoding schemes that represent binary data in an ASCII string format by translating it into a radix-64 representation."
In short, the base64
function you are using isn't meant to encode/decode CvUN8qg9lsk
.
As a small side note, if you add a =
(padding) and try to translate e.g. CvUN8qg9lsk=
with a "normal" Base64 encoder/decoder, this may work. That said, it's unlikely you'll get anything worthwhile (i.e. meaningful to humans). It's very likely the values YouTube uses to get its IDs are the product of a very specific algorithm that likely has no relation to anything outside Google/YouTube.
:/?=
present in the url, not tha alphanumeric chars and the.
It seems the base64 encoder is actually an url encoder. Given that you haven't actually mentioned what kind of encoding you use and where you use it, answering this question other htan that I did is going to be hard to near impossible.