ਕੀ ਤੁਹਾਨੂੰ ਅਜਿਹੇ ਪਛਾਣਕਰਤਾ (identifier) ਦੀ ਲੋੜ ਹੈ ਜੋ ਕਿਸੇ ਹੋਰ ਵੱਲੋਂ ਬਣਾਏ ਗਏ ਪਛਾਣਕਰਤਾ ਨਾਲ ਕਦੇ ਵੀ ਮੇਲ ਨਾ ਖਾਵੇ, ਉਹ ਵੀ ਅਜਿਹੀ ਮਸ਼ੀਨ 'ਤੇ ਜਿਸ ਬਾਰੇ ਤੁਸੀਂ ਕਦੇ ਸੁਣਿਆ ਵੀ ਨਾ ਹੋਵੇ, ਅਤੇ ਇਸ ਲਈ ਕਿਸੇ ਦੀ ਇਜਾਜ਼ਤ ਲੈਣ ਦੀ ਵੀ ਲੋੜ ਨਾ ਪਵੇ? ਇਹੀ ਕੰਮ UUID ਕਰਦਾ ਹੈ। ਇਹ 128-ਬਿੱਟ ਦਾ ਇੱਕ ਨੰਬਰ ਹੈ, ਜਿਸਨੂੰ ਆਮ ਤੌਰ 'ਤੇ 8-4-4-4-12 ਪੈਟਰਨ ਵਿੱਚ 36 ਅੱਖਰਾਂ ਵਜੋਂ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਸਦਾ ਪੂਰਾ ਡਿਜ਼ਾਈਨ ਇਸ ਗੱਲ 'ਤੇ ਆਧਾਰਿਤ ਹੈ ਕਿ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਦੋ ਨੰਬਰ ਕਦੇ ਵੀ ਇੱਕੋ ਜਿਹੇ ਨਹੀਂ ਹੋਣਗੇ — ਭਾਵੇਂ ਕੋਈ ਵੀ ਇਹ ਤੈਅ ਨਾ ਕਰ ਰਿਹਾ ਹੋਵੇ ਕਿ ਕਿਸਨੂੰ ਕਿਹੜਾ ਨੰਬਰ ਮਿਲੇਗਾ। ਇਹ ਮੁਫਤ ਜਨਰੇਟਰ ਇਹਨਾਂ ਨੂੰ ਸਿੱਧਾ ਤੁਹਾਡੇ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਬਣਾਉਂਦਾ ਹੈ: 'ਵਰਜ਼ਨ' ਵਿੱਚੋਂ ਕੋਈ ਵਰਜ਼ਨ ਚੁਣੋ, 'ਚੋਣਾਂ ਦੀ ਗਿਣਤੀ' ਵਿੱਚ ਦੱਸੋ ਕਿ ਤੁਹਾਨੂੰ ਕਿੰਨੇ ਚਾਹੀਦੇ ਹਨ, ਅਤੇ 'ਜਨਰੇਟ ਕਰੋ' 'ਤੇ ਦਬਾਓ। ਪੇਜ ਖੁੱਲ੍ਹਣ 'ਤੇ v4 ਦਾ ਇੱਕ UUID ਪਹਿਲਾਂ ਹੀ ਬਣਿਆ ਹੁੰਦਾ ਹੈ, ਜਿਸਦੀ ਜ਼ਿਆਦਾਤਰ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਪਹਿਲਾ ਪਛਾਣਕਰਤਾ ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਕਲਿੱਕ ਨਾਲ ਮਿਲ ਜਾਂਦਾ ਹੈ।
ਹਰੇਕ ਪਛਾਣਕਰਤਾ ਤੁਹਾਡੇ ਬ੍ਰਾਊਜ਼ਰ ਦੁਆਰਾ Web Crypto API ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ। ਜਿੱਥੇ ਬ੍ਰਾਊਜ਼ਰ ਸਪੋਰਟ ਕਰਦਾ ਹੈ ਉੱਥੇ ਵਰਜ਼ਨ 4 (v4) crypto.randomUUID() ਵਰਤਦਾ ਹੈ ਅਤੇ ਹੋਰ ਥਾਵਾਂ 'ਤੇ crypto.getRandomValues() ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ — ਇਹ Math.random() ਵਰਗੇ JavaScript ਦੇ ਸੂਡੋ-ਰੈਂਡਮ (pseudo-random) ਫੰਕਸ਼ਨ ਦੀ ਬਜਾਏ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਅਤ ਰੈਂਡਮਨੈੱਸ (randomness) ਦਾ ਇੱਕ ਠੋਸ ਸਰੋਤ ਹੈ। ਵਰਜ਼ਨ 7 (v7) ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ 48-ਬਿੱਟ ਦਾ ਮਿਲੀਸੈਕਿੰਡ ਟਾਈਮਸਟੈਂਪ ਹੁੰਦਾ ਹੈ, ਫਿਰ ਉਸੇ ਮਿਲੀਸੈਕਿੰਡ ਵਿੱਚ ਵਧਣ ਵਾਲਾ 12-ਬਿੱਟ ਦਾ ਕਾਊਂਟਰ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਫਿਰ 62 ਰੈਂਡਮ ਬਿੱਟ ਹੁੰਦੇ ਹਨ, ਜੋ ਕਿ RFC 9562 ਵਿੱਚ ਦੱਸੀ ਗਈ ਕ੍ਰਮਵਾਰ ਵਿਧੀ ਹੈ; ਇਸੇ ਕਾਊਂਟਰ ਕਾਰਨ ਹਜ਼ਾਰ ਦੀ ਇੱਕ ਬੈਚ ਰਲਗੱਡ ਹੋਣ ਦੀ ਬਜਾਏ ਸਹੀ ਕ੍ਰਮ ਵਿੱਚ ਬਾਹਰ ਆਉਂਦੀ ਹੈ। ਵਰਜ਼ਨ 1 (v1) ਟਾਈਮਸਟੈਂਪ ਨੂੰ ਅਜਿਹੇ ਰੈਂਡਮ ਨੋਡ ਪਛਾਣਕਰਤਾ ਨਾਲ ਜੋੜਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਮਲਟੀਕਾਸਟ ਬਿੱਟ ਸੈੱਟ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ 1990 ਦੇ ਦਹਾਕੇ ਦੇ ਸ਼ੁਰੂਆਤੀ ਵਰਜ਼ਨਾਂ ਵਾਂਗ ਇਹ ਕਦੇ ਵੀ ਤੁਹਾਡੇ ਨੈੱਟਵਰਕ ਕਾਰਡ ਦਾ ਪਤਾ ਨਹੀਂ ਵਰਤਦਾ। ਵਰਜ਼ਨ 3 (v3) ਅਤੇ 5 (v5) ਬਿਲਕੁਲ ਵੀ ਰੈਂਡਮ ਨਹੀਂ ਹੁੰਦੇ: ਇਹ ਕ੍ਰਮਵਾਰ MD5 ਅਤੇ SHA-1 ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਨੇਮਸਪੇਸ ਅਤੇ ਨਾਮ ਨੂੰ ਇਕੱਠੇ ਹੈਸ਼ (hash) ਕਰਦੇ ਹਨ, ਅਤੇ ਇਹ ਹੈਸ਼ਿੰਗ ਵੀ ਤੁਹਾਡੀ ਆਪਣੀ ਡਿਵਾਈਸ 'ਤੇ ਹੀ ਹੁੰਦੀ ਹੈ। ਕਿਸੇ ਵੀ ਸਰਵਰ 'ਤੇ ਕੁਝ ਨਹੀਂ ਭੇਜਿਆ ਜਾਂਦਾ, ਕਿਸੇ ਚੀਜ਼ ਦਾ ਲੌਗ ਨਹੀਂ ਰੱਖਿਆ ਜਾਂਦਾ, ਅਤੇ ਇੱਕ ਵਾਰ ਪੇਜ ਲੋਡ ਹੋਣ ਤੋਂ ਬਾਅਦ ਇਹ ਇੰਟਰਨੈੱਟ ਕੁਨੈਕਸ਼ਨ ਬੰਦ ਹੋਣ 'ਤੇ ਵੀ ਕੰਮ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ।
'ਵਰਜ਼ਨ' ਉਹ ਫੀਲਡ ਹੈ ਜੋ ਬਾਕੀ ਸਭ ਕੁਝ ਤੈਅ ਕਰਦੀ ਹੈ। ਵਰਜ਼ਨ 4 ਵਿੱਚ 122 ਰੈਂਡਮ ਬਿੱਟ ਹੁੰਦੇ ਹਨ ਅਤੇ ਕੋਈ ਖਾਸ ਬਣਤਰ ਨਹੀਂ ਹੁੰਦੀ — ਇਹ ਡਿਫੌਲਟ ਵਿਕਲਪ ਹੈ, ਅਤੇ ਜਦੋਂ ਕਿਸੇ ਪਛਾਣਕਰਤਾ ਨੂੰ ਸਿਰਫ਼ ਯੂਨੀਕ (unique) ਹੋਣਾ ਜ਼ਰੂਰੀ ਹੁੰਦਾ ਹੈ ਤਾਂ ਇਹੀ ਸਹੀ ਚੋਣ ਹੁੰਦੀ ਹੈ। ਵਰਜ਼ਨ 7 ਵਿੱਚ 62 ਰੈਂਡਮ ਬਿੱਟ ਕਾਇਮ ਰਹਿੰਦੇ ਹਨ ਪਰ ਇਸਦੀ ਸ਼ੁਰੂਆਤ ਉਸ ਸਮੇਂ ਨਾਲ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਇਸਨੂੰ ਬਣਾਇਆ ਗਿਆ ਸੀ, ਇਸ ਲਈ ਇਹਨਾਂ ਪਛਾਣਕਰਤਾਵਾਂ ਦੇ ਇੱਕ ਸਮੂਹ ਨੂੰ ਉਹਨਾਂ ਦੇ ਬਣਨ ਦੇ ਸਮੇਂ ਅਨੁਸਾਰ ਤਰਤੀਬ ਵਿੱਚ ਲਗਾਇਆ ਜਾ ਸਕਦਾ ਹੈ; ਇਸੇ ਲਈ ਜਦੋਂ ਪਛਾਣਕਰਤਾ ਨੂੰ ਡੇਟਾਬੇਸ ਦੀ ਕੁੰਜੀ (key) ਬਣਾਉਣਾ ਹੋਵੇ ਤਾਂ ਇਸ ਵਰਜ਼ਨ ਨੂੰ ਚੁਣਿਆ ਜਾਂਦਾ ਹੈ। ਵਰਜ਼ਨ 1 ਸਮੇਂ 'ਤੇ ਆਧਾਰਿਤ ਅਸਲ ਵਿਧੀ ਹੈ, ਜਿਸਨੂੰ ਇੱਥੇ ਉਹਨਾਂ ਸਿਸਟਮਾਂ ਲਈ ਰੱਖਿਆ ਗਿਆ ਹੈ ਜੋ ਅਜੇ ਵੀ ਇਸਦੀ ਮੰਗ ਕਰਦੇ ਹਨ। ਵਰਜ਼ਨ 3 ਅਤੇ 5 ਇੱਕ ਵੱਖਰੀ ਹੀ ਜੋੜੀ ਹਨ: ਇਹ ਡਿਟਰਮਿਨਿਸਟਿਕ (deterministic) ਹਨ, ਮਤਲਬ ਕਿ ਇੱਕੋ ਜਿਹੀ ਇਨਪੁਟ ਦੇਣ 'ਤੇ ਹਮੇਸ਼ਾ ਇੱਕੋ ਪਛਾਣਕਰਤਾ ਬਣਦਾ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਲਈ ਦੋ ਵਾਧੂ ਫੀਲਡਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ — 'ਨੇਮਸਪੇਸ', ਜੋ ਕਿ DNS, URL, OID ਅਤੇ X.500 ਵਰਗੀਆਂ ਪ੍ਰਮਾਣਿਤ ਥਾਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਇੱਕ ਹੋ ਸਕਦੀ ਹੈ ਜਾਂ ਤੁਹਾਡੀ ਆਪਣੀ 'ਕਸਟਮ' ਹੋ ਸਕਦੀ ਹੈ, ਅਤੇ 'ਨਾਮ', ਜੋ ਕਿ ਉਹ ਸਟਰਿੰਗ ਹੈ ਜਿਸਦੀ ਪਛਾਣ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ। ਜੇ ਤੁਸੀਂ v5 ਨੂੰ URL ਨੇਮਸਪੇਸ ਅਤੇ https://example.com/a ਦਿੰਦੇ ਹੋ ਤਾਂ ਤੁਹਾਨੂੰ ਅੱਜ, ਕੱਲ੍ਹ ਅਤੇ ਕਿਸੇ ਹੋਰ ਦੇ ਕੰਪਿਊਟਰ 'ਤੇ ਵੀ ਬਿਲਕੁਲ ਉਹੀ UUID ਮਿਲੇਗਾ। ਇਸੇ ਕਾਰਨ, ਜਦੋਂ ਤੁਸੀਂ v3 ਜਾਂ v5 ਚੁਣਦੇ ਹੋ ਤਾਂ 'ਚੋਣਾਂ ਦੀ ਗਿਣਤੀ' ਵਾਲੀ ਫੀਲਡ ਲੁਕ ਜਾਂਦੀ ਹੈ: ਕਿਉਂਕਿ ਇੱਕੋ ਡਿਟਰਮਿਨਿਸਟਿਕ ਮੁੱਲ ਦੀਆਂ ਹਜ਼ਾਰ ਕਾਪੀਆਂ ਆਖਰਕਾਰ ਇੱਕੋ ਡਿਟਰਮਿਨਿਸਟਿਕ ਮੁੱਲ ਦੀਆਂ ਹਜ਼ਾਰ ਕਾਪੀਆਂ ਹੀ ਹੋਣਗੀਆਂ। ਬਾਕੀ ਹਰ ਵਰਜ਼ਨ ਲਈ 'ਚੋਣਾਂ ਦੀ ਗਿਣਤੀ' 1 ਤੋਂ ਲੈ ਕੇ 1000 ਤੱਕ ਹੋ ਸਕਦੀ ਹੈ।
ਚਾਰ ਸਵਿੱਚਾਂ ਅਸਲ 128 ਬਿੱਟਾਂ ਵਿੱਚ ਕੋਈ ਬਦਲਾਅ ਕੀਤੇ ਬਿਨਾਂ ਆਉਟਪੁੱਟ ਦਾ ਆਕਾਰ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ। 'ਵੱਡੇ ਅੱਖਰ' ਹੈਕਸਾਡੈਸੀਮਲ (hexadecimal) ਅੰਕਾਂ ਨੂੰ ਕੈਪੀਟਲ ਅੱਖਰਾਂ ਵਿੱਚ ਛਾਪਦਾ ਹੈ, 'ਹਾਈਫਨ ਤੋਂ ਬਿਨਾਂ' 32-ਅੱਖਰਾਂ ਵਾਲਾ ਸੰਖੇਪ ਰੂਪ ਦਿੰਦਾ ਹੈ ਜਿਸਨੂੰ ਕੁਝ ਕਾਲਮ ਅਤੇ ਫਾਈਲਾਂ ਦੇ ਨਾਮ ਵੱਧ ਪਸੰਦ ਕਰਦੇ ਹਨ, ਅਤੇ 'ਕਰਲੀ ਬ੍ਰੈਕਟਸ' ਮੁੱਲ ਨੂੰ { } ਵਿੱਚ ਲਪੇਟ ਦਿੰਦਾ ਹੈ — ਵਿੰਡੋਜ਼ (Windows) ਅਤੇ .NET ਦੀ ਦੁਨੀਆ ਇਸੇ ਆਕਾਰ ਨੂੰ GUID ਕਹਿੰਦੀ ਹੈ। 'ਐਡਵਾਂਸਡ ਵਿਕਲਪ' ਦੇ ਹੇਠਾਂ, urn:uuid: ਉਹ ਅਗੇਤਰ (prefix) ਜੋੜ ਦਿੰਦਾ ਹੈ ਜੋ ਇਸਨੂੰ ਇੱਕ ਅਧਿਕਾਰਤ URN ਬਣਾਉਂਦਾ ਹੈ; ਜਦੋਂ ਇਹ ਚਾਲੂ ਹੁੰਦਾ ਹੈ ਤਾਂ 'ਕਰਲੀ ਬ੍ਰੈਕਟਸ' ਅਤੇ 'ਹਾਈਫਨ ਤੋਂ ਬਿਨਾਂ' ਬੰਦ ਹੋ ਜਾਂਦੇ ਹਨ, ਕਿਉਂਕਿ ਸਟੈਂਡਰਡ ਸਿਰਫ਼ ਇੱਕ ਹੀ URN ਰੂਪ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਅਤੇ ਉਹ ਹਾਈਫਨ ਵਾਲਾ ਕੈਨੋਨੀਕਲ (canonical) ਰੂਪ ਹੁੰਦਾ ਹੈ। 'ਕਾਪੀ ਫਾਰਮੈਟ' ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਜਦੋਂ ਤੁਸੀਂ ਕੋਈ ਬੈਚ ਲੈਂਦੇ ਹੋ ਤਾਂ ਉਸਨੂੰ ਕਿਵੇਂ ਜੋੜਿਆ ਜਾਵੇਗਾ: ਹਰ ਲਾਈਨ ਵਿੱਚ ਇੱਕ, ਕਾਮਿਆਂ ਨਾਲ ਵੱਖ ਕੀਤੇ ਹੋਏ, ਜਾਂ ਕੋਡ ਵਿਚਲੀ ਐਰੇ (array) ਵਿੱਚ ਸਿੱਧਾ ਪੇਸਟ ਕਰਨ ਲਈ ਹਰ ਮੁੱਲ ਕੋਟਸ ਵਿੱਚ ਅਤੇ ਅੰਤ ਵਿੱਚ ਇੱਕ ਕਾਮੇ ਨਾਲ। ਨਤੀਜੇ ਦੇ ਹੇਠਾਂ ਇੱਕ ਲਾਈਨ ਹੁੰਦੀ ਹੈ ਜੋ ਬਿੱਟਾਂ ਵਿੱਚ ਰੈਂਡਮਨੈੱਸ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ — v4 ਲਈ 122, v7 ਲਈ 62 — ਅਤੇ v7 ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਬੈਚ ਦੇ ਪਹਿਲੇ ਪਛਾਣਕਰਤਾ ਵਿੱਚ ਐਨਕੋਡ ਕੀਤਾ ਟਾਈਮਸਟੈਂਪ ਦਿਖਾਇਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਜੋ ਮੁੱਲ ਦੇ ਅੰਦਰਲਾ ਸਮਾਂ ਲੁਕਿਆ ਰਹਿਣ ਦੀ ਬਜਾਏ ਸਪਸ਼ਟ ਦਿਖਾਈ ਦੇਵੇ। 'ਸਭ ਕਾਪੀ ਕਰੋ' ਅਤੇ 'ਫਾਈਲ ਵਿੱਚ ਸੰਭਾਲੋ' ਦੋਵੇਂ 'ਕਾਪੀ ਫਾਰਮੈਟ' ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ। 'ਹਿਸਟਰੀ' ਤੁਹਾਡੇ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਤੁਹਾਡੀਆਂ ਪਿਛਲੀਆਂ 10 ਬੈਚਾਂ ਨੂੰ ਸੰਭਾਲ ਕੇ ਰੱਖਦੀ ਹੈ: ਕਿਸੇ ਬੈਚ ਨੂੰ ਵਾਪਸ ਲਿਆਉਣ ਲਈ ਉਸ 'ਤੇ ਕਲਿੱਕ ਕਰੋ, ਕਿਸੇ ਇੱਕ ਐਂਟਰੀ ਨੂੰ ਕਾਪੀ ਜਾਂ ਡਿਲੀਟ ਕਰੋ, ਜਾਂ ਸਭ ਕੁਝ ਸਾਫ਼ ਕਰ ਦਿਓ। 'ਸਾਫ਼ ਕਰੋ' ਬਟਨ ਤੁਹਾਡੀਆਂ ਸੈਟਿੰਗਾਂ ਨੂੰ ਉਵੇਂ ਹੀ ਰੱਖ ਕੇ ਸਿਰਫ਼ ਨਤੀਜੇ ਨੂੰ ਖਾਲੀ ਕਰ ਦਿੰਦਾ ਹੈ, ਅਤੇ 50 ਤੋਂ ਵੱਧ ਪਛਾਣਕਰਤਾ ਹੋਣ 'ਤੇ ਸੂਚੀ ਪੰਜਾਹ ਲਾਈਨਾਂ ਦੀ ਬਜਾਏ ਸਕ੍ਰੋਲ (scroll) ਹੋਣ ਵਾਲੇ ਇੱਕ ਬਲਾਕ ਦੇ ਰੂਪ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ।
ਇਸ ਪੇਜ 'ਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਪ੍ਰਾਇਮਰੀ ਕੁੰਜੀ (primary key) ਵਜੋਂ v4 ਅਤੇ v7 ਵਿਚਲਾ ਫਰਕ ਹੈ, ਅਤੇ ਇਹ ਸਿਰਫ਼ ਪਸੰਦ ਦਾ ਮਾਮਲਾ ਨਹੀਂ ਹੈ। ਡੇਟਾਬੇਸ ਇੰਡੈਕਸ ਅਜਿਹੇ ਟ੍ਰੀ (trees) ਹੁੰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤਰਤੀਬ (sorted order) ਵਿੱਚ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਕੋਈ ਨਵੀਂ ਕੁੰਜੀ ਉਸ ਤਰਤੀਬ ਵਿੱਚ ਕਿੱਥੇ ਜਾ ਕੇ ਡਿੱਗਦੀ ਹੈ, ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਇਨਸਰਟ (insert) ਕਰਨ ਲਈ ਕਿੰਨਾ ਕੰਮ ਕਰਨਾ ਪਵੇਗਾ। v4 ਦੀ ਕੁੰਜੀ ਰੈਂਡਮ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਲਗਾਤਾਰ ਹੋਣ ਵਾਲੇ ਇਨਸਰਟਸ ਇੰਡੈਕਸ ਦੇ ਕਿਸੇ ਵੀ ਅਣਕਿਆਸੇ ਹਿੱਸੇ ਵਿੱਚ ਡਿੱਗਦੇ ਹਨ: ਭਰੇ ਹੋਏ ਪੇਜ ਵੰਡੇ ਜਾਂਦੇ ਹਨ, ਡੇਟਾਬੇਸ ਦੁਆਰਾ ਮੈਮਰੀ ਵਿੱਚ ਰੱਖੇ ਗਏ ਟ੍ਰੀ ਦੇ ਹਿੱਸੇ ਅਕਸਰ ਉਹ ਨਹੀਂ ਹੁੰਦੇ ਜਿਨ੍ਹਾਂ ਦੀ ਅਗਲੇ ਇਨਸਰਟ ਨੂੰ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਅੰਤ ਵਿੱਚ ਇੰਡੈਕਸ ਉਹਨਾਂ ਕਤਾਰਾਂ (rows) ਦੇ ਮੁਕਾਬਲੇ ਬਹੁਤ ਵੱਡਾ ਅਤੇ ਖਿੰਡਿਆ ਹੋਇਆ (fragmented) ਬਣ ਜਾਂਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਵੱਲ ਇਹ ਇਸ਼ਾਰਾ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ। v7 ਦੀ ਕੁੰਜੀ ਮੌਜੂਦਾ ਮਿਲੀਸੈਕਿੰਡ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਲਗਾਤਾਰ ਹੋਣ ਵਾਲੇ ਇਨਸਰਟਸ ਟ੍ਰੀ ਦੇ ਸੱਜੇ ਪਾਸੇ ਦੇ ਸਿਰੇ 'ਤੇ ਇਕੱਠੇ ਜਾ ਕੇ ਡਿੱਗਦੇ ਹਨ, ਜੋ ਕਿ ਉਹੀ ਪੈਟਰਨ ਹੈ ਜੋ ਆਟੋ-ਇਨਕਰੀਮੈਂਟਿੰਗ ਇੰਟੀਜਰ (auto-incrementing integer) ਪੈਦਾ ਕਰਦਾ ਹੈ ਅਤੇ ਜਿਸ ਪੈਟਰਨ 'ਤੇ ਇੰਡੈਕਸ ਬਣਤਰਾਂ ਆਧਾਰਿਤ ਹੁੰਦੀਆਂ ਹਨ। ਇਹੀ ਅਸਲ ਸਮਝੌਤਾ ਹੈ: v7 ਤੁਹਾਨੂੰ ਕ੍ਰਮਵਾਰ ਕੁੰਜੀ ਵਾਲਾ ਇਨਸਰਟ ਵਤੀਰਾ ਦਿੰਦਾ ਹੈ ਅਤੇ ਨਾਲ ਹੀ ਉਹ ਖਾਸੀਅਤ ਵੀ ਬਰਕਰਾਰ ਰੱਖਦਾ ਹੈ ਜਿਸ ਕਰਕੇ ਤੁਸੀਂ ਪਹਿਲੀ ਥਾਂ 'ਤੇ UUID ਚੁਣਿਆ ਸੀ, ਯਾਨੀ ਕਿ ਕੋਈ ਵੀ ਸਰਵਰ ਨੂੰ ਪੁੱਛੇ ਬਿਨਾਂ ਇਸਨੂੰ ਬਣਾ ਸਕਦਾ ਹੈ। ਇਸਦੀ ਕੀਮਤ ਇਹ ਹੈ ਕਿ ਬਣਨ ਦਾ ਸਮਾਂ ਹੁਣ ਪਛਾਣਕਰਤਾ ਦੇ ਅੰਦਰ ਪੜ੍ਹਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਸ ਨਾਲ ਕੋਈ ਫਰਕ ਪੈਂਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਹ ਤੁਹਾਡੇ ਡੇਟਾ ਬਾਰੇ ਸਵਾਲ ਹੈ, ਫਾਰਮੈਟ ਬਾਰੇ ਨਹੀਂ।
ਕੋਈ ਵੀ ਚੀਜ਼ ਕਦੇ ਵੀ UUID ਦੇ ਯੂਨੀਕ ਹੋਣ ਦੀ ਜਾਂਚ ਨਹੀਂ ਕਰਦੀ; ਇਸਦਾ ਆਕਾਰ ਹੀ ਇਸਦੀ ਗਾਰੰਟੀ ਹੈ। ਕੋਈ ਰਜਿਸਟਰੀ ਨਹੀਂ ਹੁੰਦੀ, ਸਰਵਰ ਦਾ ਕੋਈ ਰਾਊਂਡ-ਟ੍ਰਿਪ ਨਹੀਂ ਹੁੰਦਾ, ਕੋਈ ਲੁੱਕਅੱਪ (lookup) ਨਹੀਂ ਹੁੰਦਾ — ਇੱਕ ਜਨਰੇਟਰ ਨੰਬਰ ਪੈਦਾ ਕਰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਦੇ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਦੋ ਆਪਸ ਵਿੱਚ ਇਸ ਲਈ ਨਹੀਂ ਟਕਰਾਉਂਦੇ (collide ਨਹੀਂ ਹੁੰਦੇ) ਕਿਉਂਕਿ v4 ਦੀਆਂ 2^122 ਸੰਭਵ ਵੈਲਯੂਜ਼ (values) ਹੁੰਦੀਆਂ ਹਨ, ਜੋ ਕਿ ਲਗਭਗ 5.3 ਅਨਡੈਸੀਲੀਅਨ (5.3 × 10^36) ਹਨ। ਬਰਥ-ਡੇ ਪ੍ਰੋਬਲਮ (birthday problem) ਇਸਦੇ ਆਕਾਰ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਦਾ ਇਮਾਨਦਾਰ ਤਰੀਕਾ ਹੈ: ਕਿਸੇ ਵੀ ਦੋ ਪਛਾਣਕਰਤਾਵਾਂ ਦੇ ਮੇਲ ਖਾਣ ਦੀ 50% ਸੰਭਾਵਨਾ ਬਣਨ ਲਈ ਤੁਹਾਨੂੰ ਲਗਭਗ 2.7 ਕੁਇੰਟੀਲੀਅਨ (2.7 × 10^18) ਪਛਾਣਕਰਤਾਵਾਂ ਦੀ ਲੋੜ ਪਵੇਗੀ — ਜੋ ਕਿ 86 ਸਾਲਾਂ ਤੱਕ ਹਰ ਸੈਕਿੰਡ ਵਿੱਚ ਇੱਕ ਅਰਬ ਨਵੇਂ UUID ਬਣਾਉਣ ਦੇ ਬਰਾਬਰ ਹੈ। ਇਹ ਸਮਝਣਾ ਬਹੁਤ ਜ਼ਰੂਰੀ ਹੈ ਕਿ ਇਹ ਕੀ ਵਾਅਦਾ ਕਰਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ। ਇਹ ਇੱਕ ਅੰਕੜਾਤਮਕ (statistical) ਗਾਰੰਟੀ ਹੈ, ਗਣਿਤਕ (arithmetic) ਨਹੀਂ, ਅਤੇ ਇਹ ਸਿਰਫ਼ ਉਦੋਂ ਤੱਕ ਹੀ ਸੱਚ ਰਹਿੰਦੀ ਹੈ ਜਦੋਂ ਤੱਕ ਇਸਦੇ ਪਿੱਛੇ ਦੀ ਰੈਂਡਮਨੈੱਸ ਅਸਲੀ ਹੁੰਦੀ ਹੈ — ਜੇਕਰ ਜਨਰੇਟਰ ਨੂੰ ਗਲਤ ਸੀਡ (seed) ਦਿੱਤੀ ਗਈ ਹੋਵੇ, ਜਾਂ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਨੂੰ ਇਸਦੇ ਐਨਟ੍ਰੋਪੀ ਪੂਲ (entropy pool) ਸਮੇਤ ਕਲੋਨ ਕੀਤਾ ਗਿਆ ਹੋਵੇ, ਤਾਂ ਇਹ ਅਜਿਹੇ ਤਰੀਕੇ ਨਾਲ ਟੁੱਟ ਜਾਂਦਾ ਹੈ ਜਿਸਦਾ ਫਾਰਮੈਟ ਨੂੰ ਪਤਾ ਨਹੀਂ ਲੱਗਦਾ। ਵਰਜ਼ਨ 7 ਇਸ ਸਵਾਲ ਨੂੰ ਹੋਰ ਵੀ ਸੀਮਤ ਕਰ ਦਿੰਦਾ ਹੈ: ਇੱਕ ਮਿਲੀਸੈਕਿੰਡ ਦੇ ਅੰਦਰ-ਅੰਦਰ ਇੱਕ ਜਨਰੇਟਰ ਆਪਣੇ ਆਪ ਨੂੰ ਦੁਹਰਾ ਹੀ ਨਹੀਂ ਸਕਦਾ, ਕਿਉਂਕਿ ਕਾਊਂਟਰ ਰੈਂਡਮ ਨੰਬਰ ਸੁੱਟਣ ਦੀ ਬਜਾਏ ਲਗਾਤਾਰ ਵਧਦਾ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਵੱਖੋ-ਵੱਖਰੇ ਜਨਰੇਟਰਾਂ ਵਿੱਚ 62 ਰੈਂਡਮ ਬਿੱਟ ਇਹ ਕੰਮ ਕਰਦੇ ਹਨ।
UUID ਇੱਕ ਪਛਾਣਕਰਤਾ ਹੈ, ਕੋਈ ਪਾਸਵਰਡ ਨਹੀਂ। ਵਰਜ਼ਨ 4 ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਅਸੰਭਵ ਹੈ, ਅਤੇ ਇਸੇ ਕਾਰਨ ਲੋਕ ਇਸਨੂੰ ਗੁਪਤ (secret) ਮੰਨਣ ਦੀ ਗਲਤੀ ਕਰਦੇ ਹਨ — ਜਿਵੇਂ ਕਿ ਪਾਸਵਰਡ-ਰੀਸੈੱਟ ਲਿੰਕ, ਅੰਦਾਜ਼ਾ ਨਾ ਲਗਾਇਆ ਜਾ ਸਕਣ ਵਾਲਾ URL, ਸੈਸ਼ਨ ਟੋਕਨ, ਜਾਂ API ਕੁੰਜੀ। ਅੰਦਾਜ਼ਾ ਨਾ ਲਗਾਇਆ ਜਾ ਸਕਣਾ ਇੱਕ ਹਕੀਕਤ ਹੈ, ਪਰ ਗੁਪਤਤਾ ਇਸ ਗੱਲ ਦਾ ਗੁਣ ਹੈ ਕਿ ਕਿਸੇ ਵੈਲਯੂ ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਪਛਾਣਕਰਤਾਵਾਂ ਨੂੰ ਜਾਣਬੁੱਝ ਕੇ ਲਾਪਰਵਾਹੀ ਨਾਲ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ: ਇਹ URL ਵਿੱਚ ਮੌਜੂਦ ਹੁੰਦੇ ਹਨ, ਜੋ ਕਿ ਬ੍ਰਾਊਜ਼ਰ ਦੀ ਹਿਸਟਰੀ, ਸਰਵਰ ਲੌਗਜ਼ (logs), ਰੈਫਰਰ (referrer) ਹੈਡਰਜ਼ ਅਤੇ ਐਨਾਲਿਟਿਕਸ ਵਿੱਚ ਦਰਜ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਚੈਟ ਮੈਸੇਜਾਂ ਵਿੱਚ ਪੇਸਟ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਬਾਕੀ ਵਰਜ਼ਨ ਤਾਂ ਇਸ ਤੋਂ ਵੀ ਮਾੜੇ ਵਿਕਲਪ ਹਨ। ਵਰਜ਼ਨ 1 ਅਤੇ ਵਰਜ਼ਨ 7 ਦੋਵੇਂ ਹੀ ਆਪਣੇ ਬਣਨ ਦੇ ਸਮੇਂ ਨੂੰ ਐਨਕੋਡ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਜਿਸ ਕੋਲ ਵੀ ਇਹ ਹੁੰਦਾ ਹੈ, ਉਸਨੂੰ ਅੰਦਾਜ਼ਾ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿ ਇਹ ਕਦੋਂ ਬਣਾਇਆ ਗਿਆ ਸੀ ਅਤੇ ਉਹ ਇਸਦੇ ਨਾਲ ਬਣੀਆਂ ਬਾਕੀ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਦੇ ਘੇਰੇ ਨੂੰ ਵੀ ਛੋਟਾ ਕਰ ਸਕਦਾ ਹੈ। ਵਰਜ਼ਨ 3 ਅਤੇ 5 ਜਾਣਬੁੱਝ ਕੇ ਡਿਟਰਮਿਨਿਸਟਿਕ ਬਣਾਏ ਗਏ ਹਨ: ਕਿਸੇ ਈਮੇਲ ਪਤੇ ਦਾ v5 UUID ਕੋਈ ਹੈਸ਼ ਕੀਤਾ ਹੋਇਆ ਸੀਕ੍ਰੇਟ ਨਹੀਂ ਹੁੰਦਾ, ਇਹ ਇੱਕ ਅਜਿਹੀ ਵੈਲਯੂ ਹੈ ਜਿਸਦੀ ਗਣਨਾ ਉਹੀ ਪਤਾ ਰੱਖਣ ਵਾਲਾ ਕੋਈ ਵੀ ਵਿਅਕਤੀ ਇੱਕ ਸੈਕਿੰਡ ਵਿੱਚ ਕਰ ਸਕਦਾ ਹੈ। ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਨਾਮ ਦੇਣ ਲਈ UUID ਦੀ ਵਰਤੋਂ ਕਰੋ। ਜੇਕਰ ਵੈਲਯੂ ਨੂੰ ਗੁਪਤ ਰੱਖਣਾ ਜ਼ਰੂਰੀ ਹੋਵੇ, ਤਾਂ ਪਾਸਵਰਡ ਜਨਰੇਟਰ ਜਾਂ ਸੀਕ੍ਰੇਟਸ ਲਈ ਬਣਾਈ ਗਈ ਕਿਸੇ ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਟੋਕਨ ਦੀ ਵਰਤੋਂ ਕਰੋ।
ਇਹ UUID ਜਨਰੇਟਰ ਕਿਉਂ ਚੁਣਿਆ ਜਾਵੇ?
- ਸਿਰਫ਼ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਜਨਰੇਸ਼ਨ: ਪਛਾਣਕਰਤਾ ਤੁਹਾਡੀ ਡਿਵਾਈਸ 'ਤੇ ਬਣਦੇ ਹਨ ਅਤੇ ਕਦੇ ਕਿਤੇ ਨਹੀਂ ਭੇਜੇ ਜਾਂਦੇ
- Web Crypto API ਦੀ ਰੈਂਡਮਨੈੱਸ: ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਅਤ, ਨਾ ਕਿ Math.random()
- ਪੰਜ ਵਰਜ਼ਨ ਇੱਕੋ ਥਾਂ 'ਤੇ: ਟੂਲ ਬਦਲੇ ਬਿਨਾਂ v1, v3, v4, v5 ਅਤੇ v7
- ਸਹੀ ਮਾਅਨਿਆਂ ਵਿੱਚ ਕ੍ਰਮਵਾਰ v7: RFC 9562 ਦੇ ਵਰਣਨ ਅਨੁਸਾਰ ਮਿਲੀਸੈਕਿੰਡ ਦੇ ਅੰਦਰਲਾ ਕਾਊਂਟਰ
- ਚਾਰ ਸਟੈਂਡਰਡ ਨੇਮਸਪੇਸਾਂ ਜਾਂ ਤੁਹਾਡੀ ਆਪਣੀ ਨੇਮਸਪੇਸ ਵਾਲੇ ਡਿਟਰਮਿਨਿਸਟਿਕ v3 ਅਤੇ v5
- ਇੱਕੋ ਵਾਰ ਵਿੱਚ 1000 ਤੱਕ ਬਣਾਉਣ ਦੀ ਸਹੂਲਤ, ਪੰਜਾਹ ਤੋਂ ਵੱਧ ਹੋਣ 'ਤੇ ਸੰਖੇਪ ਸਕ੍ਰੋਲ ਹੋਣ ਵਾਲੀ ਸੂਚੀ
- ਹਰ ਆਮ ਆਕਾਰ: ਹਾਈਫਨ ਵਾਲੇ, ਸਾਦੇ, ਵੱਡੇ ਅੱਖਰ, ਬ੍ਰੈਕਟਾਂ ਵਾਲੇ ਜਾਂ urn:uuid: URN
- ਲਾਈਨਾਂ, ਕਾਮਿਆਂ ਜਾਂ ਕੋਟਸ ਵਾਲੀਆਂ ਵੈਲਯੂਜ਼ ਵਜੋਂ ਕਾਪੀ ਕਰੋ ਜੋ ਸਿੱਧਾ ਕੋਡ ਵਿੱਚ ਪੇਸਟ ਹੋ ਜਾਂਦੀਆਂ ਹਨ
- ਅਸੀਮਤ ਅਤੇ ਮੁਫਤ: ਕੋਈ ਸਾਈਨ-ਅੱਪ ਨਹੀਂ, ਵਰਤੋਂ ਦੀ ਕੋਈ ਸੀਮਾ ਨਹੀਂ, ਸਾਡੇ ਸਰਵਰਾਂ 'ਤੇ ਕੁਝ ਨਹੀਂ
UUID ਦੀ ਲੋੜ ਉਦੋਂ ਪੈਂਦੀ ਹੈ ਜਦੋਂ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਨਾਮ ਦੇਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਅਤੇ ਕੋਈ ਵੀ ਇਸ ਗੱਲ ਦੀ ਪੁਸ਼ਟੀ ਨਹੀਂ ਕਰ ਸਕਦਾ ਕਿ ਉਹ ਨਾਮ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਤਾਂ ਨਹੀਂ। ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਉਹਨਾਂ ਕਤਾਰਾਂ (rows) ਲਈ ਇਹ ਪਛਾਣਕਰਤਾ ਬਣਾਉਂਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਉਹ ਇਨਸਰਟ ਕਰਨ ਵਾਲਾ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਜੋ ਆਬਜੈਕਟ ਦੀ ਡੇਟਾਬੇਸ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਆਪਣੀ ਪਛਾਣ ਹੋਵੇ ਅਤੇ ਕਲਾਇੰਟ ਰਾਈਟ (write) ਹੋਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦੌਰਾਨ ਹੀ ਇਸਦਾ ਹਵਾਲਾ ਦੇ ਸਕੇ। ਡਿਸਟ੍ਰੀਬਿਊਟਿਡ ਸਿਸਟਮ ਇਹਨਾਂ 'ਤੇ ਹੋਰ ਵੀ ਜ਼ਿਆਦਾ ਨਿਰਭਰ ਕਰਦੇ ਹਨ: ਇੱਕੋ ਟੇਬਲ ਵਿੱਚ ਲਿਖਣ ਵਾਲੀਆਂ ਕਈ ਸਰਵਿਸਾਂ, ਹਵਾਈ ਜਹਾਜ਼ ਵਿੱਚ ਆਫਲਾਈਨ ਰਿਕਾਰਡ ਬਣਾਉਣ ਵਾਲਾ ਮੋਬਾਈਲ ਕਲਾਇੰਟ, ਜਾਂ ਅਜਿਹੀ ਕਤਾਰ (queue) ਜਿਸਨੇ ਪਹਿਲਾਂ ਹੀ ਪ੍ਰਕਿਰਿਆ ਕੀਤੇ ਗਏ ਸੁਨੇਹੇ ਨੂੰ ਪਛਾਣਨਾ ਹੁੰਦਾ ਹੈ — ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਕਿਸੇ ਸਾਂਝੇ ਕਾਊਂਟਰ (shared counter) ਲਈ ਆਪਣੀ ਵਾਰੀ ਦੀ ਉਡੀਕ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਵਰਜ਼ਨ 5 ਇੱਕ ਵੱਖਰੀ ਲੋੜ ਪੂਰੀ ਕਰਦਾ ਹੈ, ਜੋ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ਕਿਸੇ ਚੀਜ਼ ਤੋਂ ਪ੍ਰਾਪਤ ਕੀਤਾ ਗਿਆ ਇੱਕ ਸਥਿਰ ਪਛਾਣਕਰਤਾ ਹੈ: ਇੱਕੋ ਦਸਤਾਵੇਜ਼, ਇੱਕੋ URL ਜਾਂ ਇੱਕੋ ਖਾਤਾ ਹਮੇਸ਼ਾ ਇੱਕੋ UUID ਨਾਲ ਜੁੜਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਦੀ ਨਕਲ ਬਣਾਏ ਬਿਨਾਂ ਇੰਪੋਰਟ ਨੂੰ ਦੋ ਵਾਰ ਚਲਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਹੋਰ ਥਾਵਾਂ 'ਤੇ ਇਹ ਸਿਰਫ਼ ਉਹ ਫਾਰਮੈਟ ਹੁੰਦਾ ਹੈ ਜਿਸਦੀ ਕੋਈ ਸਿਸਟਮ ਮੰਗ ਕਰਦਾ ਹੈ — ਲੌਗਜ਼ ਅਤੇ ਟਰੇਸਿਜ਼ ਵਿੱਚੋਂ ਲੰਘਣ ਵਾਲਾ ਇੱਕ ਸਹਿਸੰਬੰਧ (correlation) ਪਛਾਣਕਰਤਾ, ਹਜ਼ਾਰਾਂ ਉਪਭੋਗਤਾਵਾਂ ਦੁਆਰਾ ਅਪਲੋਡ ਕੀਤੀਆਂ ਫਾਈਲਾਂ ਜਦੋਂ ਇੱਕੋ ਬਾਲਟੀ (bucket) ਵਿੱਚ ਆਉਂਦੀਆਂ ਹਨ ਤਾਂ ਆਪਸ ਵਿੱਚ ਨਾ ਟਕਰਾਉਣ ਵਾਲਾ ਫਾਈਲ ਨਾਮ, ਇੱਕ Windows ਰਜਿਸਟਰੀ ਕੁੰਜੀ, ਜਾਂ ਕੋਈ ਟੈਸਟ ਫਿਕਸਚਰ (test fixture) ਜਿਸਨੂੰ ਅਸਲੀ ਡੇਟਾ ਵਰਗਾ ਦਿਖਣਾ ਜ਼ਰੂਰੀ ਹੁੰਦਾ ਹੈ।
ਕੁਝ ਇਮਾਨਦਾਰ ਸੀਮਾਵਾਂ ਬਾਰੇ ਜਾਣਨਾ ਫਾਇਦੇਮੰਦ ਹੈ। ਇੱਕ ਬੈਚ ਦਾ ਮਤਲਬ ਹੈ ਇੱਕ ਵਰਜ਼ਨ: 'ਵਰਜ਼ਨ' ਵਿਚਲੀ ਵੈਲਯੂ ਇਸ ਵਿਚਲੀ ਹਰ ਚੀਜ਼ 'ਤੇ ਲਾਗੂ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ v4 ਦੀ ਇੱਕ ਰਨ ਅਤੇ v7 ਦੀ ਇੱਕ ਰਨ ਦੋ ਵੱਖ-ਵੱਖ ਬੈਚ ਹਨ। ਇਹ ਇੱਕ ਜਨਰੇਟਰ ਹੈ, ਕੋਈ ਇੰਸਪੈਕਟਰ ਨਹੀਂ — ਕਿਸੇ UUID ਨੂੰ ਇੱਥੇ ਪੇਸਟ ਕਰਕੇ ਉਸਦਾ ਵਰਜ਼ਨ ਜਾਂ ਟਾਈਮਸਟੈਂਪ ਵਾਪਸ ਪੜ੍ਹਨਾ ਇਸ ਪੇਜ ਦਾ ਕੰਮ ਨਹੀਂ ਹੈ। 'ਫਾਈਲ ਵਿੱਚ ਸੰਭਾਲੋ' CSV ਜਾਂ JSON ਦੀ ਬਜਾਏ ਇੱਕ ਪਲੇਨ ਟੈਕਸਟ (plain text) ਫਾਈਲ ਲਿਖਦਾ ਹੈ। ਵਰਜ਼ਨ 7 ਖੁੱਲ੍ਹੇਆਮ ਦੱਸਦਾ ਹੈ ਕਿ ਇਹ ਕਦੋਂ ਬਣਾਇਆ ਗਿਆ ਸੀ, ਉਹ ਵੀ ਮਿਲੀਸੈਕਿੰਡ ਤੱਕ, ਜੋ ਕਿ ਕੋਈ ਖਾਮੀ ਨਹੀਂ ਬਲਕਿ ਇੱਕ ਅਸਲ ਸਮਝੌਤਾ ਹੈ, ਅਤੇ ਵਰਜ਼ਨ 1 ਵੀ ਇਸੇ ਤਰ੍ਹਾਂ ਸਮਾਂ ਜ਼ਾਹਰ ਕਰਦਾ ਹੈ; ਜੇਕਰ ਇਹ ਤੁਹਾਡੇ ਡੇਟਾ ਲਈ ਕੋਈ ਸਮੱਸਿਆ ਹੈ, ਤਾਂ ਵਰਜ਼ਨ 4 ਉਹ ਵਰਜ਼ਨ ਹੈ ਜੋ ਕਿਸੇ ਨੂੰ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ। ਸਟੈਂਡਰਡ ਵਿਚਲੀਆਂ ਦੋ ਖਾਸ ਵੈਲਯੂਜ਼ ਵਰਜ਼ਨ ਨਹੀਂ ਹਨ ਇਸ ਲਈ ਉਹ 'ਵਰਜ਼ਨ' ਵਿੱਚ ਵਿਕਲਪ ਵਜੋਂ ਨਹੀਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ, ਪਰ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਇੱਥੋਂ ਕਾਪੀ ਕਰ ਸਕਦੇ ਹੋ: nil UUID, 00000000-0000-0000-0000-000000000000, ਅਤੇ max UUID, ffffffff-ffff-ffff-ffff-ffffffffffff। ਇਸ ਪੇਜ 'ਤੇ ਸਭ ਕੁਝ RFC 9562 ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ, ਜਿਸਨੇ 2024 ਵਿੱਚ RFC 4122 ਦੀ ਥਾਂ ਲਈ, ਇਸ ਲਈ ਇੱਥੋਂ ਮਿਲਣ ਵਾਲੀ ਆਉਟਪੁੱਟ UUID ਨੂੰ ਸੰਭਾਲਣ ਵਾਲੀ ਕਿਸੇ ਵੀ ਲਾਇਬ੍ਰੇਰੀ, ਡੇਟਾਬੇਸ ਜਾਂ API ਦੁਆਰਾ ਸਵੀਕਾਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਹਨਾਂ ਸੀਮਾਵਾਂ ਦੇ ਅੰਦਰ ਗਾਰੰਟੀ ਬਹੁਤ ਮਜ਼ਬੂਤ ਹੈ: ਹਰੇਕ ਪਛਾਣਕਰਤਾ ਸਟੈਂਡਰਡ ਅਨੁਸਾਰ, ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਅਤ ਰੈਂਡਮਨੈੱਸ ਤੋਂ, ਤੁਹਾਡੀ ਆਪਣੀ ਮਸ਼ੀਨ 'ਤੇ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਕੋਈ ਹੋਰ ਇਸਨੂੰ ਕਦੇ ਨਹੀਂ ਦੇਖਦਾ।