সবচেয়ে সাধারণ CRC-32 বাস্তবায়ন, CRC-32b নামেও পরিচিত। এটি বহুপদী 0x04C11DB7 এর প্রতিফলিত রূপ ব্যবহার করে, যথা 0xEDB88320। ইনপুট বাইট এবং আউটপুট উভয়ই বিট-প্রতিফলিত (এলএসবি প্রথম), প্রাথমিক মান এবং চূড়ান্ত XOR উভয়ই 0xFFFFFFFFF এ সেট করা হয়েছে।

জিপ, জিজিপ, পিএনজি ইমেজ, ইথারনেট ফ্রেম (IEEE 802.3), PKCS#7, এবং অনেক লিগ্যাসি সিস্টেম দ্বারা ব্যাপকভাবে ব্যবহৃত হয়। এটি ডি ফ্যাক্টো "ডিফল্ট CRC-32" ভেরিয়েন্ট।

1993 সালে G. Castagnoli এবং সহকর্মীদের দ্বারা প্রস্তাবিত, এই রূপটি বহুপদী 0x1EDC6F41 (0x82F63B78 ​​প্রতিফলিত রূপ) ব্যবহার করে। একই হ্যামিং দূরত্বে, এটি ISO-HDLC বহুপদীর চেয়ে শক্তিশালী বিস্ফোরণ-ত্রুটি সনাক্তকরণের প্রস্তাব দেয়।

Hardware ত্বরণ Intel SSE4.2 এবং ARM CRC32 নির্দেশাবলীর মাধ্যমে উপলব্ধ। আধুনিক স্টোরেজ এবং ট্রান্সপোর্ট প্রোটোকল যেমন iSCSI, NVMe, Btrfs এবং SCTP-এ এটি ব্যাপকভাবে ব্যবহৃত হয়।

ISO-HDLC হিসাবে একই 0x04C11DB7 বহুপদী ব্যবহার করে, কিন্তু ইনপুট বা আউটপুট নয়বিট-প্রতিফলিত(MSB প্রথম, বড়-এন্ডিয়ান)। প্রাথমিক মান হল 0xFFFFFFFF এবং চূড়ান্ত XOR নিষ্ক্রিয় (XorOut = 0x00000000)।

প্রধানত MPEG-2 ট্রান্সপোর্ট স্ট্রীম (PAT, PMT, NIT, এবং সম্পর্কিত টেবিলে) PSI/SI টেবিলের জন্য ব্যবহৃত হয়, এছাড়াও DVB এবং ATSC সম্প্রচার সিস্টেমে অখণ্ডতা পরীক্ষা করা হয়।

এর পরামিতিগুলি প্রায় MPEG-2 (বহুপদ 0x04C11DB7, কোন প্রতিফলন নেই, প্রাথমিক মান 0xFFFFFFFF) এর মতো। পার্থক্য শুধু একটিফাইনাল XOR 0xFFFFFFFF এর সাথে, যা প্রতি বিট উল্টে যায়। এটি CRC-32/AAL5 বা CRC-32/DECT-B নামেও পরিচিত।

BZip2 সংকুচিত ফাইল বিন্যাস এবং ATM AAL5 প্রোটোকলের ট্রেলার চেকসাম ক্ষেত্র দ্বারা ব্যবহৃত।

একটি হিসাবে ইনপুট ব্যবহার করেUTF-8স্ট্রিং, এটিকে বাইটে রূপান্তর করে এবং তারপর CRC32 গণনা করে। প্লেইন টেক্সট, সোর্স কোড, JSON এবং অনুরূপ কন্টেন্টের জন্য এটি সবচেয়ে সাধারণ মোড।

দ্রষ্টব্য: GBK বা UTF-16 এর মতো ভিন্ন অক্ষর সেটের সাথে এনকোড করা একই পাঠ্য একটি ভিন্ন বাইট স্ট্রিম তৈরি করে এবং তাই একটি ভিন্ন CRC32 মান। এই টুল সবসময় UTF-8 ব্যবহার করে।

ইনপুটকে কাঁচা হিসাবে বিবেচনা করেহেক্সাডেসিমেল বাইট লিটারেল। স্থান এবং লাইন বিরতি উপেক্ষা করা হয়. প্রতি দুটি হেক্স অক্ষর একটি বাইট (00-FF) হয়ে যায়।

