ਲੁਹਨ ਐਲਗੋਰਿਦਮ ਕੈਲਕੁਲੇਟਰ - ਕ੍ਰੈਡਿਟ ਕਾਰਡ ਅਤੇ ਆਈਐਮਈਆਈ ਦੀ ਵੈਲੀਡੇਸ਼ਨ

ਲੁਹਨ ਐਲਗੋਰਿਦਮ ਨੂੰ ਸਮਝਣਾ

ਕ੍ਰੈਡਿਟ ਕਾਰਡ ਨੰਬਰ ਦੀ ਜਾਂਚ ਕਰਨ ਜਾਂ IMEI ਨੂੰ ਵੈਲੀਡੇਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ? ਲੁਹਨ ਐਲਗੋਰਿਦਮ (ਜਾਂ "ਮੋਡ 10 ਐਲਗੋਰਿਦਮ") ਇੱਕ ਚੈੱਕਸਮ ਫਾਰਮੂਲਾ ਹੈ ਜੋ 1954 ਤੋਂ ਭੁਗਤਾਨ ਦੀ ਤਸਦੀਕ ਦੀ ਨੀਂਹ ਰਹਿ ਚੁੱਕਾ ਹੈ। IBM ਦੇ ਵਿਗਿਆਨੀ ਹੰਸ ਪੀਟਰ ਲੁਹਨ ਨੇ ਇਸ ਸੁੰਦਰ ਗਣਿਤਕ ਜਾਂਚ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਤਾਂ ਜੋ ਮੈਨੁਅਲ ਡਾਟਾ ਐਂਟਰੀ ਵਿੱਚ ਹੋਣ ਵਾਲੀਆਂ ਟਾਈਪੋ ਅਤੇ ਲਿਖਤ ਤਰੁੱਟੀਆਂ ਨੂੰ ਫੜਿਆ ਜਾ ਸਕੇ—ਜਿਵੇਂ ਕਿ ਜਦੋਂ ਤੁਸੀਂ ਗਲਤੀ ਨਾਲ ਦੋ ਅੰਕਾਂ ਨੂੰ ਬਦਲ ਦਿੰਦੇ ਹੋ ਜਾਂ ਇੱਕ ਅੰਕ ਨੂੰ ਗਲਤ ਟਾਈਪ ਕਰ ਦਿੰਦੇ ਹੋ।

ਇਹ ਉਹ ਹੈ ਜੋ ਇਸਨੂੰ ਅਮੁੱਲ ਬਣਾਉਂਦਾ ਹੈ: ਹਰ ਵੱਡਾ ਕ੍ਰੈਡਿਟ ਕਾਰਡ ਨੈੱਟਵਰਕ (ਵੀਜ਼ਾ, ਮਾਸਟਰਕਾਰਡ, ਅਮੈਰਿਕਨ ਐਕਸਪ੍ਰੈੱਸ), ਮੋਬਾਈਲ ਡਿਵਾਈਸ IMEI ਨੰਬਰ, ਕੈਨੇਡਿਅਨ ਸੋਸ਼ਲ ਇੰਸ਼ੋਰੈਂਸ ਨੰਬਰ, ਅਤੇ ਯੂ.ਐਸ. ਹੈਲਥਕੇਅਰ ਪ੍ਰੋਵਾਈਡਰ ਪਛਾਣਕਰਤਾ ਇਸ ਐਲਗੋਰਿਦਮ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਭੁਗਤਾਨ ਫਾਰਮ ਵਿੱਚ ਕਾਰਡ ਨੰਬਰ ਟਾਈਪ ਕਰਦੇ ਹੋ ਅਤੇ ਇਹ ਤੁਰੰਤ ਇੱਕ ਤਰੁੱਟੀ ਨੂੰ ਰੱਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਇਹ ਲੁਹਨ ਜਾਂਚ ਹੈ ਜੋ ਕੰਮ ਕਰ ਰਹੀ ਹੈ।

ਇਹ ਕੈਲਕੁਲੇਟਰ ਤੁਹਾਨੂੰ ਕਿਸੇ ਵੀ ਨੰਬਰ ਅਨੁਕ੍ਰਮ ਨੂੰ ਵੈਲੀਡੇਟ ਕਰਨ ਜਾਂ ਟੈਸਟ ਡਾਟਾ ਤਿਆਰ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਜੋ ਤਸਦੀਕ ਤੋਂ ਗੁਜਰਦਾ ਹੈ—ਜਦੋਂ ਤੁਸੀਂ ਭੁਗਤਾਨ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਬਣਾ ਰਹੇ ਹੋ ਜਾਂ ਵਾਸਤਵਿਕ ਗਾਹਕ ਡਾਟਾ ਦੀ ਵਰਤੋਂ ਕੀਤੇ ਬਿਨਾਂ ਪਛਾਣ ਪ੍ਰਣਾਲੀਆਂ ਦਾ ਪਰੀਖਣ ਕਰ ਰਹੇ ਹੋ।

ਇਸ ਕੈਲਕੁਲੇਟਰ ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕਰੀਏ

ਮੌਜੂਦਾ ਨੰਬਰਾਂ ਦੀ ਵੈਧਤਾ ਜਾਂਚ: ਕੋਈ ਵੀ ਨੰਬਰ ਅਨੁਕ੍ਰਮ ਦਾਖਲ ਕਰੋ—ਜਿਵੇਂ 16-ਅੰਕਾਂ ਦਾ ਕ੍ਰੈਡਿਟ ਕਾਰਡ ਜਾਂ 15-ਅੰਕਾਂ ਦਾ IMEI—ਅਤੇ "ਵੈਲਿਡੇਟ" 'ਤੇ ਕਲਿਕ ਕਰੋ। ਤੁਸੀਂ ਤੁਰੰਤ ਵੇਖ ਸਕੋਗੇ ਕਿ ਕੀ ਇਹ ਮੋਡ 10 ਜਾਂਚ ਪਾਸ ਕਰਦਾ ਹੈ, ਨਾਲ ਹੀ ਹਰੇਕ ਅੰਕ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰੋਸੈਸ ਕੀਤਾ ਗਿਆ ਇਸਦਾ ਚਰਣ-ਦਰ-ਚਰਣ ਵੇਰਵਾ। ਇਹ ਖਾਸ ਤੌਰ 'ਤੇ ਭੁਗਤਾਨ ਫਾਰਮਾਂ ਨੂੰ ਡੀਬੱਗ ਕਰਨ ਜਾਂ ਡਾਟਾ ਐਂਟਰੀ ਦੀ ਸਟੀਕਤਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਵਿੱਚ ਉਪਯੋਗੀ ਹੈ।

