Hello, I was expecting the barcode in the README to contain the string "NaN9~!D" but unfortunately it's a CODE_128 containing 141141594 😢

https://github.com/dylang/shortid

If I already have an existing 16 bytes of a uuid, can I use nanoid to generate a shorter id from that (providing a given alphabet) and also ensuring an even distribution of generated ids? I suppose the generated id length would vary in that case so I suppose the even distribution wouldn't work?

I think we could put a link to Nano ID repo to this logo

Not sure if we should just test 6, 8 and 10 (like in most projects) or is it intended to also test Node.js 9?

Hey there,

What's the reason you jumped from v1.3.4 to v2? What are the breaking changes and how can I update my code? It would be great if you could make this obvious and maybe include it in the readme file.

Thanks

To be sure about RNG distribution we need some test

@wenliangdai Can I ask you to translate React Native section in docs into Chinese version?

We can minify CSS by csso and remove .hljs-* classes which we don’t use

view-source:https://zelark.github.io/nano-id-cc/

UUID collision probability is too low for many users. Many of users want to have smaller ID and smaller alphabet. It will be good to give them a collision: alphabet + ID length + IDs/hour → years of work before 1% collision

@wenliangdai @gucong3000 hi, thanks for the help in translating PostCSS docs.

This project got 1M/month downloads. Maybe you want to translate it too? The docs are not so big. And it will be a good reason to mention your in tweets. =^_^=

How this library compare to https://www.npmjs.com/package/uniqid

Dear Andrey:

I am a PHPer,you can call me Chen.I star your nanoid lib and I checked the source code,then I make a copy from your Javascript version in PHP.
But I have some issue in index.js,I do not understand why that is different algorithm between formart.js for generate id or I just misunderstood?

PS: Here is my PHP version nano-id, if you have time and interest,check it: https://github.com/hidehalo/nanoid-php
Thank you!!

Seen here:

What's the reason for the if statement? Is this a holdover from before the mask was calculated?

Maybe I'm missing something. But, if it's removed. It clean up the code a lot as the while loop would disappear as well.

The IDs per hour allowed by the calculator should be 1or more. If I intend to type 10 and start with "1", the entire page freezes.

It would be better if the page just says, "The speed should be 1 or more" , like it says when the input field is blank.

The security section proclaims random % alphabet to be insecure, and it understandably is, when the range of random isn't divisible by the length of alphabet and parts of the random space get "folded" into the smaller space. (I'm sure there's a mathematical term for this...) Anyway, it would be nice if the readme explained why the above algorithm is bad.

So I started wondering about the usual Math.random() * alphabet.length approach and tested it a bit: https://gist.github.com/akx/7afb144ed2b4d32886a29bfd45e7986f

With 100,000 characters generated, the distribution seems reasonably uniform:

