Which digits of a UUID are least likely to collide if the generator (e.g. Java version of UUID) is unknown?












1















Suppose we have an existing set of UUIDs (say, millions, though it doesn't matter) that may have been generated by different clients, so that we don't know the algorithm that generated any UUID. But we can assume that they are popular implementations.



Are there a set of 8 or more digits (not necessarily contiguous, though ideally yes) that are less or more likely to collide?



For example, I've seen the uuid() function in MySQL, when used twice in the same statement, generate 2 UUIDs exactly the same except the 5th through 8th digits:



0dec7a69-ded8-11e8-813e-42010a80044f

0decc891-ded8-11e8-813e-42010a80044f

    ^^^^


What is the answer generally?



The application is to expose a more compact ID for customers to copy and paste or communicate over phone. Unfortunately we're bound to using UUIDs in the backend, and understandably reluctant to creating mappings between long and short versions of IDs, but we can live with using a truncated UUID that occasionally collides and returns more than 1 result.






java uuid hash-collision







share|improve this question























  • UUIDs are implemented in a wide variety of algorithms. Some Use MAC (or similar) addresses for part and then part is based on timestamp and some bits are random. Others, the whole UUID is pseudo-random. In short: can you narrow down your question: What is the actual UUID generator being used?

    – sofend
    Nov 20 '18 at 22:22











  • With your two there being so close in value during the same query, it’s probably a time based UUID (v1 I think?). However, I’m not sure which, if any, parts are less likely to differ, I’m sure it wouldn’t matter if the user is copy/pasting anyway. I can see the annoyance in having to read out one over the phone all the time, though so maybe another approach is needed.

    – achAmháin
    Nov 20 '18 at 22:23













  • @sofend - I see. Well, that's why I was asking. I thought there might be a portion that's more random regardless of the generator (because UUIDs were spec'ed a certain way, for example, regardless the generator). I can narrow down the list of generators to Java (mulitple versions though) and Google's protobuf libraries.

    – Andrew Cheong
    Nov 20 '18 at 22:24













  • @achAmháin - Yup, and I know most of the generators and versions in use. My question is precisely what to do in the mixed case.

    – Andrew Cheong
    Nov 20 '18 at 22:25













  • The "right" answer in my opinion is to create a second, short identifier and either add it to the record, or if that schema is set in stone, create a trivial lookup table or service. Tell the user their short ID. Integrate lookup by short ID into the help desk tools, etc. ING Direct used to do this. Their transaction IDs had values like "27" or "15" or similar. I think I only once saw a 3-digit tx ID. Of course those were scoped to individual accounts thus keeping the IDs short, but presumably the user knows their name and other characteristics and so their account ID can be retrieved.

    – sofend
    Nov 20 '18 at 22:30
















1















Suppose we have an existing set of UUIDs (say, millions, though it doesn't matter) that may have been generated by different clients, so that we don't know the algorithm that generated any UUID. But we can assume that they are popular implementations.



Are there a set of 8 or more digits (not necessarily contiguous, though ideally yes) that are less or more likely to collide?



For example, I've seen the uuid() function in MySQL, when used twice in the same statement, generate 2 UUIDs exactly the same except the 5th through 8th digits:



0dec7a69-ded8-11e8-813e-42010a80044f

0decc891-ded8-11e8-813e-42010a80044f

    ^^^^


What is the answer generally?



The application is to expose a more compact ID for customers to copy and paste or communicate over phone. Unfortunately we're bound to using UUIDs in the backend, and understandably reluctant to creating mappings between long and short versions of IDs, but we can live with using a truncated UUID that occasionally collides and returns more than 1 result.






java uuid hash-collision







share|improve this question























  • UUIDs are implemented in a wide variety of algorithms. Some Use MAC (or similar) addresses for part and then part is based on timestamp and some bits are random. Others, the whole UUID is pseudo-random. In short: can you narrow down your question: What is the actual UUID generator being used?

    – sofend
    Nov 20 '18 at 22:22











  • With your two there being so close in value during the same query, it’s probably a time based UUID (v1 I think?). However, I’m not sure which, if any, parts are less likely to differ, I’m sure it wouldn’t matter if the user is copy/pasting anyway. I can see the annoyance in having to read out one over the phone all the time, though so maybe another approach is needed.

    – achAmháin
    Nov 20 '18 at 22:23













  • @sofend - I see. Well, that's why I was asking. I thought there might be a portion that's more random regardless of the generator (because UUIDs were spec'ed a certain way, for example, regardless the generator). I can narrow down the list of generators to Java (mulitple versions though) and Google's protobuf libraries.

    – Andrew Cheong
    Nov 20 '18 at 22:24













  • @achAmháin - Yup, and I know most of the generators and versions in use. My question is precisely what to do in the mixed case.

    – Andrew Cheong
    Nov 20 '18 at 22:25













  • The "right" answer in my opinion is to create a second, short identifier and either add it to the record, or if that schema is set in stone, create a trivial lookup table or service. Tell the user their short ID. Integrate lookup by short ID into the help desk tools, etc. ING Direct used to do this. Their transaction IDs had values like "27" or "15" or similar. I think I only once saw a 3-digit tx ID. Of course those were scoped to individual accounts thus keeping the IDs short, but presumably the user knows their name and other characteristics and so their account ID can be retrieved.

    – sofend
    Nov 20 '18 at 22:30














1












1








1








Suppose we have an existing set of UUIDs (say, millions, though it doesn't matter) that may have been generated by different clients, so that we don't know the algorithm that generated any UUID. But we can assume that they are popular implementations.



Are there a set of 8 or more digits (not necessarily contiguous, though ideally yes) that are less or more likely to collide?



For example, I've seen the uuid() function in MySQL, when used twice in the same statement, generate 2 UUIDs exactly the same except the 5th through 8th digits:



0dec7a69-ded8-11e8-813e-42010a80044f

0decc891-ded8-11e8-813e-42010a80044f

    ^^^^


What is the answer generally?



The application is to expose a more compact ID for customers to copy and paste or communicate over phone. Unfortunately we're bound to using UUIDs in the backend, and understandably reluctant to creating mappings between long and short versions of IDs, but we can live with using a truncated UUID that occasionally collides and returns more than 1 result.






java uuid hash-collision







share|improve this question














Suppose we have an existing set of UUIDs (say, millions, though it doesn't matter) that may have been generated by different clients, so that we don't know the algorithm that generated any UUID. But we can assume that they are popular implementations.



Are there a set of 8 or more digits (not necessarily contiguous, though ideally yes) that are less or more likely to collide?



For example, I've seen the uuid() function in MySQL, when used twice in the same statement, generate 2 UUIDs exactly the same except the 5th through 8th digits:



0dec7a69-ded8-11e8-813e-42010a80044f

0decc891-ded8-11e8-813e-42010a80044f

    ^^^^


What is the answer generally?



The application is to expose a more compact ID for customers to copy and paste or communicate over phone. Unfortunately we're bound to using UUIDs in the backend, and understandably reluctant to creating mappings between long and short versions of IDs, but we can live with using a truncated UUID that occasionally collides and returns more than 1 result.






java uuid hash-collision




java uuid hash-collision






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 20 '18 at 21:54









Andrew CheongAndrew Cheong

19.4k105498




19.4k105498













  • UUIDs are implemented in a wide variety of algorithms. Some Use MAC (or similar) addresses for part and then part is based on timestamp and some bits are random. Others, the whole UUID is pseudo-random. In short: can you narrow down your question: What is the actual UUID generator being used?

    – sofend
    Nov 20 '18 at 22:22











  • With your two there being so close in value during the same query, it’s probably a time based UUID (v1 I think?). However, I’m not sure which, if any, parts are less likely to differ, I’m sure it wouldn’t matter if the user is copy/pasting anyway. I can see the annoyance in having to read out one over the phone all the time, though so maybe another approach is needed.

    – achAmháin
    Nov 20 '18 at 22:23













  • @sofend - I see. Well, that's why I was asking. I thought there might be a portion that's more random regardless of the generator (because UUIDs were spec'ed a certain way, for example, regardless the generator). I can narrow down the list of generators to Java (mulitple versions though) and Google's protobuf libraries.

    – Andrew Cheong
    Nov 20 '18 at 22:24













  • @achAmháin - Yup, and I know most of the generators and versions in use. My question is precisely what to do in the mixed case.

    – Andrew Cheong
    Nov 20 '18 at 22:25













  • The "right" answer in my opinion is to create a second, short identifier and either add it to the record, or if that schema is set in stone, create a trivial lookup table or service. Tell the user their short ID. Integrate lookup by short ID into the help desk tools, etc. ING Direct used to do this. Their transaction IDs had values like "27" or "15" or similar. I think I only once saw a 3-digit tx ID. Of course those were scoped to individual accounts thus keeping the IDs short, but presumably the user knows their name and other characteristics and so their account ID can be retrieved.

    – sofend
    Nov 20 '18 at 22:30



















  • UUIDs are implemented in a wide variety of algorithms. Some Use MAC (or similar) addresses for part and then part is based on timestamp and some bits are random. Others, the whole UUID is pseudo-random. In short: can you narrow down your question: What is the actual UUID generator being used?

    – sofend
    Nov 20 '18 at 22:22











  • With your two there being so close in value during the same query, it’s probably a time based UUID (v1 I think?). However, I’m not sure which, if any, parts are less likely to differ, I’m sure it wouldn’t matter if the user is copy/pasting anyway. I can see the annoyance in having to read out one over the phone all the time, though so maybe another approach is needed.

    – achAmháin
    Nov 20 '18 at 22:23













  • @sofend - I see. Well, that's why I was asking. I thought there might be a portion that's more random regardless of the generator (because UUIDs were spec'ed a certain way, for example, regardless the generator). I can narrow down the list of generators to Java (mulitple versions though) and Google's protobuf libraries.

    – Andrew Cheong
    Nov 20 '18 at 22:24













  • @achAmháin - Yup, and I know most of the generators and versions in use. My question is precisely what to do in the mixed case.

    – Andrew Cheong
    Nov 20 '18 at 22:25













  • The "right" answer in my opinion is to create a second, short identifier and either add it to the record, or if that schema is set in stone, create a trivial lookup table or service. Tell the user their short ID. Integrate lookup by short ID into the help desk tools, etc. ING Direct used to do this. Their transaction IDs had values like "27" or "15" or similar. I think I only once saw a 3-digit tx ID. Of course those were scoped to individual accounts thus keeping the IDs short, but presumably the user knows their name and other characteristics and so their account ID can be retrieved.

    – sofend
    Nov 20 '18 at 22:30

















UUIDs are implemented in a wide variety of algorithms. Some Use MAC (or similar) addresses for part and then part is based on timestamp and some bits are random. Others, the whole UUID is pseudo-random. In short: can you narrow down your question: What is the actual UUID generator being used?

– sofend
Nov 20 '18 at 22:22





UUIDs are implemented in a wide variety of algorithms. Some Use MAC (or similar) addresses for part and then part is based on timestamp and some bits are random. Others, the whole UUID is pseudo-random. In short: can you narrow down your question: What is the actual UUID generator being used?

– sofend
Nov 20 '18 at 22:22













With your two there being so close in value during the same query, it’s probably a time based UUID (v1 I think?). However, I’m not sure which, if any, parts are less likely to differ, I’m sure it wouldn’t matter if the user is copy/pasting anyway. I can see the annoyance in having to read out one over the phone all the time, though so maybe another approach is needed.

– achAmháin
Nov 20 '18 at 22:23







With your two there being so close in value during the same query, it’s probably a time based UUID (v1 I think?). However, I’m not sure which, if any, parts are less likely to differ, I’m sure it wouldn’t matter if the user is copy/pasting anyway. I can see the annoyance in having to read out one over the phone all the time, though so maybe another approach is needed.

– achAmháin
Nov 20 '18 at 22:23















@sofend - I see. Well, that's why I was asking. I thought there might be a portion that's more random regardless of the generator (because UUIDs were spec'ed a certain way, for example, regardless the generator). I can narrow down the list of generators to Java (mulitple versions though) and Google's protobuf libraries.

– Andrew Cheong
Nov 20 '18 at 22:24







@sofend - I see. Well, that's why I was asking. I thought there might be a portion that's more random regardless of the generator (because UUIDs were spec'ed a certain way, for example, regardless the generator). I can narrow down the list of generators to Java (mulitple versions though) and Google's protobuf libraries.

– Andrew Cheong
Nov 20 '18 at 22:24















@achAmháin - Yup, and I know most of the generators and versions in use. My question is precisely what to do in the mixed case.

– Andrew Cheong
Nov 20 '18 at 22:25







@achAmháin - Yup, and I know most of the generators and versions in use. My question is precisely what to do in the mixed case.

– Andrew Cheong
Nov 20 '18 at 22:25















The "right" answer in my opinion is to create a second, short identifier and either add it to the record, or if that schema is set in stone, create a trivial lookup table or service. Tell the user their short ID. Integrate lookup by short ID into the help desk tools, etc. ING Direct used to do this. Their transaction IDs had values like "27" or "15" or similar. I think I only once saw a 3-digit tx ID. Of course those were scoped to individual accounts thus keeping the IDs short, but presumably the user knows their name and other characteristics and so their account ID can be retrieved.

– sofend
Nov 20 '18 at 22:30





The "right" answer in my opinion is to create a second, short identifier and either add it to the record, or if that schema is set in stone, create a trivial lookup table or service. Tell the user their short ID. Integrate lookup by short ID into the help desk tools, etc. ING Direct used to do this. Their transaction IDs had values like "27" or "15" or similar. I think I only once saw a 3-digit tx ID. Of course those were scoped to individual accounts thus keeping the IDs short, but presumably the user knows their name and other characteristics and so their account ID can be retrieved.

– sofend
Nov 20 '18 at 22:30












2 Answers
2






active

oldest

votes


















2














Suggestion: first 8 digits



1c59f6a6-21e6-481d-80ee-af3c54ac400a

^^^^^^^^


All generator implementations are required to use the same algorithms for a given version, so worry about the latter rather than the former.



UUID version 1 & version 2 are generally arranged from most to least entropy for a given source. So, the first 8 digits are probably the least likely to collide.



UUID version 4 and version 3 & 5 are designed to have uniform entropy, aside from the reserved digits for version and variant. So the first 8 digits are as good as any others.






share|improve this answer





















  • 1





    An exact answer, thanks!

    – Andrew Cheong
    Nov 21 '18 at 21:29



















2














There is one method that will work, no matter the caveats of the UUID specification. Since a UUID is in itself intended to be globally unique, a secure hash made out of it using a proper algorithm with at least the same bit size will have the same properties.
Except that the secure hash will have entropy through the hash value instead of specific locations.



As an example, you could do:



MessageDigest digest = MessageDigest.getInstance("SHA-256");

byte hash = digest.digest(uuid.toString().getBytes(StandardCharsets.UTF_8));


And then you take as many bits out of the hash as you need and convert them back to a String.



This is a one-way function though; to map it back to the UUID in a fast an efficient manner, you need to keep a mapping table. (You can of course check if a UUID matches the shorter code by performing the one-way hash on the UUID again)



However, if you were to take a non-contiguous portion out of the UUID, you would have the same issue.






share|improve this answer
























  • Ah, of course! That's a great point.

    – Andrew Cheong
    Nov 20 '18 at 22:37











  • Interesting idea. Wikipedia has a list of hash functions. Java offers the Checksum interface with 2 or 3 implementations. The Adler32 is not appropriate for a small input such as a UUID. But perhaps the 32-bits produced by the CRC32 or CRC32C classes might be appropriate.

    – Basil Bourque
    Nov 24 '18 at 20:56













Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53402176%2fwhich-digits-of-a-uuid-are-least-likely-to-collide-if-the-generator-e-g-java-v%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









2














Suggestion: first 8 digits



1c59f6a6-21e6-481d-80ee-af3c54ac400a

^^^^^^^^


All generator implementations are required to use the same algorithms for a given version, so worry about the latter rather than the former.



UUID version 1 & version 2 are generally arranged from most to least entropy for a given source. So, the first 8 digits are probably the least likely to collide.



UUID version 4 and version 3 & 5 are designed to have uniform entropy, aside from the reserved digits for version and variant. So the first 8 digits are as good as any others.






share|improve this answer





















  • 1





    An exact answer, thanks!

    – Andrew Cheong
    Nov 21 '18 at 21:29
















2














Suggestion: first 8 digits



1c59f6a6-21e6-481d-80ee-af3c54ac400a

^^^^^^^^


All generator implementations are required to use the same algorithms for a given version, so worry about the latter rather than the former.



UUID version 1 & version 2 are generally arranged from most to least entropy for a given source. So, the first 8 digits are probably the least likely to collide.



UUID version 4 and version 3 & 5 are designed to have uniform entropy, aside from the reserved digits for version and variant. So the first 8 digits are as good as any others.






share|improve this answer





















  • 1





    An exact answer, thanks!

    – Andrew Cheong
    Nov 21 '18 at 21:29














2












2








2







Suggestion: first 8 digits



1c59f6a6-21e6-481d-80ee-af3c54ac400a

^^^^^^^^


All generator implementations are required to use the same algorithms for a given version, so worry about the latter rather than the former.



UUID version 1 & version 2 are generally arranged from most to least entropy for a given source. So, the first 8 digits are probably the least likely to collide.



UUID version 4 and version 3 & 5 are designed to have uniform entropy, aside from the reserved digits for version and variant. So the first 8 digits are as good as any others.






share|improve this answer















Suggestion: first 8 digits



1c59f6a6-21e6-481d-80ee-af3c54ac400a

^^^^^^^^


All generator implementations are required to use the same algorithms for a given version, so worry about the latter rather than the former.



UUID version 1 & version 2 are generally arranged from most to least entropy for a given source. So, the first 8 digits are probably the least likely to collide.



UUID version 4 and version 3 & 5 are designed to have uniform entropy, aside from the reserved digits for version and variant. So the first 8 digits are as good as any others.







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 24 '18 at 20:32









Basil Bourque

113k28386545




113k28386545










answered Nov 21 '18 at 21:22









StephenSStephenS

35235




35235








  • 1





    An exact answer, thanks!

    – Andrew Cheong
    Nov 21 '18 at 21:29














  • 1





    An exact answer, thanks!

    – Andrew Cheong
    Nov 21 '18 at 21:29








1




1





An exact answer, thanks!

– Andrew Cheong
Nov 21 '18 at 21:29





An exact answer, thanks!

– Andrew Cheong
Nov 21 '18 at 21:29













2














There is one method that will work, no matter the caveats of the UUID specification. Since a UUID is in itself intended to be globally unique, a secure hash made out of it using a proper algorithm with at least the same bit size will have the same properties.
Except that the secure hash will have entropy through the hash value instead of specific locations.



As an example, you could do:



MessageDigest digest = MessageDigest.getInstance("SHA-256");

byte hash = digest.digest(uuid.toString().getBytes(StandardCharsets.UTF_8));


And then you take as many bits out of the hash as you need and convert them back to a String.



This is a one-way function though; to map it back to the UUID in a fast an efficient manner, you need to keep a mapping table. (You can of course check if a UUID matches the shorter code by performing the one-way hash on the UUID again)



However, if you were to take a non-contiguous portion out of the UUID, you would have the same issue.






share|improve this answer
























  • Ah, of course! That's a great point.

    – Andrew Cheong
    Nov 20 '18 at 22:37











  • Interesting idea. Wikipedia has a list of hash functions. Java offers the Checksum interface with 2 or 3 implementations. The Adler32 is not appropriate for a small input such as a UUID. But perhaps the 32-bits produced by the CRC32 or CRC32C classes might be appropriate.

    – Basil Bourque
    Nov 24 '18 at 20:56


















2














There is one method that will work, no matter the caveats of the UUID specification. Since a UUID is in itself intended to be globally unique, a secure hash made out of it using a proper algorithm with at least the same bit size will have the same properties.
Except that the secure hash will have entropy through the hash value instead of specific locations.



As an example, you could do:



MessageDigest digest = MessageDigest.getInstance("SHA-256");

byte hash = digest.digest(uuid.toString().getBytes(StandardCharsets.UTF_8));


And then you take as many bits out of the hash as you need and convert them back to a String.



This is a one-way function though; to map it back to the UUID in a fast an efficient manner, you need to keep a mapping table. (You can of course check if a UUID matches the shorter code by performing the one-way hash on the UUID again)



However, if you were to take a non-contiguous portion out of the UUID, you would have the same issue.






share|improve this answer
























  • Ah, of course! That's a great point.

    – Andrew Cheong
    Nov 20 '18 at 22:37











  • Interesting idea. Wikipedia has a list of hash functions. Java offers the Checksum interface with 2 or 3 implementations. The Adler32 is not appropriate for a small input such as a UUID. But perhaps the 32-bits produced by the CRC32 or CRC32C classes might be appropriate.

    – Basil Bourque
    Nov 24 '18 at 20:56
















2












2








2







There is one method that will work, no matter the caveats of the UUID specification. Since a UUID is in itself intended to be globally unique, a secure hash made out of it using a proper algorithm with at least the same bit size will have the same properties.
Except that the secure hash will have entropy through the hash value instead of specific locations.



As an example, you could do:



MessageDigest digest = MessageDigest.getInstance("SHA-256");

byte hash = digest.digest(uuid.toString().getBytes(StandardCharsets.UTF_8));


And then you take as many bits out of the hash as you need and convert them back to a String.



This is a one-way function though; to map it back to the UUID in a fast an efficient manner, you need to keep a mapping table. (You can of course check if a UUID matches the shorter code by performing the one-way hash on the UUID again)



However, if you were to take a non-contiguous portion out of the UUID, you would have the same issue.






share|improve this answer













There is one method that will work, no matter the caveats of the UUID specification. Since a UUID is in itself intended to be globally unique, a secure hash made out of it using a proper algorithm with at least the same bit size will have the same properties.
Except that the secure hash will have entropy through the hash value instead of specific locations.



As an example, you could do:



MessageDigest digest = MessageDigest.getInstance("SHA-256");

byte hash = digest.digest(uuid.toString().getBytes(StandardCharsets.UTF_8));


And then you take as many bits out of the hash as you need and convert them back to a String.



This is a one-way function though; to map it back to the UUID in a fast an efficient manner, you need to keep a mapping table. (You can of course check if a UUID matches the shorter code by performing the one-way hash on the UUID again)



However, if you were to take a non-contiguous portion out of the UUID, you would have the same issue.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 20 '18 at 22:31









Erwin BolwidtErwin Bolwidt

24k123858




24k123858













  • Ah, of course! That's a great point.

    – Andrew Cheong
    Nov 20 '18 at 22:37











  • Interesting idea. Wikipedia has a list of hash functions. Java offers the Checksum interface with 2 or 3 implementations. The Adler32 is not appropriate for a small input such as a UUID. But perhaps the 32-bits produced by the CRC32 or CRC32C classes might be appropriate.

    – Basil Bourque
    Nov 24 '18 at 20:56





















  • Ah, of course! That's a great point.

    – Andrew Cheong
    Nov 20 '18 at 22:37











  • Interesting idea. Wikipedia has a list of hash functions. Java offers the Checksum interface with 2 or 3 implementations. The Adler32 is not appropriate for a small input such as a UUID. But perhaps the 32-bits produced by the CRC32 or CRC32C classes might be appropriate.

    – Basil Bourque
    Nov 24 '18 at 20:56



















Ah, of course! That's a great point.

– Andrew Cheong
Nov 20 '18 at 22:37





Ah, of course! That's a great point.

– Andrew Cheong
Nov 20 '18 at 22:37













Interesting idea. Wikipedia has a list of hash functions. Java offers the Checksum interface with 2 or 3 implementations. The Adler32 is not appropriate for a small input such as a UUID. But perhaps the 32-bits produced by the CRC32 or CRC32C classes might be appropriate.

– Basil Bourque
Nov 24 '18 at 20:56







Interesting idea. Wikipedia has a list of hash functions. Java offers the Checksum interface with 2 or 3 implementations. The Adler32 is not appropriate for a small input such as a UUID. But perhaps the 32-bits produced by the CRC32 or CRC32C classes might be appropriate.

– Basil Bourque
Nov 24 '18 at 20:56




















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid …



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53402176%2fwhich-digits-of-a-uuid-are-least-likely-to-collide-if-the-generator-e-g-java-v%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







-

Popular posts from this blog

How to change which sound is reproduced for terminal bell?

Image
3 Recently upgrade to 18.10 from 18.04, and using the terminal is becoming annoying: the new alert sound is a drip ( /usr/share/sounds/gnome/default/alerts/drip.ogg ), and the previous one is still located at ( /usr/share/sounds/ubuntu/stereo/bell.ogg ). My issue is that at the gnome-terminal, when autocompleting or pressing left BOTH sounds are reproduced, at the same time. I want to just have ubuntu/stereo/bell.ogg active, not both . At the moment I have been only able to reduce the volume of the alerts (but still both are played), or turn the alerts down (but I dislike both "solutions"). gnome-terminal 18.10 teminal-bell share | improve this question
Read more

Can I use Tabulator js library in my java Spring + Thymeleaf project?

Image
0 I want to add Tabulator js to my java project. I added tabulator.min.js, tabulator.min.css to resources folder. After that added to my html page these dependencies as recommending in readme.md. <link rel="stylesheet" th:href="@{/css/tabulator.min.css}"> <script type="text/javascript" th:src="@{/js/tabulator.min.js}"></script> Now my tables view all elements, that I have in the html page, but not correct. In the documentation of Tabulator is example how to create header and table, var table = new Tabulator("#example-table", { columns:[ {title:"Name", field:"name", sorter:"string", width:200, editor:true}, {title:"Age", field:"age", sorter:"
Read more

Title Spacing in Bjornstrup Chapter, Removing Chapter Number From Contents

Image
up vote 5 down vote favorite 2 I would like to make it so that the vertical space below the title of each chapter is the same when using the Bjornstrup package (i.e. so that the descenders do not affect the spacing - as shown by the red arrow in the picture below). I think I'm fairly happy with the spacing around "A chapter", so I'd really like titles without descenders (e.g. "Contents") to have the same vertical spacing as "A chapter" below the title. I would also like to remove the large "0" in the contents title. Any help appreciated, as always. documentclass[11pt,a4paper]{book} % Packages[![enter image description here][1]][1] usepackage[left=3.5cm, right=3.5cm, top=4.3cm, bottom=4.25cm]{geometry} usepackage[utf8]{inputenc} usepackage{libertine} usepackage[libertine]{newtx
Read more