কোনও ইউআরএলকে কোনও স্থান থাকতে অনুমতি দেওয়া হয়েছে?

Question

কোনও ইউআরআই (বিশেষত একটি এইচটিটিপি ইউআরএল) এক বা একাধিক স্পেস অক্ষর রাখার জন্য অনুমোদিত? যদি কোনও ইউআরএল অবশ্যই এনকোড করা থাকে তবে +এটি কেবল একটি সাধারণ অনুসরণ করা কনভেনশন, বা বৈধ বিকল্প?

বিশেষত, কেউ কি কোনও আরএফসির দিকে ইঙ্গিত করতে পারে যা নির্দেশ করে যে কোনও স্থানের URL টি এনকোড করা উচিত ?

প্রশ্নের জন্য অনুপ্রেরণা: কোনও ওয়েবসাইটের বিটা-পরীক্ষা করার সময়, আমি লক্ষ করেছি যে কিছু ইউআরএল স্পেস দিয়ে তৈরি করা হয়েছিল। ফায়ারফক্স ঠিক কাজটি করেছে বলে আমার মনে হয়েছিল! তবে আমি বিকাশকারীদের একটি আরএফসির দিকে নির্দেশ করতে সক্ষম হতে চেয়েছিলাম যাতে তারা এই ইউআরএলগুলি ঠিক করার প্রয়োজন বোধ করে।

Comments

সুপারসেটও যা পরে এসেছিলেন কি সব অবৈধ অক্ষর আছে: stackoverflow.com/questions/1547899/...

— সিরো Santilli郝海东冠状病六四事件法轮功

সম্পর্কিত: কোনও ইউআরএলে,% 20 বা + ব্যবহার করে স্পেসগুলি এনকোড করা উচিত?

— ডেভিডআরআর

Answer 1

অনুযায়ী বোঝায় যা RFC 1738 :

অনিরাপদ:

চরিত্রগুলি বেশ কয়েকটি কারণে অনিরাপদ হতে পারে। স্পেস অক্ষরটি অনিরাপদ কারণ ইউআরএলগুলি প্রতিলিপি বা টাইপসেট বা ওয়ার্ড-প্রসেসিং প্রোগ্রামগুলির চিকিত্সার সাথে জড়িত থাকার সময় উল্লেখযোগ্য স্থানগুলি অদৃশ্য হয়ে যেতে পারে এবং তুচ্ছ স্থানগুলি উপস্থিত হতে পারে। অক্ষরগুলি "<"এবং ">"অনিরাপদ কারণ এগুলি ফ্রি পাঠ্যে ইউআরএল এর চারপাশে সীমানা হিসাবে ব্যবহৃত হয়; উদ্ধৃতি চিহ্ন ( """) কিছু সিস্টেমে ইউআরএল সীমাবদ্ধ করতে ব্যবহৃত হয়। চরিত্রটি "#"অনিরাপদ এবং সর্বদা এনকোড করা উচিত কারণ এটি ওয়ার্ল্ড ওয়াইড ওয়েবে এবং অন্যান্য সিস্টেমে কোনও খণ্ড / অ্যাঙ্কর শনাক্তকারী যা এটি অনুসরণ করতে পারে তার থেকে URL ডিলিট করতে ব্যবহৃত হয়। চরিত্র"%"এটি অনিরাপদ কারণ এটি অন্যান্য অক্ষরের এনকোডিংয়ের জন্য ব্যবহৃত হয়। অন্যান্য অক্ষরগুলি অনিরাপদ কারণ গেটওয়ে এবং অন্যান্য পরিবহণ এজেন্ট কখনও কখনও এই জাতীয় অক্ষরগুলি সংশোধন করতে পারে বলে জানা যায়। এই অক্ষরগুলি হয় "{", "}", "|", "\", "^", "~", "[", "]", এবং "`"।

সমস্ত অনিরাপদ অক্ষর সর্বদা একটি URL এর মধ্যে এনকোড থাকা আবশ্যক । উদাহরণস্বরূপ, অক্ষরগুলি "#"অবশ্যই ইউআরএলগুলির মধ্যে এনকোড করা আবশ্যক এমনকি এমন সিস্টেমে যেগুলি সাধারণত খণ্ড বা অ্যাঙ্কর শনাক্তকারীদের সাথে ডিল করে না, যাতে ইউআরএল অন্য সিস্টেমে অনুলিপি করা হয় যা সেগুলি ব্যবহার করে, তবে ইউআরএল এনকোডিং পরিবর্তন করার প্রয়োজন হবে না।

Comments

1738 2396. দ্বারা superceeded হয়েছে ietf.org/rfc/rfc2396.txt যে বর্তমান উরি স্পেসিফিকেশন হয়। যদিও এই ক্ষেত্রে এটি বিবেচনা করে না।

— স্টিভ সিভেনেন্স

3996 দ্বারা 2396 কে বরখাস্ত করা হয়েছে FC আরএফসি অপরিবর্তনীয় বলে অনেক লোক এটিকে ভুল বলে মনে করে এবং তাই পাঠককে বলে না যে তারা অপ্রচলিত। ইঙ্গিত: টিউনস.ইএইটিএফ.আর.এইচ.টি.এল. / আরএফসিএনএন , যেমন সরঞ্জাম.এইটিএফ.আর.এফ.এইচটিএমএল / আরএফসি 2396 এর পরিবর্তে এটি নিখোঁজ মেটাডেটা প্রদর্শন করে।

— জুলিয়ান রেসকে

Answer 2

কেন এটি এনকোড করতে হবে? একটি অনুরোধ এর মতো দেখাচ্ছে:

GET /url HTTP/1.1
(Ignoring headers)

একটি সাদা স্থান দ্বারা পৃথক 3 ক্ষেত্র আছে। আপনি যদি আপনার ইউআরএলে একটি স্থান রাখেন:

GET /url end_url HTTP/1.1

আপনি জানেন যে 4 টি ক্ষেত্র রয়েছে, HTTP সার্ভার আপনাকে বলবে এটি একটি অবৈধ অনুরোধ।

GET /url%20end_url HTTP/1.1

3 ক্ষেত্র => বৈধ

দ্রষ্টব্য: ক্যোরি স্ট্রিংয়ে (পরে?), একটি স্পেস সাধারণত + হিসাবে এনকোড থাকে

GET /url?var=foo+bar HTTP/1.1 

বরং

GET /url?var=foo%20bar HTTP/1.1 

Comments

যদি var সত্যিই "foo + বার" এবং "foo বার" না হত?

— Ivo3185

আমি যুক্তি দিয়ে বলব যে এটি ইউআরআই স্পেসিফিকেশন নয়, পরিবহন স্তরের প্রয়োজনীয়তা। GET স্পষ্টতই http: স্পেসিফিকেশনের সম্পত্তি, URL স্পেসিফিকেশন নয়। একইভাবে আপনি ইউআরএলগুলিতে "অবশ্যই" এনকোড থাকা উচিত কারণ অন্যথায় ওয়েব পৃষ্ঠাগুলি ভেঙে যায় ar তবে এটি এইচটিএমএল ফর্ম্যাটিং সীমাবদ্ধতার সম্পত্তি, (যার বিরুদ্ধে অন্যান্য কৌশল রয়েছে), ইউআরএল স্পেসিফিকেশনের সম্পত্তি নয়।

— কেন্ট ফ্রেড্রিক

ietf.org/rfc/rfc1738.txt - স্থান সহ অসুরক্ষিত অক্ষরগুলি এনকোড করা উচিত

— জুলিয়েন

@ কেন্টফ্রেড্রিক এটি সম্ভবত উপস্থাপনা স্তর, পরিবহন স্তর নয়। হিসাবে জুলিয়েন (প্রায়) লিখছেন, অরিজিনাল URI বৈশিষ্ট ( বোঝায় যা RFC 1630 ) তাই এটা কোনো URI স্পেসিফিকেশন নিজেই একটা অংশ আপনার ব্যক্তিগত অনুভূতি নির্বিশেষে, এই সীমাবদ্ধতা রয়েছে। যেহেতু ইউআরআই স্পেকটি এইচটিটিপি খসড়াগুলির পরে রচিত হয়েছিল , এটি খুব সম্ভব যে ইউআরআইগুলি স্থান ব্যবহারের বিরুদ্ধে নিষেধাজ্ঞাসহ এইচটিটিপিকে মাথায় রেখে ডিজাইন করা হয়েছিল, তবে এটি সত্যিকার অর্থে কোনও ব্যাপার না, তাই না? সত্য কথাটি হচ্ছে অনুমানটি কী তা অনুমান করা হয়।

— ক্রিস্টোফার শুল্টজ

Answer 3

সংক্ষিপ্ত উত্তর: না, আপনাকে অবশ্যই একটি স্থান এনকোড করতে হবে; এটি কোনও স্থান হিসাবে এনকোড করা সঠিক +, তবে কেবল ক্যোরিয় স্ট্রিংয়ে; আপনি অবশ্যই ব্যবহার করতে হবে %20।

Comments

হাই, আমিও বিভ্রান্ত হয়ে পড়েছি, কিছু সময় আমি বইটি "+" ব্যবহার করতে দেখেছি তবে কিছু সময় "% 20" ব্যবহার করতে পেরেছি, আপনি কি এর জন্য কিছু উদাহরণ প্রদর্শন করতে পারেন? ব্যবহারকারী ফর্মটি জমা দেওয়ার সময়, ফর্মটি স্থানটিকে কীভাবে এনকোড করবে? কোন চরিত্রের সাথে?

— GMsoF

অতিরিক্ত বিশদের জন্য এই উত্তরটি দেখুন ।

— ডেভিডআরআর

খণ্ড / হ্যাশ অংশ সম্পর্কে কি? কীভাবে স্থানগুলি এনকোড করা উচিত?

— gumkins

@ গুমকিনস: খণ্ডটি (# এবং পরে) সার্ভারে প্রেরণ করা হয় না। অনুশীলনে, কোনও স্থান এনকোড করতে আপনি% 20 বা + যে কোনও জায়গায় ব্যবহার করতে পারেন।

— জুলিয়েন

Answer 4

ইউআরএলগুলি আরএফসি 3986 - এ সংজ্ঞায়িত করা হয়েছে , যদিও অন্যান্য আরএফসিগুলি প্রাসঙ্গিক তবে আরএফসি 1738 অপ্রচলিত।

তাদের অনেকগুলি চরিত্রের সাথে তাদের মধ্যে ফাঁকা স্থান নাও থাকতে পারে। যেহেতু এই নিষিদ্ধ চরিত্রগুলিকে প্রায়শই কোনও উপায়ে উপস্থাপন করা প্রয়োজন, তাই তাদের "AS" উপসর্গের সাথে তাদের ASCII হেক্সাডেসিমাল সমতুল্যে অনুবাদ করে একটি URL এ এনকোড করার জন্য একটি পরিকল্পনা রয়েছে।

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

Answer 5

হ্যাঁ, স্থানটি যদিও সাধারণত "% 20" এ এনকোড করা থাকে। কোনও URL এ পাস হওয়া কোনও প্যারামিটার কেবল সুরক্ষার কারণেই এনকোড করা উচিত।

Answer 6

ইউআরএলের একটি স্পেস ক্যারেক্টার থাকতে পারে এবং এগুলি বেশিরভাগ ব্রাউজারে% 20 হিসাবে প্রদর্শিত হবে তবে ব্রাউজারের এনকোডিংয়ের নিয়মগুলি প্রায়শই পরিবর্তিত হয় এবং কোনও ব্রাউজার কীভাবে ইউআরএল প্রদর্শন করবে তার উপর আমরা নির্ভর করতে পারি না।

সুতরাং পরিবর্তে আপনি ইউআরএলটিতে স্পেস ক্যারেক্টারটি এমন কোনও অক্ষরের সাথে প্রতিস্থাপন করতে পারেন যা আপনি মনে করেন যে ইউআরএলকে আরও পঠনযোগ্য এবং 'সুন্দর' করা হবে;) ..... হে এত সাধারণ চরিত্রগুলি যা পছন্দসই হয় "-", "_", "+" .... তবে এগুলি বাধ্যবাধকতা নয় তাই আপনি এমন কোনও চরিত্র ব্যবহার করতে পারেন যা ইতিমধ্যে ইউআরএলে থাকা উচিত নয়।

দয়া করে%, &,}, {,], [, /,>, <কে URL স্পেস ক্যারেক্টার রিপ্লেসমেন্ট হিসাবে এড়িয়ে চলুন কারণ তারা নির্দিষ্ট ব্রাউজার এবং প্ল্যাটফর্মগুলিতে কোনও ত্রুটি তুলতে পারে।

আপনি দেখতে পাচ্ছেন যে স্টাকের ওভারফ্লো নিজেই '-' অক্ষরটি স্থান (% 20) প্রতিস্থাপন হিসাবে ব্যবহার করে।

একটি শুভ প্রশ্ন আছে।

Answer 7

ইউআরএলগুলিতে স্পেস থাকা উচিত নয় । আপনার যদি এমন কোনও ঠিকানার প্রয়োজন হয় তবে এর এনকোডযুক্ত মানটি ব্যবহার করুন%20

Answer 8

কেউ কি কোনও আরএফসির দিকে ইঙ্গিত করতে পারে যে কোনও স্থান সহ একটি URL অবশ্যই এনকোড করা উচিত?

ইউআরআই এবং ইউআরএলগুলি আরএফসি 3986-এ সংজ্ঞায়িত করা হয়েছে।

যদি আপনি সেখানে সংজ্ঞায়িত ব্যাকরণটি লক্ষ্য করেন তবে আপনি অবশেষে লক্ষ করবেন যে কোনও স্থান অক্ষর কখনই সিন্ট্যাক্টিক্যালি আইনী ইউআরএল এর অংশ হতে পারে না, সুতরাং "স্পেস সহ ইউআরএল" শব্দটি নিজের মধ্যে বৈপরীত্য।

Answer 9

আপনার প্রশ্নের উত্তর দিতে। আমি বলব যে অ্যাপ্লিকেশনগুলিতে ইউআরএল-এ ব্যবহৃত হবে এমন মানগুলিতে শূন্যস্থান প্রতিস্থাপন করা মোটামুটি সাধারণ। এর কারণটি হ'ল ইউসুয়ালি হ'ল শতাংশ (ইউআরআই) এনকোডিংটি পড়তে আরও বেশি অসুবিধা এড়ানো।

পারসেন্ট-এনকোডিং সম্পর্কে এই উইকিপিডিয়া নিবন্ধটি দেখুন ।

Answer 10

ফায়ারফক্স 3 %20ইউআরএলগুলিতে অ্যাড্রেস বারের স্পেস হিসাবে প্রদর্শন করবে ।

Comments

এই বেশ সহজবোধ্য প্রশ্নের যথাযথ উত্তর নয়: "Is a URL allowed to contain a space?"। বরং একটি মন্তব্য।

— রোকো সি বুলজান