Tag v2.0.0 exists, but it is not valid to make a clean Go module version: v2.0.0 is listed as "incompatible".

Here is the process to create a v2.0.1 that would fix the problem:

1. Fix the module go.mod to add a /v2 suffix
2. Tag v2.0.1

sed -i '' '1s!.*!module github.com/speps/go-hashids/v2!' go.mod
git add go.mod
git commit -m "Fix go module to add /v2 suffix #57"
git tag v2.0.1
git push origin v2.0.1

Currently it's impossible to safely Encode/Decode int64 IDs unless all involved systems run on a 64bit machine where int data type is 64-bit. Hashids libraries in other languages (checked C#, JS) seem to support 64bit IDs.

This PR changes the []int to []int64 everywhere. All tests pass. However, since it changes the signature of the Encode/Decode functions all users of this library have to migrate their code manually.

• Fix building hashid command line
• Fix go 1.10 warning about Error vs. Errorf
• Remove unused function
• Reduce memory allocations in tests by over half, greatly reducing allocations per encode and decode, significantly reducing amount of garbage which collects

Memory usage of go-hashids.test

go test -memprofile mem.out -test.memprofilerate=1
go tool pprof --alloc_space go-hashids.test mem.out

before: 1314.59kB

after: 592.42kB

If you use the Salt like "\xcb\x91\x96\xd0\xa7\x36\x91\x5b\xbf\xd4" the output of both the JS and PHP version is the same (haven't tested other libraries) but the output of his library is completely different

Will there be a UInt32 and UInt64 version for these:

func (h *HashID) Encode(numbers []int) (string, error) func (h *HashID) EncodeInt64(numbers []int64) (string, error)

Obviously it may create incompatibilities with eg PHP version of library but for some people that is irrelevant.

hashids is in the middle of a fairly performance sensitive bit of code where I work (Returning thousands of search results, each result id gets encoded). The allocations which happen end up taking a significant amount of the time, so this PR works to reduce the number of allocations per execution from 31 + varying based on the input data to 5 always, while trying to keep the code reasonable to read / work through. The company's code using this doesn't use MinLength, so that I haven't spent a lot of time optimizing, and has more allocations which could probably be removed (Although less than it used to). There is a test added which should make it easier for someone to improve if they want down the line, as well as make sure it doesn't regress.

Overall:

• EncodeInt64 allocations reduced from 31 to 5
• DecodeInt64WithError allocations reduced from 21 to 11 when there is a salt and MinLength isn't specified for single-int64 encodings

Using TestDecodeWithError on https://github.com/speps/go-hashids/blob/master/hashids_test.go#L163 I noticed that it fails and no error is produced if I do the following:

hdata.Alphabet = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890"
dec, err := hid.DecodeWithError("")

However if I use hdata.Alphabet = "PleasAkMEFoThStx" that is currently in the test it works. Depending on the hash dec is either [] or [some number].

My expectation here was to see an error and [].

This should not fail, and it never used to, but now it does. The hashid with min length 20 fails to decode the encoded string of length 30.

func TestHashids(t *testing.T) {

	// MinLength 30
	hData30 := hashids.NewData()
	hData30.Salt = "blarg123"
	hData30.MinLength = 30
	h30, err := hashids.NewWithData(hData30)
	if err != nil {
		t.Error(err)
	}

	encoded30, err := h30.EncodeInt64([]int64{4})
	if err != nil {
		t.Error(err)
	}
	decoded30, err := h30.DecodeInt64WithError(encoded30)
	if err != nil {
		t.Error(err)
	}
	if len(decoded30) != 1 || decoded30[0] != []int64{4}[0] {
		t.Error("Expected: ", []int64{4}, "; Got: ", decoded30)
	}

	// Same hashid, but minLength 20
	hData20 := hashids.NewData()
	hData20.Salt = "blarg123"
	hData20.MinLength = 20
	h20, err := hashids.NewWithData(hData20)
	if err != nil {
		t.Error(err)
	}

	// Should still be able to decode, as the only change is MinLength
	decoded20, err := h20.DecodeInt64WithError(encoded30)
	if err != nil {
		t.Error(err)
	}
	if len(decoded20) != 1 || decoded20[0] != []int64{4}[0] {
		t.Error("Expected: ", []int64{4}, "; Got: ", decoded20)
	}
}

What is the consequence of changing the minimum alphabet length to 10.

I want my alphabet to be "0123456789"?

I changed your code. I only want to encode numbers and it seems to work.

Hashed ids are often used as part of urls. They are outside of program's control (e.g. a user on the website might manually modify url).

If such modified value is passed to Decode(), it'll panic, which is against Go conventions, see http://blog.golang.org/defer-panic-and-recover:

The convention in the Go libraries is that even when a package uses panic internally, its external API still presents explicit error return values.

It would be better if it was Decode(hash string) ([]int, error).

This would require breaking the API, which might not be a good idea, so an alternative would be to provide additional DecodeSafe (not a great name) or IsValid(hash string) bool so that the string can be checked for correctness before calling Decode().

Running the following code you end up with an index out of range panic:

package main

import hashids "github.com/speps/go-hashids"

func main() {
    hd := hashids.NewData()
    hd.Salt = "salt1"
    hd.MinLength = 10
    h := hashids.NewWithData(hd)
    h.Encode([]int{0})
}

panic: runtime error: index out of range

goroutine 16 [running]:
runtime.panic(0x311a0, 0x5e67c)
    /usr/local/Cellar/go/1.3.1/libexec/src/pkg/runtime/panic.c:279 +0xf5
github.com/speps/go-hashids.(*HashID).Encode(0x2080b6000, 0x2208239ef8, 0x1, 0x1, 0x0, 0x0, 0x0, 0x0)
    /Volumes/CaseSensitive/go/src/github.com/speps/go-hashids/hashids.go:172 +0x11fa
main.main()
    /private/tmp/hashids.go:14 +0xd5

goroutine 17 [runnable]:
runtime.MHeap_Scavenger()
    /usr/local/Cellar/go/1.3.1/libexec/src/pkg/runtime/mheap.c:507
runtime.goexit()
    /usr/local/Cellar/go/1.3.1/libexec/src/pkg/runtime/proc.c:1445

goroutine 18 [runnable]:
bgsweep()
    /usr/local/Cellar/go/1.3.1/libexec/src/pkg/runtime/mgc0.c:1976
runtime.goexit()
    /usr/local/Cellar/go/1.3.1/libexec/src/pkg/runtime/proc.c:1445

As far as I can tell, when the second guard character is appended to the result an index offset larger than the length of result is used. Might be worth adding a regression test for this as well.

Thanks, Adrian

The documentation for the DecodeWithError functions currently don't reflect what the code actually does. When using DecodeWithError with a different MinLength the sanity check will fail, had to look at the actual code to figure out why that is happening because the comment said that MinLength has no effect, which is not correct.

The PR fixes the comments and mentions the sanity check which is done by the functions.

Hi in original implementation encode the hex 5a74d76ac89b05000e977baa with salt this is my salt is equal with bv89jEY45DslgBOeD2Qg. but i tested it with this repo and it's different with original implementation. i fixed it in this PR.

Due to lack of any example available on the web for changing Alphabet string to be used instead of DefaultAlphabet, I had to read the code files to understand this. I have added a new example so its easier for other users to figure this out.