ডেটার বিট-রূপ — অক্ষর, Unicode, endianness আর bit manipulation

১ · সবকিছুই বিট — একই ৩২ বিট, চার রকম অর্থ

মহল্লার একটি বাড়ির দেয়ালে লেখা “১২”. পিয়নের কাছে এটি বাড়ির নম্বর, বাসের যাত্রীর কাছে রুট নম্বর, আর দোকানির কাছে হয়তো ডিমের দাম। লেখাটি একই, অর্থ ঠিক করে কে পড়ছে আর কোন উদ্দেশ্যে। কম্পিউটারের মেমরিতেও ঠিক এমনই ঘটে। মেমরিতে থাকে শুধু bit — 0 আর 1. সেখানে কোথাও লেখা থাকে না “এটি একটি সংখ্যা” বা “এটি একটি অক্ষর”।

পর্ব ০৪-এ আপনি binary আর hexadecimal দেখেছেন, আর পর্ব ০৫-এ দেখেছেন integer কীভাবে বিটে বসে। এবার একটি চমকপ্রদ পরীক্ষা করি। নিচের ৩২টি বিট নিন:

এই একই বিটগুলো চারজন আলাদা “পাঠক” চারভাবে পড়ে:

প্রতিটি পড়াই “সঠিক”। CPU যদি program counter দিয়ে এই word-টি আনে, এটি instruction; একটি flw (float load) নির্দেশ আনলে এটি দশমিক সংখ্যা; printf("%s") আনলে এটি লেখা। অর্থাৎ type কোনো বিটের গায়ে লেখা থাকে না — type হলো পড়ার নিয়ম, আর সেই নিয়ম থাকে instruction-এর ভেতরে। High-level ভাষায় compiler type মনে রাখে আর ঠিক instruction বেছে দেয়; মেশিনের স্তরে কেবল বিট।

এই ভাবনার একটি ঐতিহাসিক মূল আছে। ১৯৪০-এর দশকে stored-program ধারণা (পর্ব ০১ আর ০২-এ দেখেছেন) বলেছিল, প্রোগ্রাম আর ডেটা একই মেমরিতে থাকবে। এর অর্থই হলো — instruction আর সংখ্যা মেমরিতে আলাদা করে চেনার কোনো উপায় নেই। এই নমনীয়তা থেকেই compiler, loader আর JIT সম্ভব হয়েছে (একটি প্রোগ্রাম আরেকটি প্রোগ্রামের instruction “ডেটা” হিসেবে লিখতে পারে)। আবার এখান থেকেই এসেছে বহু নিরাপত্তা-সমস্যা: ডেটা হিসেবে ঢোকানো বিট যদি instruction হিসেবে চলে যায়। আধুনিক CPU তাই page-এ “execute নিষেধ” বিট (NX বা XN) রাখে — সেটি পর্ব ৫০-এ আসবে।

২ · Bit, nibble, byte আর word — মাপের একক

বাজারে চাল মাপা হয় ছটাক, সের, মণে। বিটেরও তেমন কয়েকটি প্রচলিত মাপ আছে:

byte সবসময় ৮ বিট ছিল না। ১৯৬০-এর দশকে ৬ বা ৯ বিটের “byte”-ও ছিল; IBM System/360 (১৯৬৪) ৮ বিটের byte জনপ্রিয় করে, আর পরে এটিই নিয়ম হয়ে যায়। নেটওয়ার্কের RFC-গুলো তাই সাবধানে “octet” (ঠিক ৮ বিট) শব্দটি ব্যবহার করে। C ভাষাও নিশ্চয়তা দেয় শুধু “char অন্তত ৮ বিট” (CHAR_BIT).

Word — যে শব্দের মানে ISA-ভেদে বদলায়

“Word” শব্দটি সবচেয়ে বিভ্রান্তিকর, কারণ প্রতিটি ISA-র নিজের পরিভাষা আছে:

তাহলে “৬৪-বিট CPU” মানে কী? সাধারণত এর অর্থ — general-purpose register ৬৪ বিট চওড়া, আর memory address-ও ৬৪ বিটের register-এ রাখা হয়। ফলে একটি pointer ৮ byte. তবে বাস্তবে x86-64 CPU-গুলো সাধারণত ৪৮ বিটের (নতুন কিছুতে ৫৭ বিটের) virtual address ব্যবহার করে — বাকি বিটগুলোর নিয়ম পর্ব ৫০-এ।

C ভাষায় int, long-এর মাপও ISA আর OS মিলে ঠিক হয়, একে বলে data model. Linux আর macOS-এর ৬৪-বিট প্রোগ্রাম LP64 মানে: long আর pointer ৮ byte, int ৪ byte. কিন্তু ৬৪-বিট Windows LLP64: সেখানে long মাত্র ৪ byte, শুধু long long আর pointer ৮ byte. একই C কোড দুই OS-এ ভিন্ন আচরণ করতে পারে — তাই বিট-গোনা কাজে uint32_t, uint64_t-এর মতো নির্দিষ্ট মাপের type (<stdint.h>) ব্যবহার করাই পেশাদার নিয়ম।

৩ · Alignment আর padding — struct কেন বড় হয়ে যায়

মেমরি আর cache (পর্ব ৪৫) ডেটা দেয় নির্দিষ্ট মাপের টুকরো ধরে — যেমন ৮ byte-এর bus, ৬৪ byte-এর cache line. একটি ৪-byte int যদি ঠিকানা ৪-এর গুণিতকে থাকে, সেটি কখনো দুটি টুকরোর সীমানা পার হয় না: এক বারে পড়া যায়। একেই বলে natural alignment: N byte-এর একটি সাধারণ মান (N = ১, ২, ৪, ৮) এমন ঠিকানায় বসবে, যা N-এর গুণিতক।

ঠিকানা ৬ থেকে শুরু হওয়া একটি ৪-byte মান ৬, ৭, ৮, ৯ — চারটি byte নেয়। ৮-byte-এর টুকরো ধরে আনলে ৬–৭ পড়ে প্রথম টুকরোয় (০–৭), আর ৮–৯ পড়ে দ্বিতীয়টিতে (৮–১৫)। ফলে দুবার আনতে হয়, তারপর জোড়া লাগাতে হয়। ISA-ভেদে এর ফল আলাদা:

