URL انکوڈنگ اور ڈی کوڈنگ، ڈویلپرز کے لیے وضاحت
کسی URL میں ایک اسپیس ٹائپ کریں، یا کوئی سیریلک لفظ، یا ایک اینپرسینڈ جو ایڈریس کی بجائے آپ کے ڈیٹا کا حصہ ہو، تو کچھ نہ کچھ سمجھوتہ کرنا پڑتا ہے۔ ویب صرف ASCII حروف کے ایک چھوٹے، متوقع مجموعے کے لیے محفوظ ترسیل کی ضمانت دیتا ہے۔ باقی سب کچھ ایسے فارمیٹ میں لپیٹنا پڑتا ہے جس پر روٹرز، سرورز اور براؤزرز سب متفق ہوں۔ وہی فارمیٹ پرسنٹ انکوڈنگ ہے، جسے عام طور پر URL انکوڈنگ کہا جاتا ہے، اور یہ صفحہ آپ کو براہِ راست اپنے براؤزر میں ٹیکسٹ کو دونوں سمتوں میں تبدیل کرنے دیتا ہے۔
پرسنٹ انکوڈنگ دراصل ہے کیا
یہ اصول میکانکی اور آسان پیروی کے قابل ہے۔ کوئی بھی حرف جو لفظی طور پر ظاہر نہیں ہو سکتا اسے % علامت اور دو ہیکسا ڈیسیمل ہندسوں سے بدل دیا جاتا ہے جو اس حرف کی بائٹ قدر کو بیان کرتے ہیں۔ ایک اسپیس %20 بن جاتا ہے۔ ایک پلس کی علامت %2B بن جاتی ہے۔ نمبر کی علامت %23 بن جاتی ہے۔ جب کوئی حرف کئی بائٹس سے مطابقت رکھتا ہو، جیسا کہ زیادہ تر غیر ASCII ٹیکسٹ UTF-8 کے تحت کرتا ہے، تو آپ کو محض قطار میں کئی ٹرپلٹس مل جاتے ہیں: یورو کی علامت %E2%82%AC بن جاتی ہے۔ ڈی کوڈنگ اس عمل کو الٹا کر دیتی ہے، ہر ٹرپلٹ کو واپس اس کی اصل بائٹ میں پڑھتے ہوئے۔
یہ اصول URI کی وضاحت (RFC 3986) میں طے کیا گیا ہے اور یہ جان بوجھ کر بورنگ ہے۔ بورنگ ہونا ہی مقصد ہے۔ کرہ ارض کا ہر اچھا HTTP کلائنٹ اور سرور انہی اصولوں پر عمل کرتا ہے، اس لیے ایک لنک جو ایک جگہ درست انکوڈ کیا گیا ہو ہر جگہ درست حالت میں پہنچتا ہے۔
یہ کیوں وجود میں لانا ضروری ہے
URLs دو قسم کے حروف لے کر چلتے ہیں جن کے کام بالکل مختلف ہیں۔ محفوظ شدہ حروف جیسے /، ?، #، &، = اور : ساختی ہیں۔ یہ ایک پارسر کو بتاتے ہیں کہ راستہ کہاں ختم ہوتا ہے اور کوئری اسٹرنگ کہاں شروع ہوتی ہے، یا ایک پیرامیٹر کہاں رکتا ہے اور اگلا کہاں شروع ہوتا ہے۔ اگر آپ کے اصل ڈیٹا میں ان علامتوں میں سے کوئی ایک ہو، تو اسے انکوڈ کیا جانا ضروری ہے تاکہ پارسر اسے وقفے کی علامت نہ سمجھ بیٹھے۔ ایک آرڈر ریفرنس جیسے A&B/2024 کوئری اسٹرنگ میں کچے طور پر ڈالا جائے تو اسے غلطی سے دو پیرامیٹرز اور ایک راستے کا حصہ سمجھ لیا جائے گا۔
پھر غیر محفوظ اور غیر ASCII حروف بھی ہیں: اسپیسز، کوٹیشن مارکس، اینگل بریکٹس، لہجے والے حروف، ایموجی، اور وہ سب کچھ جو خالص ASCII رینج سے باہر ہے۔ ان کا لفظی طور پر کسی URL میں ظاہر ہونا مناسب نہیں، چاہے اس لیے کہ وہ ترسیل کے دوران بگڑ جاتے ہیں یا اس لیے کہ ان کی کوئی متعین نمائندگی نہیں ہے۔ انہیں انکوڈ کرنا لنکس کو صاف اور متوقع رکھتا ہے، بجائے اس کے کہ نتیجہ اتفاق پر چھوڑ دیا جائے۔
یہ حقیقی کام میں کہاں نظر آتا ہے
کوئری اسٹرنگز کلاسک مثال ہیں۔ ہر وہ قدر جو آپ ?key=... میں شامل کریں اسے انکوڈ کیا جانا چاہیے تاکہ صارف کا ان پٹ ساخت کو نہ توڑ سکے۔ یہی اصول HTML فارم سبمیشنز پر بھی لاگو ہوتا ہے جو application/x-www-form-urlencoded کے طور پر بھیجی جاتی ہیں، جہاں براؤزر خود بخود فیلڈ کی قدروں کو انکوڈ کرتا ہے (اور، تاریخی رواج کے مطابق، اسپیسز کو %20 کی بجائے + بنا دیتا ہے)۔ آپ اسے اُس وقت بھی دیکھیں گے جب غیر لاطینی عنوانات والے صفحات کی طرف اشارہ کرنے والے لنکس بناتے ہیں، جب ہاتھ سے API درخواستیں تعمیر کرتے ہیں، جب ری ڈائریکٹ کے اہداف کو پیرامیٹرز کے طور پر منتقل کرتے ہیں، اور جب یہ ڈیبگ کرتے ہیں کہ ایڈریس بار میں ٹھیک نظر آنے والی درخواست سرور پر بگڑی ہوئی کیوں پہنچتی ہے۔
encodeURI بمقابلہ encodeURIComponent
JavaScript دو انکوڈرز فراہم کرتی ہے، اور غلط کا انتخاب ایک عام غلطی ہے۔ فرق دائرہ کار کا ہے۔ encodeURIComponent ڈیٹا کے ایک ٹکڑے کے لیے ہے، جیسے کوئی ایک کوئری قدر۔ یہ تقریباً سب کچھ انکوڈ کرتا ہے، بشمول محفوظ شدہ حروف /، ?، :، @، &، =، + اور #۔ یہ عین وہی ہے جو آپ چاہتے ہیں جب ڈیٹا کو ان علامتوں کو عام ٹیکسٹ کے طور پر رکھنے کی اجازت ہو۔
encodeURI پورے ایڈریس کے لیے ہے جسے آپ کام کرتا رکھنا چاہتے ہیں۔ یہ ساختی حروف کو چھیڑتا نہیں، اس لیے سلیشز، کولنز اور سوالیہ نشانات جو URL کو جوڑے رکھتے ہیں محفوظ رہتے ہیں۔ اسے اُس وقت استعمال کریں جب آپ کے پاس مکمل URL ہو اور آپ صرف اسپیسز یا غیر ASCII حروف صاف کرنا چاہتے ہوں؛ جب بھی آپ کوئی قدر کسی بڑے URL میں شامل کر رہے ہوں تو encodeURIComponent کی طرف رخ کریں۔ ایک سادہ اصول: پورے لنک کو encodeURI سے انکوڈ کریں، جو حصے آپ اس میں ڈال رہے ہیں انہیں encodeURIComponent سے انکوڈ کریں۔
سب کچھ آپ کی مشین پر ہی رہتا ہے
یہ ٹول مکمل طور پر آپ کے براؤزر میں چلتا ہے۔ آپ جو ٹیکسٹ پیسٹ کرتے ہیں وہ انہی معیاری روٹینز سے مقامی طور پر انکوڈ یا ڈی کوڈ ہوتا ہے اور کبھی کسی سرور کو نہیں بھیجا جاتا، جس سے یہ ٹوکنز، دستخط شدہ پیرامیٹرز یا کسی اور چیز کے لیے محفوظ بن جاتا ہے جسے آپ نیٹ ورک پر بھیجنا نہ چاہیں۔ اگر آپ دیگر ٹیکسٹ تبدیلیوں کے ساتھ کام کرتے ہیں، تو Base64 کنورٹر بالکل اس کے ساتھ موجود ہے، اور آپ روزمرہ کے مزید معاون ٹولز کے لیے مکمل ڈویلپر ٹولز کا مجموعہ دیکھ سکتے ہیں۔
اکثر پوچھے جانے والے سوالات
URL میں %20 کا کیا مطلب ہے؟
یہ ایک انکوڈڈ اسپیس ہے۔ اسپیس کریکٹر URL میں لفظی طور پر جائز نہیں، اس لیے اسے ایک پرسنٹ کی علامت اور ہیکسا ڈیسیمل قدر 20 سے بدل دیا جاتا ہے، جو ایک اسپیس کی بائٹ قدر ہے۔
مجھے کبھی کبھی %20 کی بجائے پلس کی علامت کیوں نظر آتی ہے؟
application/x-www-form-urlencoded قسم کا HTML فارم ڈیٹا تاریخی رواج کے تحت اسپیسز کو پلس کی علامت سے انکوڈ کرتا ہے۔ ایک عام راستے یا کوئری میں، ایک اسپیس %20 کے طور پر انکوڈ ہوتی ہے۔ دونوں اپنے مناسب سیاق میں واپس ایک اسپیس میں ڈی کوڈ ہو جاتے ہیں۔
مجھے encodeURI کی بجائے encodeURIComponent کب استعمال کرنا چاہیے؟
encodeURIComponent کسی ایک قدر کے لیے استعمال کریں جو آپ کسی URL میں شامل کر رہے ہیں، جیسے کوئری پیرامیٹر، کیونکہ یہ محفوظ شدہ حروف کو بھی انکوڈ کر دیتا ہے۔ ایک مکمل ایڈریس کے لیے encodeURI استعمال کریں جب آپ سلیشز، کولنز اور سوالیہ نشانات کو محفوظ رکھنا چاہتے ہوں جو اسے جوڑے رکھتے ہیں۔
کیا URL انکوڈنگ میرے ڈیٹا کا مطلب بدل دیتی ہے؟
نہیں۔ انکوڈنگ مکمل طور پر واپسی کے قابل ہے۔ نتیجے کو ڈی کوڈ کرنا عین اصل ٹیکسٹ واپس دے دیتا ہے، بائٹ بہ بائٹ، جب تک دونوں طرف ایک ہی کریکٹر سیٹ استعمال ہو۔
لہجے والے حروف یا ایموجی جیسے غیر ASCII حروف کیسے سنبھالے جاتے ہیں؟
پہلے انہیں UTF-8 بائٹس میں بدلا جاتا ہے، پھر ہر بائٹ اپنا ایک الگ پرسنٹ ٹرپلٹ بن جاتی ہے۔ ایک ہی لہجہ دار حرف یا ایموجی اس لیے انکوڈ شدہ آؤٹ پٹ میں کئی ٹرپلٹس میں پھیل سکتا ہے۔
کیا اس ٹول کے استعمال کے دوران میرا ٹیکسٹ کسی سرور کو بھیجا جاتا ہے؟
نہیں۔ انکوڈنگ اور ڈی کوڈنگ مکمل طور پر آپ کے براؤزر میں ہوتی ہے۔ آپ جو کچھ پیسٹ کریں وہ اپلوڈ نہیں ہوتا، اس لیے اسے نجی یا حساس اسٹرنگز کے ساتھ استعمال کرنا محفوظ ہے۔