ਟੈਸਟ ਡਾਟਾ ਉਤਪੰਨ ਕਰਨਾ: "ਉਤਪੰਨ" ਮੋਡ 'ਤੇ ਸਵਿੱਚ ਕਰੋ ਤਾਂ ਜੋ ਕਿਸੇ ਵੀ ਲੰਬਾਈ ਦੇ ਵੈਧ ਟੈਸਟ ਨੰਬਰ ਬਣਾਏ ਜਾ ਸਕਣ। ਇਹ ਨੰਬਰ ਲੂਹਨ ਤਸਦੀਕ ਪਾਸ ਕਰਦੇ ਹਨ ਪਰ ਅਸਲ, ਸਰਗਰਮ ਕਾਰਡ ਨਹੀਂ ਹਨ—ਜੋ ਕਿ ਵਿਕਾਸ ਵਾਤਾਵਰਣ ਲਈ ਬਿਲਕੁਲ ਸਹੀ ਹੈ ਜਿੱਥੇ ਤੁਹਾਨੂੰ ਜੀਵੰਤ ਭੁਗਤਾਨ ਪ੍ਰਮਾਣ ਨੂੰ ਛੂਹੇ ਬਿਨਾਂ ਯਥਾਰਥਵਾਦੀ ਟੈਸਟ ਕੇਸਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸਮਝਣਾ: ਵਿਜ਼ੁਅਲਾਈਜ਼ੇਸ਼ਨ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਹਰੇਕ ਅੰਕ ਨਾਲ ਕੀ ਹੁੰਦਾ ਹੈ: ਕਿਹੜੇ ਅੰਕ ਦੁੱਗੇ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਕਦੋਂ 9 ਘਟਾਇਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਅੰਤਮ ਯੋਗ ਕਿਵੇਂ ਵੈਧਤਾ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ। ਮੈਨੂੰ ਇਹ ਵਿਜ਼ੁਅਲ ਫੀਡਬੈਕ ਸਹਿकारਕ ਸਾਥੀਆਂ ਨੂੰ ਐਲਗੋਰਿਦਮ ਸਮਝਾਉਣ ਜਾਂ ਲਾਗੂਕਰਣ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਡੀਬੱਗ ਕਰਨ ਵਿੱਚ ਬਹੁਤ ਮਦਦਗਾਰ ਲੱਗਦਾ ਹੈ।

ਲੂਹਨ ਐਲਗੋਰਿਦਮ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ

ਐਲਗੋਰਿਦਮ ਸੰਖਿਆਵਾਂ ਨੂੰ ਸੱਜੇ ਤੋਂ ਖੱਬੇ ਪ੍ਰੋਸੈਸ ਕਰਦਾ ਹੈ, ਇੱਕ ਸਰਲ ਪੈਟਰਨ ਲਾਗੂ ਕਰਦਾ ਹੈ ਜੋ ਡੇਟਾ ਦਰਜ ਕਰਨ ਦੀਆਂ ਜਿਆਦਾਤਰ ਗਲਤੀਆਂ ਨੂੰ ਫੜਦਾ ਹੈ:

1. ਸੱਜੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ: ਹਰੇਕ ਅੰਕ ਨੂੰ ਲਵੋ, ਖੱਬੇ ਵੱਲ ਜਾਂਦੇ ਹੋਏ। ਹਰ ਦੂਜੇ ਅੰਕ ਨੂੰ ਦੁੱਗਣਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਇਹ ਉਹ ਅੰਕ ਹਨ ਜੋ ਸੱਜੇ ਤੋਂ ਗਿਣਨ 'ਤੇ ਸਮ ਸਥਾਨਾਂ 'ਤੇ ਹਨ)।

2. ਵੱਡੇ ਦੁੱਗਣੇ ਨੂੰ ਸੰਭਾਲੋ: ਜਦੋਂ ਦੁੱਗਣਾ ਕਰਨ ਤੋਂ ਬਾਅਦ ਸੰਖਿਆ 9 ਤੋਂ ਵੱਡੀ ਹੋ ਜਾਂਦੀ ਹੈ, 9 ਘਟਾਓ। ਇਹ ਗਣਿਤੀ ਤੌਰ 'ਤੇ ਵਿਅਕਤੀਗਤ ਅੰਕਾਂ ਨੂੰ ਜੋੜਨ ਦੇ ਬਰਾਬਰ ਹੈ (18 1+8=9 ਬਣ ਜਾਂਦਾ ਹੈ)।

3. ਸਭ ਕੁਝ ਜੋੜੋ: ਸਾਰੇ ਪ੍ਰੋਸੈਸ ਕੀਤੇ ਅੰਕਾਂ ਨੂੰ ਜੋੜੋ—ਦੁੱਗਣੇ/ਸਮਾਯੋਜਿਤ ਅੰਕ ਅਤੇ ਅਪਰਿਵਰਤਿਤ ਅੰਕ।

