Question

uniqid() function returns a 13 digits long hexadecimal number. According to the spec in php.net site, the function uses microtime to generate the unique value.

But microtime returns numbers in string format as the following one:

"0.70352700 12689396875"

which are basically the microseconds and the seconds elapsed since 1970.
This is a 9+11 digits decimal number.

Converting a 20 decimal number into hex would result in a 16 digits hexadecimal NOT a 13 digits one.

I also thought to take out the “0.” part that seem to never change, and the last two digits of the microsec part that seem to remain always “00”. Doing this the decimal number would be only 9+11-3 digits long, but still a decimal number of 17 digits when converted into hex would result in 14 digits hexadecimal number NOT 13.

I’M NOT INTERESTED IN GETTING A UNIQUE ID IN ANOTHER WAY OR A LONGER/SHORTER UNIQUE ID! I’M ONLY ASKING IF SOMEONE KNOWS WHY DOES uniqid RETURNS ONLY 13 DIGITS.

It seems nosense: if uniqid returns one digit less than microtime, it means that microtime gives out results that are more unique of the ones returned by uniqid.

Answer 1

Found this on http://www.php.net/manual/en/function.uniqid.php#95001

Makes sense to me. Comment if you need an explanation

For the record, the underlying
function to uniqid() appears to be
roughly as follows:

$m=microtime(true);
sprintf(“%8x%05x\n”,floor($m),($m-floor($m))*1000000);

In other words, first 8 hex chars =
Unixtime, last 5 hex chars =
microseconds. This is why it has
microsecond precision. Also, it
provides a means by which to
reverse-engineer the time when a
uniqid was generated:

date(“r”,hexdec(substr(uniqid(),0,8)));

Increasingly as you go further down
the string, the number becomes “more
unique” over time, with the exception
of digit 9, where numeral prevalence
is 0..3>4>5..f, because of the
difference between 10^6 and 16^5 (this
is presumably true for the remaining
digits as well but much less
noticeable).