सर्वात सामान्य CRC-32 अंमलबजावणी, ज्याला CRC-32b देखील म्हणतात. हे बहुपदी 0x04C11DB7 चे परावर्तित रूप वापरते, म्हणजे 0xEDB88320. दोन्ही इनपुट बाइट्स आणि आउटपुट बिट-रिफ्लेक्ड (एलएसबी प्रथम), प्रारंभिक मूल्यासह आणि अंतिम XOR दोन्ही 0xFFFFFFFFF वर सेट केले आहेत.

ZIP, gzip, PNG प्रतिमा, इथरनेट फ्रेम्स (IEEE 802.3), PKCS#7, आणि बऱ्याच लेगसी सिस्टमद्वारे मोठ्या प्रमाणावर वापरले जाते. हे डीफॅक्टो "डीफॉल्ट CRC-32" प्रकार आहे.

G. Castagnoli आणि सहकाऱ्यांनी 1993 मध्ये प्रस्तावित केलेला, हा प्रकार बहुपदी 0x1EDC6F41 (0x82F63B78 ​​प्रतिबिंबित केलेला फॉर्म) वापरतो. त्याच हॅमिंग अंतरावर, हे ISO-HDLC बहुपदी पेक्षा अधिक मजबूत बर्स्ट-एरर डिटेक्शन देते.

हार्डवेअर प्रवेग Intel SSE4.2 आणि ARM CRC32 निर्देशांद्वारे उपलब्ध आहे. हे iSCSI, NVMe, Btrfs आणि SCTP सारख्या आधुनिक स्टोरेज आणि ट्रान्सपोर्ट प्रोटोकॉलमध्ये मोठ्या प्रमाणावर वापरले जाते.

ISO-HDLC प्रमाणे समान 0x04C11DB7 बहुपदी वापरते, परंतु इनपुट किंवा आउटपुट दोन्ही नाहीबिट-प्रतिबिंबित(MSB प्रथम, बिग-एंडियन). प्रारंभिक मूल्य 0xFFFFFFFF आहे आणि अंतिम XOR अक्षम केले आहे (XorOut = 0x00000000).

प्रामुख्याने MPEG-2 वाहतूक प्रवाहातील PSI/SI सारण्यांसाठी (PAT, PMT, NIT, आणि संबंधित सारण्या), तसेच DVB आणि ATSC प्रसारण प्रणालींमधील अखंडता तपासणीसाठी वापरले जाते.

त्याचे पॅरामीटर्स MPEG-2 (बहुपदी 0x04C11DB7, कोणतेही प्रतिबिंब नाही, प्रारंभिक मूल्य 0xFFFFFFFF) सारखेच आहेत. फरक फक्त एवढाच आहेअंतिम XOR 0xFFFFFFFF सह, जो प्रत्येक क्षणी उलटतो. याला CRC-32/AAL5 किंवा CRC-32/DECT-B असेही म्हणतात.

BZip2 संकुचित फाइल स्वरूप आणि ATM AAL5 प्रोटोकॉलच्या ट्रेलर चेकसम फील्डद्वारे वापरले जाते.

इनपुटला a म्हणून हाताळतेUTF-8स्ट्रिंग, त्यास बाइट्समध्ये रूपांतरित करते, आणि नंतर CRC32 ची गणना करते. हा साधा मजकूर, स्त्रोत कोड, JSON आणि तत्सम सामग्रीसाठी सर्वात सामान्य मोड आहे.

टीप: GBK किंवा UTF-16 सारख्या भिन्न वर्ण संचासह एन्कोड केलेला समान मजकूर भिन्न बाइट प्रवाह आणि म्हणून भिन्न CRC32 मूल्य तयार करतो. हे साधन नेहमी UTF-8 वापरते.

इनपुटला कच्चा मानतोहेक्साडेसिमल बाइट लिटरल्स. मोकळी जागा आणि लाइन ब्रेक्सकडे दुर्लक्ष केले जाते. प्रत्येक दोन हेक्स वर्ण एक बाइट (00-FF) होतात.

