التطبيق الأكثر شيوعًا لـ CRC-32، ويُسمى أيضًا CRC-32b. ويستخدم الشكل المنعكس من متعدد الحدود 0x04C11DB7، أي 0xEDB88320. تنعكس البتات في كل من بايت الإدخال والإخراج (LSB أولاً)، مع تعيين القيمة الأولية وXOR النهائية على 0xFFFFFFFF.

يُستخدم على نطاق واسع بواسطة صور ZIP وgzip وPNG وإطارات Ethernet (IEEE 802.3) وPKCS#7 والعديد من الأنظمة القديمة. هذا هو البديل "الافتراضي CRC-32" الفعلي.

تم اقتراحه بواسطة G. Castagnoli وزملائه في عام 1993، ويستخدم هذا المتغير متعدد الحدود 0x1EDC6F41 (الشكل المنعكس 0x82F63B78). وعلى نفس مسافة Hamming، فإنه يوفر كشفًا أقوى لخطأ الاندفاع من متعدد الحدود ISO-HDLC.

يتوفر تسريع الأجهزة من خلال تعليمات Intel SSE4.2 وARM CRC32. يُستخدم على نطاق واسع في بروتوكولات التخزين والنقل الحديثة مثل iSCSI وNVMe وBtrfs وSCTP.

يستخدم نفس متعدد الحدود 0x04C11DB7 مثل ISO-HDLC، ولكن لا يتم إدخال أو إخراجبت منعكس(MSB أولًا، كبير النهاية). القيمة الأولية هي 0xFFFFFFFF وتم تعطيل XOR النهائي (XorOut = 0x00000000).

يستخدم بشكل أساسي لجداول PSI/SI في تدفقات النقل MPEG-2 (PAT، وPMT، وNIT، والجداول ذات الصلة)، بالإضافة إلى عمليات التحقق من التكامل في أنظمة البث DVB وATSC.

معلماتها متطابقة تقريبًا مع MPEG-2 (متعدد الحدود 0x04C11DB7، بدون انعكاس، القيمة الأولية 0xFFFFFFFF). الفرق الوحيد هو أfinal XOR مع 0xFFFFFFFF، الذي يقلب كل جزء. ومن المعروف أيضًا باسم CRC-32/AAL5 أو CRC-32/DECT-B.

يُستخدم بواسطة تنسيق الملف المضغوط BZip2 وحقل المجموع الاختباري للمقطورة لبروتوكول ATM AAL5.

يتعامل مع الإدخال باعتباره aUTF-8string، ويحولها إلى بايت، ثم يحسب CRC32. هذا هو الوضع الأكثر شيوعًا للنص العادي والتعليمات البرمجية المصدرية وJSON والمحتوى المشابه.

ملاحظة: نفس النص المشفر بمجموعة أحرف مختلفة مثل GBK أو UTF-16 ينتج عنه تدفق بايت مختلف وبالتالي قيمة CRC32 مختلفة. تستخدم هذه الأداة دائمًا UTF-8.

يتعامل مع الإدخال على أنه خامحرفية بايت سداسية عشرية. يتم تجاهل المسافات وفواصل الأسطر. يصبح كل حرفين سداسي عشري بايت واحد (00–FF).

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

يتعامل مع الإدخال باعتباره aسلسلة مشفرة بـ Base64، يقوم بفك ترميزه إلى بايتات أولية، ثم يقوم بحساب CRC32. مفيد لشهادات PEM وحمولات JWT ومعرفات URI للبيانات ومحتويات Base64 الأخرى.

يدعم الأبجدية Base64 القياسية (A-Z a-z 0-9 + /). حرف الحشو=اختياري. URL الآمن Base64 (-_) غير مدعوم.

يعرض القيمة كرقم سداسي عشري كبير مكون من 8 أرقام مسبوقًا بـ0x. يمثل كل حرف 4 بتات، أي ما مجموعه 32 بت. هذا هو التنسيق القياسي المستخدم في معظم الأدوات والتعليمات البرمجية المصدرية والوثائق.

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

يعرض المجموع الاختباري كـعدد صحيح عشري 32 بت غير موقعفي النطاق 0–4,294,967,295 (2³²−1). تقوم بعض اللغات والأدوات بمقارنة قيم CRC في شكل عشري، وغالبًا ما تقوم حقول قاعدة البيانات بتخزين هذا التمثيل.

ملاحظة: يجب التعامل مع نتائج CRC32 كأعداد صحيحة غير موقعة. في أنواع int الموقعة مثل Java أو C#، قد تظهر القيم الأعلى من 0x7FFFFFFFF سالبة ويجب تحويلها إلى uint أو تمثيل أوسع غير موقع.

يعرض المجموع الاختباري كسلسلة ثنائية 32 بت مسبوقة بـ0b. كل حرف هو 0 أو 1، محاذاة مع البت الأكثر أهمية على اليسار، ومبطن بالأصفار البادئة عند الضرورة.

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

يعرض المجموع الاختباري كرقم ثماني مكون من 11 رقمًا مسبوقًا بـ0o. هناك حاجة إلى 11 حرفًا ثمانيًا على الأكثر لـ 32 بت، لأن 3×11 = 33 > 32. يمثل كل رقم ثماني 3 بتات.

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