কোড — BCD, ASCII, Unicode আর প্যারিটি

১ · কোড কী — একটি চুক্তির টেবিল

ক্রিকেট মাঠের কথা ভাবুন। আম্পায়ার দুই হাত মাথার ওপরে তুললেন — দর্শক সবাই বুঝল, ছক্কা। এক হাত সামনে-পেছনে নাড়লেন — চার। আঙুল তুললেন — আউট। হাতের এই ভঙ্গিগুলো নিজে থেকে কিছুই বলে না। কিন্তু খেলোয়াড়, স্কোরার আর দর্শক সবাই একটি চুক্তি মানেন বলে ভঙ্গিগুলো অর্থ পায়। যে কোনোদিন ক্রিকেট দেখেনি, তার কাছে এগুলো শুধুই হাত নাড়া।

কম্পিউটারের ভেতরেও ঠিক তাই। পর্ব ০৪-এ দেখেছেন, সবকিছু থাকে bit হয়ে — 0 আর 1. আর পর্ব ১৬-এ দেখছেন, সংখ্যাকে কীভাবে binary-তে লেখা হয়। কিন্তু অক্ষর, চিহ্ন, ঘড়ির অঙ্ক — এগুলো বিটে রাখতে হলে একটি টেবিল লাগে: “এই বিট-নকশা মানে এই চিহ্ন”। এই টেবিলের নামই কোড (code). আর কোনো তথ্যকে সেই টেবিল মেনে বিটে বদলানোর কাজকে বলে encoding; উল্টো কাজটি decoding.

একটি পরীক্ষা করি। নিচের আটটি বিট দেখুন: 01000001. এর মানে কী?

তাহলে একটি কোডেই সব কাজ চলে না কেন? কারণ প্রতিটি কোড একটি নির্দিষ্ট সমস্যা সমাধানের জন্য বানানো, আর সেই কাজে সে সেরা:

২ · BCD — দশমিকের প্রতিটি অঙ্ক আলাদা ৪ বিটে

একটি ক্যালকুলেটরে 59 চাপলেন। পর্দায় দুটি অঙ্ক দেখাতে হবে — 5 আর 9. পুরো সংখ্যাটিকে binary-তে বদলালে হয় 111011. কিন্তু এখান থেকে “5” আর “9” আলাদা করে পর্দায় দেখাতে আবার ভাগ-অঙ্ক করে দশমিকে ফেরাতে হয়। ছোট, সস্তা যন্ত্রের জন্য এটা বাড়তি ঝামেলা।

সমাধান: পুরো সংখ্যা নয়, প্রতিটি দশমিক অঙ্ককে আলাদা করে ৪ বিটে লেখা। এর নাম BCD (Binary Coded Decimal). ৪ বিটের প্রতিটি ঘরের মান 8, 4, 2, 1 — তাই একে 8421 কোড-ও বলে। যেহেতু প্রতিটি ঘরের নির্দিষ্ট মান (ওজন) আছে, BCD একটি weighted code. ৪ বিটের এই দলকে পর্ব ০৪-এ nibble নামে চিনেছেন।

BCD-র টেবিল আর অবৈধ কোড

০ থেকে ৯ — দশটি অঙ্কের জন্য দশটি কোড লাগে। কিন্তু ৪ বিটে নকশা হয় ২^৪ = ১৬টি। বাকি ছয়টি — 1010 থেকে 1111 (দশমিকে ১০–১৫) — BCD-তে অবৈধ; কোনো অঙ্ক বোঝায় না। কোনো BCD সংখ্যার ভেতরে এর একটিও দেখলে বুঝবেন, সংখ্যাটি ভুল।

পরীক্ষার খাতার মতো — দুটি উদাহরণ

দশমিক অঙ্ক :    2      0      2      6
BCD (8421) :  0010   0000   0010   0110
∴ (2026)10 = (0010 0000 0010 0110)BCD

BCD        :  1001   0011   0111
দশমিক অঙ্ক :    9      3      7
∴ উত্তর = (937)10

BCD কোথায় ব্যবহার হয়