जेव्हा तुम्हाला नेटवर्क फ्रेम्स, फर्मवेअर इमेज फ्रॅगमेंट्स किंवा मेमरी डंप सारख्या अचूक बायनरी डेटासाठी CRC तपासण्याची आवश्यकता असते तेव्हा उपयुक्त. तुम्ही वायरशार्क किंवा हेक्स डंप आउटपुट थेट पेस्ट करू शकता.

इनपुटला a म्हणून हाताळतेBase64-एनकोड केलेली स्ट्रिंग, ते रॉ बाइट्समध्ये डीकोड करते आणि नंतर CRC32 ची गणना करते. PEM प्रमाणपत्रे, JWT पेलोड, डेटा URI आणि इतर Base64 सामग्रीसाठी उपयुक्त.

मानक Base64 वर्णमाला (A-Z a-z 0-9 + /) चे समर्थन करते. पॅडिंग वर्ण=पर्यायी आहे. URL-सुरक्षित बेस64 (-_) समर्थित नाही.

8-अंकी अप्परकेस हेक्साडेसिमल संख्या म्हणून मूल्य प्रदर्शित करते0x. प्रत्येक वर्ण एकूण 32 बिट्ससाठी 4 बिट्स दर्शवतो. हे बहुतेक साधने, स्त्रोत कोड आणि दस्तऐवजीकरणामध्ये वापरले जाणारे मानक स्वरूप आहे.

दशांश आउटपुटच्या तुलनेत, हेक्साडेसिमल बाइट सीमांचे निरीक्षण करणे सोपे करते आणि मेमरी डंप आणि प्रोटोकॉल फील्ड अधिक नैसर्गिकरित्या जुळते.

एक म्हणून चेकसम प्रदर्शित करतेअसाइन केलेले ३२-बिट दशांश पूर्णांकश्रेणी 0–4,294,967,295 (2³²−1) मध्ये. काही भाषा आणि साधने सीआरसी मूल्यांची दशांश स्वरूपात तुलना करतात आणि डेटाबेस फील्ड अनेकदा हे प्रतिनिधित्व संग्रहित करतात.

टीप: CRC32 निकालांना स्वाक्षरी न केलेले पूर्णांक मानले जावे. Java किंवा C# सारख्या साइन केलेल्या int प्रकारांमध्ये, 0x7FFFFFFF वरील मूल्ये नकारात्मक दिसू शकतात आणि ती uint किंवा विस्तीर्ण अस्वाक्षरित प्रतिनिधित्वामध्ये रूपांतरित केली जावीत.

चेकसमला 32-बिट बायनरी स्ट्रिंग म्हणून प्रदर्शित करते0b. प्रत्येक वर्ण 0 किंवा 1 आहे, डावीकडील सर्वात लक्षणीय बिटसह संरेखित आहे आणि आवश्यक असल्यास अग्रगण्य शून्यांसह पॅड केलेले आहे.

मुख्यतः अंतर्गत CRC अल्गोरिदम समजून घेण्यासाठी, बहुपद विभागाचा अभ्यास करण्यासाठी, शिकवण्यासाठी आणि बिट-लेव्हल चेकसम प्रक्रियेची आवश्यकता असलेल्या एम्बेड केलेल्या परिस्थितीसाठी उपयुक्त.

चेकसम 11-अंकी ऑक्टल संख्या म्हणून प्रदर्शित करते0o. 32 बिट्ससाठी जास्तीत जास्त 11 ऑक्टल वर्ण आवश्यक आहेत कारण 3×11 = 33 > 32. प्रत्येक ऑक्टल अंक 3 बिट्स दर्शवतो.

Octal आउटपुट आधुनिक CRC वर्कफ्लोमध्ये असामान्य आहे, परंतु तरीही ते काही युनिक्स टूल्स, एम्बेडेड फर्मवेअर टूलचेन्स आणि जुन्या कम्युनिकेशन प्रोटोकॉल वैशिष्ट्यांमध्ये दिसते.