• x86-64: misaligned access চলে, তবে cache line বা page-এর সীমানা পার হলে ধীর হতে পারে। আর atomic instruction যদি দুটি cache line জুড়ে থাকে (“split lock”), পুরো সিস্টেমের গতিতে বড় ধাক্কা লাগে।
• ARMv8 (AArch64): সাধারণ মেমরিতে বেশিরভাগ load/store misaligned হলেও চলে, কিন্তু atomic/exclusive instruction আর device memory-তে alignment বাধ্যতামূলক।
• RISC-V: spec বলে misaligned access hardware নিজে সামলাতে পারে, অথবা একটি exception তুলে software-কে দিয়ে সামলাতে পারে — দ্বিতীয় ক্ষেত্রে এটি শতগুণ ধীর হতে পারে। তাই RISC-V-তে aligned ডেটাই নিরাপদ।
• পুরোনো অনেক RISC (যেমন MIPS) misaligned load-এ সরাসরি exception দিত।

Struct layout-এর তিনটি নিয়ম

Compiler তাই struct-এর member-দের মাঝে ফাঁকা byte বসিয়ে দেয় — একে বলে padding. x86-64 Linux-এর ABI (System V) অনুযায়ী নিয়মগুলো এমন:

1. প্রতিটি member বসে এমন offset-এ, যা তার নিজের alignment-এর গুণিতক (char ১, short ২, int ৪, double/long/pointer ৮)।
2. পুরো struct-এর alignment = member-দের মধ্যে সবচেয়ে বড় alignment.
3. sizeof struct-এর alignment-এর গুণিতক পর্যন্ত বাড়ানো হয় (শেষে tail padding).

তৃতীয় নিয়মটি কেন? একটি array struct S a[2] ভাবুন। a[1] শুরু হয় ঠিক sizeof(struct S) byte পরে। a[0] যদি aligned ঠিকানা A-তে থাকে (A হলো alignment k-এর গুণিতক), তবে a[1]-এর ঠিকানা A + sizeof. এটি k-এর গুণিতক হবে কেবল তখনই, যখন sizeof নিজে k-এর গুণিতক। অর্থাৎ array-র প্রতিটি উপাদান aligned রাখতে হলে tail padding অপরিহার্য — এটি একটি ছোট গাণিতিক প্রমাণ।

এবার হিসাব করি। struct {char c; int i;}: c offset ০-তে (১ byte), i-কে ৪-এর গুণিতকে যেতে হবে, তাই ১, ২, ৩ — তিনটি byte padding, i বসে ৪-এ, শেষ হয় ৮-এ। মোট ৮ byte, যদিও ডেটা মাত্র ৫ byte. নিচের প্রোগ্রাম চালিয়ে compiler-এর কাছ থেকেই সত্যিটা জেনে নিন — offsetof বলে দেয় প্রতিটি member কোথায় বসেছে:

#include <stdio.h>
#include <stddef.h>
#include <stdalign.h>

struct A    { char c; int i; };
struct Bad  { char a; double d; char b; };
struct Good { double d; char a; char b; };

int main(void) {
    printf("char %zu, short %zu, int %zu, long %zu, double %zu, pointer %zu\n",
           sizeof(char), sizeof(short), sizeof(int), sizeof(long),
           sizeof(double), sizeof(void *));
    printf("struct A    size %2zu align %zu | c@%zu i@%zu\n",
           sizeof(struct A), alignof(struct A),
           offsetof(struct A, c), offsetof(struct A, i));
    printf("struct Bad  size %2zu align %zu | a@%zu d@%zu b@%zu\n",
           sizeof(struct Bad), alignof(struct Bad), offsetof(struct Bad, a),
           offsetof(struct Bad, d), offsetof(struct Bad, b));
    printf("struct Good size %2zu align %zu | d@%zu a@%zu b@%zu\n",
           sizeof(struct Good), alignof(struct Good), offsetof(struct Good, d),
           offsetof(struct Good, a), offsetof(struct Good, b));
    printf("1000 x Bad = %zu bytes, 1000 x Good = %zu bytes\n",
           1000 * sizeof(struct Bad), 1000 * sizeof(struct Good));
    return 0;
}

char 1, short 2, int 4, long 8, double 8, pointer 8
struct A    size  8 align 4 | c@0 i@4
struct Bad  size 24 align 8 | a@0 d@8 b@16
struct Good size 16 align 8 | d@0 a@8 b@9
1000 x Bad = 24000 bytes, 1000 x Good = 16000 bytes

৪ · অক্ষরের কোড — ASCII, control code আর পুরোনো code page

লেখা রাখার কৌশল একটাই: প্রতিটি অক্ষরকে একটি নম্বর দিন, তারপর নম্বরটি বিটে রাখুন। প্রাথমিক কথাগুলো — ASCII-র টেবিল, BCD, EBCDIC — বিস্তারিত আছে Computer Fundamentals কোর্সের কোড পর্বে। এখানে আমরা দেখব নকশার ভেতরের কৌশল, যেগুলো hardware আর low-level কোডে কাজে লাগে।

ASCII (১৯৬৩ সালে প্রথম প্রকাশিত) ৭ বিটের — ১২৮টি ঘর। প্রথম ৩২টি (০–৩১) আর শেষেরটি (১২৭) control code: এগুলো ছাপার অক্ষর নয়, যন্ত্রকে নির্দেশ। যেমন ৭ = BEL (টেলিপ্রিন্টারে ঘণ্টা বাজানো), ৯ = TAB, ১০ = LF (নতুন লাইন), ১৩ = CR (ছাপার মাথা বাঁ দিকে ফেরানো), ২৭ = ESC. Windows-এর ফাইলে লাইনের শেষে CR LF দুটিই থাকে, Linux-এ শুধু LF — পুরোনো টেলিপ্রিন্টারের সেই দুই আলাদা যান্ত্রিক কাজের উত্তরাধিকার।

