حاسبة خوارزمية لون - التحقق من صحة بطاقات الائتمان وأرقام IMEI

فهم خوارزمية لون

هل تحتاج إلى التحقق من رقم بطاقة ائتمان أو التحقق من رقم IMEI؟ خوارزمية لون (أو "خوارزمية المعدل 10") هي صيغة مجموع تدقيق كانت عمود الفقري للتحقق من المدفوعات منذ عام 1954. صمم العالم في IBM هانز بيتر لون هذا الفحص الرياضي الأنيق للكشف عن الأخطاء المطبعية وأخطاء النسخ التي تعاني منها إدخال البيانات اليدوي - مثل عندما تتبادل رقمين عن طريق الخطأ أو تكتب رقمًا خاطئًا.

وهذا ما يجعلها لا تقدر بثمن: كل شبكات بطاقات الائتمان الرئيسية (فيزا، ماستركارد، أمريكان إكسبريس)، وأرقام IMEI للأجهزة المحمولة، وأرقام التأمين الاجتماعي الكندية، ومعرفات مقدمي الرعاية الصحية الأمريكية تعتمد على هذه الخوارزمية. عندما تكتب رقم بطاقة في نموذج دفع ويرفضه فورًا، فهذا هو فحص لون في العمل.

يتيح لك هذا الحاسبة التحقق من أي تسلسل أرقام أو إنشاء بيانات اختبار تمر بالتحقق - وهو أمر أساسي عند بناء تكاملات الدفع أو اختبار أنظمة التعريف دون استخدام بيانات العملاء الحقيقية.

كيفية استخدام الآلة الحاسبة

التحقق من الأرقام الموجودة: أدخل أي تسلسل أرقام - مثل بطاقة ائتمان من 16 رقمًا أو IMEI من 15 رقمًا - وانقر على "التحقق". ستتمكن فورًا من رؤية ما إذا كان يجتاز فحص mod 10، بالإضافة إلى تفصيل خطوة بخطوة لكيفية معالجة كل رقم. هذا مفيد بشكل خاص عند إصلاح أخطاء في نماذج الدفع أو التحقق من دقة إدخال البيانات.

إنشاء بيانات اختبار: انتقل إلى وضع "الإنشاء" لإنشاء أرقام اختبار صالحة بأي طول. هذه الأرقام تجتاز التحقق من Luhn ولكنها ليست بطاقات حقيقية نشطة - مما يجعلها مثالية لبيئات التطوير حيث تحتاج إلى حالات اختبار واقعية دون المساس بمعلومات الدفع الفعلية.

فهم العملية: يُظهر التصور بالضبط ما يحدث لكل رقم: أيها يتم مضاعفته، ومتى يتم طرح 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$ هو العملية المتبقية.

التطبيقات الواقعية

معالجة المدفوعات: تستخدم كل شبكات البطاقات الرئيسية - فيزا، ماستركارد، أمريكان إكسبريس، ديسكفر - فحص لون كخط دفاع أول ضد الأخطاء الإملائية. عند بناء نموذج الدفع، يساعد التحقق من لون على جانب العميل في منع المستخدمين من إرسال أرقام واضحة الخطأ ويقلل من المكالمات غير الضرورية إلى بوابات الدفع.

تتبع الأجهزة المحمولة: تتضمن أرقام IMEI على الهواتف والأجهزة اللوحية رقم تحقق لون. يصبح هذا حاسمًا في إدارة سلسلة التوريد وأنظمة مصادقة الأجهزة - لقد رأيت أنظمة المستودعات ترفض مسح IMEI غير الصالح على الفور، مما يمنع أخطاء الشحن قبل حدوثها.

المعرفات الصحية: يتحقق نظام المعرف الوطني للمزود (NPI) في الولايات المتحدة من أرقام المزودين باستخدام هذه الخوارزمية. مع ملايين المعاملات الصحية يوميًا، يساعد اكتشاف أخطاء النسخ في معرفات المزودين في منع تأخير الفواتير وتقليل رفض المطالبات.