• ক্যালকুলেটর আর ডিজিটাল ঘড়ি: প্রতিটি অঙ্ক আলাদা থাকায় সরাসরি seven-segment display-এ (আটের মতো সাতটি দাগের পর্দা) পাঠানো যায়।
• কম্পিউটারের ভেতরের ঘড়ি (RTC চিপ): অনেক চিপ সময় আর তারিখ BCD-তেই রাখে।
• টাকার হিসাব: দশমিক ভগ্নাংশ (যেমন ০.১ টাকা) binary-তে হুবহু লেখা যায় না, সামান্য গোলমাল থাকে। তাই ব্যাংকের পুরোনো mainframe সিস্টেম আর কিছু হিসাবের সফটওয়্যার দশমিক-ভিত্তিক কোড ব্যবহার করে।

Excess-3 — এক নজরে

Excess-3 (XS-3) কোডে প্রতিটি দশমিক অঙ্কের সাথে ৩ যোগ করে তারপর ৪ বিটে লেখা হয়। যেমন 5 → 5 + 3 = 8 → 1000. তাই 59-এর excess-3 হলো 1000 1100. এর ঘরগুলোর নির্দিষ্ট ওজন নেই, তাই এটি unweighted কোড। এর একটি বিশেষ গুণ আছে — এটি self-complementing: কোনো অঙ্কের সব বিট উল্টে দিলে (0 ↔ 1) পাওয়া যায় ৯ থেকে সেই অঙ্ক বিয়োগের ফল। যেমন 4 = 0111; উল্টালে 1000 = 5, আর 9 − 4 = 5. পুরোনো যন্ত্রে দশমিক বিয়োগ সহজ করতে এই গুণটি কাজে লাগত (complement দিয়ে বিয়োগের ধারণা পর্ব ১৭-এ দেখেছেন)।

৩ · Gray code — প্রতিবার মাত্র একটি বিট বদলায়

সাধারণ binary-তে ৭ থেকে ৮-এ যেতে কী হয় দেখুন: 0111 → 1000. চারটি বিটই একসাথে বদলাল। কাগজে সমস্যা নেই। কিন্তু একটি যন্ত্রের কথা ভাবুন — ধরুন একটি ঘুরন্ত চাকা, যার অবস্থান চারটি সেন্সর পড়ে। চারটি সেন্সর কখনো ঠিক একই মুহূর্তে বদলায় না। বদলের মাঝপথে কোনোটি আগে, কোনোটি পরে — ফলে মুহূর্তের জন্য 1111 (১৫) বা 0000 (০)-এর মতো সম্পূর্ণ ভুল মান পড়া হতে পারে। একটি রোবটের হাত হঠাৎ ভাবল সে ০ ডিগ্রিতে আছে!

Gray code এই সমস্যার চমৎকার সমাধান: এর নিয়মে পরপর দুটি মানের মধ্যে ঠিক একটি বিট বদলায়। তাই মাঝপথে ভুল পড়লেও সেটি হয় আগের মান, নয়তো পরের মান — কখনো দূরের কোনো মান নয়। এর ঘরগুলোরও নির্দিষ্ট ওজন নেই, তাই এটিও unweighted কোড। একে reflected binary code-ও বলে।

শেষ সারিটি খেয়াল করুন: 100 থেকে আবার 000-এ ফিরতেও একটি বিট বদলায়। তাই Gray code বৃত্তাকার চাকার জন্য একদম উপযুক্ত। এই কারণেই rotary encoder — রোবটের হাতের জোড়, শিল্প-কারখানার মোটর আর CNC মেশিনের অবস্থান মাপার সেন্সর — Gray code ব্যবহার করে।

Binary থেকে Gray — XOR-এর নিয়ম

রূপান্তরে একটিই অপারেশন লাগে — XOR (⊕): দুটি বিট আলাদা হলে 1, একই হলে 0. (0⊕0 = 0, 0⊕1 = 1, 1⊕0 = 1, 1⊕1 = 0. লজিক গেট হিসেবে XOR আসছে পর্ব ২০-এ।) নিচে 1011-কে ধাপে ধাপে Gray code-এ বদলাই:

Binary :  1   0   1   1
Gray   :  1   _   _   _

