base64 encode / decode

Can I safely remove the padding = at the end?

[GoNC]

I'm using a simple encode / decode script for a portion of my site:

function encode($sData) {
return strtr(base64_encode($sData), '+/=', '-_,');
}

function decode($sData) {
return base64_decode(strtr($sData, '-_,', '+/='));
}

I see, though, that I occasionally have a trailing = after encoding, which I understand is used to pad the data to the correct number of bytes.

The question is, can I safely remove the trailing = from function encode()? If so, do I HAVE to add them back to function decode() manually, or does base64_decode() handle it automatically?

From testing, it seems like I can just remove them from encode() and forget them, but I want to make sure that this is stable before doing so.

TIA!

[lucy24]

can I safely remove the trailing = from function encode()?

For a given definition of "safely". If the sole purpose of your base64 encode, ever, is to produce something that can later be decoded by your own program, and if you've found by experiment that base64 decode works even without the trailing = signs--meaning that the decode function supplies them where needed--then it is probably safe. (On rereading, I see you haven't actually done this experiment. I thought you had; it would be the first thing to check for.)

But why would you want to? How vast is your database, that shaving one or two bytes off the end of a record outweighs the extra work of removing the = and the risk that future decoding programs will have trouble with the result?

[GoNC]

In my case, it's not in the database. I had the data unencrypted in the database, and in some instances would send the data through the URI. For example:

www.example.com/?id=lucy24

would bring up the profile data for the username "lucy24".

It turns out, though, that this is a violation of Google rules, so I had to start encrypting the username for the URI. So now, the link is more like:

www.example.com/?id=cHJpbm,,

(that encryption was just made up on the fly, of course)

This isn't actually stored in the database (although I might do that in the future), it's just encrypted on the fly before a link is generated.

It's really not a big deal, I just don't like to see so many links ending with a comma (encrypted from the =). I see that I can delete the commas and the link still works, I just wanted to make sure that this is generally safe, and not going to cause a mass number of PHP warnings, or possibly stop working with a PHP update.

Thank for the help, Lucy!

[whitespace]

... this is a violation of Google rules

What rule is that then? (TBH, I don't think the "encoding" method you have used would satisfy a "violation"?)

I just don't like to see so many links ending with a comma

You don't need to use a comma, there are other valid chars you could use here if that helps?

Can I safely remove the padding = at the end?

Implementations vary. As can be seen on Wikipedia - Base64 variants [en.wikipedia.org], for some it's mandatory, some it's optional. I think with PHP's base64_decode() it's optional. But as lucy24 states, if you've tested it for your particular use case it should be OK.

However, whether you should or not is another matter - it doesn't "smell" good.

[GoNC]

... this is a violation of Google rules

What rule is that then? (TBH, I don't think the "encoding" method you have used would satisfy a "violation"?)

I should have said "Google Adsense", not just Google. They sent me a warning because of it, and after I encoded everything they said that there's no more violation. I can't honestly explain why, though.

Here's the link to the rule:

In the interests of protecting end user privacy, Google ads product policies mandate that publishers must not pass any data to Google that Google could use or recognize as personally identifiable information (PII)

[support.google.com...]

Thanks for the other info!

[default password]

"Lucy24" for me encodes to "THVjeTI0". And I do not think that MIME base 64 encoding would produce commas.

But you can remove the trailing "==". Here is confirmation. (They are "padding"; see Wikipedia.)

$s = base64_encode("This is an encoded string");
echo("$s<br>");
$s = rtrim($s,',=');
echo("$s<br>");
$s = base64_decode($s);
echo("$s<br>");

VGhpcyBpcyBhbiBlbmNvZGVkIHN0cmluZw==
VGhpcyBpcyBhbiBlbmNvZGVkIHN0cmluZw
This is an encoded string

EDIT: From Wikipedia, "In some implementations, the padding character is mandatory, while for others it is not used. One case in which padding characters are required is concatenating multiple Base64 encoded files."

But looks like PHP and small strings removing the padding is okay. I'd have to run a comprehensive test of hundreds of various strings to verify that though.

OOPS: Someone already said that! Sorry for not paying full attention and duplicating content.

[default password]

Maybe you can use str_rot13() instead of base64 encoding.

(Again, I apologize for my duplicate content... moderator can delete it.)

[lucy24]

---

[default password]

Now that I took the time to read your question fully (sorry to all for not doing so previously), if all you want to do is obsure URL strings from Google Adsense (or anyone else for that matter), you can modify your base64 encode/decode (which was a good thing to start with) like:

function encode($sData) {
return urlencode(base64_encode($sData));
}

function decode($sData) {
return base64_decode(urldecode($sData));
}

Or using str_rot13:

function encode($sData) {
return str_rot13($sData);
}

function decode($sData) {
return str_rot13($sData);
}

[d3vrandom]

Hello why are using username in url? Your database table primary key column id should be an integer and you use that int in your urls. This is a database design problem and that's where you should fix it.