الهويات الحكومية: تتضمن الأرقام التأمينية الاجتماعية الكندية التحقق من صحة لون. توفر الخوارزمية فحصًا سريعًا دون الحاجة إلى البحث في قاعدة البيانات، مما يجعلها فعالة في سيناريوهات التحقق عالية الحجم.

أنظمة الكتب القديمة: تستخدم بعض تطبيقات ISBN-10 نسخة من لون. بينما يستخدم ISBN-13 خوارزمية رقم تحقق مختلفة، لا تزال أنظمة المكتبات والمخزون القديمة تعتمد على التحقق من صحة لون.

خطوات بالأمثلة التوضيحية

التحقق من رقم بطاقة الائتمان

دعنا نتحقق من الرقم 4532015112830366:

1. بدءًا من اليمين: 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 القديم (الذي استخدم لون) عندما احتاجت الصناعة إلى مساحة معرفات أكبر.

التاريخ والسياق

طوّر هانز بيتر لوهن هذه الخوارزمية في IBM عام 1954، خلال الأيام الأولى للمعالجة الآلية للبيانات. كان لوهن معروفًا بالفعل بعمله الرائد في استرجاع المعلومات - حيث أثر نظام الفهرسة KWIC (الكلمة الرئيسية في السياق) على كيفية البحث في المستندات حتى يومنا هذا - لكن خوارزمية المعامل 10 أصبحت مساهمته الأكثر بقاءً.

وهنا التمييز الحاسم: صمم لوهن هذه الخوارزمية للكشف عن الأخطاء، وليس للأمان. في خمسينيات القرن الماضي، كانت المشكلة تتعلق بأخطاء البطاقات المثقوبة وأخطاء النسخ اليدوية، وليس الاحتيال الرقمي. تلتقط الخوارزمية الأخطاء المطبعية العرضية بشكل رائع - لكنها ليست تشفيرًا. رقم لوهن الصالح لا يعني أن البطاقة نشطة أو ممولة أو تنتمي للشخص الذي يستخدمها.

والملفت للنظر هو مدى فعالية خوارزمية عمرها 70 عامًا في خدمة غرضها الأصلي. يضيف معالجو المدفوعات طبقات من الأمان الحديث (التشفير، التحقق من CVV، 3D Secure)، لكن فحص لوهن الأولي على جانب العميل لا يزال يوقف ملايين الأخطاء الواضحة يوميًا قبل إهدار عرض النطاق على مكالمات بوابة الدفع.

أمثلة التنفيذ

فيما يلي كيفية تنفيذ التحقق من صحة وإنشاء رقم لون في Python وJavaScript وJava. تركز هذه الأمثلة على سهولة القراءة مع الحفاظ على الكفاءة:

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
23طباعة(luhn_validate(4532015112830366))  # صحيح
24طباعة(luhn_validate(4532015112830367))  # خطأ
25طباعة(generate_valid_number(16))  # يولد رقم صالح من 16 رقمًا
26