Binary :  1 ⊕ 0   1   1
Gray   :  1   1   _   _

Binary :  1   0 ⊕ 1   1      → 1
Binary :  1   0   1 ⊕ 1      → 0
Gray   :  1   1   1   0

(1011)binary = (1110)Gray

যাচাই (Gray → Binary):
B1 = G1 = 1
B2 = B1 ⊕ G2 = 1 ⊕ 1 = 0
B3 = B2 ⊕ G3 = 0 ⊕ 1 = 1
B4 = B3 ⊕ G4 = 1 ⊕ 0 = 1   → 1011 ✓

৪ · ASCII আর EBCDIC — ইংরেজি লেখার কোড

পর্ব ০৭-এ ASCII-র সাথে আপনার পরিচয় হয়েছে। এবার ভেতরে ঢুকি। ASCII (American Standard Code for Information Interchange) প্রথম প্রকাশিত হয় ১৯৬৩ সালে। এটি ৭ বিটের কোড — তাই ঘর ২^৭ = ১২৮টি (০ থেকে ১২৭)। ঘরগুলো এভাবে ভাগ করা:

প্রথম ৩২টি ঘর আর ১২৭ হলো control character — এগুলো ছাপা হয় না, যন্ত্রকে নির্দেশ দেয়: “নতুন লাইনে যাও”, “ঘণ্টা বাজাও”, “এক ঘর পিছাও”। এগুলো এসেছে টেলিপ্রিন্টার যন্ত্রের যুগ থেকে। আজও Windows-এ টেক্সট ফাইলে লাইন শেষ হয় CR + LF (১৩, ১০) দিয়ে, আর Linux-এ শুধু LF (১০) দিয়ে — তাই একটি ফাইল কখনো কখনো অন্য সিস্টেমে সব লাইন এক লাইনে জোড়া দেখায়।

অঙ্কের ঘরটিও খেয়াল করুন: অক্ষর '0'-এর ASCII মান 48, সংখ্যা শূন্য নয়। কি-বোর্ডে “7” চাপলে কম্পিউটার পায় 55; গণনা করার আগে প্রোগ্রামকে 48 বিয়োগ করে আসল সংখ্যা 7 বের করতে হয়।

C     a     t        ← তিনটি অক্ষর, তিনটি আলাদা ঘর

C  →  67     (hex 43)
a  →  97     (hex 61)
t  →  116    (hex 74)

67   = 64 + 2 + 1          → 1000011
97   = 64 + 32 + 1         → 1100001
116  = 64 + 32 + 16 + 4    → 1110100

01000011 01100001 01110100
↑ ৮ নম্বর বিট: 0, বা প্যারিটি বিট (অংশ ৬)
মোট ২৪টি বিট, পরপর — ‿‾‾‿‿‿‾‾ …

বড় হাত আর ছোট হাতের রহস্য — একটি বিট, মান ৩২

A = 65 আর a = 97. পার্থক্য ঠিক ৩২. এটা কাকতালীয় নয় — নকশাকারীরা ইচ্ছা করেই এমন রেখেছিলেন। binary-তে দেখুন:

A = 1000001   (65)
a = 1100001   (97)
        ↑ শুধু এই একটি বিট (মান 32) আলাদা

তাই বড় হাতকে ছোট হাত বানাতে শুধু একটি বিট 1 করলেই চলে, উল্টোটা করতে 0. পুরোনো ধীর কম্পিউটারে এই সহজ কৌশল অনেক সময় বাঁচাত। একইভাবে অঙ্কগুলো 48 (hex 30) থেকে শুরু, তাই '7' = hex 37 — শেষের অঙ্কটিই আসল সংখ্যা।

Extended ASCII আর code page-এর বিশৃঙ্খলা

