URL এনকোডিং (পার্সেন্ট-এনকোডিং) কী?
দ্রুত উত্তর: URL এনকোডিং ওয়েব URL-এ বিশেষ অর্থ আছে এমন ক্যারেক্টারকে (স্পেস, অ্যাম্পারস্যান্ড, ইকুয়াল সাইন) বিশ্বজনীন ফরম্যাটে অনুবাদ করে—একটি পার্সেন্ট সাইন (%) ও দুটি হেক্সাডেসিমেল ডিজিট।
ইন্টারনেটের আর্কিটেকচার চায় Uniform Resource Locator (URL) স্ট্যান্ডার্ড US-ASCII ক্যারেক্টার সেট দিয়ে HTTP-তে পাঠানো হোক। URL-এ এই কঠোর বর্ণমালার বাইরের ক্যারেক্টার—স্পেস, ইমোজি বা সিরিলিক টেক্সট—থাকলে ব্রাউজার বা সার্ভার ক্র্যাশ বা রুট ভুল ব্যাখ্যা করতে পারে।
URL কোয়েরি স্ট্রিংয়ে জটিল ডেটা নিরাপদে পাঠাতে আমাদের URL Encoding (পার্সেন্ট-এনকোডিং) প্রয়োগ করতে হয়। এই অ্যালগরিদম অনিরাপদ ক্যারেক্টারকে % সিম্বল ও ক্যারেক্টারের ASCII/UTF-8 মানের হেক্সাডেসিমেল উপস্থাপনায় রূপান্তর করে।
উদাহরণস্বরূপ, স্ট্যান্ডার্ড স্পেস ক্যারেক্টার হয় %20, আর অ্যাম্পারস্যান্ড (&) হয় %26। এতে ডেটা ব্যাকএন্ড সার্ভারে সম্পূর্ণ অক্ষুণ্ণ পৌঁছায়।
encodeURI() বনাম encodeURIComponent() কেন গুরুত্বপূর্ণ
দ্রুত উত্তর: encodeURI() পূর্ণ URL এনকোড করে মূল স্ট্রাকচার (যেমন http://) না ভেঙে। encodeURIComponent() নির্দিষ্ট ডেটা প্যারামিটার (সার্চ কোয়েরি) এনকোড করে, কারণ এটি স্ল্যাশ ও ইকুয়াল সাইন আক্রমণাত্মকভাবে এনকোড করে।
JavaScript ওয়েব ডেভেলপমেন্টে ঘন ঘন বাগ হলো ভুল URL এনকোডিং ফাংশন ব্যবহার। 404 এরর ও ভাঙা API রিকোয়েস্ট এড়াতে পার্থক্য বোঝা জরুরি।
- encodeURI(): এই ফাংশন ধরে নেয় আপনি সম্পূর্ণ, বৈধ URL পাস করছেন। স্পেস ও বিদেশি ক্যারেক্টার এনকোড করবে, কিন্তু URL-এ বিশেষ স্ট্রাকচারাল অর্থ আছে এমন ক্যারেক্টার—
?, =, &, /, বা :—এনকোড করবে না।
- encodeURIComponent(): এই ফাংশন ধরে নেয় আপনি URL কোয়েরি স্ট্রিংয়ের ভিতরে বসানো নির্দিষ্ট ডেটা এনকোড করছেন। স্ল্যাশ ও অ্যাম্পারস্যান্ডসহ প্রায় সবকিছু আক্রমণাত্মকভাবে এনকোড করে। ইউজার ইনপুট নিয়ে URL প্যারামিটার হিসেবে যোগ করার সময় এই ফাংশন ব্যবহার করতেই হবে।
Utiliome-এর URL Encoder কঠোরভাবে encodeURIComponent() সেমান্টিক্স ব্যবহার করে ডেভেলপার পেলোড এস্কেপ করার সময় সর্বোচ্চ নিরাপত্তা নিশ্চিত করে।
অনলাইনে URL ডিকোড করার গোপনীয়তা ঝুঁকি
দ্রুত উত্তর: অনেক URL-এ কোয়েরি প্যারামিটারে অত্যন্ত সংবেদনশীল অথেন্টিকেশন টোকেন, পাসওয়ার্ড রিসেট হ্যাশ বা কাস্টমার ইমেইল থাকে। ক্লাউড-ভিত্তিক URL ডিকোডারে পেস্ট করলে ডেটা সার্ভার লগে উন্মুক্ত হয়। Utiliome সবকিছু ১০০% লোকালভাবে প্রসেস করে।
ডেভেলপাররা নিয়মিত OAuth রিডাইরেক্ট বা Webhook পেলোড ডিবাগ করতে জটিল URL স্ট্রিং ডিকোড করেন (যেমন ?email=user%40example.com&token=abc%3D%3D)।
জেনেরিক অনলাইন SEO টুলে এই স্ট্রিং পেস্ট করলে URL HTTP POST রিকোয়েস্টে রিমোট সার্ভারে যায়। সার্ভার অ্যাডমিন সহজেই আপনার সংবেদনশীল OAuth টোকেন, সেশন ID ও PII (ব্যক্তিগত শনাক্তকরণ তথ্য) লগ করতে পারে।
Utiliome জিরো-ট্রাস্ট, লোকাল-ফার্স্ট আর্কিটেকচারে চলে। ডিকোডিং গণিত সম্পূর্ণ ব্রাউজারের লোকাল RAM-এ হয়। প্রোডাকশন API কী নিরাপদে ডিকোড করতে পারেন, জেনে যে ডেটা বাইরের নেটওয়ার্কে যায় না।
URL-এ ইমোজি ও Unicode হ্যান্ডলিং
দ্রুত উত্তর: আধুনিক URL এনকোডিং অ্যালগরিদম মাল্টি-বাইট Unicode ক্যারেক্টার নিখুঁতভাবে সাপোর্ট করে। 🚀-এর মতো ইমোজি এনকোড করলে প্রথমে UTF-8 বাইট উপস্থাপনায় ম্যাপ হয়, তারপর আলাদাভাবে পার্সেন্ট-এনকোড হয়।
ইন্টারনেটের শুরুর দিনে URL কঠোরভাবে ইংরেজি ASCII ছিল। আজ URL-এ বিশ্বজনীন ভাষা, আরবি লিপি ও জটিল ইমোজি নিয়মিত থাকে।
আধুনিক URL এনকোডিং স্ট্যান্ডার্ড (RFC 3986) বলে বিদেশি ক্যারেক্টার প্রথমে UTF-8 বাইট সিকোয়েন্সে রূপান্তর করতে হবে। তারপর প্রতিটি বাইট পার্সেন্ট-এনকোড হয়।
উদাহরণস্বরূপ, রকেট ইমোজি (🚀) UTF-8-এ চার বাইট লাগে। Utiliome-এর URL Encoder দিয়ে গেলে এটি গাণিতিকভাবে %F0%9F%9A%80-এ রূপান্তরিত হয়। এতে যেকোনো ব্যাকএন্ড সার্ভার, প্রাথমিক ভাষা আর্কিটেকচার যাই হোক, ইমোজি নিরাপদে রাউট ও ডিকোড করতে পারে।
রিজার্ভড বনাম আনরিজার্ভড ক্যারেক্টার
দ্রুত উত্তর: URL স্ট্যান্ডার্ড 'Unreserved' ক্যারেক্টার (অক্ষর, সংখ্যা, হাইফেন, পিরিয়ড) সংজ্ঞায়িত করে যেগুলো কখনো এনকোড করতে হয় না। 'Reserved' ক্যারেক্টার (?, =, এবং &) স্ট্রাকচারাল কমান্ড—রো ডেটা হিসেবে ব্যবহার করলে আক্রমণাত্মকভাবে এনকোড করতে হয়।
URL এনকোডিং আয়ত্ত করতে RFC 3986 স্পেসিফিকেশনে ক্যারেক্টার শ্রেণিবিন্যাস বুঝতে হবে।
- আনরিজার্ভড ক্যারেক্টার:
A-Z, a-z, 0-9, -, _, ., এবং ~। এগুলো স্বতঃসিদ্ধভাবে নিরাপদ। URL এনকোডার সেগুলো উপেক্ষা করে অক্ষুণ্ণ রাখে।
- রিজার্ভড ক্যারেক্টার:
! * ' ( ) ; : @ & = + $ , / ? # [ ]। এগুলো ইন্টারনেটের "সিনট্যাক্স"। উদাহরণস্বরূপ, & সিম্বল ভেরিয়েবল আলাদা করে। আপনার আসল ভেরিয়েবল ডেটায় অ্যাম্পারস্যান্ড থাকলে (যেমন "M&M Candy") সেটাকে %26-এ এনকোড করতে হবে, যাতে সার্ভার ডেটা মাঝখানে না ভাঙে।
স্পেস কেন %20 এবং প্লাস (+) সিম্বল দুটোই হতে পারে
দ্রুত উত্তর: ঐতিহাসিকভাবে ফর্ম ডেটায় স্পেস প্লাস (+) হিসেবে এনকোড হতো, আর স্ট্যান্ডার্ড URL-এ %20। আধুনিক JavaScript API বিভ্রান্তি এড়াতে ও ক্রস-প্ল্যাটফর্ম সামঞ্জস্যের জন্য %20-এ মানক করে।
সাধারণ বিভ্রান্তি হলো স্পেস ক্যারেক্টার কখনো %20 আর কখনো + সিম্বল হিসেবে এনকোড হয় কেন।
এটি লিগ্যাসি ইন্টারনেট আর্কিটেকচার থেকে আসে। application/x-www-form-urlencoded স্পেক (HTML ফর্ম সাবমিটের সময় ব্যবহৃত) ঐতিহাসিকভাবে বলেছে স্পেস প্লাস সিম্বলে রূপান্তর করতে হবে ব্যান্ডউইথ বাঁচাতে।
তবে স্ট্যান্ডার্ড URL পাথ ও আধুনিক API কোয়েরি স্ট্রিংয়ে স্পেস ক্যারেক্টার কঠোরভাবে %20-এ পার্সেন্ট-এনকোড করতে হয়। Utiliome আধুনিক encodeURIComponent() স্পেসিফিকেশনে মানক করে, যাতে স্পেস নিরাপদে %20-এ রূপান্তরিত হয় এবং আধুনিক REST API-তে সার্ভার-সাইড ডিকোডিং ত্রুটি না হয়।