4. ਭਾਗ ਯੋਗਤਾ ਦੀ ਜਾਂਚ ਕਰੋ: ਜੇਕਰ ਜੋੜ 10 ਨਾਲ ਸਮਾਨ ਢੰਗ ਨਾਲ ਭਾਗ ਦਿੰਦਾ ਹੈ (0 'ਤੇ ਖਤਮ ਹੁੰਦਾ ਹੈ), ਤਾਂ ਸੰਖਿਆ ਵੈਧ ਹੈ। ਕੋਈ ਹੋਰ ਨਤੀਜਾ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਇੱਥੇ ਇੱਕ ਗਲਤੀ ਹੈ।

ਇਸ ਦ�ृਸ਼ਟਿਕੋਣ ਦੀ ਸਮਝ ਇਹ ਹੈ ਕਿ ਇਹ ਆਮ ਗਲਤੀਆਂ ਨੂੰ ਕਿਵੇਂ ਫੜਦਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਦੋ ਨੇੜਲੇ ਅੰਕਾਂ ਨੂੰ ਬਦਲ ਦਿੰਦੇ ਹੋ ਜਾਂ ਇੱਕ ਅੰਕ ਨੂੰ ਗਲਤ ਲਿਖ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਚੈਕਸਮ ਲਗਭਗ ਹਮੇਸ਼ਾ ਬਦਲ ਜਾਂਦਾ ਹੈ। ਐਲਗੋਰਿਦਮ ਹਰ ਸੰਭਵ ਗਲਤੀ ਨੂੰ ਨਹੀਂ ਫੜ ਸਕਦਾ—ਜੁੜਵਾਂ ਗਲਤੀਆਂ ਜਿਵੇਂ 22 ਨੂੰ 55 ਵਿੱਚ ਬਦਲਣਾ ਨਿਕਲ ਜਾਂਦਾ ਹੈ—ਪਰ ਇਹ ਲਗਭਗ 98% ਯਾਦृਚ੍ਛਿਕ ਇੱਕ-ਅੰਕ ਦੀਆਂ ਗਲਤੀਆਂ ਅਤੇ ਲਗਭਗ 90% ਨੇੜਲੇ ਬਦਲਾਵਾਂ ਨੂੰ ਫੜ ਲੈਂਦਾ ਹੈ।

ਇੱਥੇ ਪ੍ਰਕਿਰਿਆ ਦਾ ਇੱਕ ਦृਸ਼ ਪ੍ਰਤੀਨਿਧਿ ਹੈ:

ਗਣਿਤੀ ਫਾਰਮੂਲਾ

ਉਹਨਾਂ ਲੋਕਾਂ ਲਈ ਜੋ ਔਪਚਾਰਿਕ ਨੋਟੇਸ਼ਨ ਪਸੰਦ ਕਰਦੇ ਹਨ, ਇੱਥੇ ਗਣਿਤੀ ਅਭਿਵਿਅਕਤੀ ਹੈ:

ਮੰਨੋ $d_i$ $i$-ਵਾਂ ਅੰਕ ਹੈ, ਸਭ ਤੋਂ ਸੱਜੇ ਅੰਕ (ਚੈੱਕ ਅੰਕ ਨੂੰ ਛੱਡ ਕੇ) ਤੋਂ ਗਿਣਦੇ ਹੋਏ ਅਤੇ ਖੱਬੇ ਵੱਲ ਜਾਂਦੇ ਹੋਏ। ਫਿਰ ਚੈੱਕ ਅੰਕ $d_0$ ਇਸ ਤਰ੍ਹਾਂ ਚੁਣਿਆ ਜਾਂਦਾ ਹੈ ਕਿ:

$(2d_{2n} \bmod 9 + d_{2n-1} + 2d_{2n-2} \bmod 9 + d_{2n-3} + \cdots + 2d_2 \bmod 9 + d_1 + d_0) \bmod 10 = 0$

ਜਿੱਥੇ $\bmod$ ਮੋਡੂਲੋ ਆਪਰੇਸ਼ਨ ਹੈ।

ਅਸਲ ਦੁਨੀਆ ਦੇ ਉਪਯੋਗ

ਭੁਗਤਾਨ ਪ੍ਰੋਸੈਸਿੰਗ: ਹਰ ਵੱਡਾ ਕਾਰਡ ਨੈੱਟਵਰਕ—ਵੀਜ਼ਾ, ਮਾਸਟਰਕਾਰਡ, ਅਮੈਰਿਕਨ ਐਕਸਪ੍ਰੈਸ, ਡਿਸਕਵਰ—ਲੂਹਨ ਚੈੱਕ ਦੀ ਵਰਤੋਂ ਟਾਈਪੋ ਤੋਂ ਬਚਾਅ ਲਈ ਪਹਿਲੀ ਪੰਗਤ ਦੀ ਰੱਖਿਆ ਵਜੋਂ ਕਰਦੇ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਚੈੱਕਆਉਟ ਫਾਰਮ ਬਣਾ ਰਹੇ ਹੋ, ਕਲਾਈਟ-ਸਾਈਡ ਲੂਹਨ ਵੈਲੀਡੇਸ਼ਨ ਲਾਗੂ ਕਰਨ ਨਾਲ ਤੁਹਾਡੇ ਉਪਯੋਗਕਰਤਾਵਾਂ ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਗਲਤ ਨੰਬਰ ਜਮ੍ਹਾਂ ਕਰਨ ਤੋਂ ਬਚਾਇਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਭੁਗਤਾਨ ਗੇਟਵੇਜ਼ 'ਤੇ ਅਨਾਵਸ਼ਕ API ਕਾਲਾਂ ਨੂੰ ਘਟਾਇਆ ਜਾਂਦਾ ਹੈ।

ਮੋਬਾਈਲ ਡਿਵਾਈਸ ਟਰੈਕਿੰਗ: ਫ਼ੋਨਾਂ ਅਤੇ ਟੈਬਲੇਟਾਂ 'ਤੇ IMEI ਨੰਬਰਾਂ ਵਿੱਚ ਲੂਹਨ ਚੈੱਕ ਅੰਕ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ। ਇਹ ਸਪਲਾਈ ਚੇਨ ਮੈਨੇਜਮੈਂਟ ਅਤੇ ਡਿਵਾਈਸ ਪ੍ਰਮਾਣੀਕਰਣ ਸਿਸਟਮਾਂ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ—ਮੈਂ ਵੇਅਰਹਾਊਸ ਸਿਸਟਮਾਂ ਨੂੰ ਤੁਰੰਤ ਗਲਤ IMEI ਸਕੈਨ ਨੂੰ ਰੱਦ ਕਰਦਿਆਂ ਦੇਖਿਆ ਹੈ, ਜੋ ਸ਼ਿਪਿੰਗ ਗਲਤੀਆਂ ਨੂੰ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਰੋਕਦਾ ਹੈ।

ਸਿਹਤ ਸੰਭਾਲ ਪਛਾਣਕਰਤਾ: ਅਮਰੀਕੀ ਰਾਸ਼ਟਰੀ ਪ੍ਰੋਵਾਈਡਰ ਪਛਾਣਕਰਤਾ (NPI) ਸਿਸਟਮ ਪ੍ਰੋਵਾਈਡਰ ਨੰਬਰਾਂ ਨੂੰ ਇਸ ਐਲਗੋਰਿਦਮ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਵੈਲੀਡੇਟ ਕਰਦਾ ਹੈ। ਰੋਜ਼ਾਨਾ ਲੱਖਾਂ ਸਿਹਤ ਸੰਭਾਲ ਲੈਣ-ਦੇਣ ਦੇ ਨਾਲ, ਪ੍ਰੋਵਾਈਡਰ ਆਈਡੀ ਵਿੱਚ ਲਿਖਣ ਦੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਫੜਨ ਨਾਲ ਬਿਲਿੰਗ ਦੇ ਵਿਲੰਬ ਨੂੰ ਰੋਕਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਦਾਅਵਿਆਂ ਦੀ ਰੱਦੀ ਨੂੰ ਘਟਾਇਆ ਜਾਂਦਾ ਹੈ।

ਸਰਕਾਰੀ ਪਛਾਣ: ਕੈਨੇਡਾਈ ਸਮਾਜਿਕ ਬੀਮਾ ਨੰਬਰ ਲੂਹਨ ਵੈਲੀਡੇਸ਼ਨ ਨੂੰ ਸ਼ਾਮਲ ਕਰਦੇ ਹਨ। ਐਲਗੋਰਿਦਮ ਡੇਟਾਬੇਸ ਲੁੱਕਅੱਪ ਦੀ ਲੋੜ ਤੋਂ ਬਿਨਾਂ ਇੱਕ ਤੁਰੰਤ ਸਮਝ ਚੈੱਕ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਉੱਚ-ਮਾਤਰਾ ਵੈਰੀਫਿਕੇਸ਼ਨ ਸਥਿਤੀਆਂ ਲਈ ਇਹ ਕੁਸ਼ਲ ਹੁੰਦਾ ਹੈ।

ਪੁਰਾਣੀਆਂ ਕਿਤਾਬ ਪ੍ਰਣਾਲੀਆਂ: ਕੁਝ ISBN-10 ਲਾਗੂਕਰਨ ਲੂਹਨ ਵੇਰੀਅੰਟ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਹਾਲਾਂਕਿ ISBN-13 ਇੱਕ ਵੱਖਰੇ ਚੈੱਕ ਅੰਕ ਐਲਗੋਰਿਦਮ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਪੁਰਾਣੀਆਂ ਲਾਇਬਰੇਰੀ ਅਤੇ ਇਨਵੈਂਟਰੀ ਪ੍ਰਣਾਲੀਆਂ ਅਜੇ ਵੀ ਲੂਹਨ-ਅਧਾਰਤ ਵੈਲੀਡੇਸ਼ਨ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨ।

ਚਰਣ-ਦਰ-ਚਰਣ ਉਦਾਹਰਣਾਂ

ਕ੍ਰੈਡਿਟ ਕਾਰਡ ਨੰਬਰ ਦੀ ਵੈਧਤਾ ਦੀ ਜਾਂਚ

ਆਉ 4532015112830366 ਨੰਬਰ ਦੀ ਵੈਧਤਾ ਦੀ ਜਾਂਚ ਕਰੀਏ:

1. ਸੱ�dx ਤੋਂ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋਏ: 6, 6, 3, 0, 3, 8, 2, 1, 1, 5, 1, 0, 2, 3, 5, 4
2. ਹਰ ਦੂਜੇ ਅੰਕ ਨੂੰ ਦੁੱਗਣਾ ਕਰੋ (ਸੱਜੇ ਤੋਂ): 6, 12, 3, 0, 3, 16, 2, 2, 1, 10, 1, 0, 2, 6, 5, 8
3. 9 ਤੋਂ ਵੱਡੇ ਨੰਬਰਾਂ ਤੋਂ 9 ਘਟਾਓ: 6, 3, 3, 0, 3, 7, 2, 2, 1, 1, 1, 0, 2, 6, 5, 8
4. ਯੋਗ: 6+3+3+0+3+7+2+2+1+1+1+0+2+6+5+8 = 50
5. 50 % 10 = 0 ✓ ਵੈਧ!

ਗਲਤ IMEI ਨੰਬਰ ਨੂੰ ਫੜਨਾ

490154203237518 (ਆਖਰੀ ਅੰਕ ਜਾਣਬੁੱਝ ਕੇ ਗਲਤ ਹੈ) ਦੀ ਜਾਂਚ:

1. ਦੁੱਗਣਾ ਕਰਨ ਅਤੇ ਪ੍ਰੋਸੈਸ ਕਰਨ ਤੋਂ ਬਾਅਦ: ਯੋਗ = 57
2. 57 % 10 = 7 ✗ ਅਵੈਧ!

ਯੋਗ ਸ਼ੂਨਯ ਤੇ ਖਤਮ ਨਹੀਂ ਹੁੰਦਾ, ਇਸਲਈ ਐਲਗੋਰਿਦਮ ਇਸਨੂੰ ਗਲਤ ਮੰਨਦਾ ਹੈ। ਇਸਨੂੰ ਵੈਧ ਬਣਾਉਣ ਲਈ, ਆਖਰੀ ਅੰਕ 1 ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਜੋ ਕਿ ਯੋਗ ਨੂੰ 60 ਤੱਕ ਲਿਆਵੇਗਾ - ਜੋ ਕਿ 10 ਨਾਲ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੰਡਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਇਹ ਬਿਲਕੁਲ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਐਲਗੋਰਿਦਮ ਉਪਕਰਣ ਪਛਾਣਕਰਤਾਵਾਂ ਵਿੱਚ ਲਿਖਣ ਦੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਫੜਦਾ ਹੈ।

ਵੈਕਲਪਿਕ ਚੈਕਸਮ ਐਲਗੋਰਿਦਮ

ਲੂਹਨ ਐਲਗੋਰਿਦਮ ਲੋਕਪ੍ਰਿਅ ਹੈ ਕਿਉਂਕਿ ਇਹ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਸਰਲ ਹੈ, ਪਰ ਜਦੋਂ ਤੁਹਾਨੂੰ ਮਜਬੂਤ ਤਰੁੱਟੀ ਪਛਾਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਤਾਂ ਹੋਰ ਸਫਿਸਟੀਕੇਟਡ ਵਿਕਲਪ ਮੌਜੂਦ ਹਨ:

ਵੇਰਹੋਫ ਐਲਗੋਰਿਦਮ: ਸਾਰੀਆਂ ਇਕੱਲੀ-ਅੰਕ ਤਰੁੱਟੀਆਂ ਅਤੇ ਲਗਭਗ ਸਾਰੀਆਂ ਤਬਦੀਲੀ ਤਰੁੱਟੀਆਂ ਨੂੰ ਫੜਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਲੂਹਨ ਤੋਂ ਛੁੱਟ ਗਈਆਂ ਜੁੜਵਾਂ-ਅੰਕ ਦੀਆਂ ਸਥਿਤੀਆਂ ਵੀ ਸ਼ਾਮਲ ਹਨ (ਜਿਵੇਂ 22↔55)। ਇਸਦਾ ਮੁੱਲ ਵਧੇਰੇ ਜਟਿਲਤਾ ਹੈ—ਇਸਨੂੰ ਗੁਣਾ ਅਤੇ ਪਰਮੂਟੇਸ਼ਨ ਕਾਰਵਾਈਆਂ ਵਾਲੀਆਂ ਲੁੱਕਅੱਪ ਟੇਬਲਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਸਦੀ ਵਰਤੋਂ ਕਰੋ ਜਦੋਂ ਡਾਟਾ ਸ਼ੁੱਧਤਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਅਤੇ ਕੰਪਿਊਟੇਸ਼ਨਲ ਓਵਰਹੈੱਡ ਚਿੰਤਾ ਦਾ ਵਿਸ਼ਾ ਨਹੀਂ ਹੈ।

ਡਾਮ ਐਲਗੋਰਿਦਮ: ਬਿਨਾਂ ਕਿਸੇ ਅਪਵਾਦ ਦੇ ਸਾਰੀਆਂ ਇਕੱਲੀ-ਅੰਕ ਤਰੁੱਟੀਆਂ ਅਤੇ ਸਾਰੀਆਂ ਨੇੜਲੀਆਂ ਤਬਦੀਲੀ ਤਰੁੱਟੀਆਂ ਦਾ ਪਤਾ ਲਗਾਉਂਦਾ ਹੈ। ਇਹ ਇੱਕ ਖਾਸ ਤਰੀਕੇ ਨਾਲ ਬਣਾਏ ਗਏ ਕੁਆਸੀਗਰੁੱਪ ਕਾਰਵਾਈ 'ਤੇ ਅਧਾਰਿਤ ਹੈ ਜੋ ਪੂਰੀ ਕਵਰੇਜ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ। ਲਾਗੂਕਰਨ ਇੱਕ ਇਕੱਲੀ ਲੁੱਕਅੱਪ ਟੇਬਲ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਜੋ ਇਸਨੂੰ ਵੇਰਹੋਫ ਨਾਲੋਂ ਸਰਲ ਪਰ ਲੂਹਨ ਨਾਲੋਂ ਹਾਲੇ ਵੀ ਜਟਿਲ ਬਣਾਉਂਦਾ ਹੈ।

ISBN-13 ਚੈਕ ਅੰਕ: ਲੂਹਨ ਅਤੇ ISBN-10 ਤੋਂ ਵੱਖਰੇ ਇੱਕ ਭਾਰੀ ਮੋਡੂਲੋ 10 ਐਲਗੋਰਿਦਮ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਭਾਰ 1 ਅਤੇ 3 ਵਿਚਕਾਰ ਬਦਲਦਾ ਹੈ, ਜੋ ਖਾਸ ਤੌਰ 'ਤੇ ਕਿਤਾਬ ਪਛਾਣਕਰਤਾਵਾਂ ਲਈ ਚੰਗੀ ਤਰੁੱਟੀ ਪਛਾਣ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਇਸਨੇ ਪੁਰਾਣੀ ISBN-10 ਪ੍ਰਣਾਲੀ (ਜਿਸਨੇ ਲੂਹਨ ਦੀ ਵਰਤੋਂ ਕੀਤੀ) ਨੂੰ ਬਦਲ ਦਿੱਤਾ ਜਦੋਂ ਉਦਯੋਗ ਨੂੰ ਹੋਰ ਪਛਾਣਕਰਤਾ ਸਥਾਨ ਦੀ ਲੋੜ ਸੀ।

ਇਤਿਹਾਸ ਅਤੇ ਸੰਦਰਭ

ਹੈਂਸ ਪੀਟਰ ਲੂਹਨ ਨੇ ਇਹ ਐਲਗੋਰਿਦਮ 1954 ਵਿੱਚ IBM ਵਿੱਚ ਸ਼ੁਰੂਆਤੀ ਆਟੋਮੇਟਿਡ ਡਾਟਾ ਪ੍ਰੋਸੈਸਿੰਗ ਦੇ ਦੌਰਾਨ ਵਿਕਸਿਤ ਕੀਤਾ। ਲੂਹਨ ਪਹਿਲਾਂ ਹੀ ਸੂਚਨਾ ਪੁਨਰਪ੍ਰਾਪਤੀ ਵਿੱਚ ਅਗਵਾਈ ਕਰਨ ਵਾਲੇ ਕੰਮ ਲਈ ਜਾਣਿਆ ਜਾਂਦਾ ਸੀ—ਉਸਦੀ KWIC (ਕੀ ਵਰਡ ਇਨ ਕੰਟੈਕਸਟ) ਇੰਡੈਕਸਿੰਗ ਸਿਸਟਮ ਨੇ ਅੱਜ ਵੀ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਖੋਜਣ ਦੇ ਤਰੀਕੇ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ—ਪਰ ਮੋਡ 10 ਐਲਗੋਰਿਦਮ ਉਸਦਾ ਸਭ ਤੋਂ ਵੱਧ ਸਥਾਈ ਯੋਗਦਾਨ ਬਣ ਗਿਆ।

ਇੱਥੇ ਮਹੱਤਵਪੂਰਨ ਅੰਤਰ ਹੈ: ਲੂਹਨ ਨੇ ਇਸਨੂੰ ਤਰੁੱਟੀ ਦੀ ਪਛਾਣ ਲਈ, ਸੁਰੱਖਿਆ ਲਈ ਨਹੀਂ ਡਿਜ਼ਾਇਨ ਕੀਤਾ। 1950 ਦੇ ਦਹਾਕੇ ਵਿੱਚ, ਸਮੱਸਿਆ ਪੰਚ ਕਾਰਡ ਦੀਆਂ ਗਲਤੀਆਂ ਅਤੇ ਮੈਨੁਅਲ ਨਕਲ ਦੀਆਂ ਗਲਤੀਆਂ ਸਨ, ਡਿਜਿਟਲ ਧੋਖਾਧੜੀ ਨਹੀਂ। ਐਲਗੋਰਿਦਮ ਅਚਾਨਕ ਟਾਈਪੋ ਨੂੰ ਬਹੁਤ ਵਧੀਆ ਫੜਦਾ ਹੈ—ਪਰ ਇਹ ਕ੍ਰਿਪਟੋਗਰਾਫੀ ਨਹੀਂ ਹੈ। ਇੱਕ ਵੈਧ ਲੂਹਨ ਨੰਬਰ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਕਾਰਡ ਸਕਰਿਅ, ਫੰਡਡ ਜਾਂ ਉਸ ਵਿਅਕਤੀ ਦਾ ਹੈ ਜੋ ਇਸਦੀ ਵਰਤੋਂ ਕਰ ਰਿਹਾ ਹੈ।

ਜੋ ਅਚਰਜ਼ ਹੈ ਉਹ ਇਹ ਹੈ ਕਿ 70 ਸਾਲ ਪੁਰਾਣਾ ਐਲਗੋਰਿਦਮ ਅਜੇ ਵੀ ਆਪਣੇ ਮੂਲ ਉਦੇਸ਼ ਨੂੰ ਬਖੂਬੀ ਪੂਰਾ ਕਰਦਾ ਹੈ। ਭੁਗਤਾਨ ਪ੍ਰੋਸੈਸਰ ਇਸਨੂੰ ਆਧੁਨਿਕ ਸੁਰੱਖਿਆ (ਟੋਕਨਾਈਜ਼ੇਸ਼ਨ, CVV ਤਸਦੀਕ, 3D ਸੁਰੱਖਿਅਤ) ਦੇ ਨਾਲ ਜੋੜਦੇ ਹਨ, ਪਰ ਉਹ ਮੂਲ ਕਲਾਈਟ-ਸਾਈਡ ਲੂਹਨ ਚੈੱਕ ਅਜੇ ਵੀ ਰੋਜ਼ਾਨਾ ਲੱਖਾਂ ਸਪੱਸ਼ਟ ਗਲਤੀਆਂ ਨੂੰ ਰੋਕਦਾ ਹੈ ਪਹਿਲਾਂ ਜਿਵੇਂ ਉਹ ਭੁਗਤਾਨ ਗੇਟਵੇ ਕਾਲਾਂ 'ਤੇ ਬੈਂਡਵਿਡਥ ਬਰਬਾਦ ਕਰਦੀਆਂ ਹਨ।

ਲਾਗੂਕਰਨ ਉਦਾਹਰਣਾਂ

ਇੱਥੇ ਪਾਈਥਨ, ਜਾਵਾਸਕ੍ਰਿਪਟ ਅਤੇ ਜਾਵਾ ਵਿੱਚ ਲੁਹਨ ਵੈਲੀਡੇਸ਼ਨ ਅਤੇ ਜਨਰੇਸ਼ਨ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦਾ ਤਰੀਕਾ ਹੈ। ਇਹ ਉਦਾਹਰਣਾਂ ਕਾਰਗਰਤਾ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਦੇ ਹੋਏ ਪੜ੍ਹਨਯੋਗਤਾ ਨੂੰ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿੰਦੀਆਂ ਹਨ:

1import random
2
3def luhn_validate(number):
4    digits = [int(d) for d in str(number)]
5    checksum = 0
6    for i in range(len(digits) - 1, -1, -1):
7        d = digits[i]
8        if (len(digits) - i) % 2 == 0:
9            d = d * 2
10            if d > 9:
11                d -= 9
12        checksum += d
13    return checksum % 10 == 0
14
15def generate_valid_number(length):
16    digits = [random.randint(0, 9) for _ in range(length - 1)]
17    checksum = sum(digits[::2]) + sum(sum(divmod(d * 2, 10)) for d in digits[-2::-2])
18    check_digit = (10 - (checksum % 10)) % 10
19    return int(''.join(map(str, digits + [check_digit])))
20
21## ਉਦਾਹਰਣ ਵਰਤੋਂ:
22
23print(luhn_validate(4532015112830366))  # ਸੱਚ
24print(luhn_validate(4532015112830367))  # ਗਲਤ
25print(generate_valid_number(16))  # 16 ਅੰਕਾਂ ਦੀ ਵੈਧ ਸੰਖਿਆ ਬਣਾਉਂਦਾ ਹੈ
26

1function luhnValidate(number) {
2    const digits = number.toString().split('').map(Number);
3    let checksum = 0;
4    for (let i = digits.length - 1; i >= 0; i--) {
5        let d = digits[i];
6        if ((digits.length - i) % 2 === 0) {
7            d *= 2;
8            if (d > 9) d -= 9;
9        }
10        checksum += d;
11    }
12    return checksum % 10 === 0;
13}
14
15function generateValidNumber(length) {
16    const digits = Array.from({length: length - 1}, () => Math.floor(Math.random() * 10));
17    const checksum = digits.reduce((sum, digit, index) => {
18        if ((length - 1 - index) % 2 === 0) {
19            digit *= 2;
20            if (digit > 9) digit -= 9;
21        }
22        return sum + digit;
23    }, 0);
24    const checkDigit = (10 - (checksum % 10)) % 10;
25    return parseInt(digits.join('') + checkDigit);
26}
27
28// ਉਦਾਹਰਣ ਵਰਤੋਂ:
29console.log(luhnValidate(4532015112830366));  // ਸੱਚ
30console.log(luhnValidate(4532015112830367));  // ਗਲਤ
31console.log(generateValidNumber(16));  // 16 ਅੰਕਾਂ ਦੀ ਵੈਧ ਸੰਖਿਆ ਬਣਾਉਂਦਾ ਹੈ
32

1import java.util.Random;
2
3public class LuhnValidator {
4    public static boolean luhnValidate(long number) {
5        String digits = String.valueOf(number);
6        int checksum = 0;
7        boolean isEven = true;
8        for (int i = digits.length() - 1; i >= 0; i--) {
9            int digit = Character.getNumericValue(digits.charAt(i));
10            if (isEven) {
11                digit *= 2;
12                if (digit > 9) digit -= 9;
13            }
14            checksum += digit;
15            isEven = !isEven;
16        }
17        return checksum % 10 == 0;
18    }
19
20    public static long generateValidNumber(int length) {
21        Random random = new Random();
22        long[] digits = new long[length - 1];
23        for (int i = 0; i < length - 1; i++) {
24            digits[i] = random.nextInt(10);
25        }
26        long checksum = 0;
27        for (int i = digits.length - 1; i >= 0; i--) {
28            long digit = digits[i];
29            if ((length - 1 - i) % 2 == 0) {
30                digit *= 2;
31                if (digit > 9) digit -= 9;
32            }
33            checksum += digit;
34        }
35        long checkDigit = (10 - (checksum % 10)) % 10;
36        long result = 0;
37        for (long digit : digits) {
38            result = result * 10 + digit;
39        }
40        return result * 10 + checkDigit;
41    }
42
43    public static void main(String[] args) {
44        System.out.println(luhnValidate(4532015112830366L));  // ਸੱਚ
45        System.out.println(luhnValidate(4532015112830367L));  // ਗਲਤ
46        System.out.println(generateValidNumber(16));  // 16 ਅੰਕਾਂ ਦੀ ਵੈਧ ਸੰਖਿਆ ਬਣਾਉਂਦਾ ਹੈ
47    }
48}
49

ਕਿਨਾਰੇ ਦੇ ਮਾਮਲੇ ਅਤੇ ਲਾਗੂਕਰਨ ਦੀਆਂ ਚੁਣੌਤੀਆਂ

ਉਤਪਾਦਨ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਲੁਹਨ ਵੈਲੀਡੇਸ਼ਨ ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਸਮੇਂ, ਇਨ੍ਹਾਂ ਆਮ ਮੁੱਦਿਆਂ ਤੇ ਧਿਆਨ ਦਿਓ:

ਇਨਪੁਟ ਸੈਨੀਟਾਈਜ਼ੇਸ਼ਨ: ਅਸਲ ਦੁਨੀਆ ਦੇ ਇਨਪੁਟ ਵਿੱਚ ਅਕਸਰ ਸਪੇਸ, ਹਾਈਫਨ, ਜਾਂ ਹੋਰ ਫਾਰਮੈਟਿੰਗ ਅੱਖਰ (ਜਿਵੇਂ "4532-0151-1128-3036") ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ। ਇਨਪੁਟ ਨੂੰ ਅਸਵੀਕਾਰ ਕਰਨ ਦੀ ਬਜਾਏ ਵੈਲੀਡੇਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਇਨ੍ਹਾਂ ਨੂੰ ਹਟਾ ਦਿਓ—ਉਪਭੋਗਤਾ ਅਕਸਰ ਫਾਰਮੈਟ ਕੀਤੇ ਗਏ ਨੰਬਰ ਕਾਪੀ ਕਰਦੇ ਹਨ। ਹਾਲਾਂਕਿ, ਤੁਰੰਤ ਵਰਣਮਾਲਾ ਵਾਲੇ ਅੱਖਰਾਂ ਨੂੰ ਅਸਵੀਕਾਰ ਕਰੋ ਕਿਉਂਕਿ ਉਹ ਵਾਸਤਵ ਵਿੱਚ ਗਲਤ ਇਨਪੁਟ ਦਰਸਾਉਂਦੇ ਹਨ।

ਅਗਲੇ ਜ਼ੀਰੋ ਮਹੱਤਵਪੂਰਨ ਹਨ: ਇੱਕ ਨੰਬਰ ਜਿਵੇਂ "0123456789" ਲੁਹਨ ਦੇ ਉਦੇਸ਼ ਲਈ "123456789" ਤੋਂ ਵੱਖਰਾ ਹੈ। ਵੈਲੀਡੇਸ਼ਨ ਦੌਰਾਨ ਅਗਲੇ ਜ਼ੀਰੋ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਉਨ੍ਹਾਂ ਡਵੈਲਪਰਾਂ ਨੂੰ ਫਸਾ ਦਿੰਦਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਇੰਟੀਜਰ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ—ਇਸਦੇ ਬਜਾਏ ਸਟਰਿੰਗ ਆਪਰੇਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ।

ਭਾਸ਼ਾ ਇੰਟੀਜਰ ਸੀਮਾਵਾਂ: ਕ੍ਰੈਡਿਟ ਕਾਰਡ ਆਮ ਤੌਰ 'ਤੇ 19 ਅੰਕਾਂ ਤੱਕ ਮੈਕਸ ਹੁੰਦੇ ਹਨ, ਜੋ 64-ਬਿੱਟ ਇੰਟੀਜਰ ਵਿੱਚ ਫਿੱਟ ਹੁੰਦੇ ਹਨ। ਪਰ ਜੇਕਰ ਤੁਸੀਂ ਯਾਦਗਾਰ ਲੰਬਾਈ ਦੀਆਂ ਪਛਾਣ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇੰਟੀਜਰ ਵਿੱਚ ਬਦਲਣ ਤੋਂ ਬਚੋ। ਓਵਰਫਲੋ ਨੂੰ ਰੋਕਣ ਲਈ ਸਟਰਿੰਗ ਜਾਂ ਅੰਕਾਂ ਦੇ ਐਰੇ ਵਜੋਂ ਪ੍ਰੋਸੈਸ ਕਰੋ।

ਖਾਲੀ ਜਾਂ ਨਲ ਇਨਪੁਟ: ਆਪਣੇ ਵਿਵਹਾਰ ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਪਰਿਭਾਸ਼ਤ ਕਰੋ: ਇੱਕ ਅਪਵਾਦ ਸੁੱਟੋ, ਗਲਤ ਵਾਪਸ ਕਰੋ, ਜਾਂ ਸੁਚੱਜੇ ਢੰਗ ਨਾਲ ਨਿਪਟੋ? ਮੈਂ ਪਾਇਆ ਹੈ ਕਿ ਵੈਲੀਡੇਸ਼ਨ ਫੰਕਸ਼ਨਾਂ ਲਈ ਗਲਤ ਵਾਪਸ ਕਰਨਾ ਸਭ ਤੋਂ ਵਧੀਆ ਅਰਥ ਰੱਖਦਾ ਹੈ, ਪਰ API ਐਂਡਪੋਇੰਟਸ ਇੱਕ 400 ਤਰੁੱਟੀ ਨਾਲ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਸੁਨੇਹਾ ਵਾਪਸ ਕਰਨਾ ਚਾਹ ਸਕਦੇ ਹਨ।

ਪੈਮਾਨੇ 'ਤੇ ਕਾਰਗੁਜ਼ਾਰੀ: ਬੈਚ ਵੈਲੀਡੇਸ਼ਨ ਲਈ (ਜਿਵੇਂ ਕਿ ਅਪਲੋਡ ਕੀਤੀਆਂ ਗਈਆਂ CSV ਫਾਈਲਾਂ ਵਿੱਚ ਹਜ਼ਾਰਾਂ ਕਾਰਡ ਨੰਬਰਾਂ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰਨਾ), ਮੂਲ ਐਲਗੋਰਿਦਮ ਪਹਿਲੇ ਤੋਂ ਹੀ ਕਾਫੀ ਤੇਜ਼ ਹੈ—O(n) ਜਿੱਥੇ n ਅੰਕ ਗਿਣਤੀ ਹੈ। ਬੋਤਲ ਨੱਕ ਆਮ ਤੌਰ 'ਤੇ I/O ਹੈ, ਨਾ ਕਿ ਗਣਨਾ। ਫਾਈਲ ਪਾਰਸਿੰਗ ਅਤੇ ਤਰੁੱਟੀ ਰਿਪੋਰਟਿੰਗ 'ਤੇ ਅਨੁਕੂਲਨ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਤ ਕਰੋ ਬਜਾਏ ਵੈਲੀਡੇਸ਼ਨ ਲਾਜਿਕ ਦੇ।

ਤੁਰੰਤ ਸੰਦਰਭ: ਟੈਸਟ ਨੰਬਰ

ਇਹਨਾਂ ਨੰਬਰਾਂ ਦੀ ਆਪਣੇ ਲਾਗੂਕਰਨ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਵਰਤੋਂ:

ਵੈਧ ਨੰਬਰ:

• 4532015112830366 — ਵੀਜ਼ਾ ਫਾਰਮੈਟ (16 ਅੰਕ)
• 046454286 — ਕੈਨੇਡੀਅਨ SIN ਫਾਰਮੈਟ (9 ਅੰਕ)
• 79927398713 — ਸਧਾਰਨ ਵੈਧ ਨੰਬਰ

ਅਵੈਧ ਨੰਬਰ:

• 4532015112830367 — ਇੱਕ ਅੰਕ ਤੋਂ ਅਲੱਗ
• 490154203237518 — ਗਲਤ ਚੈੱਕ ਅੰਕ
• 79927398714 — ਆਖਰੀ ਅੰਕ ਗਲਤ

ਇਹ ਟੈਸਟ ਕੇਸ ਆਮ ਪਰਿਦʼਸ਼ਾਂ ਨੂੰ ਕਵਰ ਕਰਦੇ ਹਨ: ਮਾਨਕ ਵੈਧ ਨੰਬਰ, ਇੱਕ ਅੰਕ ਦੀਆਂ ਗਲਤੀਆਂ, ਅਤੇ ਗਲਤ ਚੈੱਕ ਅੰਕ।

ਆਟੋਮੇਟਿਡ ਟੈਸਟ ਸੂਟ

ਇੱਥੇ ਤੁਹਾਡੇ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਨੂੰ ਵੈਲੀਡੇਟ ਕਰਨ ਲਈ ਇੱਕ ਵਿਆਪਕ ਟੈਸਟ ਸੂਟ ਹੈ:

1def test_luhn_algorithm():
2    # ਬੇਸਿਕ ਵੈਲੀਡੇਸ਼ਨ ਟੈਸਟ
3    assert luhn_validate(4532015112830366) == True
4    assert luhn_validate(4532015112830367) == False
5    assert luhn_validate(79927398713) == True
6    assert luhn_validate(79927398714) == False
7
8    # ਉਤਪੰਨ ਨੰਬਰ ਜੋ ਵਾਸਤਵ ਵਿੱਚ ਵੈਲੀਡੇਸ਼ਨ ਪਾਸ ਕਰਦੇ ਹਨ
9    for _ in range(10):
10        generated = generate_valid_number(16)
11        assert luhn_validate(generated) == True, f"ਉਤਪੰਨ {generated} ਵੈਲੀਡੇਸ਼ਨ ਵਿੱਚ ਅਸਫਲ"
12
13    # ਕਿਨਾਰੇ ਦਾ ਕੇਸ: ਇੱਕ ਅੰਕ
14    assert luhn_validate(0) == True  # 0 ਮੋਡ 10 = 0
15
16    # ਕਿਨਾਰੇ ਦਾ ਕੇਸ: ਅਗਵਾਈ ਵਾਲੇ ਜ਼ੀਰੋ ਬਰਕਰਾਰ
17    assert luhn_validate("0000000000000000") != luhn_validate(0)
18
19    print("ਸਾਰੇ ਟੈਸਟ ਪਾਸ ਹੋ ਗਏ!")
20
21test_luhn_algorithm()
22

Frequently Asked Questions

What is the Luhn algorithm used for?

The Luhn algorithm validates identification numbers including credit cards (Visa, Mastercard, Amex), mobile device IMEI numbers, Canadian Social Insurance Numbers, and U.S. healthcare NPI numbers. It catches common data entry mistakes—like mistyped digits or accidentally swapped numbers—before they cause processing errors or failed transactions.

How accurate is the Luhn algorithm at detecting errors?

Luhn catches approximately 98% of single-digit errors and about 90% of adjacent transposition errors (like typing "12" instead of "21"). However, it misses twin errors where both digits are the same (22→55) and jump transpositions (101→404). For most practical applications involving manual data entry, this detection rate is sufficient.

Can I validate credit cards offline with the Luhn algorithm?

Yes, Luhn validation works entirely offline—it's pure mathematics requiring no database lookups or API calls. This makes it perfect for client-side validation in web forms, reducing server load and providing instant feedback to users. But remember: a valid Luhn number doesn't mean the card is active or has available credit.

Is the Luhn algorithm secure for payment processing?

No—Luhn is error detection, not security. It verifies mathematical format only. A passing Luhn check doesn't confirm the card is real, active, funded, or belongs to the user. Modern payment security requires multiple layers: CVV/CVC verification, address validation (AVS), 3D Secure authentication, and tokenization. Luhn is just the first sanity check.

What programming languages support Luhn implementation?

Every general-purpose language can implement Luhn—it's a simple algorithm requiring only basic arithmetic and loops. Python, JavaScript, Java, C++, C#, PHP, Ruby, Go, Rust, and Swift all handle it easily in 10-20 lines of code. Some languages have third-party libraries, but the algorithm is straightforward enough that most developers implement it directly.

Why is it called the mod 10 algorithm?

The final step checks if the digit sum is divisible by 10 using the modulo operation (sum % 10 == 0). "Mod 10" refers to this modulus 10 check. If the remainder is zero when dividing by 10, the number passes—otherwise it fails. This mathematical property is what makes the algorithm work.

Can I generate test credit card numbers with Luhn?

Yes—you can generate numbers that pass Luhn validation for testing payment forms during development. These aren't real, active cards; they just satisfy the mathematical format. This is legal and necessary for testing, but attempting to use generated numbers for actual purchases is fraud. Most payment gateways offer official test card numbers for staging environments.

What are the limitations of the Luhn algorithm?

Luhn won't catch: twin errors (22↔55), jump transpositions (101↔404), phonetic errors (60↔06 in some cases), or multiple simultaneous errors. It also provides no cryptographic security—valid format doesn't mean valid card. Despite these limitations, its simplicity and 90%+ error detection rate make it practical for real-world payment systems when combined with other verification methods.

ਨੰਬਰਾਂ ਦੀ ਵੈਲੀਡੇਸ਼ਨ ਸ਼ੁਰੂ ਕਰੋ

ਉੱਪਰ ਦੇ ਕੈਲਕੁਲੇਟਰ ਦੀ ਵਰਤੋਂ ਕਰੋ ਕ੍ਰੈਡਿਟ ਕਾਰਡ ਨੰਬਰਾਂ ਦੀ ਵੈਲੀਡੇਸ਼ਨ ਕਰਨ, ਵਿਕਾਸ ਵਾਤਾਵਰਣ ਲਈ ਟੈਸਟ ਡੇਟਾ ਉਤਪੰਨ ਕਰਨ, ਜਾਂ ਇਹ ਪਤਾ ਲਗਾਉਣ ਲਈ ਕਿ ਮੋਡ 10 ਐਲਗੋਰਿਦਮ ਹਰੇਕ ਅੰਕ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰੋਸੈਸ ਕਰਦਾ ਹੈ। ਚਰਣ-ਦਰ-ਚਰਣ ਵਿਜ਼ੁਅਲਾਈਜ਼ੇਸ਼ਨ ਲਾਗੂ ਕਰਨ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਡੀਬੱਗ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਅਤੇ ਗੈਰ-ਤਕਨੀਕੀ ਹਿੱਤਧਾਰਕਾਂ ਨੂੰ ਵੈਲੀਡੇਸ਼ਨ ਦੇ ਨਤੀਜਿਆਂ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ।

ਭੁਗਤਾਨ ਫਾਰਮ ਬਣਾ ਰਹੇ ਹੋ, IMEI ਵੈਲੀਡੇਸ਼ਨ ਸਿਸਟਮ ਨੂੰ ਡੀਬੱਗ ਕਰ ਰਹੇ ਹੋ, ਜਾਂ ਬੱਸ ਚੈਕਸਮ ਐਲਗੋਰਿਦਮ ਬਾਰੇ ਸਿੱਖ ਰਹੇ ਹੋ, ਇਹ ਟੂਲ ਤੁਹਾਨੂੰ ਤੁਰੰਤ ਫੀਡਬੈਕ ਅਤੇ ਤਕਨੀਕੀ ਪਾਰਦਰਸ਼ਤਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

ਹਵਾਲੇ ਅਤੇ ਹੋਰ ਪੜ੍ਹਾਈ

1. ਲੂਹਨ, ਐਚ. ਪੀ. (1960). "ਨੰਬਰਾਂ ਦੀ ਜਾਂਚ ਲਈ ਕੰਪਿਊਟਰ". ਯੂ.ਐਸ. ਪੇਟੈਂਟ 2,950,048 - ਐਲਗੋਰਿਦਮ ਦਾ ਮੂਲ ਪੇਟੈਂਟ।

2. ISO/IEC 7812-1:2017 - ਪਛਾਣ ਕਾਰਡ - ਪਛਾਣ ਕਾਰਡ ਨੰਬਰਿੰਗ ਸਿਸਟਮ ਲਈ ਅੰਤਰਰਾਸ਼ਟਰੀ ਮਾਨਕ, ਜੋ ਭੁਗਤਾਨ ਕਾਰਡਾਂ ਲਈ ਲੂਹਨ ਦੀ ਵਰਤੋਂ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ।

3. ਗਾਲੀਅਨ, ਜੋਸਫ (1991). "ਪਛਾਣ ਨੰਬਰਾਂ ਦਾ ਗਣਿਤ" - ਲੂਹਨ ਸਮੇਤ ਵੱਖ-ਵੱਖ ਚੈੱਕ ਅੰਕ ਐਲਗੋਰਿਦਮ ਦਾ ਅਕਾਦਮਿਕ ਵਿਸ਼ਲੇਸ਼ਣ, ਕਾਲਜ ਗਣਿਤ ਜਰਨਲ ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਤ।

4. ਭੁਗਤਾਨ ਕਾਰਡ ਉਦਯੋਗ ਡੇਟਾ ਸੁਰੱਖਿਆ ਮਾਨਕ (PCI DSS) - ਸੁਰੱਖਿਆ ਮਾਨਕ ਜੋ ਭੁਗਤਾਨ ਕਾਰਡ ਡੇਟਾ ਨੂੰ ਕਿਵੇਂ ਨਿਪਟਾਇਆ ਜਾਵੇ, ਸੁਰੱਖਿਆ ਸਟੈਕ ਵਿੱਚ ਲੂਹਨ ਦੇ ਸੰਦਰਭ ਨੂੰ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ।