UUID is same from different strings

Viet :

I have two different strings, but after parsing to UUID it's seem to be same

public static void main(String[] args) {
    try {
        UUID t1 = UUID.fromString("38e1036d-7527-42a3-98ca-f2f19d3155db");
        UUID t2 = UUID.fromString("123438e1036d-7527-42a3-98ca-f2f19d3155db");
        System.out.println(t1.toString().equals(t2.toString()));
    } catch (Exception e) {
        e.printStackTrace();
    }
}

Any idea why it is?

Agent_L :

"123438e1036d-7527-42a3-98ca-f2f19d3155db"

This is not a UUID. It's a concatenated string of "1234" and a UUID. The problem here is that the parser should have told you this by throwing an exception. Instead it tries its best to actually find the UUID buried somewhere in there.

Once you extract the UUID from your concatenated string, it's identical to the first UUID which is the correct result you're observing.

We can analyze the parser (thanks to @tim-biegeleisen for providing the link):

public static UUID fromString(String name) {
    String[] components = name.split("-");
    if (components.length != 5)
        throw new IllegalArgumentException("Invalid UUID string: "+name);
    for (int i=0; i<5; i++)
        components[i] = "0x"+components[i];

    long mostSigBits = Long.decode(components[0]).longValue();
    mostSigBits <<= 16;
    mostSigBits |= Long.decode(components[1]).longValue();
    mostSigBits <<= 16;
    mostSigBits |= Long.decode(components[2]).longValue();

    long leastSigBits = Long.decode(components[3]).longValue();
    leastSigBits <<= 48;
    leastSigBits |= Long.decode(components[4]).longValue();

    return new UUID(mostSigBits, leastSigBits);
}

As we can see, there is no validation except for counting the number of groups limited by hyphens. It just takes those groups and then shifts them into positions. You've added extra characters in front of the first group, which is the most significant part. It's parsed and stored first, and then it gets shifted up and again up until it occupies the most significant part. Now, all bits that were farther left than assumed get pushed out of the long limit, hence they're completely ignored.

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=426318&siteId=1