When encoding a number the library throw an exception if the number is loo long (greater than MAX_NUMBER) but return an empty string for negative numbers. IMHO this is a little unexpected, using two different behaviours for the same thing, input validation.

Since negative numbers are also illegal arguments, shouldn't it throw a IllegalArgumentException?

Both:

Hashids hashids = new Hashids("this is my salt");
long[] numbers = hashids.decode("0");

and:

Hashids hashids = new Hashids("this is my salt");
long[] numbers = hashids.decode("test.txt");

are causing exceptions in various places.

I realize that they are not valid hashes, but the exception should either be declared or handled.

Hope this helps.

I understand the desire to be completely compatible with the Javascript implementation/limitiations, as explained in #47 and in the docs, but is it possible to provide a toggle that disables this functionality?

This would ensure backward compatibility with Javascript's limitations, but would allow this library to make use of the full potential that the Java platform provides.

Other implementations (such as Scala and .Net) don't impose these restrictions and allow the library to be used with the native implementation of the number.

Hello,

I was looking into this great library for my project, but I quickly found undocumented limitation that this library doesn't support any number > 9007199254740992L. Could you please explain the reasoning behind this limitation?

ids.encode(new Random().nextLong()

Exception in thread "main" java.lang.IllegalArgumentException: number can not be greater than 9007199254740992L at org.hashids.Hashids.encode(Hashids.java:178) at io.remotable.experiments.ids.IdsExperiment.main(IdsExperiment.java:21)

From issue Issue 43 - kmandeville:

I have found two other occurrences where I get ArrayIndexOutOfBoundsException from deep in the HashIds code. Hashids hashids = new Hashids("this is my salt"); long[] numbers = hashids.decode("[]");

and

Hashids hashids = new Hashids("this is my salt"); long[] numbers = hashids.decode("()");

Like the original submitter above, these aren't valid hashes, but I'm running into these errors in my web app because someone COULD put these characters in as an ID in a URL accidentally or on purpose. My app is just passing in these characters directly into HashIds. I would expect something other than ArrayIndexOutOfBoundsExceptions.

Since we are using a salt, it might be a good idea to have a version as part of the actual id. That will allow us to change the salt later if we need to. I'm not sure if this is out of scope for this library or maybe should be added as a best practice. What do you guys think?

Cheers, Itay

if you call the encode(number) with a random large number. then numberHashInt += (numbers[i] % (i+100)) has a chance to return a negative number, in my case -35. the next calculation use alphabet.toCharArray()[numberHashInt % alphabet.length()] could thow an ArrayIndexOutOfBoundsException.

I ran a quick stress test on this library and I'm seeing very poor and unpredictable performance. Generating 1,000,000 ids from the same Hashids instance (same salt) takes anywhere between 15 and 90 seconds on a 2.9GHz i7 CPU using 1.8 GB of RAM. There's also a strange stall somewhere between 30k and 60k in the test loop, after which the rest of the test runs quickly.

Here's my test case:

    // generates a random 32 character string
    Hashids h = new Hashids(RandomStringUtils.random(32));
    long start = System.currentTimeMillis();
    for (int i = 0; i < 1000000; i++) {
      h.encode(i);
    }
    long end = System.currentTimeMillis();
    long duration = end - start;
    System.out.println("time taken: " + duration/1000 + " seconds");
    System.out.println("hashes per second: " + 1000000/(duration/1000.0));

I got this exception when trying to decode some bad data. This test case illustrates the exception.

public class TestClass
{
    @Test
    public void test()
    {
        Hashids hasher = new Hashids("this is my salt", 3);
        long[] numbers = hasher.decode("A");
    }
}

And it throws this exception.

java.lang.StringIndexOutOfBoundsException: String index out of range: 2
	at java.lang.String.charAt(String.java:658)
	at org.hashids.Hashids._encode(Hashids.java:292)
	at org.hashids.Hashids._decode(Hashids.java:350)
	at org.hashids.Hashids.decode(Hashids.java:194)
	at TestClass.test(TestClass.java:15)

Looks like any character that is in HashIds.guards will throw this exception. Other input like "asdf" or any other character not in HashIds.guards seem to work ok.

Debugging, I noticed that on the call to _encode, usually an array with 0L is passed, but when one of those chars is used, the call is made with an empty array.

Hi, When using different salt it should return empty array. But I recognized the behavior is quite unpredictable, there is a probability that it decodes to a wrong number instead or crashes with an ArrayIndexOutOfBoundsException.

Here and example that will decode to a wrong number:

    @Test
    public void encodeAndDecodeTokenWithWrongKey() {
        Hashids a = new Hashids("supersecret",4);
        Hashids b = new Hashids("differentsupersecret",4);

        long sampleId = 123l;
        String token = a.encode(sampleId);

        long[] ids = b.decode(token); // []long id = { 81143 }
        assertEquals(0, ids.length);
    }

assertion will fail, id[0] will be 81143

Same test with sampleId = 37l will cause "ArrayIndexOutOfBoundsException"

The doc says:

decodable hashes from unsigned (long) integers

but then it says

All (long) integers need to be greater than or equal to zero

And the implementation caps the max number to 2^53 (0-9,007,199,254,740,992)

https://github.com/10cella/hashids-java/blob/162a263c8007652472bf1821a26d33190730f8a5/src/main/java/org/hashids/Hashids.java#L24

• IF unsigned 64-bit integer was support, it would accept: 2^64 or 0 - 18,446,744,073,709,551,616 (1.8x10^19)
• IF signed 64-bit integer was support from zero up, it would accept: 2^63 or 0 - 9,223,372,036,854,775,807 (9.2x10^18)

You currently support 53 bit long integers - I can only assume that is a bug? Java's primitives are always signed, so you have about 2^63 values in the plus and minus range. The most logical range would be 2^63 if you only want to support from 0 up and not make the caller convert to unsigned longs?

When generating hashes that are separated by 100 the hash strings are very similar. This is unavoidable with this implementation and perhaps not a huge deal, but maybe it would be best if the periodicity were a number that is not so "tidy". This PR adds the ability to construct the class with a user-specified hash mod base. I personally would use a similarly large prime number, like 97. The strings are very similar for every 97 ids, but this is probably less likely to be noticed.

Also increase JUnit 4 version to avoid CVE flagging

In encode, we passed a greater number(like 44913000000003047) than fixed MAX_LIMIT(9007199254740992L). How to solve this case and handle any number to encode.

Added a new Hashids constructor to support customized "separators" plus a pre-check for NULL that prevents a NullException by defaulting to DEFAULT_SEPS (this behaviour is modeled after the "salt" pre-check for NULL).

Added a pre-check for NULL for the custom "alphabet" that prevents a NullException by defaulting to DEFAULT_ALPHABET (this behaviour is also modeled after the "salt" pre-check for NULL).

Added rudimentary comments for existing constructors for better Javadoc output. Added relevant details about the new constructor that supports custom "separators" (should this also be mentioned in the documentation on the web site?).

Version 2.0 Proposal

This issue will be a discussion point to exchange ideas about version 2.0.

Big picture

The community is urging for a more java idiom version, and the current version can't handle these changes, that's why I'm proposing a new version, incorporating all the needs from the community in a broad discussion.

What about v2?

The new version must be compatible with original implementation as much as it can, without sacrificing java idiom. We will discuss how it will be implemented and the design considerations will be made here.

@cazacugmihai Proposal

• [ ] Use of char arrays and StringBuilder instead of Strings
• [ ] Precompute and cache recurrent operations
• [ ] Helper class (CharUtils) for working with char arrays

@iggymoran Proposal

• [] Relax MAX_NUMBER restriction

@KangoV Proposal

• [] BigInteger as input/output

Reference implementation PR #53.