The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

The $data being passed in looks like... "||12-94||" - The numbers will be be changing and will potentially range from 2-8 digits each.

I realize you can never say never in terms of collisions, but what kind of odds am I looking at? These hashes values are then base64_encoded and use in URLs for tracking, so being unique is paramount, is there a better way to achieve this that wont suffer from possible collisions?

What you are doing is not hashing, its encryption which can then be decrypted. Collisions is not something you have to worry about when encrypting. Because unlike hashing the data is never really gone.

Logic without the fatal effects.
All code snippets are licensed under WTFPL.

If these numbers need to be protected, you could also consider just never putting them out in the wild. Each combination of numbers could just be stored in a private database, and let the database generate an integer id. This could be safer unless you think someone may be able to predict sequences.

It seems like its still "never gone" similar to encryption, but it doesnt require mcrypt and it just tacks on something extra to the end to confuse anyone that would attempt a base64_decode()

I don't think you really understand how Base64 works. Adding "aAn" onto the end of the string doesn't meant that when you B64 Decode you're going to get something different: you're just going to get the string with "aAn" on the end of it.

As for your question on collisions: you have a 10^8th chance of a collision, because that's the maximum size of your dataset. As long as the starting data is unique, the ending data will be unique.

I'm going to second the idea of locking the values in question in a database, though. Note that you'll need to properly secure yourself against SQL injection or you're right back where you started in all this.