URL এনকোড করুন
টেক্সট পার্সেন্ট-এনকোড করুন, যাতে তা URL-এ টিকে থাকে। তিনটি আলাদা কাজের জন্য তিনটি আলাদা এনকোডিং আছে, আর ভুলটি বেছে নিলেই মান নিঃশব্দে ভেঙে যায় — তাই কোনটি আপনার দরকার, পেজ তা বলে দেয়।
- কখনো সংরক্ষণ করা হয় না
- কোনো লাইন নেই, অপেক্ষা নেই
- সাইনআপ নেই, ওয়াটারমার্ক নেই
এনকোড করা এখানে দেখা যাবে।
যেভাবে কাজ করে
আপনার টেক্সট পেস্ট করুন
যেকোনো টেক্সট, যেকোনো ভাষায়। এটি UTF-8 হিসেবে এনকোড হয়, যা প্রতিটি আধুনিক সার্ভার আশা করে।
কাজটি বেছে নিন
কোয়েরি স্ট্রিংয়ে যাওয়া একটি মান, জোড়া লাগানো একটি পুরো URL, অথবা একটি ফর্ম সাবমিশন। পার্থক্যটা গুরুত্বপূর্ণ, আর প্রতিটির ব্যাখ্যা দেওয়া আছে।
ফলাফল কপি করুন
একসাথে একটি তালিকা এনকোড করতে হলে লাইন ধরে ধরে এনকোড করুন।
তিনটি সঠিক উত্তর, আর কেন একটি বোতাম ভুল
পার্সেন্ট-এনকোডিং একটি অক্ষরকে একটি % আর হেক্সে তার বাইট মান দিয়ে বদলে দেয়। স্পেসিফিকেশন অক্ষরগুলোকে তিন ভাগে ভাগ করে, আর এ নিয়ে সব বিভ্রান্তি সেখান থেকেই আসে। Unreserved অক্ষর — বর্ণ, অঙ্ক, হাইফেন, ফুল স্টপ, আন্ডারস্কোর আর টিল্ড — কখনো এনকোড করতে হয় না। Reserved অক্ষর — যে স্ল্যাশ, প্রশ্নবোধক চিহ্ন, অ্যাম্পারস্যান্ড, সমান চিহ্ন আর কোলন একটি URL-এর কাঠামো তৈরি করে — *যখন সেগুলো ডেটা* তখন এনকোড করতেই হয়, আর *যখন সেগুলো কাঠামো* তখন করা চলবে না। বাকি সবকিছু সবসময় এনকোড হয়।
এ কারণেই একটিমাত্র সঠিক উত্তর নেই। পুরো URL এনকোড করতে গেলে স্ল্যাশ আর প্রশ্নবোধক চিহ্ন ছুঁতে নেই, নইলে ঠিকানাটি আর ঠিকানা থাকে না। কোয়েরি প্যারামিটারে বসানোর মান এনকোড করতে গেলে অ্যাম্পারস্যান্ড ও সমান চিহ্ন এস্কেপ করতেই হয়, নইলে এর একটি থাকা মান ভেঙে দুটি প্যারামিটার হয়ে যায়। পাথ সেগমেন্ট এনকোড করতে গেলে স্ল্যাশ এস্কেপ করতে হয়, নইলে নামে স্ল্যাশ থাকা একটি ফাইল দুটি ডিরেক্টরি হয়ে যায়। একটিমাত্র Encode বোতাম এর একটি বেছে নেয় আর বাকি দুই-তৃতীয়াংশ ক্ষেত্রে ভুল হয় — সাধারণত নিঃশব্দে, আর সাধারণত এমনভাবে যা শুধু অস্বাভাবিক ইনপুটে ধরা পড়ে।
সবচেয়ে বেশি ইতিহাস জড়িয়ে আছে স্পেসের সঙ্গে। URL-এ এটি %20। জমা দেওয়া HTML ফর্মে এটি +, যা আলাদা, পুরোনো একটি এনকোডিং, আর টিকে আছে কারণ ১৯৯৪ সাল থেকে ফর্ম এভাবেই কাজ করে। দুটিই নিজ নিজ প্রসঙ্গে সঠিক, আর অন্যটির প্রসঙ্গে কোনোটিই সঠিক নয়, এ কারণেই কোয়েরি স্ট্রিংয়ে প্লাস চিহ্ন এমনভাবে দ্ব্যর্থক, যা এনকোড করার দিকে যত সাবধানতাই নেওয়া হোক, ঠিক করা যায় না।
ASCII নয় এমন টেক্সট আগে UTF-8-এ, তারপর বাইট ধরে ধরে এনকোড হয়, তাই অ্যাকসেন্টযুক্ত একটি অক্ষর দুটি পার্সেন্ট সিকোয়েন্স হয়ে যায়, আর একটি ইমোজি চারটি। Double encoding হলো ক্লাসিক বাগ: আগেই এনকোড করা কিছু আবার এনকোড করলে প্রতিটি % হয়ে যায় %25, ফলে %20 হয় %2520 আর অন্য প্রান্ত পায় একটি আক্ষরিক পার্সেন্ট চিহ্ন। কোনো URL %25-এ ভরা থাকলে বুঝবেন সেটি একটি এনকোডার বেশি পার হয়েছে।
অন্য কিছু দরকার হলে
কোডে ভাষার নিজস্ব ফাংশন ব্যবহার করুন, আর এই পেজ যতটা ভেবেচিন্তে বাছাই করায়, ততটাই ভেবে বেছে নিন। JavaScript-এ পুরো ঠিকানার জন্য encodeURI আর মানের জন্য encodeURIComponent আছে; Python-এ আছে urllib.parse.quote, যার safe আর্গুমেন্ট ডিফল্টভাবে স্ল্যাশ অপরিবর্তিত রাখে; PHP rawurlencode আর urlencode-কে আলাদা করে, যা ঠিক ওপরের স্পেস-বনাম-প্লাস প্রশ্নেই ভিন্ন। আরও ভালো হয় স্ট্রিং জোড়া না লাগিয়ে একটি URL টাইপ দিয়ে URL বানালে — তখন প্রশ্নটাই আর থাকে না।
কমান্ড লাইনে jq -rR @uri নিরাপদে এনকোড করে আর একটি তালিকাও সামলায়, আর curl --data-urlencode সঠিকভাবে এনকোড করা প্যারামিটার বানিয়ে দেয়, তিনটি ক্ষেত্রের কোনটিতে আছেন তা আপনাকে ভাবতেই হয় না — এই একটি জায়গাতেই কাজটি সত্যিই সহজ।
সাধারণ প্রশ্নোত্তর
তিনটির কোনটি ব্যবহার করব?
প্রায় সবসময় কম্পোনেন্ট। এটি ব্যবহার করুন যখন এমন একটি মান এনকোড করছেন যা কোয়েরি স্ট্রিং বা পাথ সেগমেন্টে যাবে — একটি সার্চ টার্ম, একটি ইমেইল ঠিকানা, একটি রিডাইরেক্ট টার্গেট। তিনটির মধ্যে শুধু এটিই &, =, ? ও / এস্কেপ করে, আর ঠিক এটাই আপনার মানকে তার প্যারামিটার ভেঙে বেরিয়ে দুটি প্যারামিটার হয়ে যাওয়া থেকে আটকায়। পূর্ণ URI ব্যবহার করুন শুধু তখন, যখন আপনার হাতে আগে থেকেই একটি সম্পূর্ণ URL আছে আর শুধু এর অনিরাপদ অক্ষরগুলো পরিষ্কার করতে চান; এটি ইচ্ছা করেই কাঠামোর অক্ষরগুলো ছোঁয় না, যাতে URL-টি URL-ই থাকে। ফর্ম ব্যবহার করুন যখন একটি application/x-www-form-urlencoded বডি বানাচ্ছেন, যেখানে স্পেস %20 নয়, +।
আমার “&” কেন URL ভেঙে দিল?
কারণ এটি এনকোড করা হয়নি, আর & দিয়েই কোয়েরি স্ট্রিং একটি প্যারামিটারকে পরেরটি থেকে আলাদা করে। “Smith & Sons” মানটি কাঁচা অবস্থায় ?company=-এর পরে জুড়ে দিলে সার্ভারে পৌঁছায় company=Smith আর “Sons” নামের একটি দ্বিতীয়, খালি প্যারামিটার হিসেবে। এটাই সবচেয়ে প্রচলিত URL বাগ, আর কম্পোনেন্ট এনকোডিং এর সমাধান — এটি &-কে %26 বানায়, ফলে মানটি একটিই থাকে।
আমার “+” কেন স্পেস হয়ে গেল?
কারণ কোয়েরি স্ট্রিংয়ে + মানে স্পেস — HTML ফর্ম থেকে পাওয়া এমন একটি নিয়ম, যা কেউ কখনো সরাতে পারেনি। তাই আপনার ডেটায় থাকা আক্ষরিক প্লাস, যেমন ফোন নম্বরে বা Base64 স্ট্রিংয়ে, গ্রহণকারী সার্ভার স্পেস হিসেবে পড়ে। কম্পোনেন্ট এনকোডিং এটিকে %2B-তে এস্কেপ করে, যা অক্ষত অবস্থায় পৌঁছায়।
এটি কি অন্য ভাষা ও ইমোজি সামলাতে পারে?
হ্যাঁ। টেক্সট আগে UTF-8-এ রূপান্তর করে তারপর বাইট ধরে ধরে পার্সেন্ট-এনকোড করা হয়, যা RFC 3986-এর নিয়ম এবং প্রতিটি আধুনিক সার্ভার যা আশা করে। জাপানি, আরবি, অ্যাকসেন্টযুক্ত লাতিন আর ইমোজি — সবই এনকোড করে ডিকোড করলে হুবহু ফিরে আসে।
অন্য টুল যেখানে ! ' ( ) * রেখে দেয়, এখানে সেগুলো এনকোড হয় কেন?
কারণ ব্রাউজারের বিল্ট-ইন encodeURIComponent এই পাঁচটি অক্ষর রেখে দেয়, অথচ RFC 3986 এগুলোকে reserved হিসেবে তালিকাভুক্ত করে। কিছু সার্ভার ও ফ্রেমওয়ার্ক এগুলোকে কাঠামোর অংশ হিসেবে ধরে, তাই এগুলো থাকা একটি মান ভুলভাবে পড়া হতে পারে। এগুলো এনকোড করায় কোনো ক্ষতি নেই — সব জায়গায় হুবহু ডিকোড হয়ে ফিরে আসে — আর এতে বিরল, খুঁজে বের করা কঠিন এক ধরনের বাগ দূর হয়। যত্নশীল ইমপ্লিমেন্টেশনগুলো এটাই করে।
আমার টেক্সট কি কোথাও সংরক্ষণ করা হয়?
না। কিছুই সংরক্ষণ করা হয় না, আর কোনো রিকোয়েস্ট পাঠানো হয় না। পেজ লোড হওয়ার পর ইন্টারনেট সংযোগ বিচ্ছিন্ন করলেও এটি কাজ করতে থাকে।
জেনে রাখুন: সঠিক উত্তর তিনটি, আর পেজ আপনাকে একটি বেছে নিতে বলে, কারণ প্রচলিত একটিমাত্র Encode বোতাম তিনবারে দুবার ভুল হয়। পুরো URL, একটি কোয়েরি প্যারামিটার আর একটি পাথ সেগমেন্ট এনকোড করতে আলাদা আলাদা অক্ষর এস্কেপ হয়; ভুলটি ব্যবহার করলে স্ল্যাশ, প্লাস চিহ্ন বা অ্যাম্পারস্যান্ড নিঃশব্দে ভেঙে যায়।
এই টুলটি আপনার ওয়েবসাইটে যোগ করুন
যেকোনো ব্লগ, ক্লাসের পেজ বা হেল্প আর্টিকেলের জন্য ফ্রি। একটি স্নিপেট পেস্ট করলেই আপনার ভিজিটররা আপনার পেজেই এটি ব্যবহার করতে পারবেন।