কম্পিউটারের byte ৮ বিটের, অথচ ASCII নেয় ৭ বিট। বাড়তি বিটটি কাজে লাগালে আরও ১২৮টি ঘর (১২৮–২৫৫) পাওয়া যায়। এই ৮ বিটের সংস্করণগুলোকে একসাথে বলে extended ASCII. সমস্যা হলো, এর কোনো একক মান ছিল না। পশ্চিম ইউরোপে ঘর ২৩৩ মানে é, রাশিয়ার code page-এ সেখানে সিরিলিক অক্ষর, আর বিজয়-যুগের বাংলা ফন্ট সেখানে বসাত বাংলা অক্ষরের টুকরো (পর্ব ০৭-এর “Avwg” সমস্যা)। পাঠ্যবইয়ে এ কারণে “ASCII-7” (১২৮ অক্ষর) আর “ASCII-8” (২৫৬ অক্ষর) — দুটি নামই পাবেন।

EBCDIC — IBM-এর নিজস্ব পথ

ASCII-র প্রায় একই সময়ে, ১৯৬৪ সালে IBM তাদের বিখ্যাত System/360 মেইনফ্রেমের জন্য নিজস্ব ৮ বিটের কোড ব্যবহার শুরু করে — EBCDIC (Extended Binary Coded Decimal Interchange Code). এটি এসেছে punched card-এর পুরোনো BCD-ভিত্তিক নকশা থেকে। তাই এখানে অক্ষরগুলো একটানা নয়: A–I হলো hex C1–C9, তারপর একটি ফাঁক, J শুরু D1 থেকে। অঙ্ক 0–9 হলো F0–F9. আজও কিছু ব্যাংক আর বিমা কোম্পানির IBM মেইনফ্রেমে EBCDIC চলে; সেখান থেকে ডেটা আনতে রূপান্তর লাগে।

৫ · Unicode, UTF-8, UTF-16 আর UTF-32

পর্ব ০৭-এ দেখেছেন, code page-এর বিশৃঙ্খলা দূর করতে এসেছে Unicode — পৃথিবীর প্রায় সব লিপির প্রতিটি অক্ষর ও চিহ্নের জন্য একটি করে স্থায়ী নম্বর, যার নাম code point. যেমন A = U+0041 (ASCII-র ৬৫, hex-এ ৪১ — হুবহু একই), “আ” = U+0986, আর হাসিমুখ 😀 = U+1F600. বাংলার ব্লক U+0980–U+09FF. এই পর্বে আমরা দেখব বড় ছবিটি — কোড-স্পেস কত বড়, আর নম্বর থেকে বাইট বানানোর তিনটি নিয়ম।

কোড-স্পেস: ১৭টি plane

Unicode-এর নম্বর চলে U+0000 থেকে U+10FFFF পর্যন্ত — মোট ১১,১৪,১১২টি ঘর। এগুলো ১৭টি plane-এ ভাগ করা, প্রতিটিতে ৬৫,৫৩৬টি ঘর। প্রথমটি Plane 0 — Basic Multilingual Plane (BMP): এখানে ইংরেজি, বাংলা, আরবি, হিন্দি, চীনা-জাপানির বেশিরভাগ — আধুনিক লেখার প্রায় সবকিছু। ইমোজি, প্রাচীন লিপি আর বিরল চীনা অক্ষর থাকে পরের plane-গুলোতে; যেমন 😀 আছে Plane 1-এ। এখন পর্যন্ত দেড় লাখের বেশি অক্ষর বরাদ্দ হয়েছে, আর প্রতি বছর নতুন সংস্করণে কিছু যোগ হয়।

Character set বনাম encoding — দুটি আলাদা প্রশ্ন

অনেকে “Unicode” আর “UTF-8” এক জিনিস ভাবেন। আসলে এরা দুটি আলাদা প্রশ্নের উত্তর:

• Character set — “কোন অক্ষরের নম্বর কত?” Unicode এই তালিকা। “আ” = U+0986 — ব্যস, এর বেশি কিছু বলে না।
• Encoding — “সেই নম্বর বাইটে কীভাবে লিখব?” একই নম্বর লেখার কয়েকটি নিয়ম আছে: UTF-8, UTF-16 আর UTF-32.

