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

Biblatex bibliography style without URLs when DOI exists (in Overleaf with Zotero bibliography)

Image
2 2 I have a Zotero bibliography in Overleaf. I use biblatex . usepackage[backend=biber,citestyle=authoryear]{biblatex} addbibresource{zoteroALH.bib} Bibliography entries look like: @book{de_saint-gervais_uniformization_2016, title = {Uniformization of {Riemann} {Surfaces}}, isbn = {978-3-03719-145-3}, url = {https://www.ems-ph.org/books/book.php?proj_nr=198&srch=series%7Chem}, urldate = {2019-02-03}, author = {de Saint-Gervais, Paul Henri}, year = {2016}, doi = {10.4171/145} } In the bibliography down the paper the reference shows like this: There is the DOI, great, but also the URL which is unnecessary when the DOI is there. How can I remove the URL when the DOI is present? biblatex bibliographies overleaf zote
Read more

ComboBox Display Member on multiple fields

Image
2 I'm trying to set the .DisplayMember property of a ComboBox in C#, but I want to bind it to multiple columns in the .DataSouce . My SQL looks like this: SELECT PersNbr, PersFirstName, PersMiddleName, PersLastName FROM Pers WHERE PersNbr = :persNbr; I'm saving this query in a DataTable so each column selected has it's own column in the Datatable . I want to make the .DisplayMember a combination of PersFirstName + PersMiddleName + PersLastName so their full name appears like this: comboBox.DisplayMemeber = "PersFirstName" + "PersMiddleName" + "PersLastName" I know I can just to this on the query: SELECT PersNbr, (PersFirstName || PersMiddleName || PersLastName) PersName and then just do this: comboBox.DisplayMember = "PersName"; but I
Read more

Is it possible to collect Nectar points via Trainline?

Image
2 Since I am not eligible for any Railcard, the only available discount/bonus scheme is Nectar Card for me. GWR, SWR, LNER and Virgin Trains allow to collect Nectar points and I have already linked a card to my GWR account. A friend suggested me to use Trainline App, because it can search for bus tickets either. I had a look at the application, but could not see any option for Nectar. Is there a way to collect Nectar points when I buy tickets via Trainline? uk trains loyalty-programs trainline share | improve this question asked Dec 2 '18 at 15:50 ahmedus 3,224 5 19 49
Read more