Uuid's with hyphens?

Plugins Plugin Development
1

when trying to retrieve a players uuid it’s returned as eb10cec3-d8f4-457f-84e9-21ef6488e0e5 instead of eb10cec3d8f4457f84e921ef6488e0e5. From what I’ve seen in a few plugins storing info the player uuid didn’t have hyphens, am I doing something wrong?

2

The hypens are just a display format.

The two UUID’s should be considered equivalent.

3

is there a way I can get the uuid without the hyphens? mostly out of preference lol
or would it be better to keep the hyphens?

edit would removing all the dashes with a method like replaceAll() be a logical way to do it?

player.getUniqueId().toString().replaceAll("[\\s\\-()]", "");

4

The UUID with hyphens is called the full uuid, without hyphens is called the trimmed uuid.
They are the same value whether they have the dashes or not, just make sure that it has all the dashes or none of them.

5

UUIDs with hyphens is the standard way to do it. I’ve only seen it done without hyphens in Minecraft. I’d always use the ‘full UUID’.

6

It’s extremely common when storing as a binary / network format to leave out the hyphens.

If you are running a major service, bytes add up.

2 Likes
7

This. For scalable software this should be kept in-mind, but you could get away without account for this on the small scale.

8

UUIDs are always stored with hyphens when stored as strings as per RFC 4122, but hyphens don’t exist in the binary representation, which is simply a 128 bit number.

When dealing with UUIDs use the java UUID class whenever possible and convert any string UUIDs to UUID objects as much as possible. It will save you many headaches.

2 Likes
9

That’s what I was trying to say gravity, thanks for clearing it up, my brain must have been asleep when I wrote that.

10

I agree with gravity. Here’s a method that optionally constructs UUID objects based off a String, dashes agnostic. I find it particularly useful sometimes.

Disclaimer: I did not write this snippet. Although at this moment I can’t recall the original author, let me know if you do.
EDITED:::


    /**
     * Retrieve a UUID safely from a {@link String}.
     *
     * @param string - The {@link String} to deserialize into an {@link UUID} object.
     * @return {@link Optional#empty()} if the provided {@link String} is illegal, otherwise an
     * {@link Optional} containing the deserialized {@link UUID} object.
     */
    public static Optional<UUID> getUUIDFrom(String string) {
        Validate.notNull(string);
        Validate.notEmpty(string);

        if (!string.contains("-")) {
            string = string.substring(0, 8) + "-"
                  + string.substring(8, 12) + "-"
                  + string.substring(12, 16) + "-"
                  + string.substring(16, 20) + "-"
                  + string.substring(20, 32);
        }

        try {
            return Optional.of(UUID.fromString(string));
        } catch (IllegalArgumentException exc) {
            return Optional.empty();
        }
    }
11

That is a horrifying piece of code xD

At least by merit of being a horrible hackjob for even existing.

Also you might want to use another try-catch block for the second UUID.fromString() in case of malformed uuid in general.

2 Likes
12

Why not do something like:

    @Test
    public void test() {
        final UUID uuid = UUID.randomUUID();

        final String hexRep = toHexString(uuid);

        System.out.println(hexRep);
        System.out.println(uuid.toString());

        assertEquals(uuid.toString().replaceAll(Pattern.quote("-"), ""), hexRep);

        assertEquals(uuid, fromHexString(hexRep));
    }

    private String toHexString(final UUID uuid) {
        requireNonNull(uuid);

        return Long.toHexString(uuid.getMostSignificantBits()) + Long.toHexString(uuid.getLeastSignificantBits());
    }

    private UUID fromHexString(final String uuid) {
        requireNonNull(uuid);
        checkArgument(uuid.length() == 32);

        final String msb = uuid.substring(0,16);
        final String lsb = uuid.substring(16);

        return new UUID(Long.parseUnsignedLong(msb, 16),Long.parseUnsignedLong(lsb, 16));
    }
13

can be replaced with Long.parseUnsignedLong(msb, 16) which is way more performant

14

thanks, I was looking for this, I have edited the post

15

Updated post to be a bit more sane, although I prefer @nap’s solution. Nice!

16

UUIDs have a specification:
https://www.ietf.org/rfc/rfc4122.txt

The visualization is up to the application. We tend to put the hypens between the major components of the overall UID number:

      UUID                   = time-low "-" time-mid "-"
                               time-high-and-version "-"
                               clock-seq-and-reserved
                               clock-seq-low "-" node

The UUID is three main things:
A timestamp and version or uniquely qualifying hash of a version (in this case treat “version” as simply your MC player)
A time-sequence adjustment due to temporal displacement. Yes, that.
And finally the MAC address of the node on which the UUID was created (or a facsimile thereof)

The point of the UUID is to be universally unique across space and time. That’s what the sequence-adjustment is for in case you find your self moving through time at relativistic speed. Timestamp is your wall-clock time, version is essentially saying “Notch” or whomever the target thing is (a Thing), and MAC address is yet more disambiguation.

Take a look at the RFC. It’s interesting.

It’s just a very long number that has portions reserved for those three purposes. Parse to suit.

ps. RFC stands for “Request for Comments”. It is the specification system that defined the net.

1 Like