Base64 URL ডিকোডার পার্সার

হ্যাঁ। data URL বা raw Base64 ছবির স্ট্রিং পেস্ট করলে টুলটি শনাক্ত করা MIME টাইপ ও সাইজসহ ছবির প্রিভিউ দেখায়।

হ্যাঁ। ডিকোড মোডে plus চিহ্নগুলোকে URI ডিকোডিংয়ের আগে স্পেস হিসেবে ব্যাখ্যা করা হয়, যা সাধারণ ফর্ম এনকোডিং আচরণের সাথে মেলে।

হ্যাঁ। JWT মোডে আপনি হেডার, পেলোড বা সিগনেচার-সংক্রান্ত সেগমেন্ট আলাদাভাবে বেছে ডিকোড করতে পারেন।

স্ট্যান্ডার্ড Base64 (RFC 4648 সেকশন 4) + এবং / ব্যবহার করে, যেগুলো URL-এর রিজার্ভড ক্যারেক্টারের সাথে সংঘর্ষ করে। URL-সেফ অ্যালফাবেট (সেকশন 5) সেগুলোকে - এবং _ দিয়ে বদলে দেয়। JWT সবসময় URL-সেফ অ্যালফাবেট ব্যবহার করে - এ কারণেই টোকেন সিগনেচারে কখনো + বা / থাকে না। এই টুল দুটো অ্যালফাবেটই অটো-ডিটেক্ট করে।

Base64 ৩ বাইটকে ৪ ক্যারেক্টারে এনকোড করে, তাই ৩-এর গুণিতক না হলে দৈর্ঘ্য ৪-এর গুণিতক রাখতে = দিয়ে প্যাডিং হয়। একটি = মানে ২টি বাকি বাইট, দুটি = মানে ১টি। দৈর্ঘ্য অন্য উপায়ে জানা থাকলে প্যাডিং নিরাপদে বাদ দেওয়া যায় - JWT সেগমেন্ট ঠিক এটাই করে - এবং ডিকোডার সেটি অটোমেটিক পুনরুদ্ধার করে।

Base64 নিজে লসলেস, কিন্তু সাধারণ JavaScript btoa() ফাংশন শুধু Latin-1 ক্যারেক্টার নেয় এবং বাকি সবকিছুতে এরর ছুড়ে দেয়। সঠিক পদ্ধতি হলো আগে UTF-8-এ এনকোড করা (TextEncoder), তারপর বাইটগুলো Base64 করা। এই টুল সেই পাইপলাইন অটোমেটিক সামলায়, তাই চীনা, আরবি বা ইমোজি টেক্সট নষ্ট না হয়ে ঠিকঠাক ফিরে আসে।

তিনটি সিগন্যাল দেখুন: ক্যারেক্টার সেট শুধু A-Z, a-z, 0-9, +, / (অথবা URL-সেফ - এবং _); প্যাডিং পুনরুদ্ধার করলে দৈর্ঘ্য ৪-এর গুণিতক; এবং ডিকোড করলে অর্থবহ বাইট পাওয়া যায়। কোনো পদ্ধতিই ১০০% নিশ্চিত নয়, কারণ অনেক সাধারণ স্ট্রিং (যেমন abcd)ও বৈধ Base64 হতে পারে - প্রসঙ্গ গুরুত্বপূর্ণ।

না। Base64 একটি রিভার্সিবল এনকোডিং, যেকোনো মানুষ কোনো সিক্রেট ছাড়াই ডিকোড করতে পারে - এটি শূন্য গোপনীয়তা দেয়। পাসওয়ার্ড বা API কী রক্ষায় এটি কখনো ব্যবহার করবেন না। সুরক্ষার জন্য ট্রানজিটে TLS এবং AES-256-GCM-এর মতো আসল সাইফার ব্যবহার করুন; Base64-এর একমাত্র কাজ বাইনারি ডেটাকে টেক্সট চ্যানেলের জন্য নিরাপদ করা।