Base64 এনকোডার / ডিকোডার

Base64 এনকোডিং কী?

Base64 হলো একটি বাইনারি-থেকে-টেক্সট এনকোডিং যা যেকোনো ডেটাকে ৬৪-অক্ষরের একটি বর্ণমালা (A–Z, a–z, 0–9, + ও /) দিয়ে উপস্থাপন করে। এটি বাইনারি সামগ্রীকে টেক্সটের জন্য তৈরি চ্যানেলগুলির — যেমন ইমেল, JSON, XML ও data: URI — মধ্য দিয়ে নিরাপদে যেতে দেয়।

এই টুল কীভাবে ব্যবহার করবেন

1. আপনার টেক্সট ইনপুট বক্সে পেস্ট করুন।
2. এটি রূপান্তর করতে Base64-এ এনকোড করুন-এ ক্লিক করুন, বা উল্টাতে Base64 থেকে ডিকোড করুন-এ।
3. ফলাফল নিতে আউটপুট কপি করুন ব্যবহার করুন।

এই টুল UTF-8-এর মাধ্যমে এনকোড করে, তাই Unicode টেক্সট ও ইমোজি সঠিকভাবে রাউন্ড-ট্রিপ হয়।

Base64 কোথা থেকে এলো

Base64-এর জন্ম একটি খুব নির্দিষ্ট সমস্যা থেকে: প্রাথমিক ইন্টারনেট মেইলকে সাধারণ 7-বিট ASCII টেক্সট হিসেবে পাঠাত। মূল Simple Mail Transfer Protocol (SMTP) ধরে নিত যে প্রতিটি বাইট সাত বিটে আঁটে, এবং অনেক মেইল রিলে অষ্টম বিটটি সরিয়ে দিত, কন্ট্রোল অক্ষর বিকৃত করত, বা লাইন-এন্ডিং পাল্টে দিত। কাঁচা বাইনারি — একটি ছবি, একটি প্রোগ্রাম, একটি সংকুচিত আর্কাইভ — সেই যাত্রায় অক্ষত থাকতে পারত না। প্রয়োজন ছিল যেকোনো বাইটকে সাধারণ অক্ষর ও অঙ্ক হিসেবে ছদ্মবেশ দেওয়ার একটি প্রতিবর্তনীয় (reversible) উপায়ের।

এই এনকোডিং প্রথমে Privacy-Enhanced Mail (PEM)-এ দেখা যায়, যা ফেব্রুয়ারি ১৯৯৩-এ RFC 1421 হিসেবে প্রকাশিত হয়, যেখানে এটি এনক্রিপ্টেড বার্তা-বডিকে ছাপার-উপযোগী টেক্সটে মুড়ে দিত। এটি অনেক বৃহত্তর দর্শকের কাছে পৌঁছায় MIME (Multipurpose Internet Mail Extensions)-এর মাধ্যমে, যার প্রথম অংশ RFC 2045 নভেম্বর ১৯৯৬-এ প্রকাশিত হয় এবং যা Base64-কে ইমেল অ্যাটাচমেন্টের জন্য একটি মানক Content-Transfer-Encoding হিসেবে সংজ্ঞায়িত করে। আধুনিক, সমন্বিত স্পেসিফিকেশন হলো RFC 4648, "The Base16, Base32, and Base64 Data Encodings" (অক্টোবর ২০০৬), যা পুরনো RFC 3548-কে অপ্রচলিত করে এবং এটিই সেই দলিল যা আজ বেশিরভাগ সফটওয়্যার অনুসরণ করে।

Base64 এনকোডিং আসলে কীভাবে কাজ করে

Base64 ইনপুটকে একবারে তিন বাইট হিসেবে প্রক্রিয়া করে। তিন বাইট মানে ২৪ বিট, আর ২৪, ছয়-বিটের চারটি সমান দলে ভাগ হয়ে যায়। প্রতিটি 6-বিট দল — একটি sextet — 0 থেকে 63 পর্যন্ত একটি মান ধরে, যা একটি ৬৪-অক্ষরের বর্ণমালাকে ইনডেক্স করার জন্য ঠিক যথেষ্ট। তাই প্রতি 3 ইনপুট বাইট 4 আউটপুট অক্ষরে পরিণত হয়, এবং আউটপুট কেবল নিরাপদ, ছাপার-উপযোগী প্রতীক ব্যবহার করে।

