I saw that hashid intentionally doesn't support encoding strings because it's not secure, but I was wondering about hashing uuids as a way to shorten them (not for security). is that possible with this library? thanks!

thx

The JS version just returns an empty array.

Example with salt -70d0ch47b07:
Encode [42, 1, 255] -> KafyS8p.
If we change the first symbol to u, DecodeWithError produces [42, 21, 999] from uafyS8p without the error.
JS version returns an empty array.

How can I solve this issue?

NewWithData allows spaces in alphabet.

go-hashids provides EncodeInt64 but it actually rejects negative numbers in below. Does it make sense to use uint64, or provides a uint64 variant?

// EncodeInt64 hashes an array of int64 to a string containing at least MinLength characters taken from the Alphabet.
// Use DecodeInt64 using the same Alphabet and Salt to get back the array of int64.
func (h *HashID) EncodeInt64(numbers []int64) (string, error) {
	if len(numbers) == 0 {
		return "", errors.New("encoding empty array of numbers makes no sense")
	}
	for _, n := range numbers {
		if n < 0 {
			return "", errors.New("negative number not supported")
		}
	}

I'm using go-hashids along with hashids' Ruby implementation. In some cases, go-hashids rejects inputs that exceed MaxInt, while the Ruby implementation can handle it because Ruby's Integer can be larger than Go's MaxInt.

I made a fork to workaround the issue and happy to upstream something like this.

https://github.com/kzys/go-hashids/

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().

The badge points to https://ci.appveyor.com/project/speps/libtessdotnet, which I assume is a mistake.

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 [].

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.

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

I've created a package that is perfect for generating ids with all numbers:

https://github.com/pjebs/optimus-go

Thanks for your help in the previous issue I had posted regarding an all-number alphabet.

With introduction of NewWithData returning error vs panic there's now a chance of runtime error if the error is ignored. Say you have an alphabet with two same characters (causes error to be thrown) and you choose to ignore the error and continue with h.Encode() it will lead to runtime error because (h *HashID) is nil. Readme example by default ignores the error.

While of course it is bad practice to ignore errors I wonder if all exported functions needs check if h == nil. Only reason why I am thinking about such an implementation is because the library is small (easy to implement such check) and because the library can play a crucial part of web application setup. Rather than dying without error message it would be nice to have message saying why something failed.

Instead of returning an error as is the convention in Go, this library panics when it encounters (non-exceptional) errors. A function being passed bad input is not exceptional, it is to be expected, and so an error should be returned if it happens.

Since code in master is considered 1.0.0, the go1 branch (which go get pulls by default) should be updated to use this new stable version.

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)
	}
}

Current implementation fails if we use numeric only alphabet.
But from an algorithm perspective it should be working.

Can it encode string?
When i try it with a sting([]byte) with a small MinLength, it returned a long string.

Would be very nice for those of us using package managers such as glide.

Hi Team,

I don't know whether or not you think this is a valid bug or not.

If I do something like:

// HashMaker performs a salted hash based upon epoch
func HashMaker() string {
	now := time.Now()
	hash := hashids.NewData()
	value := now.Unix()
	hash.Salt = "hello world"
	h, _ := hashids.NewWithData(hash)
	e, _ := h.Encode(toIntSlice(string(value)))
	got, _ := h.DecodeWithError(e)
	fmt.Println("should be", value, "got", got)

	return e
}

I get something like:

should be 1538515448 got [65533]
jolM
should be 1538515449 got [65533]
jolM
should be 1538515450 got [65533]
jolM
should be 1538515451 got [65533]
jolM

I guess that my expectation is to see something like:

should be <epoch> got <epoch>
<hash>

I am sending the epoch as a string into the hash as data, and I can replace it for the salt as well, and it results in the same problem.

go-hashids has one release tag, 1.0.0

There are a few changes to master -- most notably the prototype change to NewWithData() from issue #29 -- that postdate the 1.0.0 tag.

When I added go dep vendoring to a project that depends on hashids, it pulled the 1.0.0 release instead of the latest master, this breaking my build.

This was an easy fix via a dep override, but it'd be nice to have the current master version tagged, since that's probably what most people are using anyway, and it'll save a few minutes of vendoring hassle.

NewWithData should return (*HashID, error) so that error cases can be handled.

The website example at http://hashids.org/go/ appears to be outdated since it no longer aligns with the example code in this project's README. Is this the right place to get that fixed?

Is that okey that javascript and golang implementation is not compatible?
Thanks!

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

Hi
I am trying to use hashids on golang and big int , the length of number is 18, length of alphabet is 62.
Encode and decode is work.
But decode result is wrong. just like that:
243253735426375465
decode result is
243253735426375464
or
243253735426375445

I don't see the curse word protection implemented. Am I missing something? Or maybe it's planned for later? In my testing with a non-default alphabet, I was seeing letter sequences that the hashids.org website says will not occur. The hashids.org website has the following in the documentation:

%@&

This code was written with the intent of placing generated hashes in visible places - like the URL.

Therefore, the algorithm tries to avoid generating most common English curse words by never placing the following letters next to each other:

c, C, s, S, f, F, h, H, u, U, i, I, t, T

what is min length can i use to have unique ids ?

Hi I only want to hash 1 value at a time. The built in function seems to only support an array of int as input.

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.

Hi, the release version v1.0.0 is too old. Could you please make a new tag for the newest commit ?
How about v2.0.0 because there is a breaking change since 2017/05/09. Thank you.

step：
go get github.com/speps/go-hashids

error：
cannot resolve file 'go-hashids',but file exist