টেবিলের ভেতরে লুকানো বিট-কৌশল

'A' আর 'a'-র পার্থক্য ঠিক ৩২ — এটি কাকতালীয় নয়। ৩২ = ২^৫, অর্থাৎ বড় আর ছোট হাতের অক্ষর কেবল বিট ৫-এ আলাদা। তাই একটি XOR (c ^ 0x20) অক্ষরের case উল্টে দেয়, আর c & ~0x20 ছোট হাতের অক্ষরকে বড় করে (শুধু ইংরেজি অক্ষরের ক্ষেত্রে; অন্য চিহ্নে এটি ভুল ফল দেবে)। পুরোনো টেলিপ্রিন্টার আর কীবোর্ডের hardware এভাবে একটি তার চালু-বন্ধ করেই Shift-এর কাজ সারত।

আরেকটি মজার উদাহরণ: টার্মিনালে Ctrl + কোনো অক্ষর চাপলে ঐতিহ্যগতভাবে সেই অক্ষরের নিচের ৫ বিট পাঠানো হয় (c & 0x1F). 'C' = 0x43, তাই Ctrl+C = ৩ (ETX, “লেখা শেষ”) — যা দিয়ে আপনি প্রোগ্রাম থামান। Ctrl+[ দেয় ২৭, অর্থাৎ ESC. আর DEL কেন ১২৭? কাগজের টেপে ভুল অক্ষরের ওপর সাতটি ছিদ্রই করে দিলে সেটি “মুছে” যেত — সব বিট 1.

৮ম বিট আর code page-এর বিশৃঙ্খলা

byte যখন ৮ বিটের হলো, ASCII-র বাইরে আরও ১২৮টি ঘর (১২৮–২৫৫) খালি থাকল। প্রতিটি কোম্পানি আর দেশ সেগুলো নিজের মতো ভরল — একেকটি তালিকার নাম code page. ISO-8859-1 (Latin-1)-এ byte 0xE9 হলো é, আর পুরোনো IBM PC-র CP437-এ একই byte হলো Θ. ফাইলটি কোন code page-এ লেখা, সেটি ফাইলের ভেতরে লেখা থাকত না। ফলে ভুল তালিকা দিয়ে পড়লে আসত আবর্জনা লেখা — জাপানিরা এর নাম দিয়েছিল mojibake.

বাংলার ক্ষেত্রে আরও অদ্ভুত একটি পথ নেওয়া হয়েছিল। Unicode জনপ্রিয় হওয়ার আগে বিজয়ের মতো বহুল প্রচলিত পদ্ধতিতে ফাইলে আসলে ইংরেজি বা ANSI কোডই রাখা হতো, আর একটি বিশেষ font সেই কোডগুলোর জায়গায় বাংলা আকৃতি এঁকে দিত। সেই font না থাকলে লেখাটি দেখায় অর্থহীন ইংরেজি অক্ষরের সারি — আর সার্চ, সাজানো বা অন্য সফটওয়্যারে পাঠানো প্রায় অসম্ভব। পুরোনো সরকারি নথি বা পত্রিকার আর্কাইভ রূপান্তরে আজও এই সমস্যা দেখা যায়। সমাধান এসেছে Unicode দিয়ে।

৫ · Unicode — code point আর encoding

Unicode (সংস্করণ ১.০ প্রকাশিত ১৯৯১ সালে) পৃথিবীর প্রায় সব লিপির প্রতিটি অক্ষরকে একটি স্থায়ী নম্বর দেয় — code point, লেখা হয় U+ আর hex দিয়ে। পরিসর U+0000 থেকে U+10FFFF, অর্থাৎ ২১ বিটে আঁটে। কিন্তু নম্বর পেলেই কাজ শেষ নয়: নম্বরটি byte-এ কীভাবে লিখবেন, সেটি আলাদা প্রশ্ন — তার উত্তর হলো encoding. মূল তিনটি encoding: UTF-8, UTF-16 আর UTF-32.

UTF-8-এর bit layout

UTF-8 একটি code point-কে ১ থেকে ৪ byte-এ লেখে। প্রথম byte-এর শুরুর বিটগুলো বলে দেয় মোট কয়টি byte, আর বাকি প্রতিটি byte শুরু হয় 10 দিয়ে:

বাংলার পুরো ব্লক U+0980–U+09FF তৃতীয় সারিতে পড়ে, তাই প্রতিটি বাংলা code point UTF-8-এ ৩ byte. এবার “ক” (U+0995)-কে হাতে encode করে দেখি — প্রতিটি ধাপে “পরে” চাপুন:

code point = U+0995
0x0800 ≤ 0x0995 ≤ 0xFFFF   -> 3 bytes
template   = 1110xxxx 10xxxxxx 10xxxxxx
             (4 + 6 + 6 = 16 payload bits)

hex      0    9    9    5
bits  0000 1001 1001 0101

0000 1001 1001 0101
->  0000 │ 100110 │ 010101
    4 bits  6 bits   6 bits

1110 xxxx  ->  1110 0000
10 xxxxxx  ->  10 100110
10 xxxxxx  ->  10 010101

1110 0000  =  E0
1010 0110  =  A6
1001 0101  =  95
"ক" in UTF-8 = E0 A6 95

stream:  41 E0 A6 95 E0 A6 BE
reader starts here:  ^ A6 = 10100110 (continuation)
skip 10xxxxxx bytes -> next lead E0 = 1110xxxx
-> back in sync after at most 3 bytes

UTF-8 কেন এত ভালো নকশা

• ASCII-compatible: U+007F পর্যন্ত অক্ষর হুবহু ASCII-র byte. পুরোনো ইংরেজি ফাইল কোনো পরিবর্তন ছাড়াই বৈধ UTF-8.
• Self-synchronizing: প্রথম byte (0xxxxxxx, 11xxxxxx) আর ধারাবাহিক byte (10xxxxxx) কখনো এক রকম দেখায় না — উপরের ধাপ ৬.
• ০ byte নেই: U+0000 ছাড়া কোনো অক্ষরের encoding-এ 0x00 আসে না, তাই C-র '\0'-শেষ string ভাঙে না। আর ASCII-র / বা " কখনো বহু-byte অক্ষরের ভেতরে লুকিয়ে থাকে না।
• Endianness-মুক্ত: একক হলো byte, তাই byte-ক্রমের প্রশ্নই নেই (অংশ ৭)।
• সাজানো: UTF-8 byte-গুলোকে সংখ্যার মতো তুলনা করলে যে ক্রম আসে, code point-এর ক্রমও তাই।

UTF-16 আর surrogate pair, UTF-32

UTF-16-এর একক ১৬ বিট। U+FFFF পর্যন্ত অক্ষর (বাংলা সহ) একটি ১৬-বিটের একক। তার ওপরের অক্ষর, যেমন ইমোজি, লাগে দুটি একক — surrogate pair. নিয়মটি পুরোপুরি বিট-কৌশল:

1. code point থেকে 0x10000 বাদ দিন — ফল ২০ বিটে আঁটে।
2. ওপরের ১০ বিট + 0xD800 = high surrogate; নিচের ১০ বিট + 0xDC00 = low surrogate.

😀 = U+1F600: 0x1F600 − 0x10000 = 0xF600. ওপরের ১০ বিট 0x3D, তাই D800 + 3D = D83D; নিচের ১০ বিট 0x200, তাই DC00 + 200 = DE00. U+D800–U+DFFF পরিসরটি এজন্যই কোনো অক্ষরকে দেওয়া হয়নি। UTF-16-এ একক দুই byte-এর, তাই byte-ক্রমের প্রশ্ন আছে: ফাইলের শুরুতে BOM (U+FEFF) থাকলে FE FF মানে big-endian, FF FE মানে little-endian. Windows-এর API, Java আর JavaScript-এর string ভেতরে UTF-16.

UTF-32 প্রতিটি code point সরাসরি ৪ byte-এ রাখে — সরল, কিন্তু ইংরেজির জন্য চারগুণ জায়গা। Linux-এ C-র wchar_t ৪ byte (UTF-32), Windows-এ ২ byte (UTF-16) — আরেকটি “একই নাম, ভিন্ন মাপ”-এর উদাহরণ।

৬ · বাংলা Unicode-এ — যুক্তাক্ষর, grapheme আর string-এর “দৈর্ঘ্য”

বাংলা লিপি পেয়েছে U+0980 থেকে U+09FF — ১২৮টি ঘরের একটি ব্লক। ক = U+0995, া (আ-কার) = U+09BE, ং = U+0982, ্ (হসন্ত, Unicode-এর নামে virama) = U+09CD. বাংলা অঙ্ক ০–৯ বসে U+09E6–U+09EF-এ, পরপর — ঠিক ASCII-র অঙ্কের মতো, তাই অঙ্কের মান = code point − 0x09E6.

কিন্তু বাংলায় সবচেয়ে গুরুত্বপূর্ণ কথা: যুক্তাক্ষরের জন্য আলাদা code point নেই। “ক্ষ” আসলে তিনটি code point — ক (U+0995) + ্ (U+09CD) + ষ (U+09B7). ফাইলে থাকে এই তিনটি, ৯ byte. পর্দায় একটি যুক্ত আকৃতি আঁকার কাজ করে font আর text shaping engine (যেমন HarfBuzz), যারা font-এর ভেতরের নিয়ম দেখে তিনটিকে একটি glyph-এ বদলায়। হসন্ত দৃশ্যমান রাখতে চাইলে মাঝে ZWNJ (U+200C) বসানো হয় — তখন দেখায় ক্‌ষ।

মানুষ যাকে “একটি অক্ষর” বলে দেখে, Unicode তার নাম দিয়েছে grapheme (আরও নির্দিষ্ট করে “extended grapheme cluster”). তাই একটি string-এর “দৈর্ঘ্য” চারভাবে মাপা যায়, আর বাংলায় চারটি উত্তর প্রায়ই চার রকম:

* যুক্তাক্ষরকে এক grapheme ধরার নিয়ম Unicode যোগ করেছে সংস্করণ ১৫.১-এ (২০২৩); পুরোনো সফটওয়্যার “ক্ষ”-কে ২টি grapheme গুনতে পারে। আর “বাংলা”-য় ং আলাদা grapheme নয়, কারণ Unicode একে আগের অক্ষরের সাথে জুড়ে থাকা চিহ্ন (spacing mark) হিসেবে দেখে।

এর বাস্তব ফল অনেক। মোবাইলের SMS-এ ইংরেজি বার্তা ১৬০ অক্ষর পর্যন্ত এক SMS, কিন্তু বাংলা থাকলে বার্তা যায় ১৬-বিটের UCS-2-এ, তখন এক SMS-এ মাত্র ৭০টি একক — বাংলায় একই কথা লিখতে বেশি SMS লাগে। Database-এ VARCHAR(10) byte গোনে না code point — ডেটাবেস-ভেদে আলাদা; MySQL-এর পুরোনো utf8 আসলে সর্বোচ্চ ৩ byte রাখে, তাই ইমোজি রাখতে লাগে utf8mb4. আর কোনো লেখা byte গুনে মাঝখান থেকে কাটলে একটি বাংলা অক্ষরের ৩ byte-এর মাঝে কাটা পড়তে পারে — পর্দায় আসে � (U+FFFD, “replacement character”).

হাতের হিসাব যন্ত্রে মিলিয়ে নিন। নিচের simulator নিজে UTF-8 encode আর decode করে, প্রতিটি লেখার code point, UTF-8 byte, UTF-16 একক আর grapheme গোনে, আর ব্রাউজারের নিজস্ব TextEncoder-এর সাথে মিলিয়ে দেখে। Run চাপুন:

// Hand-made UTF-8 encoder/decoder, checked against the browser's TextEncoder.
function encode(cp) {                       // one code point -> 1..4 bytes
  if (cp < 0x80) return [cp];                                   // 0xxxxxxx
  if (cp < 0x800) return [0xC0 | (cp >> 6), 0x80 | (cp & 63)];  // 110xxxxx 10xxxxxx
  if (cp < 0x10000)
    return [0xE0 | (cp >> 12), 0x80 | ((cp >> 6) & 63), 0x80 | (cp & 63)];
  return [0xF0 | (cp >> 18), 0x80 | ((cp >> 12) & 63),
          0x80 | ((cp >> 6) & 63), 0x80 | (cp & 63)];
}
function decode(bytes) {                    // bytes -> code points
  const out = [];
  for (let i = 0; i < bytes.length; ) {
    const b = bytes[i], n = b < 0x80 ? 1 : b < 0xE0 ? 2 : b < 0xF0 ? 3 : 4;
    let cp = n === 1 ? b : b & (0xFF >> (n + 1));    // payload of lead byte
    for (let k = 1; k < n; k++) cp = (cp << 6) | (bytes[i + k] & 63);
    out.push(cp); i += n;
  }
  return out;
}
const hex = (a, w) => a.map(v => v.toString(16).toUpperCase().padStart(w, "0")).join(" ");
const seg = typeof Intl.Segmenter === "function"
  ? new Intl.Segmenter("bn", { granularity: "grapheme" }) : null;
const samples = { A: "A", ka: "ক", bangla: "বাংলা",
                  ksha: "ক্ষ", emoji: "\u{1F600}" };
for (const [name, s] of Object.entries(samples)) {
  const cps = [...s].map(c => c.codePointAt(0));
  const mine = cps.flatMap(encode);
  const ref = [...new TextEncoder().encode(s)];
  const units = Array.from({ length: s.length }, (_, i) => s.charCodeAt(i));
  const same = hex(mine, 2) === hex(ref, 2) && hex(decode(mine), 4) === hex(cps, 4);
  console.log(`${name.padEnd(6)} U+${hex(cps, 4).replace(/ /g, " U+")}`);
  console.log(`       UTF-8  ${hex(mine, 2)}  (${mine.length} bytes, TextEncoder ${same ? "agrees" : "DIFFERS"})`);
  console.log(`       UTF-16 ${hex(units, 4)}  (.length = ${s.length})`);
  console.log(`       code points ${cps.length}, graphemes ${seg ? [...seg.segment(s)].length : "n/a"}`);
}

A      U+0041
       UTF-8  41  (1 bytes, TextEncoder agrees)
       UTF-16 0041  (.length = 1)
       code points 1, graphemes 1
ka     U+0995
       UTF-8  E0 A6 95  (3 bytes, TextEncoder agrees)
       UTF-16 0995  (.length = 1)
       code points 1, graphemes 1
bangla U+09AC U+09BE U+0982 U+09B2 U+09BE
       UTF-8  E0 A6 AC E0 A6 BE E0 A6 82 E0 A6 B2 E0 A6 BE  (15 bytes, TextEncoder agrees)
       UTF-16 09AC 09BE 0982 09B2 09BE  (.length = 5)
       code points 5, graphemes 2
ksha   U+0995 U+09CD U+09B7
       UTF-8  E0 A6 95 E0 A7 8D E0 A6 B7  (9 bytes, TextEncoder agrees)
       UTF-16 0995 09CD 09B7  (.length = 3)
       code points 3, graphemes 1
emoji  U+1F600
       UTF-8  F0 9F 98 80  (4 bytes, TextEncoder agrees)
       UTF-16 D83D DE00  (.length = 2)
       code points 1, graphemes 1

টার্মিনালেও একই সত্য দেখা যায়। Linux-এ od একটি ফাইল বা লেখার কাঁচা byte দেখায়:

$ printf 'বাংলা' | od -An -tx1
 e0 a6 ac e0 a6 be e0 a6 82 e0 a6 b2 e0 a6 be
$ printf 'বাংলা' | wc -c
15

৭ · Endianness — byte কোন ক্রমে বসে

একটি ৪-byte মান 0x12345678 ভাবুন। এর সবচেয়ে “ভারী” byte হলো 12 (most significant byte, MSB), আর সবচেয়ে হালকা 78 (least significant byte, LSB). মেমরিতে প্রতিটি byte-এর আলাদা ঠিকানা। প্রশ্ন: ঠিকানা 0x1000 থেকে 0x1003 — এই চারটি ঘরে কোন byte কোথায় বসবে? এর দুটি প্রচলিত উত্তর, আর সেই পছন্দের নামই endianness.

value = 0x12345678
        12   34   56   78
        MSB             LSB
addresses: 0x1000 0x1001 0x1002 0x1003

address : 0x1000 0x1001 0x1002 0x1003
byte    :   12     34     56     78
reads like the number written on paper

address : 0x1000 0x1001 0x1002 0x1003
byte    :   78     56     34     12
x86-64, RISC-V, ARM (in practice)

little-endian : byte at 0x1000 = 0x78
big-endian    : byte at 0x1000 = 0x12
little-endian bonus: 16-bit read at 0x1000 = 0x5678
                     (the low half, same address)

x86 memory      : 78 56 34 12
htonl(x)        : byte swap
memory to send  : 12 34 56 78
on the wire     : 12 34 56 78  (network byte order)
receiver ntohl  : back to its own order

নামটি এসেছে একটি ব্যঙ্গ-উপন্যাস থেকে। Jonathan Swift-এর Gulliver's Travels (১৭২৬)-এ লিলিপুট আর ব্লেফুস্কুর মানুষেরা যুদ্ধ করে — সেদ্ধ ডিম কোন দিক থেকে ভাঙতে হবে, বড় দিক (Big-Endians) না ছোট দিক (Little-Endians), তা নিয়ে। ১৯৮০ সালে Danny Cohen তাঁর বিখ্যাত নোট “On Holy Wars and a Plea for Peace”-এ এই নাম দুটি byte-ক্রমের বিতর্কে ব্যবহার করেন বলে সাধারণভাবে জানা যায়, আর সেখান থেকেই পরিভাষাটি ছড়িয়ে পড়ে। তাঁর মূল কথা ছিল: দুটির কোনোটিই আসলে “ভালো” নয়, দরকার শুধু একটি চুক্তি।

কে কোন দিকে

• Little-endian: Intel 8080 থেকে আজকের x86-64; RISC-V (মূলত); বেশিরভাগ ARM সিস্টেম; ফাইল-ফরম্যাটে BMP আর ZIP.
• Big-endian: Motorola 68000, ঐতিহ্যগত SPARC আর PowerPC, IBM-এর mainframe (z); নেটওয়ার্ক protocol (network byte order); PNG আর JPEG ফাইল।
• Bi-endian: ARM, PowerPC আর MIPS hardware দুই ক্রমেই চালানো যায় — কোনটি চলবে, তা সাধারণত চালু (boot) হওয়ার সময় hardware-এর সেটিং, firmware বা OS ঠিক করে দেয়। যেমন PowerPC-তে আজকের Linux বিতরণ প্রায়ই little-endian “ppc64le”; MIPS-এর দুই রূপের নাম mips আর mipsel.

নিচের প্রোগ্রামটি একটি int, একটি float আর একটি ছোট string-এর byte মেমরির ক্রমে ছাপে, তারপর অংশ ১-এর 0x41424337-কে একই বিট রেখে float আর অক্ষর হিসেবে পড়ে। খেয়াল করুন, type punning (এক type-এর বিট আরেক type হিসেবে পড়া) এখানে memcpy দিয়ে করা হয়েছে — pointer cast করে *(float *)&w লিখলে C-র strict aliasing নিয়ম ভাঙে, যা undefined behavior:

#include <stdio.h>
#include <string.h>
#include <stdint.h>

static void dump(const char *label, const void *p, size_t n) {
    const unsigned char *b = p;            /* any object can be viewed as bytes */
    printf("%-16s", label);
    for (size_t i = 0; i < n; i++) printf(" %02x", b[i]);
    printf("\n");
}

int main(void) {
    uint32_t x = 0x12345678u;
    float f = 1.0f;
    const char s[] = "Hi!";
    dump("int 0x12345678", &x, sizeof x);
    dump("float 1.0f", &f, sizeof f);
    dump("char[] \"Hi!\"", s, sizeof s);

    unsigned char first;
    memcpy(&first, &x, 1);                 /* lowest address first */
    printf("first byte 0x%02x -> %s-endian\n", first,
           first == 0x78 ? "little" : "big");

    uint32_t w = 0x41424337u;              /* one 32-bit pattern ... */
    float wf;
    char wc[5] = {0};
    memcpy(&wf, &w, sizeof wf);            /* ... read as a float */
    memcpy(wc, &w, 4);                     /* ... read as 4 chars */
    printf("0x%08x: unsigned %u, float %.6f, chars \"%s\"\n",
           (unsigned)w, (unsigned)w, (double)wf, wc);
    return 0;
}

int 0x12345678   78 56 34 12
float 1.0f       00 00 80 3f
char[] "Hi!"     48 69 21 00
first byte 0x78 -> little-endian
0x41424337: unsigned 1094861623, float 12.141410, chars "7CBA"

Portable কোড — endianness নিয়ে না ভাবার কৌশল

সবচেয়ে ভালো কৌশল হলো মেমরিকে সরাসরি int হিসেবে না পড়ে, byte ধরে ধরে shift করে মান বানানো। এতে কোডটি যেকোনো মেশিনে একই ফল দেয়, আর আধুনিক compiler এই ধাঁচ চিনে একটি load আর একটি byte-swap instruction-এ নামিয়ে আনে:

#include <stdint.h>

uint32_t read_be32(const unsigned char *p) {
    return ((uint32_t)p[0] << 24) | ((uint32_t)p[1] << 16) |
           ((uint32_t)p[2] << 8)  |  (uint32_t)p[3];
}

; x86-64                         ; AArch64
read_be32:                         read_be32:
    mov     eax, DWORD PTR [rdi]       ldr     w0, [x0]
    bswap   eax                        rev     w0, w0
    ret                                ret

x86-এর bswap (৮০৪৮৬ থেকে), ARM-এর rev আর RISC-V-র Zbb extension-এর rev8 — সবাই এক instruction-এ byte-ক্রম উল্টায়। Compile-এর সময় endianness জানতে gcc আর clang __BYTE_ORDER__ macro দেয়, আর C23 মানে <stdbit.h>-এ __STDC_ENDIAN_NATIVE__ যোগ হয়েছে। Socket প্রোগ্রামে htons-এর ব্যবহার দেখতে Computer Networks কোর্সের TCP socket পর্ব দেখুন।

৮ · Bit manipulation — hardware-এর ভাষায় কথা বলা

একটি বাড়ির মেইন সুইচবোর্ডের কথা ভাবুন: আটটি সুইচ পাশাপাশি — প্রতিটি একটি বাতি বা পাখার জন্য। একটি বাতি জ্বালাতে আপনি পুরো বোর্ড বদলান না, শুধু সেই সুইচটি টেপেন; অন্যগুলো যেমন ছিল তেমন থাকে। Hardware-এর সাথে কথা বলা ঠিক এমন — একটি peripheral-এর control register-এর প্রতিটি বিট বা বিটের গুচ্ছ (field) আলাদা কিছু নিয়ন্ত্রণ করে। C কোর্সের বিটওয়াইজ অপারেশন পর্বে অপারেটরগুলো ভাষার দিক থেকে দেখেছেন; এখানে দেখব hardware-এর দিক থেকে, আর CPU এগুলো কোন instruction-এ করে।

প্রতিটি কাজে একটি mask লাগে — যে সংখ্যার কেবল দরকারি বিটগুলো 1. নিয়মটি মনে রাখুন: OR দিয়ে চালু, AND দিয়ে বন্ধ বা ছাঁকা, XOR দিয়ে উল্টানো। RISC-V-র Zbs extension-এ একক-বিটের জন্য সরাসরি bset, bclr, binv, bext instruction-ও আছে।

Bit field বের করা আর বসানো

ছোট LCD-ওয়ালা যন্ত্রে (যেমন microcontroller-এর ডিসপ্লে) রঙ প্রায়ই রাখা হয় ১৬ বিটের RGB565 ফরম্যাটে: ওপরের ৫ বিট লাল (বিট ১৫–১১), মাঝের ৬ বিট সবুজ (বিট ১০–৫), নিচের ৫ বিট নীল (বিট ৪–০)। সবুজ বেশি বিট পায়, কারণ মানুষের চোখ সবুজের পার্থক্যে বেশি সংবেদনশীল। এই সাইটের সবুজ রঙ (৫৭, ১৮১, ৭৩) RGB565-এ হয় 0x3DA9. এবার একটি register-এর মতো এই মান থেকে বিট ১০..৫ — সবুজ bit field — বের করি:

bit  : 15 .. 11 │ 10 ..... 5 │ 4 ... 0
field:   red    │   green    │  blue
value:  00111   │  101101    │ 01001
all  : 0011 1101 1010 1001  = 0x3DA9

x      : 0011 1101 1010 1001
x >> 5 : 0000 0001 1110 1101  = 0x01ED
                    └ 10 1101 now at bits 5..0
blue (01001) fell off the right edge

x >> 5 : 0000 0001 1110 1101
0x3F   : 0000 0000 0011 1111
AND    : 0000 0000 0010 1101  = 0x2D = 45

field = (x >> s) & ((1u << w) - 1)
s = 5, w = 6 -> mask = (1 << 6) - 1 = 63 = 0x3F
green 6-bit = 45 -> 8-bit = (45 << 2) │ (45 >> 4)
                       = 180 + 2 = 182  (was 181)

clear  : x & ~(0x3F << 5) = 0x3DA9 & 0xF81F = 0x3809
         0011 1000 0000 1001
set    : 0x3809 │ (63 << 5) = 0x3809 │ 0x07E0
result : 0011 1111 1110 1001  = 0x3FE9

Hardware-এ কিন্তু এই কাজের কোনো খরচই নেই। Verilog-এ (পর্ব ১৪) field বের করা মানে কয়েকটি তার আলাদা করে টেনে নেওয়া — কোনো gate লাগে না:

module rgb565_unpack (
    input  wire [15:0] px,
    output wire [4:0]  r,
    output wire [5:0]  g,
    output wire [4:0]  b
);
    assign r = px[15:11];
    assign g = px[10:5];
    assign b = px[4:0];
endmodule

Software-এ একই কাজে লাগে shift আর AND — দুটি instruction. এই পার্থক্যই বোঝায় কেন নেটওয়ার্ক কার্ড বা ভিডিও decoder-এর মতো যন্ত্র bit field ভাঙার কাজ hardware-এ করে। x86-এর BMI2 extension-এর pext instruction যেকোনো ছড়ানো বিট-গুচ্ছ এক instruction-এ বের করতে পারে।

Logical বনাম arithmetic right shift

ডানে shift করলে বাঁ দিকে খালি ঘর তৈরি হয়। Logical shift সেখানে 0 বসায়; arithmetic shift বসায় sign bit-এর কপি, যাতে ঋণাত্মক সংখ্যা ঋণাত্মকই থাকে (পর্ব ০৫-এর two's complement). ধরা যাক ৩২-বিটের −২০ = 0xFFFFFFEC:

• arithmetic: -20 >> 2 = −৫. সাধারণভাবে arithmetic shift k ঘর = ⌊x / ২^k⌋, অর্থাৎ −∞-এর দিকে গোল করা।
• logical: ওপরের দুই ঘরে 0 ঢোকে, ফল 0x3FFFFFFB = ১০৭৩৭৪১৮১৯ — একটি বিশাল ধনাত্মক সংখ্যা।

সূক্ষ্ম একটি ফাঁদ: C-র / শূন্যের দিকে গোল করে, তাই -5 / 2 = −২, কিন্তু -5 >> 1 = −৩. Compiler তাই signed সংখ্যাকে ২-এর ঘাত দিয়ে ভাগ করতে শুধু shift দেয় না, আগে একটি সংশোধন যোগ করে। আর C মানে ঋণাত্মক signed সংখ্যার ডান shift-এর ফল implementation-defined — gcc আর clang arithmetic shift করে, তবে নিশ্চিত logical shift চাইলে unsigned type ব্যবহার করুন। (C++20 থেকে C++-এ এটি arithmetic হিসেবে নির্ধারিত।)

প্রতিদিনের কয়েকটি কৌশল আর তাদের প্রমাণ

• x & (x − 1) সবচেয়ে নিচের 1-বিটটি মুছে দেয়। কারণ: x − 1 করলে সবচেয়ে নিচের 1 হয়ে যায় 0, আর তার নিচের সব 0 হয়ে যায় 1 (ধার নেওয়া); ওপরের বিট বদলায় না। AND করলে ওই অংশ পুরো 0, ওপরের অংশ অক্ষত। যেমন 1011 0100 → 1011 0000.
• ২-এর ঘাত পরীক্ষা: x != 0 && (x & (x − 1)) == 0. ২-এর ঘাতে ঠিক একটি 1 থাকে, সেটি মুছলে শূন্য।
• Popcount (কয়টি বিট 1): x &= x − 1 যতবার করা যায় ততবার গুনুন — লুপ চলে শুধু 1-এর সংখ্যার সমান বার (Brian Kernighan-এর নামে পরিচিত কৌশল)। Hardware-এ সরাসরি instruction আছে: x86-এর popcnt, RISC-V Zbb-এর cpop, ARM64-এ SIMD cnt.
• x & -x সবচেয়ে নিচের 1-বিটটি একা রাখে (two's complement-এ −x = ~x + 1).
• XOR swap (a ^= b; b ^= a; a ^= b;) তৃতীয় ভ্যারিয়েবল ছাড়াই অদলবদল করে — কিন্তু আজ কাজের নয়। a আর b একই জায়গা হলে দুটোই 0 হয়ে যায়; তিনটি instruction একটির ওপর আরেকটি নির্ভর করে, তাই আধুনিক out-of-order CPU (পর্ব ৪০) সমান্তরালে চালাতে পারে না; আর সাধারণ temp-ভিত্তিক swap compiler register-এর নাম বদলেই সেরে ফেলে, প্রায়ই কোনো instruction ছাড়াই।

এবার পুরো toolkit একসাথে চালিয়ে দেখুন — set, clear, toggle, test, x & (x − 1), popcount, ২-এর ঘাত, RGB565 প্যাক-আনপ্যাক আর দুই রকম shift:

#include <stdio.h>
#include <stdint.h>

static void show(const char *label, unsigned v) {     /* print 8 bits */
    printf("%-26s ", label);
    for (int k = 7; k >= 0; k--) putchar(((v >> k) & 1u) ? '1' : '0');
    printf("  0x%02X\n", v & 0xFFu);
}
static unsigned popcount(uint32_t x) { unsigned n = 0; while (x) { x &= x - 1; n++; } return n; }
static int is_pow2(uint32_t x) { return x != 0 && (x & (x - 1)) == 0; }

int main(void) {
    unsigned x = 0xB4;                                 /* 1011 0100 */
    show("x", x);
    show("set bit 0:    x | (1<<0)", x | (1u << 0));
    show("clear bit 2:  x & ~(1<<2)", x & ~(1u << 2));
    show("toggle bit 7: x ^ (1<<7)", x ^ (1u << 7));
    printf("%-26s %u\n", "test bit 4:   (x>>4) & 1", (x >> 4) & 1u);
    show("x & (x-1)", x & (x - 1));
    printf("popcount %u (builtin %d), pow2: 64->%d 96->%d 0->%d\n",
           popcount(x), __builtin_popcount(x), is_pow2(64), is_pow2(96), is_pow2(0));

    unsigned r = 57, g = 181, b = 73;                  /* RGB565: rrrrr gggggg bbbbb */
    uint16_t px = (uint16_t)(((r >> 3) << 11) | ((g >> 2) << 5) | (b >> 3));
    unsigned g6 = (px >> 5) & 0x3Fu;                   /* extract bits 10..5 */
    printf("RGB565(57,181,73) = 0x%04X, green field %u -> 8-bit %u\n",
           (unsigned)px, g6, (g6 << 2) | (g6 >> 4));
    px = (uint16_t)((px & ~(0x3Fu << 5)) | (63u << 5)); /* insert green = 63 */
    printf("after inserting green=63: 0x%04X\n", (unsigned)px);

    int32_t neg = -20;                                 /* 0xFFFFFFEC */
    printf("-20 >> 2 as int32_t  = %d (gcc: arithmetic)\n", (int)(neg >> 2));
    printf("-20 >> 2 as uint32_t = %u (logical)\n", (unsigned)((uint32_t)neg >> 2));
    return 0;
}

x                          10110100  0xB4
set bit 0:    x | (1<<0)   10110101  0xB5
clear bit 2:  x & ~(1<<2)  10110000  0xB0
toggle bit 7: x ^ (1<<7)   00110100  0x34
test bit 4:   (x>>4) & 1   1
x & (x-1)                  10110000  0xB0
popcount 4 (builtin 4), pow2: 64->1 96->0 0->0
RGB565(57,181,73) = 0x3DA9, green field 45 -> 8-bit 182
after inserting green=63: 0x3FE9
-20 >> 2 as int32_t  = -5 (gcc: arithmetic)
-20 >> 2 as uint32_t = 1073741819 (logical)

Register-এ বিট — embedded জগতের রোজকার কাজ

একটি microcontroller-এর GPIO বা UART-এর control register ঠিক এমন field-এ ভাগ করা: কোনো বিট “চালু/বন্ধ”, কোনো ২–৩ বিট “mode”, কোনো ৮ বিট “baud rate-এর ভাজক”। এই register-গুলো মেমরির নির্দিষ্ট ঠিকানায় বসানো থাকে (memory-mapped I/O, পর্ব ৫১), তাই C কোডে সেগুলো একটি pointer দিয়ে পড়া-লেখা হয় — compiler যেন পড়া-লেখা বাদ না দেয়, তার জন্য volatile. datasheet-এ লেখা থাকে কোন বিটের কী কাজ, আর একটি ভুল mask মানে হয়তো ভুল pin-এ ভোল্টেজ। এই বিষয়টি পর্ব ৫৬-এ (embedded সিস্টেম) আবার আসবে। বিট উল্টে যাওয়া ধরার জন্য একটি বাড়তি parity bit বা ECC কীভাবে কাজ করে, তা আছে Computer Networks কোর্সের error detection পর্বে।

৯ · AI-এর যুগে — বিট-স্তরের দাবি যাচাই

বিট-স্তরের প্রশ্নে AI-এর উত্তর শুনতে খুব আত্মবিশ্বাসী লাগে, কিন্তু ভুলের হার বেশি — কারণ সঠিক উত্তরের জন্য গুনে গুনে বিট মেলাতে হয়, আর ভাষা-মডেল সেখানে প্রায়ই “দেখতে ঠিক” উত্তর বানায়। সুখবর হলো, এই বিষয়ের প্রায় সব দাবি কয়েক লাইনের কোডে যাচাই করা যায়।

AI-এর উত্তর হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি byte বা bit pattern নিজে হাতে (বা Python/JS-এ) হিসাব করে মিলিয়েছি
• struct-এর মাপ নিজের compiler-এ sizeof/offsetof চালিয়ে দেখেছি — এবং কোন ABI-তে, সেটি লিখে রেখেছি
• encoding-এর দাবি TextEncoder বা od/xxd দিয়ে আসল byte দেখে যাচাই করেছি
• endianness-নির্ভর কোডে byte-ধরে shift করার portable রূপ ব্যবহার করেছি, pointer cast নয়
• কোনো ISA instruction-এর নাম বা আচরণ (যেমন RISC-V-র sra, x86-এর bswap) ISA manual-এ মিলিয়েছি, আর ঐচ্ছিক extension (Zbb, BMI2) আমার CPU-তে আছে কি না দেখেছি