৬৪-অক্ষরের বর্ণমালা, ক্রমানুসারে, এটি:

• A–Z — মান 0–25-এর জন্য
• a–z — মান 26–51-এর জন্য
• 0–9 — মান 52–61-এর জন্য
• + — 62-এর জন্য এবং / — 63-এর জন্য

একটি সমাধান-করা উদাহরণ এটিকে বাস্তব করে তোলে। তিনটি অক্ষর Man হলো বাইট 77 97 110, বা বাইনারিতে 01001101 01100001 01101110। sextet-এ পুনরায় দল করলে এটি হয় 010011 010110 000101 101110 — মান 19 22 5 46 — যা T W F u-তে ম্যাপ করে। তাই Man, TWFu-তে এনকোড হয়। ডিকোডিং কেবল ধাপগুলিকে উল্টে দেয়: চারটি অক্ষর আবার চারটি sextet-এ, ২৪ বিটে যুক্ত হয়ে, তারপর আবার মূল তিন বাইটে কেটে নেওয়া হয়।

ইনপুট খুব কমই ঠিক তিন বাইটের গুণিতক হয়, তাই Base64 = অক্ষরটিকে প্যাডিং হিসেবে ব্যবহার করে যাতে নথিভুক্ত হয় যে শেষ দলে কতগুলি আসল বাইট ছিল:

• 3 বাইটের পূর্ণ দল → 4 অক্ষর, কোনো প্যাডিং নেই।
• 2 অবশিষ্ট বাইট (16 বিট) → 3 অক্ষর এবং একটি =।
• 1 অবশিষ্ট বাইট (8 বিট) → 2 অক্ষর এবং দুটি ==।

প্যাডিং সাজসজ্জা নয়: এটি ডিকোডারকে বলে দেয় যে শেষ sextet পূর্ণ করতে যোগ করা অতিরিক্ত শূন্য বিটগুলি বাদ দিতে, যাতে মূল বাইট-সংখ্যা ঠিক ঠিক পুনরুদ্ধার হয়।

33% আকার-অতিরিক্ততা, ব্যাখ্যা

যেহেতু প্রতি 3 বাইট 4 অক্ষরে পরিণত হয়, Base64 আউটপুট সর্বদা প্রায় ইনপুটের আকারের চার-তৃতীয়াংশ (4/3) হয় — মোটামুটি একটি 33% বৃদ্ধি। সঠিক সংখ্যাটি ইনপুটের দৈর্ঘ্যের উপর, তিন দিয়ে ভাগ করলে তার ভাগশেষের উপর (প্যাডিং শেষ দলটিকে চারটি অক্ষর পর্যন্ত ওপরে তোলে), এবং লাইন-ব্রেক ঢোকানো হয়েছে কিনা তার উপর নির্ভর করে। একটি 9 KB ফাইল প্রায় 12 KB টেক্সটে পরিণত হয়; একটি 3 MB ছবি প্রায় 4 MB-তে পরিণত হয়।

যদি এনকোডেড টেক্সটকে লাইনে মোড়া হয় — ইমেলে সাধারণ — তবে প্রতিটি লাইন-ব্রেক একটি বা দুটি করে বাড়তি অক্ষর যোগ করে, যা সাধারণ MIME আউটপুটে অতিরিক্ততাকে আরও প্রায় 4% বাড়িয়ে দেয়। এটি কেবল 64টি ছাপার-উপযোগী মান ব্যবহার করে 256টি সম্ভাব্য বাইট-মান উপস্থাপনের অনিবার্য মূল্য: একই কথা বলতে আপনার কেবল আরও প্রতীক দরকার হয়। এই কারণেই যখন ব্যান্ডউইথ বা স্টোরেজ সীমিত এবং চ্যানেল আগে থেকেই বাইনারি সরাসরি বহন করতে পারে, তখন Base64 একটি খারাপ পছন্দ।

Base64 বনাম Base64URL বনাম Base32 বনাম hex