(The "dip" at the lower values disappears on subsequent runs, so it's nothing to worry about.)

However, using const cryptoRand = () => crypto.randomBytes(1)[0] / 255.; as the rand function, the distribution is significantly non-uniform, which is kind of strange. (Can someone explain what's happening there?)

• The same profile remained over multiple trials.
• The same profile occurs on both OSX and Moby Linux, as run by Docker-on-Mac.
• Also, to rule out any weirdness that might be caused by requesting only one byte at a time, I tested with an approach that fills in a larger buffer of randomBytes.

(ps. What's the magic 1.6 in

Hello,
i like this random generator.

In our-project we need some cluster-safe generator uniq, short and human friendly. We have tried Hashids, but it doesn't fulfil our expectations.

Our backend is written in Ruby language so i reimplement your original algorithm in ruby:
https://github.com/radeno/nanoid.rb

Hi, ai. I was reading your code and found var step = Math.ceil(310 / alphabet.length * size) in format.js.

Would you mind telling me how you choose 310? instead of 256?

Thanks a lot!

@ai I have ported nanoid in python while experimenting with it in my own project.

You can check my work here:

https://github.com/puyuan/py-nanoid

TODOs:
I haven't included your simpler 64 alphabet algorithm yet (will do so when I have time), currently its based on the general algorithm.

If you find it ok, perhaps you can help me link the python version.

The README says the "alphabet must contain less than 256 symbols.". It would be nice to have a technical explanation of why. Hopefully something more than "It will not be secure." :)

Reading through the README, it sounds you arrived at the number of symbols so that Nano Id has a greater than or equal number of unique combinations when compared to UUID v4. Right?

According to wiki, UUID v4 has 122 bits that contribute to randomness.

Default Nano ID has a (26+26+10+2 = 64) symbol alphabet (6 bits). So with 6 bits per symbol, and 22 symbols, we arrive at (6*22 = 132) total bits.

So we could totally drop the number of symbols down to 21 (126 bits) and still have more unique combinations than UUID v4.

Saves everyone 1 whole symbol! Unless of course I'm missing something, which is very much possible.

I created a Java version of NanoId. You can find it here: https://github.com/aventrix/jnanoid

Disclaimer

I am aware of #20.
The fact is that I wasn't aware of it 24 hours ago, when I started playing around with this port of mine.

Description

I have documented well my code, added references to the original repo (you can see many Github links inside nanoid.go and ported the test suite at test/index.test.js).

The main difference with matoous/go-nanoid is that I've strictly followed the original API. Thus, I feel it would be nice to add a link to my repo just below @matoous'

Thus the last part of README.md would become:

Other Programming Languages

• Go
  • matoous/go-nanoid (uses a different API)
  • jkomyno/nanoid (uses pretty much the same API as this original repo)
• PHP
  • hidehalo/nanoid-php

@ai, what do you thunk about it?

Is this correct?

var url = '_~getRandomVcryp0123456789bfhijklqsuvwxzABCDEFGHIJKLMNOPQSTUWXYZ'

https://github.com/ai/nanoid/blob/master/index.browser.js#L3

The Size Limit anchor in README.md should presumably point to some resource about Size Limit. It instead points back here.

The crypto.randomFillSync was added in the Node.js v7.10.0. Node.js 6.x is in the Long Term Support status until April 2019. Requirement of crypto.randomFillSync is a breaking change for Node.js 6.x users.

Could you please republish v1.2.3 as v1.2.5, and v1.2.4 as v2.0.0 to be more SemVer-friendly, or at least specify the correct engines field in the package.json?

Hi, There is a way to generate IDs words avoiding bad words ?
Here a nice ref:
https://github.com/LDNOOBW/List-of-Dirty-Naughty-Obscene-and-Otherwise-Bad-Words
Thanks

nanoid/generate can only be used synchronously, if you want to generate ids asynchronously you can't specify a custom length or alphabet.

@ai
Currently nanoid by default uses A-Za-z0-9_~ for its alphabet. Now if we reduce the alphabet to human readable characters, say, A-Z, 0-9, excluding the commonly confused 01OI, what would be the impact on collision probability in nanoid?

And, if we reduce the ID length from 22 symbols to say 10 symbols, how would the uniqueness be effected in a single processor and/or multi-processor scenario?

I found a problem while running on React Native.

Are there any plans to support React Native?

TLDR: follow the RFC for URLs. Complete reasoning.

Do you have a comparison with UUID on likelihood of collisions? For example, I've read on Wikipedia that for UUIDs that is "50% probability of at least one collision when generating 1 billion UUIDs per second for about 85 years". Does nanoid have such claims?

It would be awesome if we could create NanoId within the browser using the Crypto API

Some test is required to validate e.g. that produced strings are keeping probability of (at least) all chars same with known probability (e.g. 5%).

Many people like me use this library as unique URL identifier and it works really good.

One thing should be better to generate friendly URLs. Restrict first and last characters like underscore and tilde ( _ ~ ) from default character set.
It is better human readable when ID is something like this: 0BM_z7D than this 0BMOz7_ or ~BMOz7D.

Same case why we should restrict special characters is when they leading next to each other.
Currently we can get some of these combinations: 0B__z7D, 0B~_z7D which also doesn't look so good.

i find that this cannot support ie10 , so sad

Ran in to this error when I try to use a custom generator.

(def hex-id-generator (generate "0123456789abcdef"))

Exception

Uncaught TypeError: id.length is not a function
    at nano_id.custom.generate.cljs$core$IFn$_invoke$arity$2 (custom.cljc?rel=1531759015549:22)
    at my_tool$events$generate_system_key (events.cljs?rel=1531759024127:14)
    at events.cljs?rel=1531759024127:96
    at std_interceptors.cljc?rel=1531759023484:115
    at re_frame$std_interceptors$db_handler__GT_interceptor_$_db_handler_before (std_interceptors.cljc?rel=1531759023484:111)
    at re_frame$interceptor$invoke_interceptor_fn (interceptor.cljc?rel=1531759014576:68)
    at re_frame$interceptor$invoke_interceptors (interceptor.cljc?rel=1531759014576:106)
    at re_frame$interceptor$execute (interceptor.cljc?rel=1531759014576:199)
    at re_frame$events$handle (events.cljc?rel=1531759022762:65)
    at re_frame.router.EventQueue.re_frame$router$IEventQueue$_process_1st_event_in_queue$arity$1 (router.cljc?rel=1531759022973:178)
    at re_frame$router$_process_1st_event_in_queue (router.cljc?rel=1531759022973:84)
    at re_frame.router.EventQueue.re_frame$router$IEventQueue$_run_queue$arity$1 (router.cljc?rel=1531759022973:197)
    at re_frame$router$_run_queue (router.cljc?rel=1531759022973:86)
    at router.cljc?rel=1531759022973:145
    at re_frame.router.EventQueue.re_frame$router$IEventQueue$_fsm_trigger$arity$3 (router.cljc?rel=1531759022973:168)
    at re_frame$router$_fsm_trigger (router.cljc?rel=1531759022973:80)
    at router.cljc?rel=1531759022973:186

Environment;

[org.clojure/clojurescript "1.10.238"]
                 [reagent "0.7.0"]
                 [re-frame "0.10.5"]
                 [nano-id "0.9.2"]
                 [com.andrewmcveigh/cljs-time "0.5.2"]

Hi, your concern seems to be only with key collisions, which is fine. But I also want (visual) uniformity. I would suggest to make the length the exact same size as requested.

Thanks

Instead of converting random byte to char we can convert the whole byte to 2 chars

Ported many tests and code follows new Nano ID 2.0 https://github.com/aidarkhanov/py-nanoid

Though, I have discussed with Paul Yuan, maintainer of https://github.com/puyuan/py-nanoid, an update of his project to the new version and we have agreed upon a merge.

Nevertheless, my project has one more case - port of Nano ID dictionary to Python.

Why adding another implementation to the list?
In my opinion, having another point of view and providing another option to a user is great opportunity to increase popularity of Nano ID.

I know there is a generate method, to change the alphabet and length of the id that will be generated.

The case is; I need to migrate my id generation away from Meteor/Random, while I also don't want my id's to start look different.

I can achieve this with:

const generate = require('nanoid/generate');
const alphabet = '23456789ABCDEFGHJKLMNPQRSTWXYZabcdefghijkmnopqrstuvwxyz';
const length = 17;

generate(alphabet, length); // D8taKDubtMzi58jZn

But, that means that I need to specify this alphabet and length on every place where I need an ID.

It would be nice if there was a method to change the defaults so that the next require('nanoid')() uses custom settings.

// main.js
const nano = require('nanoid');
nano.config({
  alphabet: '23456789ABCDEFGHJKLMNPQRSTWXYZabcdefghijkmnopqrstuvwxyz',
  length: 17,
});

// some-other-file.js
const nano = require('nanoid');
nano(); // Kg6gwCgG44zEK8u6g

Is it possible to generate id based on a given pattern
e.g.
generate('0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ', 5); //returns 5LSHO
could be extended to
generate('0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ', 5, 'XXX-XX'); //could return 5LS-HO

I'm not sure that this is a big problem. But at least this is incorrect behavior.

@ai I noticed earlier you started to maintain dylang/shortid so I'm wondering that what's the difference between shortid and nanoid?

Hi, I ported nanoid in Clojure and CojureScript.
You can find it here.

Secure random values (in Node.js) in README.md (in both Chinese version) is LOST!

Maybe we can change to this：

https://en.wikipedia.org/wiki/Random_number_generation#Physical_methods.

Hey,

Thanks for building this - very cool and I appreciate all the hard work you do on it! :-)

I notice that the README says nanoid doesn't generate unpredictable ids on RN due to the lack of a secure RNG. However, would it be possible to use something like https://www.npmjs.com/package/react-native-securerandom for example?

I was thinking to avoid a dependency on this third-party RN package, maybe we could use dependency injection to inject a secure RNG, user's choice, and give instructions for simultaneously adding this react-native-securerandom. So current users would not be impacted since current defaults would work. But new users could pass in a reference to some function that uses react-native-securerandom to supply the secure random bytes (via a promise).

I'd be happy to work on a PR for this if there's interest, but could you give me a few pointers where to get started in nanoid, like where to do the dependency injection and roughly how and I could give it a shot?

Thanks1

Kind of simple question, but better safe then sorry :)
Example:

const generate = require('nanoid/generate');
const alphabet = '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ';
const prefix = 'myCustomPrefix';
const identifier =  prefix + generate(alphabet, 12);

Is that anything to worry about?
Thanks for help in advance.