search

DaveAKing / guava-libraries

Automatically exported from code.google.com/p/guava-libraries
Apache License 2.0
0 stars 0 forks source link

String representation of Murmur3_x64_128 hash in Guava #1147

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
I want to use Guava implememntation of Murmur3 x64 128 to hash some strings.
I implemented my hashing code, and some script to migrate my old data, but 
Python smhasher module results are different than Guava results.

I wrote about it in smhasher issue 
http://code.google.com/p/smhasher/issues/detail?id=6

Original issue reported on code.google.com by kamil....@gmail.com on 13 Sep 2012 at 11:26

GoogleCodeExporter commented 9 years ago 
If you just call Hasher#hashString(String), it'll hash each character in order 
(no char encoding).

What you want is Hasher#hashString(String, Charset).
HashCode foxHash =  Hashing.murmur3_128(0).hashString(
    "The quick brown fox jumps over the lazy dog", Charsets.UTF_8);
assertEquals("6c1b07bc7bbc4be347939ac4a93c437a", foxHash.toString());

Original comment by kurt.kluever on 13 Sep 2012 at 4:49

GoogleCodeExporter commented 9 years ago 
Rather than "no char encoding", isn't it more accurate to say that the char 
encoding used is UTF-16 since that's what Java chars are?

Original comment by cgdec...@gmail.com on 13 Sep 2012 at 6:53

GoogleCodeExporter commented 9 years ago 
Yup - I think saying it's UTF_16LE is even more accurate.

Original comment by kak@google.com on 13 Sep 2012 at 7:36

GoogleCodeExporter commented 9 years ago 
The point being that no encoding process of the characters is happening.  
However the bytes are represented already is what is hashed.

Original comment by kevinb@google.com on 14 Sep 2012 at 12:13

GoogleCodeExporter commented 9 years ago 
This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:13

GoogleCodeExporter commented 9 years ago

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:08