যখন আপনি সঠিক বাইনারি ডেটা যেমন নেটওয়ার্ক ফ্রেম, ফার্মওয়্যার ইমেজ ফ্র্যাগমেন্ট বা মেমরি ডাম্পের জন্য CRC চেক করতে চান তখন দরকারী। আপনি সরাসরি Wireshark বা হেক্স ডাম্প আউটপুট পেস্ট করতে পারেন।

একটি হিসাবে ইনপুট ব্যবহার করেBase64-এনকোডেড স্ট্রিং, এটিকে কাঁচা বাইটে ডিকোড করে এবং তারপর CRC32 গণনা করে। PEM সার্টিফিকেট, JWT পেলোড, ডেটা URI এবং অন্যান্য Base64 কন্টেন্টের জন্য দরকারী।

আদর্শ বেস64 বর্ণমালা সমর্থন করে (A-Z a-z 0-9 + /)। প্যাডিং চরিত্র=ঐচ্ছিক। URL-নিরাপদ বেস64 (-_) সমর্থিত নয়।

একটি 8-সংখ্যার বড় হাতের হেক্সাডেসিমেল সংখ্যা হিসাবে মানটি প্রদর্শন করে0x। প্রতিটি অক্ষর 4 বিট প্রতিনিধিত্ব করে, মোট 32 বিটের জন্য। এটি বেশিরভাগ টুল, সোর্স কোড এবং ডকুমেন্টেশনে ব্যবহৃত স্ট্যান্ডার্ড ফর্ম্যাট।

দশমিক আউটপুটের সাথে তুলনা করে, হেক্সাডেসিমেল বাইট সীমানা পরিদর্শন করা সহজ করে এবং মেমরি ডাম্প এবং প্রোটোকল ক্ষেত্রগুলিকে আরও স্বাভাবিকভাবে মেলে।

একটি হিসাবে চেকসাম প্রদর্শন করেস্বাক্ষরবিহীন 32-বিট দশমিক পূর্ণসংখ্যাপরিসরে 0–4,294,967,295 (2³²−1)। কিছু ভাষা এবং সরঞ্জাম দশমিক আকারে CRC মান তুলনা করে এবং ডাটাবেস ক্ষেত্র প্রায়ই এই উপস্থাপনা সংরক্ষণ করে।

দ্রষ্টব্য: CRC32 ফলাফলকে স্বাক্ষরবিহীন পূর্ণসংখ্যা হিসাবে বিবেচনা করা উচিত। জাভা বা C# এর মতো সাইনড int প্রকারে, 0x7FFFFFFF-এর উপরে মান নেতিবাচক প্রদর্শিত হতে পারে এবং uint বা বৃহত্তর স্বাক্ষরবিহীন উপস্থাপনায় রূপান্তরিত করা উচিত।

একটি 32-বিট বাইনারি স্ট্রিং হিসাবে চেকসাম প্রদর্শন করে0b। প্রতিটি অক্ষর হল 0 বা 1, বাম দিকে সবচেয়ে উল্লেখযোগ্য বিটের সাথে সারিবদ্ধ, এবং প্রয়োজনে অগ্রণী শূন্য দিয়ে প্যাড করা।

প্রধানত অভ্যন্তরীণ সিআরসি অ্যালগরিদম বোঝার জন্য, বহুপদী বিভাগ অধ্যয়ন, শিক্ষাদান, এবং এমবেডেড পরিস্থিতি যা বিট-লেভেল চেকসাম প্রসেসিং প্রয়োজন তার জন্য দরকারী।

চেকসামকে 11-সংখ্যার অক্টাল সংখ্যা হিসাবে প্রদর্শন করে0o। 32 বিটের জন্য সর্বাধিক 11টি অক্টাল অক্ষর প্রয়োজন কারণ 3×11 = 33 > 32। প্রতিটি অক্টাল ডিজিট 3 বিটের প্রতিনিধিত্ব করে।

অক্টাল আউটপুট আধুনিক CRC ওয়ার্কফ্লোতে অস্বাভাবিক, কিন্তু এটি এখনও কিছু ইউনিক্স টুলস, এমবেডেড ফার্মওয়্যার টুলচেইন এবং পুরানো যোগাযোগ প্রোটোকল স্পেসিফিকেশনে দেখা যায়।