মানক Base64 + ও / ব্যবহার করে, কিন্তু উভয় অক্ষরই কিছু প্রসঙ্গে অসুবিধাজনক: / একটি পাথ-বিভাজক এবং + প্রায়ই URL ও ফর্ম-ডেটায় স্পেসের অর্থ বহন করে। RFC 4648 §5 একটি "URL and filename safe" ভ্যারিয়েন্ট সংজ্ঞায়িত করে, যাকে সাধারণত Base64URL বলা হয়, যা ওই দুটি অক্ষর বদলে দেয় — - (মাইনাস) অবস্থান 62-তে +-এর জায়গা নেয়, এবং _ (আন্ডারস্কোর) অবস্থান 63-তে /-এর জায়গা। প্যাডিং =-কেও প্রায়ই বাদ দেওয়া হয়, কারণ সেটিকেও এস্কেপ করার প্রয়োজন হতে পারে। Base64URL সেটাই যা আপনি JSON Web Tokens (JWT)-এর ভিতরে, URL কোয়েরি প্যারামিটারে, এবং ফাইলনামে দেখেন।

একই RFC দুটি সহোদরও সংজ্ঞায়িত করে যারা একটি ছোট, কখনও কখনও নিরাপদ বর্ণমালার বিনিময়ে ঘনত্ব ত্যাগ করে:

hex ব্যবহার করুন যখন আপনি এমন কিছু চান যা মানব-পাঠযোগ্য এবং বাইটের সঙ্গে সহজে সারিবদ্ধ (প্রতিটি বাইট ঠিক দুটি hex অঙ্ক)। Base32 ব্যবহার করুন যখন টেক্সটকে কেস-অসংবেদনশীল সিস্টেমে টিকে থাকতে হয় বা উচ্চস্বরে পড়া বা হাতে টাইপ করা হবে। Base64 বা Base64URL ব্যবহার করুন যখন ঘনত্বই সবচেয়ে গুরুত্বপূর্ণ — ওয়েবে সাধারণ পরিস্থিতি।

লাইন-দৈর্ঘ্যের প্রথা: 76 ও 64

পুরনো টেক্সট চ্যানেল খুব দীর্ঘ লাইন পছন্দ করত না, তাই দুটি লাইন-দৈর্ঘ্যের প্রথা মানক হয়ে ওঠে। MIME (RFC 2045) Base64-কে প্রতি লাইনে 76 অক্ষর পর্যন্ত সীমিত করে, আর PEM (RFC 1421) ঠিক প্রতি লাইনে 64 অক্ষর ব্যবহার করে — সেই মোড়ানোই যা আপনি TLS সার্টিফিকেট ও SSH কী-তে -----BEGIN----- ও -----END----- চিহ্নের মাঝে ছাপা দেখেন। ছোট লাইন বার্তাগুলিকে প্রাথমিক মেইল সফটওয়্যার ও টার্মিনালের সীমার মধ্যে রাখত।

গুরুত্বপূর্ণ বিষয় হলো, লাইন-মোড়ানো হলো চারপাশের ফরম্যাটের বৈশিষ্ট্য, Base64-এর নিজের নয়। RFC 4648 স্পষ্ট যে বাস্তবায়নগুলি "MUST NOT add line feeds to base-encoded data unless the specification referring to this document explicitly directs" তাদের তা করতে। একটি সাধারণ Base64 স্ট্রিং — যেমন এই টুল তৈরি করে — তাই একটি একক অবিচ্ছিন্ন লাইন। আপনি যখন কোনো ইমেল বা সার্টিফিকেট থেকে কপি করা টেক্সট ডিকোড করেন, তখন যেকোনো অন্তর্নিহিত নিউলাইন ও স্পেস প্রথমে সরানো জরুরি; এই টুল তা স্বয়ংক্রিয়ভাবে করে।

Base64 কীসের জন্য ব্যবহৃত হয়

একবার আপনি যেকোনো বাইটকে নিরাপদ টেক্সটে বদলাতে পারলে, ব্যবহার বেড়ে যায়। সবচেয়ে সাধারণগুলি হলো:

• ইমেল অ্যাটাচমেন্ট (MIME)। কোনো ইমেলে সংযুক্ত প্রতিটি ছবি, PDF বা নথি পথে Base64-এনকোডেড হয় — সেই মূল উদ্দেশ্য যা এই ফরম্যাটকে সর্বব্যাপী করে তুলেছিল।
• data: URI। একটি সম্পূর্ণ ফাইল ইনলাইনে data:[mediatype];base64,<data> হিসেবে এম্বেড করা যায়, যা একটি পেজকে কোনো অতিরিক্ত HTTP অনুরোধ ছাড়াই একটি ছোট আইকন, ফন্ট বা ছবি বহন করতে দেয়। সমঝোতাগুলি হলো 33% আকার-জরিমানা এবং পৃথক ক্যাশিং হারানো: একটি এম্বেডেড অ্যাসেটকে সেই নথি থেকে স্বাধীনভাবে ক্যাশ বা পুনঃব্যবহার করা যায় না যেটিতে এটি রয়েছে, তাই এটি ছোট, কদাচিৎ-পরিবর্তনশীল ফাইলের জন্য সবচেয়ে ভালো রাখা হয়।
• CSS ও HTML-এ অ্যাসেট এম্বেড করা। সেই একই data: কৌশল ব্যাকগ্রাউন্ড ছবি, SVG ও ওয়েব ফন্টকে সরাসরি স্টাইলশিটের ভিতরে ইনলাইন করে দেয়।
• JSON ও XML-এর ভিতরে বাইনারি। কোনো ফরম্যাটই কাঁচা বাইট ধরতে পারে না, তাই বাইনারি ফিল্ড — ফাইল আপলোড, থাম্বনেইল, ক্রিপ্টোগ্রাফিক কী — Base64 স্ট্রিং হিসেবে বহন করা হয়।
• HTTP Basic প্রমাণীকরণ। Authorization: Basic হেডার username:password-এর Base64 বহন করে। উদাহরণস্বরূপ Aladdin:open sesame হয়ে যায় QWxhZGRpbjpvcGVuIHNlc2FtZQ== (RFC 7617-এ সংজ্ঞায়িত)।
• JSON Web Tokens। কোনো JWT-এর হেডার, পেলোড ও সিগনেচার প্রত্যেকটি Base64URL-এনকোডেড হয় এবং ডট দিয়ে যুক্ত হয়, যা একটি সংক্ষিপ্ত, URL-নিরাপদ টোকেন তৈরি করে।

Base64 এনক্রিপশন নয় — একটি সাধারণ ভুল ধারণা

বোঝার সবচেয়ে গুরুত্বপূর্ণ বিষয়টি এটাই। Base64 কোনো নিরাপত্তা দেয় না। এটি কী ছাড়া একটি প্রকাশ্য, প্রতিবর্তনীয় ম্যাপিং — যে কেউ যেকোনো Base64 স্ট্রিং তাৎক্ষণিকভাবে ডিকোড করতে পারে, ঠিক যেমন এই পেজ করে। এটি ডেটা লুকায় না, এলোমেলো করে না বা সুরক্ষিত করে না; এটি কেবল আগে থেকেই জানা বাইটের উপস্থাপন বদলায়।

দুটি প্রতিদিনের উদাহরণ এটি প্রমাণ করে। HTTP Basic প্রমাণীকরণ আপনার পাসওয়ার্ড Base64 হিসেবে পাঠায়, এই কারণেই RFC 7617 জোর দেয় যে এটি "does not provide confidentiality" এবং সর্বদা HTTPS/TLS-এর উপর চলা উচিত — Base64 সংযোগ দেখছে এমন যেকোনো ব্যক্তি দ্বারা সহজেই ডিকোড করা যায়। একইভাবে, কোনো স্বাক্ষরিত JWT-এর ক্লেইমগুলি Base64URL-এনকোডেড হয়, এনক্রিপ্টেড নয়: মাঝের খণ্ডটি যেকোনো ডিকোডারে পেস্ট করুন এবং আপনি প্রতিটি ফিল্ড পড়তে পারবেন। একটি JWT সিগনেচার প্রমাণ করে যে টোকেনটি বিকৃত হয়নি, কিন্তু এটি সামগ্রীকে গোপন রাখতে কিছুই করে না।