• UTF-8 (১ থেকে ৪ বাইট): ছোট নম্বরে কম বাইট। U+007F পর্যন্ত ১ বাইট, U+07FF পর্যন্ত ২, U+FFFF পর্যন্ত ৩ (বাংলা এখানে), তার ওপরে ৪. এর সবচেয়ে বড় গুণ — ASCII-compatible: যেকোনো পুরোনো ASCII ফাইল হুবহু একটি বৈধ UTF-8 ফাইল। “আ” কীভাবে ঠিক E0 A6 86 হয়, সেই ছাঁচের হিসাব পর্ব ০৭-এ ধাপে ধাপে দেখেছেন। আজকের প্রায় সব ওয়েবপেজ UTF-8-এ।
• UTF-16 (২ বা ৪ বাইট): BMP-র অক্ষর ২ বাইটে; তার বাইরের অক্ষর (যেমন ইমোজি) দুটি ২-বাইটের টুকরো জোড়া দিয়ে ৪ বাইটে — একে বলে surrogate pair (D83D DE00). Windows-এর ভেতরে আর Java ও JavaScript-এর string-এ এটি ব্যবহার হয়। বাংলা লেখা UTF-16-এ UTF-8-এর চেয়ে কম জায়গা নেয় (২ বনাম ৩ বাইট), কিন্তু ইংরেজি নেয় দ্বিগুণ।
• UTF-32 (সবসময় ৪ বাইট): সবচেয়ে সরল — code point-টাই সোজা ৪ বাইটে। “১০০তম অক্ষর কোথায়” — এক লাফে বের করা যায়। কিন্তু জায়গা অনেক বেশি খায়, তাই ফাইলে প্রায় দেখা যায় না; প্রোগ্রামের ভেতরের কাজে মাঝে মাঝে ব্যবহার হয়।

Mojibake — হিজিবিজি লেখা কেন হয়

কখনো ইমেইল বা ওয়েবপেজে এমন দেখেছেন — আমি? এর জাপানি নাম mojibake (文字化け, “রূপ বদলে যাওয়া অক্ষর”)। এটা পর্ব ০৭-এর “Avwg” সমস্যা থেকে আলাদা — সেখানে ছিল ফন্টের কৌশল; এখানে encoding-এর অমিল। ঘটনাটি এমন:

সমাধানও তাই সহজ: ব্রাউজার বা এডিটরে encoding “UTF-8” বেছে নিন। ওয়েবপেজে <meta charset="UTF-8"> লাইনটি ঠিক এই ঘোষণাই করে। আর যদি বাইটগুলো সত্যিই এমন হয় যা UTF-8-এ বৈধ নয়, সফটওয়্যার সেখানে বসায় একটি বিশেষ চিহ্ন � (U+FFFD) — “এখানে কিছু একটা পড়া যায়নি”। ফাইল সেভ করার সময় একবার সেই চিহ্ন বসে গেলে আসল লেখা চিরতরে হারিয়ে যায়।

৬ · প্যারিটি বিট — ভুল ধরার সবচেয়ে সহজ কৌশল

তার, বাতাস বা চুম্বকীয় ডিস্ক — কোনো মাধ্যমই নিখুঁত নয়। বিদ্যুতের ঝটকা, বজ্রপাত, মহাজাগতিক রশ্মি বা দুর্বল সিগন্যালে মাঝে মাঝে একটি 0 উল্টে 1 হয়ে যায়। তখন প্রাপক কীভাবে বুঝবেন যে ভুল হয়েছে? একে বলে error detection.

সবচেয়ে সহজ কৌশল parity bit: ডেটার সাথে একটি বাড়তি বিট জুড়ে দেওয়া, যাতে মোট 1-এর সংখ্যা একটি নির্দিষ্ট নিয়ম মানে। নিয়ম দুই রকম:

• Even parity (জোড় প্যারিটি): প্যারিটি বিটসহ মোট 1-এর সংখ্যা জোড় হবে।
• Odd parity (বিজোড় প্যারিটি): প্যারিটি বিটসহ মোট 1-এর সংখ্যা বিজোড় হবে।

প্রেরক আর প্রাপক আগেই ঠিক করে নেন কোন নিয়ম চলবে — আবারও সেই চুক্তি! নিচের টেবিলে ৭ বিটের কয়েকটি ডেটার প্যারিটি বিট হিসাব করা হলো। এখানে প্যারিটি বিট বসানো হয়েছে বাঁ দিকে (MSB); কেউ কেউ ডানে বসান — প্রশ্নে যা বলা থাকে, সেটাই মানবেন।