1دالة luhnValidate(رقم) {
2    const أرقام = رقم.toString().split('').map(Number);
3    let مجموع_التحقق = 0;
4    for (let i = أرقام.length - 1; i >= 0; i--) {
5        let د = أرقام[i];
6        if ((أرقام.length - i) % 2 === 0) {
7            د *= 2;
8            if (د > 9) د -= 9;
9        }
10        مجموع_التحقق += د;
11    }
12    return مجموع_التحقق % 10 === 0;
13}
14
15دالة generateValidNumber(الطول) {
16    const أرقام = Array.from({length: الطول - 1}, () => Math.floor(Math.random() * 10));
17    const مجموع_التحقق = أرقام.reduce((مجموع, رقم, فهرس) => {
18        if ((الطول - 1 - فهرس) % 2 === 0) {
19            رقم *= 2;
20            if (رقم > 9) رقم -= 9;
21        }
22        return مجموع + رقم;
23    }, 0);
24    const رقم_التحقق = (10 - (مجموع_التحقق % 10)) % 10;
25    return parseInt(أرقام.join('') + رقم_التحقق);
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 رقم) {
5        String أرقام = String.valueOf(رقم);
6        int مجموع_التحقق = 0;
7        boolean زوجي = true;
8        for (int i = أرقام.length() - 1; i >= 0; i--) {
9            int رقم_مميز = Character.getNumericValue(أرقام.charAt(i));
10            if (زوجي) {
11                رقم_مميز *= 2;
12                if (رقم_مميز > 9) رقم_مميز -= 9;
13            }
14            مجموع_التحقق += رقم_مميز;
15            زوجي = !زوجي;
16        }
17        return مجموع_التحقق % 10 == 0;
18    }
19
20    public static long generateValidNumber(int الطول) {
21        Random عشوائي = new Random();
22        long[] أرقام = new long[الطول - 1];
23        for (int i = 0; i < الطول - 1; i++) {
24            أرقام[i] = عشوائي.nextInt(10);
25        }
26        long مجموع_التحقق = 0;
27        for (int i = أرقام.length - 1; i >= 0; i--) {
28            long رقم = أرقام[i];
29            if ((الطول - 1 - i) % 2 == 0) {
30                رقم *= 2;
31                if (رقم > 9) رقم -= 9;
32            }
33            مجموع_التحقق += رقم;
34        }
35        long رقم_التحقق = (10 - (مجموع_التحقق % 10)) % 10;
36        long نتيجة = 0;
37        for (long رقم : أرقام) {
38            نتيجة = نتيجة * 10 + رقم;
39        }
40        return نتيجة * 10 + رقم_التحقق;
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 mod 10 = 0
15
16    # حالة خاصة: الأصفار الرائدة محفوظة
17    assert luhn_validate("0000000000000000") != luhn_validate(0)
18
19    print("تم اجتياز جميع الاختبارات!")
20
21test_luhn_algorithm()
22

الأسئلة الشائعة

ما هو خوارزمية لون المستخدمة؟

تتحقق خوارزمية لون من أرقام التعريف بما في ذلك بطاقات الائتمان (فيزا، ماستركارد، أميكس)، وأرقام IMEI للأجهزة المحمولة، وأرقام التأمين الاجتماعي الكندية، وأرقام NPI الصحية الأمريكية. وهي تلتقط أخطاء إدخال البيانات الشائعة - مثل الأرقام المكتوبة بشكل خاطئ أو الأرقام المتبادلة عن طريق الخطأ - قبل أن تتسبب في أخطاء المعالجة أو المعاملات الفاشلة.

ما مدى دقة خوارزمية لون في اكتشاف الأخطاء؟

تلتقط خوارزمية لون حوالي 98٪ من أخطاء الرقم الواحد وحوالي 90٪ من أخطاء التبادل المجاورة (مثل كتابة "12" بدلاً من "21"). ومع ذلك، فهي تفشل في اكتشاف الأخطاء المتطابقة حيث تكون الأرقام متماثلة (22→55) وتبادلات القفزات (101→404). بالنسبة لمعظم التطبيقات العملية التي تتضمن إدخال البيانات يدويًا، فإن معدل الكشف هذا كافٍ.

هل يمكنني التحقق من بطاقات الائتمان دون اتصال باستخدام خوارزمية لون؟

نعم، يعمل التحقق من لون بشكل كامل دون اتصال - وهو مجرد رياضيات بحتة لا يتطلب البحث في قاعدة بيانات أو مكالمات API. هذا يجعله مثاليًا للتحقق من جانب العميل في نماذج الويب، مما يقلل من حمل الخادم ويوفر تغذية راجعة فورية للمستخدمين. ولكن تذكر: الرقم الصالح وفقًا لخوارزمية لون لا يعني أن البطاقة نشطة أو لديها رصيد متاح.

هل خوارزمية لون آمنة لمعالجة المدفوعات؟

لا - لون هو اكتشاف الخطأ، وليس الأمان. إنه يتحقق من الصيغة الرياضية فقط. اجتياز فحص لون لا يؤكد أن البطاقة حقيقية أو نشطة أو ممولة أو تخص المستخدم. تتطلب أمان الدفع الحديث طبقات متعددة: التحقق من CVV/CVC، والتحقق من العنوان (AVS)، والمصادقة ثلاثية الأبعاد، والتشفير. لون هو مجرد أول فحص للتأكد من المنطقية.

ما هي لغات البرمجة التي تدعم تنفيذ خوارزمية لون؟

يمكن لكل لغة عامة الغرض تنفيذ لون - إنها خوارزمية بسيطة تتطلب فقط الحساب الأساسي والحلقات. بايثون، جافا سكريبت، جافا، C++، C#، PHP، روبي، Go، Rust، وSwift تتعامل معها بسهولة في 10-20 سطرًا من التعليمات البرمجية. بعض اللغات لديها مكتبات طرف ثالث، لكن الخوارزمية بسيطة بما يكفي بحيث يقوم معظم المطورين بتنفيذها مباشرة.

لماذا يُطلق عليه خوارزمية المعامل 10؟

الخطوة النهائية تتحقق مما إذا كان مجموع الأرقام قابلاً للقسمة على 10 باستخدام عملية المعامل (sum % 10 == 0). "المعامل 10" يشير إلى هذا الفحص بالمعامل 10. إذا كان المتبقي صفرًا عند القسمة على 10، فإن الرقم يمر - وإلا فإنه يفشل. هذه الخاصية الرياضية هي ما يجعل الخوارزمية تعمل.

هل يمكنني إنشاء أرقام بطاقات ائتمان اختبارية باستخدام لون؟

نعم - يمكنك إنشاء أرقام تجتاز التحقق من لون لاختبار نماذج الدفع أثناء التطوير. هذه ليست بطاقات حقيقية أو نشطة؛ إنها فقط تستوفي الصيغة الرياضية. هذا أمر قانوني وضروري للاختبار، لكن محاولة استخدام الأرقام المولدة للشراء الفعلي هو احتيال. توفر معظم بوابات الدفع أرقام بطاقات اختبار رسمية للبيئات التجريبية.

ما هي القيود المفروضة على خوارزمية لون؟

لن تلتقط لون: الأخطاء المتطابقة (22↔55)، وتبادلات القفزات (101↔404)، والأخطاء الصوتية (60↔06 في بعض الحالات)، أو الأخطاء المتعددة المتزامنة. كما أنها لا توفر أي أمان تشفيري - الصيغة الصالحة لا تعني البطاقة صالحة. على الرغم من هذه القيود، فإن بساطتها ومعدل اكتشاف الخطأ بنسبة 90٪ تجعلها عملية لأنظمة الدفع الواقعية عند دمجها مع طرق التحقق الأخرى.

ابدأ بالتحقق من الأرقام

استخدم الآلة الحاسبة أعلاه للتحقق من أرقام بطاقات الائتمان، وإنشاء بيانات اختبار لبيئات التطوير، أو استكشاف كيفية معالجة خوارزمية المود 10 لكل رقم. يساعد التصور الخطوة بخطوة على تصحيح مشكلات التنفيذ ويشرح نتائج التحقق للأطراف المعنية غير التقنية.

سواء كنت تبني نموذج دفع، أو تقوم بتصحيح نظام التحقق من IMEI، أو تتعلم فقط عن خوارزميات المجموع التدقيقي، فإن هذه الأداة توفر التغذية الراجعة الفورية والشفافية التقنية التي تحتاجها.

المراجع والقراءات الإضافية

1. لون، هـ. ب. (1960). "حاسوب للتحقق من الأرقام". براءة اختراع أمريكية 2,950,048 - براءة الاختراع الأصلية التي تصف الخوارزمية.

2. المعيار الدولي ISO/IEC 7812-1:2017 - بطاقات التعريف - المعيار الدولي لأنظمة ترقيم بطاقات التعريف، الذي يحدد استخدام لون للبطاقات الائتمانية.

3. جاليان، جوزيف (1991). "رياضيات أرقام التعريف" - تحليل أكاديمي لخوارزميات الرقم التحققي المختلفة بما في ذلك لون، المنشور في مجلة الرياضيات الجامعية.

4. معيار أمن بيانات صناعة بطاقات الدفع (PCI DSS) - معايير الأمن التي تحكم كيفية التعامل مع بيانات بطاقات الدفع، مما يوفر سياقًا لمكان تناسب لون في مكدس الأمن.