views:

176

answers:

4

Hello,

I would like an efficient utility to generate Unique sequences of bytes. UUID is a good candidate but UUID.randomUUID().toString() generates stuff like 44e128a5-ac7a-4c9a-be4c-224b6bf81b20 which is good as long as you don't need to transmit it over http, in which casa the dashes need to be removed.

I'm looking for an efficient way to generate a random strings, only from alphanumeric characters (no dashes or any other special symbols).

Thanks for helping, Maxim.

+5  A: 

This does it:

public static void main(String[] args) {
    final String uuid = UUID.randomUUID().toString().replaceAll("-", "");
    System.out.println("uuid = " + uuid);
}

But I don't understand fully why you want to remove the dashes.

Steve McLeod
+2  A: 

Dashes don't need to be removed from HTTP request as you can see in URL of this thread. But if you want to prepare well-formed URL without dependency on data you should use URLEncoder.encode( String data, String encoding ) instead of changing standard form of you data. For UUID string representation dashes is normal.

Donz
+1  A: 

I used JUG (Java UUID Generator) to generate unique ID. It is unique across JVMs. Pretty good to use. Here is the codes for your reference.


private static final SecureRandom secureRandom = new SecureRandom();
private static final UUIDGenerator generator = UUIDGenerator.getInstance();

public synchronized static String generateUniqueId() {
  UUID uuid = generator.generateRandomBasedUUID(secureRandom);

  return uuid.toString().replaceAll("-", "").toUpperCase();
}

You could download the library from: http://jug.safehaus.org/

Sheng Chien
For your case what's wrong with UUID.randomUUID().toString() ? Also note that you (theoretically) decrease the entropy by holding a static final SecureRandom (make it volatile). also why synchronize the generateUniqueId? This means all your threads are blocked on this method.
Maxim Veksler
First of all, Safehaus claims JUG is faster. And it can generate unique IDs across machines which you might not need. They have time-based method which is the fatest one among all methods. Yes, synchronized is not necessary here cause' I realized SecureRandom is thread safe already. Why would declaring static final on SecureRandom would decrease the entropy? I am curious :)There are more details here:http://jug.safehaus.org/FAQ
Sheng Chien
JUG can generate random-number based UUIDs as well; but the main reasons why developers prefer using time-based variant is either that it's 10-20x faster (http://www.cowtowncoder.com/blog/archives/2010/10/entry_429.html); or that they don't trust randomness to produce unique ids (which is kinda funny)
StaxMan
A: 

Hey guys,

Just wanted to update that I've ended up writing something of my own (after reading UUID.java implementation). Note that I'm not generating a UUID, instead just a random 32 bytes hex string in the most efficient way I could think of.

import java.security.SecureRandom;
import java.util.UUID;

public class RandomUtil {
    // Maxim: Copied from UUID implementation :)
    private static volatile SecureRandom numberGenerator = null;
    private static final long MSB = 0x8000000000000000L;

    public static String genRandom32Hex() {
        SecureRandom ng = numberGenerator;
        if (ng == null) {
            numberGenerator = ng = new SecureRandom();
        }

        return Long.toHexString(MSB | ng.nextLong()) + Long.toHexString(MSB | ng.nextLong());
    }

    public static void main(String[] args) {
        System.out.println(UUID.randomUUID().toString());
        System.out.println(RandomUtil.genRandom32Hex());

        System.out.println();
        System.out.println(Long.toHexString(0x8000000000000000L |21));
        System.out.println(Long.toBinaryString(0x8000000000000000L |21));
        System.out.println(Long.toHexString(Long.MAX_VALUE + 1));
    }
}
Maxim Veksler