শেষ সারিটি একটি কারণে মজার: odd parity-তে সব-শূন্য ডেটাও অন্তত একটি 1 নিয়ে যায়। তাই “তার ছিঁড়ে গিয়ে শুধু 0 আসছে” — এমন অবস্থাও ধরা পড়ে। এবার পুরো ঘটনাটি দেখুন:

ডেটা      :  1 0 1 1 0 0 1
1 গুনুন   :  1 + 1 + 1 + 1 = ৪টি  (জোড়)

ইতিমধ্যে জোড় → প্যারিটি বিট = 0
পাঠানো হলো :  0 1 0 1 1 0 0 1   (মোট 1 = ৪, জোড়)

পাঠানো   :  0 1 0 1 1 0 0 1
            ⚡ নয়েজ
পৌঁছাল   :  0 1 1 1 1 0 0 1

পৌঁছাল   :  0 1 1 1 1 0 0 1
1 আছে    :  ৫টি — বিজোড়!
নিয়ম ছিল জোড় → ভুল ধরা পড়েছে, আবার পাঠানোর অনুরোধ

পাঠানো   :  0 1 0 1 1 0 0 1
পৌঁছাল   :  0 1 1 1 1 1 0 1
1 আছে    :  ৬টি — জোড় → প্রাপক ভাবল “সব ঠিক” ✗

নিজে চালিয়ে দেখুন — একটি ছোট কোড-এনকোডার

নিচের প্রোগ্রামটি এই পর্বের সব কোড একসাথে হিসাব করে: “Cat”-এর ASCII, 59-এর BCD আর binary, ০–৭-এর Gray code, 1011001-এর প্যারিটি, আর তিনটি অক্ষরের UTF-8 ও UTF-16 বাইট। কোড বোঝার দরকার নেই — “চালান” চেপে আউটপুট মিলিয়ে দেখুন উপরের টেবিলগুলোর সাথে:

const toBin = (n, w) => n.toString(2).padStart(w, "0");
for (const ch of "Cat") {                       // ASCII
  const c = ch.charCodeAt(0);
  console.log(`${ch} = ${c} = 0x${c.toString(16).toUpperCase()} = ${toBin(c, 7)}`);
}
const num = 59;                                  // BCD বনাম binary
const bcd = [...String(num)].map(d => toBin(Number(d), 4)).join(" ");
console.log(`${num}: BCD ${bcd} | binary ${toBin(num, 1)}`);
const gray = [];                                 // Gray code 0-7
for (let n = 0; n < 8; n++) gray.push(toBin(n ^ (n >> 1), 3));
console.log("Gray 0-7: " + gray.join(" ") + " | 1011 -> " + toBin(0b1011 ^ 0b101, 4));
const bits = "1011001";                          // প্যারিটি
const ones = [...bits].filter(b => b === "1").length;
console.log(`${bits}: ${ones}টি 1 -> even parity ${ones % 2}, odd parity ${1 - ones % 2}`);
const enc = new TextEncoder();                   // UTF-8 বাইট
for (const s of ["A", "আ", "😀"]) {
  const hex = [...enc.encode(s)].map(b => b.toString(16).toUpperCase()).join(" ");
  console.log(`${s}: UTF-8 ${enc.encode(s).length} বাইট (${hex}), UTF-16 ${s.length * 2} বাইট`);
}

৭ · Checksum, Hamming আর CRC — আরও শক্তিশালী পাহারাদার

প্যারিটি এক বাইটের পাহারাদার। কিন্তু পুরো একটি ফাইল বা নেটওয়ার্কের একটি প্যাকেট পাহারা দিতে আরও শক্তিশালী কৌশল লাগে। এখানে তিনটির মূল ধারণা দেখি — বিস্তারিত হিসাব নয়, শুধু বুদ্ধিটা।

Checksum — যোগফল মিলিয়ে দেখা

দোকানি মাল পাঠানোর চালানের নিচে মোট টাকা লিখে দেন। ক্রেতা আলাদা আলাদা দাম যোগ করে দেখেন মোটের সাথে মেলে কি না। Checksum ঠিক এই কাজ করে: প্রেরক ডেটার সংখ্যাগুলো একটি নির্দিষ্ট নিয়মে যোগ করে ফলটি সাথে পাঠান।

