URL এনকোড / ডিকোড

URL (percent) encoding কীভাবে কাজ করে

একটি URL-এ কেবল একটি সীমিত সেটের অক্ষর থাকতে পারে। সেই সেটের বাইরের সবকিছু — স্পেস, অধিকাংশ যতিচিহ্ন, এবং নন-ASCII টেক্সট — %-এর পরে অক্ষরের UTF-8 বাইট মানগুলো হেক্সাডেসিমালে বসিয়ে বদলে দেওয়া হয়। একটি স্পেস %20 হয়ে যায়, একটি অ্যাম্পারস্যান্ড %26, এবং é হয়ে যায় %C3%A9।

Component বনাম full URI

এটিই সেই পার্থক্য যা অধিকাংশ টুল ঝাপসা করে দেয়। Component মোড (encodeURIComponent) সংরক্ষিত কাঠামোগত অক্ষরগুলোও এনকোড করে (: / ? # [ ] @ & = +), তাই এটি একটি একক query-string মান বা path সেগমেন্টের জন্য সঠিক। Full-URI মোড (encodeURI) সেই কাঠামোগত অক্ষরগুলো অপরিবর্তিত রেখে দেয় এবং কেবল স্পেস ও অবৈধ অক্ষর ঠিক করে, তাই এটি একটি সম্পূর্ণ URL একবারে এনকোড করার জন্য। ভুল মোড ব্যবহার করা ভাঙা লিংকের একটি সাধারণ কারণ।

সংরক্ষিত বনাম অসংরক্ষিত অক্ষর

RFC 3986 অনুযায়ী, অসংরক্ষিত (unreserved) অক্ষর A–Z a–z 0–9 - _ . ~ কখনো এনকোড হয় না। সংরক্ষিত (reserved) অক্ষরের কোনো URL-এ একটি কাঠামোগত অর্থ থাকে এবং সেগুলো কেবল তখনই এনকোড হয় যখন সেগুলো সীমানির্দেশক (delimiters)-এর বদলে ডেটা হিসেবে আসে।

সম্পূর্ণ RFC 3986 অক্ষর-সেট

URL-এর আধুনিক নিয়মপুস্তক হলো RFC 3986, যা জানুয়ারি 2005-এ প্রকাশিত হয়। এটি পুরনো RFC 2396 (এবং RFC 1808 ও RFC 2732)-কে অপ্রচলিত করে এবং মূল URL স্পেসিফিকেশন RFC 1738-কে হালনাগাদ করে। RFC 3986 কোনো URI যে ASCII অক্ষরগুলো ব্যবহার করতে পারে সেগুলোকে তিনটি গ্রুপে ভাগ করে, এবং এগুলো ঠিকঠাক করাই পুরো খেলা।

সংরক্ষিত অক্ষর সীমানির্দেশক হিসেবে অর্থ বহন করে। কোনো একটি URI যা অন্য একটি থেকে কেবল কোনো অসংরক্ষিত অক্ষরের percent-encoding-এ ভিন্ন হয়, তাকে সমতুল্য গণ্য করা হয়, তাই A-কে %41 হিসেবে এনকোড করা বৈধ কিন্তু অর্থহীন এবং সুআচরিত সফটওয়্যার একে আবার স্বাভাবিক করে দেয়। এর বিপরীতে, সংরক্ষিত অক্ষরগুলোকে যখনই সেগুলো কোনো বিভাজকের বদলে আক্ষরিক ডেটা হিসেবে আসে তখন percent-encode করতে হবে: কোনো সার্চ-শব্দের ভেতরে একটি অ্যাম্পারস্যান্ডকে %26 হতে হবে যাতে তাকে দুটি query প্যারামিটারের মধ্যকার বিভাজক ভেবে না ফেলা হয়।

কোনো অক্ষর কীভাবে percent-encoded অক্টেট হয়

Percent-encoding সরাসরি অক্ষরের উপর নয়, বরং বাইট-এর উপর কাজ করে। RFC 3986 ত্রয়ী ব্যাকরণ pct-encoded = "%" HEXDIG HEXDIG সংজ্ঞায়িত করে: একটি আক্ষরিক percent চিহ্নের পরে দুটি হেক্সাডেসিমাল অঙ্ক যা একটি 8-বিট অক্টেট প্রকাশ করে। স্পেস অক্ষর (US-ASCII মান 32, বাইনারি 00100000, হেক্স 20) তাই %20-এ এনকোড হয়।

সাধারণ ASCII-র বাইরে যেকোনো কিছুর জন্য আধুনিক URL-এ নিয়মটি স্পষ্ট: প্রথমে টেক্সটকে UTF-8 হিসেবে এনকোড করুন, তারপর প্রতিটি ফলস্বরূপ বাইটকে percent-encode করুন যা অসংরক্ষিত সেটে নেই। যেহেতু অধিকাংশ নন-ASCII অক্ষর দুই, তিন বা চার UTF-8 বাইট জুড়ে থাকে, সেগুলো একাধিক ত্রয়ীতে বিস্তৃত হয়। উচ্চারণ-চিহ্নযুক্ত é হয়ে যায় %C3%A9; জাপানি কাতাকানা অক্ষর a (ア) হয়ে যায় %E3%82%A2; কোনো ইমোজির মতো চার-বাইট অক্ষর চারটি ত্রয়ীতে বিস্তৃত হয়। এই টুল যে JavaScript বিল্ট-ইনগুলো ব্যবহার করে সেগুলো ইতিমধ্যেই UTF-8 অনুসরণ করে, এ কারণেই উচ্চারণ-চিহ্ন, CJK টেক্সট ও ইমোজির রাউন্ড-ট্রিপ সঠিকভাবে কাজ করে।

encodeURI, encodeURIComponent ও অপ্রচলিত escape

JavaScript তিনটি এনকোডার দেয়, এবং এদের একে অপরের সঙ্গে গুলিয়ে ফেলা একটি ক্লাসিক বাগ। নিচের টেবিলটি ঠিকঠিক দেখায় এদের প্রতিটি কোন অক্ষরগুলো বিনা-এনকোড রেখে দেয় — বাকি সবকিছু একটি percent-ত্রয়ীতে পরিণত হয়।

এগারোটি যতিচিহ্ন - _ . ! ~ * ' ( ) যেগুলো encodeURIComponent-ও রেখে দেয়, সেগুলো RFC 3986-এর অসংরক্ষিত চিহ্ন, সঙ্গে কিছু লিগ্যাসি অক্ষর। প্রতিটি কাঠামোগত জিনিস — : / ? # [ ] @ এবং গুরুত্বপূর্ণ &, = ও + — এনকোড হয়ে যায়, এ ঠিক এ কারণেই কোনো পৃথক মানের জন্য encodeURIComponent সঠিক পছন্দ। লিগ্যাসি escape ফাংশনটি অপ্রচলিত ও অ-মানক: এটি UTF-8 ব্যবহার করে না (এটি 256-এর নিচের কোড পয়েন্টের জন্য %XX এবং তার উপরে একটি অ-মানক %uXXXX রূপ উৎপন্ন করে), তাই ć-এর মতো একটি অক্ষর ভুলভাবে তার UTF-8 বাইটের বদলে %u0107 হয়ে যায়। এটি URL-এর জন্য কখনো ব্যবহার করবেন না।

স্পেসের সমস্যা: %20 বনাম +

একটি বাইট অন্য যেকোনোটির চেয়ে বেশি বিভ্রান্তি তৈরি করে: স্পেস। RFC 3986 অনুযায়ী কোনো সাধারণ URI-তে একটি স্পেস %20। কিন্তু application/x-www-form-urlencoded হিসেবে সাবমিট করা HTML ফর্ম একটি ভিন্ন, পুরনো প্রথা অনুসরণ করে — যা আজ WHATWG URL Standard-এ সংজ্ঞায়িত — যেখানে একটি স্পেস একটি আক্ষরিক প্লাস চিহ্ন + হয়ে যায়, এবং তাই একটি আক্ষরিক প্লাসকে দুটোকে আলাদা রাখতে %2B হিসেবে এনকোড করা হয়। ব্রাউজারের URLSearchParams API এই রূপটি ব্যবহার করে, তাই এটি একটি স্পেসকে + হিসেবে সিরিয়ালাইজ করে, যেখানে encodeURIComponent %20 উৎপন্ন করে।

দুটোই একটি আসল URL-এর query স্ট্রিংয়ে বৈধ, এবং একটি সঠিক ডিকোডার +-কে স্পেস হিসেবে কেবল form-encoded ডেটায় গণ্য করে — কোনো path-এ কখনো নয়। কোনো path সেগমেন্টের ভেতরে +-কে স্পেসে ডিকোড করা একটি সাধারণ বাগ যা ফাইল নাম ও স্লাগ নষ্ট করে দেয়। আপনি যদি এখানে form ডেটা পেস্ট করেন এবং চান প্লাস চিহ্নগুলোকে স্পেস হিসেবে গণ্য করা হোক, তবে ডিকোড করার আগে সেগুলো বদলে দিন; সাধারণ URL-এর জন্য, সেগুলো যেমন আছে তেমনই থাকতে দিন।

এনকোডিং URL-এর অংশের উপর নির্ভর করে

একটি URL একটি সমতল স্ট্রিং নয়; এটি কম্পোনেন্টের একটি ক্রম — scheme, userinfo, host, port, path, query ও fragment — এবং প্রতিটির নিজস্ব বৈধ অক্ষরের সেট আছে। ব্যবহারিক ফলাফল:

• Path সেগমেন্ট-এ sub-delims ও : @ থাকতে পারে, কিন্তু কোনো একক সেগমেন্টের ভেতরে একটি আক্ষরিক /-কে %2F লিখতে হবে, নয়তো তাকে একটি নতুন সেগমেন্ট সীমা হিসেবে পড়া হয়।
• Query স্ট্রিং & ও =-কে বিভাজক হিসেবে গণ্য করে, তাই এগুলো ধারণকারী যেকোনো মানকে percent-encode করতে হবে; তবে ? ও / কোনো query-এর ভেতরে বিনা-escape-এ অনুমোদিত।
• Fragment (#-এর পরে) কখনো সার্ভারে পাঠানো হয় না — ব্রাউজার এগুলো সামলায় — কিন্তু তবুও নন-ASCII বিষয়বস্তুর জন্য percent-encoding অনুসরণ করে।
• Userinfo (host-এর আগে খুব কমই ব্যবহৃত user:password@)-কে @ ও : তখন এনকোড করতে হবে যখন সেগুলো বিভাজকের বদলে ডেটা হিসেবে আসে।

এ কারণেই একটিমাত্র "পুরোটা এনকোড করে দাও" পাস ভুল: প্রথমে প্রতিটি কম্পোনেন্টকে encodeURIComponent দিয়ে এনকোড করুন, তারপর সেগুলোকে ঠিক সেই আক্ষরিক কাঠামোগত অক্ষর দিয়ে জুড়ুন যা আপনি প্রকৃতপক্ষে চান।

আন্তর্জাতিক ডোমেন ও IRI: Punycode, percent-encoding নয়

Percent-encoding path, query ও fragment-এ নন-ASCII টেক্সট সামলায়, কিন্তু এটি host নাম-এ ব্যবহার করা যায় না — DNS কেবল একটি সীমিত ASCII বর্ণমালা গ্রহণ করে। আন্তর্জাতিকীকৃত ডোমেন নাম এর বদলে IDNA মানদণ্ডের অধীনে Punycode (RFC 3492) দিয়ে রূপান্তরিত হয়। প্রতিটি নন-ASCII লেবেল রূপান্তরিত হয়ে ASCII-সামঞ্জস্যপূর্ণ উপসর্গ xn-- পায়: münchen.de হয়ে যায় xn--mnchen-3ya.de, এবং লেবেল bücher হয়ে যায় xn--bcher-kva। ব্রাউজার বন্ধুত্বপূর্ণ Unicode রূপ দেখায় কিন্তু ওয়্যারে xn-- রূপ পাঠায়।

বৃহত্তর ধারণাটি হলো IRI (Internationalized Resource Identifier, RFC 3987), যা সর্বত্র Unicode-এর অনুমতি দেয়। একটি IRI-কে একটি সাধারণ URI-তে এভাবে ম্যাপ করা হয়: টেক্সটকে স্বাভাবিক (Unicode NFC) করে, path ও query-তে নন-ASCII অক্ষরগুলোকে UTF-8-এনকোড করে, এবং সেই বাইটগুলোকে percent-encode করে — যখন host-কে Punycode দিয়ে রূপান্তরিত করা হয়। সুতরাং https://en.wiktionary.org/wiki/Ῥόδος হয়ে যায় https://en.wiktionary.org/wiki/%E1%BF%AC%CF%8C%CE%B4%CE%BF%CF%82। সংক্ষেপে: host Punycode ব্যবহার করে, বাকি সবকিছু percent-encoding।

Double-encoding: যে বাগ একটি স্তর বেশি যোগ করে

Double-encoding তখন ঘটে যখন ইতিমধ্যে-এনকোড করা টেক্সটকে আবার এনকোড করা হয়। Percent চিহ্ন নিজেই একটি সংরক্ষিত অক্ষর, তাই %20-কে দ্বিতীয়বার এনকোড করলে পাওয়া যায় %2520 — কারণ অগ্রণী % %25 হয়ে যায়। এর বিপরীত ভুল, দুটি স্তর থাকা সত্ত্বেও একবার ডিকোড করা, আউটপুটে বিপথগামী %xx ক্রম রেখে যায়। লক্ষণগুলোর মধ্যে আছে এমন URL যা অ্যাড্রেস বারে %2520 দেখায়, বা এমন ফাইল নাম যা তাদের ভেতরে একটি আক্ষরিক %20 নিয়ে আসে।

সমাধান হলো সচেতন থাকা যে কোনো মান স্তরগুলোর — আপনার কোড, একটি HTTP লাইব্রেরি, একটি প্রক্সি, একটি ফ্রেমওয়ার্কের রাউটার — মধ্য দিয়ে যাওয়ার সময় কতবার এনকোড হয়, এবং ঠিক ততবারই ডিকোড করা। URL তৈরি করার সময় একবার এনকোড করুন; কোনো মানকে "নিরাপত্তার জন্য" কখনো দুবার এনকোডারের মধ্য দিয়ে চালাবেন না। কোনো সন্দেহজনক মান যাচাই করতে, এটি এখানে বারবার ডিকোড করুন: যদি দ্বিতীয় ডিকোড ফলাফল বদলে দেয়, তবে সেটি double-encoded ছিল।

নিরাপত্তা: যেখানে সরল এনকোডিং ও ডিকোডিং ভুল হয়ে যায়

URL encoding ওয়েব-দুর্বলতার একটি বারবার আসা উপাদান, প্রায় সর্বদা এ কারণে যে কোনো ডিকোড করা মানকে পুনরায়-যাচাই ছাড়াই বিশ্বাস করা হয়।

• Open redirect। একটি ?next= বা ?return_to= প্যারামিটার যাকে ডিকোড করে একটি redirect লক্ষ্য হিসেবে ব্যবহার করা হয়, কোনো আক্রমণকারীকে ব্যবহারকারীদের একটি বৈরী সাইটে পাঠাতে দেয়। ডিকোড করা গন্তব্যকে হোস্টের একটি allow-list-এর বিপরীতে যাচাই করুন — কখনো কোনো নির্বিচার ডিকোড করা URL-এ redirect করবেন না।
• Cross-site scripting (XSS)। ডিকোডিং %3Cscript%3E-কে আবার একটি জীবন্ত ট্যাগে পরিণত করে। যদি সেই ডিকোড করা টেক্সট HTML-escape ছাড়াই কোনো পৃষ্ঠায় লেখা হয় তবে তা চলতে পারে। Percent-decoding ও HTML-escaping ভিন্ন কাজ: মান DOM-এ পৌঁছানোর আগে দ্বিতীয়টি করুন।
• Filter ও WAF বাইপাস। আক্রমণকারীরা পেলোড এনকোড ও double-encode করে — ../-এর জন্য ..%2F, বা একটি কোটের জন্য %2527 — যাতে কোনো এমন ফিল্টার থেকে ফসকে যায় যা কেবল কাঁচা রূপ পরীক্ষা করে। নিরাপত্তা যাচাই প্রয়োগ করার আগে ইনপুটকে একটি একক প্রামাণিক (canonical) ডিকোড রূপে স্বাভাবিক করুন, পরে নয়।
• Log ও header injection। কোনো মানে ইনজেক্ট করা একটি ডিকোড করা newline (%0A) বা carriage return (%0D) যা কোনো log লাইন বা HTTP হেডারে পৌঁছায়, ভুয়া এন্ট্রি তৈরি করতে বা কোনো রেসপন্স বিভক্ত করতে পারে। ডিকোড করার পরে কন্ট্রোল অক্ষর সরিয়ে ফেলুন।

মূল কথা: percent-encoding একটি পরিবহন-সুবিধা, নিরাপত্তা-সীমা নয়। যেখানেই কোনো ডিকোড করা মান শেষ পর্যন্ত ব্যবহৃত হয়, তাকে সর্বদা যাচাই ও প্রসঙ্গ অনুযায়ী escape করুন।

ওয়েব লিংকের বাইরে: যেসব জায়গায় percent-encoding দেখা যায়

Percent-encoding আপনার ব্রাউজার বারের https:// ঠিকানায় সীমাবদ্ধ নয়; একই RFC 3986 নিয়ম অনেক অন্য শনাক্তকারী নিয়ন্ত্রণ করে, এবং উপরে উল্লিখিত প্রতি-প্রসঙ্গ শৃঙ্খলা প্রতিটির উপরই প্রযোজ্য।

• mailto: লিংক। mailto:hi@example.com?subject=Hello%20there&body=Line%20one এর মতো একটি পূর্ব-পূরণ করা ইমেল লিংক subject ও body-তে স্পেস ও যতিচিহ্নের জন্য percent-encoding ব্যবহার করে, এবং ফিল্ডগুলো আলাদা করতে একটি অ্যাম্পারস্যান্ড — তাই body টেক্সটের যেকোনো আক্ষরিক অ্যাম্পারস্যান্ডকে নিজেই %26 হতে হবে।
• data: URI। data:text/plain,Hello%20World-এর মতো ইনলাইন রিসোর্স তাদের পেলোড percent-encode করে (বা এর বদলে Base64 হিসেবে বহন করে), এ কারণেই এই টুলটি একটি Base64 এনকোডারের সঙ্গে স্বাভাবিকভাবে জোড়া মেলে।
• OAuth ও redirect প্যারামিটার। একটি OAuth redirect_uri একটি সম্পূর্ণ URL যা অন্য একটি URL-এর query স্ট্রিংয়ের ভেতরে নেস্টেড থাকে, তাই একে encodeURIComponent দিয়ে একটি একক কম্পোনেন্ট হিসেবে এনকোড করতে হবে — একটি পাঠ্যপুস্তকীয় পরিস্থিতি যেখানে এনকোড করতে ভুলে যাওয়া (বা double-encode করা) নীরবে login প্রবাহ ভেঙে দেয়।
• HTTP প্রমাণীকরণ ও API। userinfo কম্পোনেন্টে রাখা credentials, স্বাক্ষরিত-অনুরোধ স্বাক্ষর এবং অনেক REST path প্যারামিটার সবই একটি সামঞ্জস্যপূর্ণ, একক-পাস percent-encoding-এর উপর নির্ভর করে যাতে সার্ভার যে মান পুনর্গঠন করে তা আপনার পাঠানো মানের সঙ্গে মেলে।

এই প্রতিটি ক্ষেত্রে ব্যর্থতার ধরনটি একটি ভাঙা ওয়েব লিংকের অভিন্ন: কোনো সংরক্ষিত অক্ষর যা ডেটা হিসেবে ছিল তা একটি বিভাজক হিসেবে ফসকে যায়, বা কোনো এনকোড করা মানকে একবার কম বা একবার বেশি ডিকোড করা হয়। প্রতিটি মান একবার, ঠিক সেই স্লটের জন্য যেখানে তা বসে, এনকোড করুন, এবং শনাক্তকারী সর্বত্র পরিচ্ছন্নভাবে রাউন্ড-ট্রিপ করে।

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

URL encoding কী?

URL (percent) encoding সেই সব অক্ষরকে বদলে দেয় যেগুলো কোনো URL-এ অনিরাপদ বা সংরক্ষিত (reserved) — একটি "%" চিহ্নের পরে তাদের হেক্সাডেসিমাল বাইট মান বসিয়ে; যেমন একটি স্পেস %20 হয়ে যায় এবং একটি অ্যাম্পারস্যান্ড %26 হয়ে যায়। এটি যেকোনো টেক্সটকে কোনো URL-এর ভেতরে নিরাপদে যাতায়াত করতে দেয়।

Component মোড বনাম full-URI মোড — কোনটি ব্যবহার করব?

"Component" (encodeURIComponent) ব্যবহার করুন যখন আপনি একটি একক অংশ এনকোড করছেন যা কোনো URL-এর ভেতরে যায় — একটি query-string মান, একটি path সেগমেন্ট বা একটি ফর্ম ফিল্ড — কারণ এটি :/?#[]@&=+ ইত্যাদিও এনকোড করে। "Full URI" (encodeURI) ব্যবহার করুন যখন আপনার কাছে একটি সম্পূর্ণ URL থাকে এবং আপনি শুধু স্পেস ও অবৈধ অক্ষর ঠিক করতে চান, কাঠামোগত অক্ষরগুলো অপরিবর্তিত রেখে।

এটি কি Unicode ও ইমোজি সামলায়?

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

কিছু কি সার্ভারে পাঠানো হয়?

না। এনকোডিং ও ডিকোডিং সম্পূর্ণভাবে আপনার ব্রাউজারে চলে, তাই আপনার ডেটা আপনার ডিভাইসেই থাকে। টুলটি একবার লোড হওয়ার পরে অফলাইনেও কাজ করে।

সম্পর্কিত টুল

• Base64 এনকোডার / ডিকোডার
• JSON ফরম্যাটার ও ভ্যালিডেটর
• টেক্সট থেকে Hex
• Unix টাইমস্ট্যাম্প কনভার্টার

সব ডেভেলপার ও ডেটা রূপান্তর দেখুন →