আর সংকোচনের বিপরীতে, Base64 ডেটাকে বড় করে, ছোট নয়। যদি আপনার গোপনীয়তা দরকার হয়, তবে ডেটা এনক্রিপ্ট করুন (তারপর আপনি পরিবহনের জন্য সাইফারটেক্সটকে Base64 করতে পারেন)। যদি আপনার ছোট পেলোড দরকার হয়, তবে এটি সংকুচিত করুন। Base64 কেবল টেক্সট-মাত্র চ্যানেলের মধ্য দিয়ে নিরাপদ পরিবহন নিয়ে — এর বেশি কিছু নয়।

এনকোড ও ডিকোড করার সময় সাধারণ ভুল

• অ-ASCII টেক্সটের জন্য UTF-8 ভুলে যাওয়া। ব্রাউজারে, পরিচিত btoa() ফাংশন বাইট-বাই-বাইট কাজ করে এবং এমন যেকোনো অক্ষরে এরর দেয় যার কোড-পয়েন্ট 0xFF-এর বেশি — তাই একটি ইমোজি বা উচ্চারণ-চিহ্নযুক্ত অক্ষর সরল কোড ভেঙে দেয়। সমাধান হলো স্ট্রিংটিকে প্রথমে তার UTF-8 বাইটে রূপান্তর করা, তারপর সেই বাইটগুলিকে Base64 করা। এই টুল ঠিক তাই করে, তাই উচ্চারণ-চিহ্ন, অ-ল্যাটিন লিপি ও ইমোজি সঠিকভাবে রাউন্ড-ট্রিপ হয়।
• ডিকোড করার সময় ফাঁকা জায়গা ও নিউলাইন। ইমেল, সার্টিফিকেট বা কনফিগ ফাইল থেকে কপি করা Base64-এ প্রায়ই লাইন-ব্রেক ও স্পেস থাকে, এবং অনেক ডিকোডার সেগুলি প্রত্যাখ্যান করে। ডিকোড করার আগে সমস্ত ফাঁকা জায়গা সরিয়ে ফেলুন (এই টুল তা স্বয়ংক্রিয়ভাবে সরিয়ে দেয়)।
• প্যাডিং বাদ পড়া বা ভুল হওয়া। কিছু উৎস, বিশেষত Base64URL, শেষের = অক্ষরগুলি ফেলে দেয়। তখন কঠোর ডিকোডার ব্যর্থ হতে পারে, যেখানে উদার ডিকোডার স্ট্রিংয়ের দৈর্ঘ্য থেকে নিহিত প্যাডিং আবার যোগ করে দেয়। যদি কোনো ডিকোড ব্যর্থ হয়, তবে দেখুন অক্ষর-সংখ্যা চারের গুণিতক কিনা।
• দুটি বর্ণমালা মিশিয়ে ফেলা। Base64URL (- ও _)-কে মানক Base64 ডিকোডারে দেওয়া — বা উল্টো — ফলাফল বিকৃত করে। ডিকোড করার আগে --কে +-এ এবং _-কে /-এ বদলান (বা এর বিপরীত)।
• এটিকে নিরাপত্তা মনে করা। উপরে যেমন বলা হয়েছে, কোনো গোপন তথ্য "লুকাতে" কখনও Base64 ব্যবহার করবেন না। এটি এনকোডিং, এনক্রিপশন নয়।

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

আমার ডেটা কি কোথাও আপলোড হয়?

না। এনকোডিং ও ডিকোডিং সম্পূর্ণভাবে আপনার ব্রাউজারে JavaScript দিয়ে হয়। আপনার টেক্সট কখনও আপনার ডিভাইস থেকে বাইরে যায় না।

এটি কি Unicode ও ইমোজি সমর্থন করে?

হ্যাঁ। এই টুল টেক্সটকে প্রথমে UTF-8 হিসেবে এনকোড করে, তাই উচ্চারণ-চিহ্নযুক্ত অক্ষর, অ-ল্যাটিন লিপি ও ইমোজি সবই সঠিকভাবে এনকোড ও ডিকোড হয়।

Base64 কীসের জন্য ব্যবহৃত হয়?

Base64 বাইনারি ডেটাকে ASCII টেক্সট হিসেবে উপস্থাপন করে যাতে তা টেক্সটের জন্য তৈরি সিস্টেমগুলির — ইমেল (MIME), JSON, XML, data URI ও HTTP হেডার — মধ্য দিয়ে নিরাপদে যেতে পারে।