পাঠানো ডেটা :  25   40   60      checksum = 125
পৌঁছাল      :  25   44   60      নতুন যোগফল = 129 ≠ 125  → ভুল!

ইন্টারনেটের IP আর TCP প্যাকেটে এ ধরনের ১৬ বিটের checksum থাকে। তবে দুর্বলতাও আছে: দুটি সংখ্যার জায়গা অদলবদল হলে যোগফল একই থাকে, ভুল ধরা পড়ে না।

Hamming code — ভুল ধরা নয়, ঠিক করা

প্যারিটি বলে “ভুল আছে”, কিন্তু কোথায় বলে না। ১৯৫০ সালে Richard Hamming দেখালেন, কয়েকটি প্যারিটি বিটকে চতুরভাবে সাজালে ভুলটি কোন জায়গায়, সেটাও বলা যায় — আর binary-তে জায়গা জানা মানেই ঠিক করা, কারণ শুধু সেই বিটটি উল্টে দিলেই হলো। এই কাজকে বলে error correction.

সবচেয়ে পরিচিত রূপ Hamming code (7,4): ৪টি ডেটা বিটের সাথে ৩টি প্যারিটি বিট, মোট ৭. প্যারিটি বিট বসে ১, ২ আর ৪ নম্বর ঘরে, আর প্রতিটি ভিন্ন ভিন্ন ঘরের দল পাহারা দেয়। প্রাপক তিনটি যাচাই করে পান তিনটি ফল — পাশাপাশি বসালে একটি ৩ বিটের binary সংখ্যা। ফল 000 মানে সব ঠিক; ফল 101 মানে “৫ নম্বর ঘরের বিটটি উল্টে গেছে” — উল্টে দিন, ঠিক হয়ে গেল! সার্ভারের ECC RAM এই ধারণারই উন্নত রূপ ব্যবহার করে।

CRC — ভাগশেষ দিয়ে পাহারা

CRC (Cyclic Redundancy Check)-এ পুরো ডেটাকে একটি বিশাল binary সংখ্যা ধরে একটি আগে-ঠিক-করা সংখ্যা দিয়ে বিশেষ নিয়মে ভাগ করা হয়; ভাগশেষটি ডেটার সাথে পাঠানো হয়। প্রাপক একই ভাগ করেন — ভাগশেষ না মিললে ভুল। এটি পাশাপাশি অনেকগুলো বিট একসাথে নষ্ট হলেও (যেমন বজ্রপাতে এক ঝলকে) প্রায় সবসময় ধরে ফেলে। Ethernet-এর প্রতিটি ফ্রেম, ZIP ফাইল আর PNG ছবিতে CRC থাকে — ZIP খুলতে গিয়ে “CRC error” দেখলে বুঝবেন ফাইলটি নষ্ট হয়েছে।

৮ · দৈনন্দিন জীবনের কোড — বারকোড, QR আর Morse

বারকোড আর check digit

সুপারশপে ক্যাশিয়ার পণ্যের গায়ে স্ক্যানার ধরলেই দাম উঠে আসে। পণ্যের গায়ের কালো-সাদা দাগগুলো একটি সংখ্যার কোড — সবচেয়ে প্রচলিত EAN-13, অর্থাৎ ১৩ অঙ্কের সংখ্যা। শুরুর কয়েকটি অঙ্ক বলে পণ্যটি কোন দেশের নিবন্ধন সংস্থায় নথিভুক্ত (বানানো কোথায়, তা নয়), মাঝের অঙ্কগুলো কোম্পানি আর পণ্য, আর শেষ অঙ্কটি একটি check digit — বাকি ১২টি অঙ্ক থেকে হিসাব করা। স্ক্যানার একটি দাগ ভুল পড়লে হিসাব মেলে না, আর মেশিন “বিপ” না দিয়ে আবার স্ক্যান করতে বলে। বইয়ের ISBN-13-ও একই নিয়মের — শুরু 978 বা 979 দিয়ে, আর বাংলাদেশের বইয়ে এরপর সাধারণত 984.

অঙ্ক   :  9  7  8  9  8  4  8  0  1  2  3  4
ওজন    :  1  3  1  3  1  3  1  3  1  3  1  3
গুণফল  :  9 21  8 27  8 12  8  0  1  6  3 12
যোগফল  = 115
115-এর পরের দশকের গুণিতক 120 → 120 − 115 = 5
∴ check digit = 5, পুরো নম্বর 9789848012345

QR কোড — অর্ধেক ছেঁড়া হলেও পড়া যায়

QR code ১৯৯৪ সালে জাপানের Denso Wave কোম্পানি বানায় — গাড়ির যন্ত্রাংশ দ্রুত চেনার জন্য। আজ bKash-Nagad-এ QR payment, রেস্টুরেন্টের মেনু, ওয়েবসাইটের লিংক — সবখানে। এর বড় শক্তি error correction: ভেতরে Reed–Solomon নামের একটি সংশোধনী কোড আছে। কতটা নষ্ট অংশ সামলাতে পারবে, তার চারটি স্তর:

অনেক QR কোডের মাঝখানে কোম্পানির লোগো থাকে, তবু পড়া যায় — কারণ লোগোটি যতটুকু ঢেকেছে, error correction সেটুকু পুনরুদ্ধার করে নেয়। দাম: যত উঁচু স্তর, তত বেশি বাড়তি বিট, তাই একই আকারে কম ডেটা ধরে।

Morse code — ছোট অক্ষরে ছোট সংকেত

Morse code-এ প্রতিটি অক্ষরের সংকেতের দৈর্ঘ্য সমান নয়। ইংরেজিতে সবচেয়ে বেশি ব্যবহৃত অক্ষর E — তার সংকেত মাত্র একটি ডট (·); T একটি ড্যাশ (–)। আর কম ব্যবহৃত Q হলো – – · –. ফলে গড়ে একটি বার্তা পাঠাতে কম সংকেত লাগে। এটাই variable-length কোড — আর এই একই বুদ্ধি থেকে পরে এসেছে ডেটা compression: ZIP ফাইল বা ছবি ছোট করার কৌশলে বেশি ঘনঘন আসা জিনিসকে ছোট কোড দেওয়া হয় (পর্ব ২৮-এ compression দেখবেন)। বিপদের সংকেত SOS হলো · · · – – – · · · — সহজে চেনা যায় বলেই বেছে নেওয়া।

৯ · AI-এর যুগে কোড-টেবিল — দ্রুত, কিন্তু যাচাই করে

AI চ্যাটবট এক সেকেন্ডে পুরো ASCII টেবিল, BCD-র তালিকা বা Gray code-এর ছক বানিয়ে দিতে পারে। পরীক্ষার প্রস্তুতিতে এটা দারুণ সাহায্য। কিন্তু এই বিষয়ে AI কিছু নির্দিষ্ট ভুল প্রায়ই করে — কারণ সে হিসাব করে না, অনুমান করে লেখে (পর্ব ১৩-এ “AI hallucination” দেখেছেন)। সংখ্যার কোডে একটি অঙ্কের ভুল মানেই পুরো উত্তর ভুল।

AI-এর দেওয়া কোড-টেবিল হাতে পেলে — যাচাইয়ের চেকলিস্ট

• অন্তত তিনটি মান পরিচিত নোঙরের সাথে মিলিয়েছি: A = 65, a = 97, '0' = 48
• বড় আর ছোট হাতের অক্ষরের পার্থক্য ঠিক ৩২ কি না দেখেছি
• UTF-8 বাইট সংখ্যা একটি টুল দিয়ে (যেমন উপরের এনকোডার বা ব্রাউজারের console) যাচাই করেছি
• BCD উত্তরে কোনো ৪-বিটের দল 1001-এর বেশি নেই
• Gray code-এর পরপর দুটি সারিতে ঠিক একটি বিট বদলেছে কি না গুনে দেখেছি
• প্যারিটি উত্তরে প্যারিটি বিটসহ মোট 1 গুনে নিয়ম (জোড়/বিজোড়) মিলিয়েছি