ইউআরএল কেস সংবেদনশীল হওয়া উচিত?

284

আমি লক্ষ্য করেছি

HTTP://STACKOVERFLOW.COM/QUESTIONS/ASK

এবং

http://stackoverflow.com/questions/ask

উভয়ই সূক্ষ্মভাবে কাজ করে - পূর্ববর্তীটি লোয়ারকেসে রূপান্তরিত হয়।

আমি মনে করি এটি ব্যবহারকারীর জন্য অর্থবোধ করে।

আমি যদি গুগলের দিকে তাকাই তবে এই ইউআরএলটি ভাল কাজ করে:

http://www.google.com/intl/en/about/corporate/index.html

তবে "ABOUT" সহ এটি একটি কাজ করছে না:

http://www.google.com/intl/en/ABOUT/corporate/index.html

ইউআরএল কি মামলা সংবেদনশীল হওয়া উচিত?

url case-sensitive

— Imageree
সূত্র

13

আইএমএইচও, ইউআরএল কখনই সংবেদনশীল হওয়া উচিত নয়, এটি কেবল তাদের জন্য জীবনকে শক্ত করে তোলে যারা এটি ব্যবহার করবে।

— মুহাম্মদ উমার

16

প্রশ্ন "সংবেদনশীল হওয়া উচিত ইউআরএলস?" এটি একটি খারাপ প্রশ্ন কারণ এটি মতামত প্রার্থনা করে। বরং আরও ভাল প্রশ্নটি হবে, "ইউআরএলগুলি কেস-সংবেদনশীল কেন? (বা কেন হয় না)?" বা "কিছু ইউআরএল কেস-সংবেদনশীল কেন অন্যরা নয়?"

— ছারভে

তবে একটি সম্ভাব্য উত্তরের জন্য, WHATWG- র নতুন ইউআরএল স্ট্যান্ডার্ডটি দেখুন , যা নোড.জেএস দ্বারা গৃহীত হয়েছে ।

— ছারভে

আমার মতে, তাদের উচিত হবে না

— অ্যান্ড্রু

ব্রাউজার যদি কেসটিকে সম্মান না জানায়, আইপিএফএস ঠিকানাটি নষ্ট হয়ে যাবে, তবে এটি ভেঙে যায়নি

— বিনো টুং

281

ডাব্লু 3 এর " এইচটিএমএল এবং ইউআরএল " অনুযায়ী তাদের উচিত:

ইউআরএল, বা ইউআরএল এর কিছু অংশ থাকতে পারে, যেখানে কেস গুরুত্বপূর্ণ নয়, তবে এগুলি সনাক্ত করা সহজ নাও হতে পারে। ব্যবহারকারীদের সর্বদা বিবেচনা করা উচিত যে URL গুলি কেস-সংবেদনশীল।

— jldupont
সূত্র

95

আমার ধারণা "আপনি যা প্রেরণ করেন তাতে উদার হন এবং আপনি যা প্রেরণ করেন তাতে রক্ষণশীল" (আইইটিএফ বক্তৃতা) হবে আমার গাইডলাইন।

— jldupont

9

ডাব্লু 3 নির্দেশিকা যুক্তিসঙ্গত। এটি সহজভাবে জানিয়েছে যে আপনি যে URL টি জমা দিচ্ছেন তা সার্ভার কীভাবে পরিচালনা করে সে সম্পর্কে কেউ অনুমান করা উচিত নয়। অনুরোধ URL টি কীভাবে পরিচালনা করবেন এটি সার্ভারের উপর নির্ভর করে। বেশিরভাগ ওয়েব সার্ভারগুলি ইউনিক্স / লিনাক্স এবং এর অর্থ বেশিরভাগ ওয়েব সার্ভার ক্ষেত্রে সংবেদনশীল।

— oᴉɹǝɥɔ

37

ডাব্লু 3 বলেছে যে ইউএসআরএসকে ধরে নেওয়া উচিত যে সার্ভারগুলি কেস-সংবেদনশীল, তবে সার্ভারগুলির জন্য কোনও সুপারিশ দেয় না।

— trysis

3

স্থিতিস্থাপকতার জন্য, ইউআরএলগুলি ব্যাখ্যা করে এমন প্রোগ্রামগুলিকে স্কীমের নামগুলিতে ছোট ছোট অক্ষরের সমতুল্য হিসাবে বড় হাতের অক্ষর হিসাবে বিবেচনা করা উচিত (যেমন, "এইচটিটিপি" পাশাপাশি "HTTP" অনুমতি দিন) allow উত্স

— রিয়েলপিকে

3

@ পি কে_ দ্রষ্টব্য যে এটি কেবলমাত্র URL এর স্কিম অংশের জন্য রয়েছে । আরএফসি 1738 ইউআরএলের অন্যান্য অংশগুলি কেস সংবেদনশীল হিসাবে ব্যাখ্যা করা উচিত কিনা তা নিয়ে আলোচনা করে না।

— dthrasher

126

সমস্ত " সংবেদনশীল " গুলি পাঠযোগ্যতার জন্য সাহসী।

আরএফসি 4343 অনুযায়ী ডোমেনের নামগুলি সংবেদনশীল । বাকি URL টি GET পদ্ধতির মাধ্যমে সার্ভারে প্রেরণ করা হয়। এটি কেস সংবেদনশীল হতে পারে বা নাও হতে পারে।

উদাহরণস্বরূপ এই পৃষ্ঠাটি ধরুন, স্ট্যাকওভারফ্লো ডটকম আপনার ব্রাউজারে এইচটিএমএল নথি প্রেরণ করে জিইটি স্ট্রিং / প্রশ্নগুলি / 7996919 / হওয়া উচিত - url-be-be-ਕੇਸ সংবেদনশীল । স্ট্যাকওভারফ্লো ডট কম ক্ষেত্রে সংবেদনশীল কারণ এটি / ক্যোসেশনস / 7996919 / স্টাড-ইউআরএল-কেস-সংবেদনশীলদের জন্য একই ফলাফল তৈরি করে ।

অন্যদিকে, উইকিপিডিয়া শিরোনামের প্রথম অক্ষর বাদে কেস সংবেদনশীল। ইউআরএলস https://en.wikedia.org/wiki/Case_ সেনসিটিভিটি এবং https://en.wikedia.org/wiki/ केस_ সংবেদনশীলতা একই নিবন্ধটি বাড়ে, তবে https://en.wikedia.org/wiki/CASE_SENSITIVITY ফেরত 404।

— jdh8
সূত্র

7

উইকিপিডিয়া প্রকৃত ক্ষেত্রে কেস-সংবেদনশীলতার জন্য খুব ক্ষমা করছে যেখানে ব্যবহারকারীরা মনে করতে পারে যে কোনও শব্দ একটি বা অন্য একটি হওয়া উচিত, তবে এটি OCD এর কারণে বেশি ... দুঃখিত, এর সম্পাদকদের বিবেচ্য প্রকৃতি। যদিও এর URL গুলি প্রযুক্তিগতভাবে ক্ষেত্রে সংবেদনশীল।

— trysis

14

এটি কারণ যে স্ট্যাকওভারফ্লোতে কোনও প্রশ্নের URL এর অর্থপূর্ণ, পঠনযোগ্য অংশ এটি সনাক্ত করে না, এটি দ্বারা চিহ্নিত করা হয়েছে 7996919। ইউআরএলটির অর্থগত অংশটি এসইওর উদ্দেশ্যে রয়েছে।

— ব্যবহারকারী 3367701

4

প্রকৃতপক্ষে /programming/7996919/should-BLABLA-be-or-NOT-to-be কাজ করে। এটি কারণ স্ট্যাকওভারফ্লো ডটকমের সার্ভারটি এটির সনাক্ত করতে এবং সঠিক ইউআরএল এবং এইচটিএমএল পৃষ্ঠা ফেরত দিতে কেবল প্রশ্নের আইডি ব্যবহার করে।

— বোজি

72

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

— জিম নট
সূত্র

1

হ্যাঁ, এটি ইউনিক্স এফটিপি সার্ভারের ফাইলগুলির HTTP অনুরোধে বেদনাদায়কভাবে খুঁজে পেয়েছে।

— লরি স্টারন

1

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

— ভ্যালেন্টিন ওয়েজিলিঙ্ক

31

কোনও ইউআরএল এর ডোমেন নামের অংশটি সংবেদনশীল নয় যেহেতু ডিএনএস কেস উপেক্ষা করে: http://en.example.org/এবং HTTP://EN.EXAMPLE.ORG/উভয়ই একই পৃষ্ঠাটি খুলবে।

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

যদি সার্ভারটি কেস সংবেদনশীল এবং http://en.example.org/wiki/URLসঠিক হয় , তবে এই URL গুলি বৈধ সংস্থাগুলি নিজেই নির্দেশ না করে http://en.example.org/WIKI/URLবা http://en.example.org/wiki/urlএকটি HTTP 404 ত্রুটি পৃষ্ঠা প্রদর্শন করবে।

— ভাভিন শাহ
সূত্র

3

এই উত্তরের একমাত্র সঠিক শব্দটি রয়েছে "এটি কেস-সংবেদনশীল, যদিও এটি কেস-সংবেদনশীল হিসাবে বিবেচনা করা যেতে পারে"। শুধুমাত্র বৈধ উত্তর।

— ড্যানিয়েল ডাব্লিউ।

@ ড্যানফ্রমজার্মিনি, পথটি কেস-সংবেদনশীল এখান থেকে অস্পষ্টভাবে অনুমিত করা যায় "সাধারণভাবে ইউআরএলগুলি কেস-সংবেদনশীল (মেশিনের নাম বাদে) হতে পারে। ইউআরএল বা ইউআরএল এর কিছু অংশ থাকতে পারে, যেখানে কেস গুরুত্বপূর্ণ নয়, তবে চিহ্নিত করা যায় এগুলি সহজ নাও হতে পারে। " তবে, এটি অনুমান করা অস্পষ্ট। উপরের একটি মন্তব্যে উল্লিখিত হিসাবে, আরএফসি 1738 আলোচনা করে না যদি স্কিম ব্যতীত ইউআরএলটির কিছু অংশ সংবেদনশীল হিসাবে ব্যাখ্যা করা উচিত বা না discuss ইউআরএলের কোন অংশগুলি কেস-সংবেদনশীল তা স্পষ্ট করে আপনার কোনও লিঙ্ক রয়েছে?

— গারনেট

2

@ গারনেট আরএফসি 3986 থেকে 6.2.2.1। কেস নরমালাইজেশন : যখন কোনও ইউআরআই জেনেরিক সিনট্যাক্সের উপাদানগুলি ব্যবহার করে, উপাদান সিনট্যাক্সের সমতুল্য বিধি সর্বদা প্রয়োগ হয়; যথা, যে স্কিম এবং হোস্টটি কেস-সংবেদনশীল এবং সেহেতু ছোট হাতের কাছে স্বাভাবিক করা উচিত। উদাহরণস্বরূপ, ইউআরআই HTTP://www.EXAMPLE.com/সমান http://www.example.com/। অন্যান্য জেনেরিক সিনট্যাক্স উপাদানগুলি কেস-সংবেদনশীল বলে ধরে নেওয়া হয় যদি না অন্যথায় স্কিম দ্বারা অন্যথায় সংজ্ঞায়িত করা হয়। "

— ড্যানিয়েল ডাব্লু।

2

@garnet এবং এইচটিটিপি আরএফসি থেকে : " দুটি ইউআরআইয়ের তুলনা করার সময় তারা মিলছে কিনা তা নির্ধারণ করার জন্য, একজন ক্লায়েন্টকে পুরো ইউআরআইয়ের সাথে কেস-সেনসেটিভ অষ্টেট-বাই-অক্টেটের তুলনা ব্যবহার করা উচিত [...] " (স্কিম ব্যতীত এবং নিজেই হোস্ট করুন)।

— ড্যানিয়েল ডাব্লু।

15

আমি পুরানো নিবন্ধগুলি ঘায়েল করার অনুরাগী নই তবে কারণ এই নির্দিষ্ট ইস্যুটির জন্য এটি প্রথম প্রতিক্রিয়াগুলির মধ্যে একটি কারণ আমি কিছু স্পষ্ট করার প্রয়োজন অনুভব করেছি।

@ ভাবিন শাহ উত্তর যেমনটি বলেছে যে ইউআরএলটির ডোমেন অংশটি সংবেদনশীল নয়

http://google.com

এবং

http://GOOGLE.COM

এবং

http://GoOgLe.CoM

সমস্ত একই তবে ডোমেন নাম অংশের পরে সবকিছু কেস সেনসিটিভ হিসাবে বিবেচনা করা হয়।

তাই ...

http://GOOGLE.COM/ABOUT

এবং

http://GOOGLE.COM/about

ভিন্ন.

দ্রষ্টব্য: আমি "প্রযুক্তিগতভাবে" কথা বলছি এবং অনেক ক্ষেত্রে "আক্ষরিক" নয়, বেশিরভাগ প্রকৃতপক্ষে, সার্ভারগুলি এই আইটেমগুলি হ্যান্ডেল করার জন্য সেটআপ করা হয়, তবে সেগুলি সেট আপ করা সম্ভব হয় যাতে সেগুলি একইভাবে পরিচালিত হয় না।

বিভিন্ন সার্ভার এটিকে ভিন্নভাবে পরিচালনা করে এবং কিছু ক্ষেত্রে তাদের কেস সংবেদনশীল হতে হয়। অনেক ক্ষেত্রে ক্যোয়ারী স্ট্রিংয়ের মানগুলি এনকোড করা হয় (যেমন সেশন আইডি বা বেস64 এনকোডড ডেটা যা ক্যোয়ারী স্ট্রিংয়ের মান হিসাবে পাস হয়েছে) এই আইটেমগুলি তাদের প্রকৃতির দ্বারা সংবেদনশীল তাই সার্ভারকে হ্যান্ডল করার ক্ষেত্রে সংবেদনশীল হতে হবে।

সুতরাং এই প্রশ্নের উত্তর দেওয়ার জন্য, "সার্ভারগুলি" এই ডেটাটি ধরার ক্ষেত্রে সংবেদনশীল হওয়া উচিত, উত্তরটি "হ্যাঁ, খুব অবশ্যই"।

অবশ্যই সবকিছু সংবেদনশীল হওয়ার দরকার নেই তবে সার্ভারটি সে কী এবং কীভাবে এই কেসগুলি পরিচালনা করতে হবে সে সম্পর্কে সচেতন হওয়া উচিত।

@ হার্ট সিমার মন্তব্য মূলত একই কথা বলে। আমি পোস্ট করার আগে এটি মিস করেছি তাই আমি যেখানে creditণ দেওয়ার দরকার সেখানে creditণ দিতে চাই।

— কেনেথ গারজা
সূত্র

7

অধ্যায় 2.7.3: স্পেসিফিকেশন এখানে তাকান http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-25#page-19

স্কিম এবং হোস্টটি কেস-সংবেদনশীল এবং সাধারণত লোয়ারকেসে সরবরাহ করা হয়; অন্যান্য সমস্ত উপাদান কেস-সংবেদনশীল পদ্ধতিতে তুলনা করা হয়।

— নিতিন
সূত্র

3

নিম্নোক্ত বিবেচনা কর:

https://www.example.com/createuser.php?name=Paul%20McCartney

এই কাল্পনিক উদাহরণটিতে, একটি এইচটিএমএল ফর্ম - জিইটি পদ্ধতি ব্যবহার করে - "নাম" প্যারামিটারটি একটি পিএইচপি স্ক্রিপ্টে প্রেরণ করে যা একটি নতুন ব্যবহারকারী অ্যাকাউন্ট তৈরি করে।

এবং আমি এই উদাহরণটি দিয়ে যা বলছি তা হ'ল "ম্যাককার্টনি" এর মূলধন সংরক্ষণ করার জন্য এই জিইটি প্যারামিটারটি কেস-সংবেদনশীল হওয়া দরকার (বা অন্য উদাহরণ হিসাবে, "ওয়াল্টার ডি'সনি" সংরক্ষণ করার জন্য, যেমন অন্যান্য উপায় রয়েছে নামগুলির জন্য সাধারণ মূলধন বিধি ভাঙার জন্য)।

এটি এর মতো কেস যা ডাব্লু 3 সি সুপারিশকে গাইড করে যে এই স্কিম এবং হোস্ট ক্ষেত্রে সংবেদনশীল নয়, তবে তার পরে সমস্ত কিছুই সম্ভাব্য ক্ষেত্রে সংবেদনশীল - এবং এটি সার্ভারে ছেড়ে দেওয়া হয়েছে। স্ট্যান্ডার্ড দ্বারা কেস সংবেদনশীলতা জোর করা উপরের উদাহরণটি জিইটি ক্যোয়ারী প্যারামিটার হিসাবে পাস হওয়া ব্যবহারকারী ইনপুট কেস সংরক্ষণে অক্ষম করে তোলে।

তবে আমি যা বলব তা হ'ল যদিও এই জাতীয় মামলাগুলি এ জাতীয় কেসগুলিকে সামঞ্জস্য করার জন্য প্রয়োজনীয়, তবে আইনের চেতনাটি হ'ল, যেখানে মামলাটি অপ্রাসঙ্গিক, কোনও ক্ষেত্রে সংবেদনশীল পদ্ধতিতে আচরণ করা। মানদণ্ডগুলি, যদিও ক্ষেত্রেটি অপ্রাসঙ্গিক তা আপনাকে বলতে পারে না কারণ, আমি যে উদাহরণ দিয়েছি তা এটি একটি প্রাসঙ্গিক নির্ভর জিনিস।

(যেমন কোনও অ্যাকাউন্টের ব্যবহারকারীর নামটি সম্ভবত সংবেদনশীলতার ক্ষেত্রে সবচেয়ে ভালভাবে বাধ্য করা হয়েছে - "ব্যবহারকারী 123" এবং "ব্যবহারকারী 123" হিসাবে বিভিন্ন অ্যাকাউন্ট হ'ল বিভ্রান্তিকর প্রমাণ হতে পারে - এমনকি যদি তাদের আসল নামটি উপরে বর্ণিত হয় তবে এটি বাম ক্ষেত্রে সবচেয়ে সংবেদনশীল))

কখনও কখনও এটি প্রাসঙ্গিক, বেশিরভাগ সময় এটি হয় না। তবে এই বিষয়গুলি সিদ্ধান্ত নেওয়ার জন্য এটি সার্ভার / ওয়েব বিকাশকারীকে ছেড়ে দিতে হবে - এবং মান অনুসারে নির্ধারিত হতে পারে না - কেবলমাত্র সেই স্তরেই প্রসঙ্গটি জানা যেতে পারে।

স্কিম এবং হোস্ট হ'ল কেস সংবেদনশীল (যা কেস সংবেদনশীলতার জন্য মানের পছন্দকে দেখায়, যেখানে এটি সর্বজনীনভাবে নির্ধারিত হতে পারে)। বাকিগুলি আপনার সিদ্ধান্তটি ঠিক রেখে দেওয়া হয়েছে, আপনি প্রসঙ্গটি আরও ভালভাবে বুঝতে পারছেন। তবে, যেমনটি আলোচনা করা হয়েছে, আপনার সম্ভবত আইনটির চেতনা অনুসারে সংবেদনশীলতা অবলম্বন করা উচিত যদি না আপনি যদি না চান তবে ভাল কারণ নেই।

— দোলক
সূত্র

কোয়েরি স্ট্রিংগুলি কি স্থানের অংশ হিসাবে বিবেচিত হয়? আমি বিশ্বাস করি যে এগুলিকে পৃথক সত্তা হিসাবে বিবেচনা করা হবে এবং অবস্থানের সমাধানের জন্য ব্যবহার করা হবে না।

— jpmc26

প্রশ্নগুলির স্ট্রিংগুলি অবস্থান থেকে পৃথক, হ্যাঁ। তবে ক্যোয়ারী প্যারামিটারগুলি সহ আমি সেখানে যে একই নীতিগুলি দেখিয়েছি তা URL এর অন্যান্য অংশেও প্রয়োগ হতে পারে। কিছু সিএমএস, উদাহরণস্বরূপ, উন্নত এসইও-বান্ধব মানব-পঠনযোগ্য ইউআরএলগুলির জন্য "/user.php?id=3756" "/ ব্যবহারকারী / পলম্যাককার্টনি" তে উদ্দেশ্যমূলকভাবে আবার লিখতে পারে (উদাহরণস্বরূপ ওয়ার্ডপ্রেস এটি করে)। মুল বক্তব্যটি হ'ল মানগুলি ইচ্ছাকৃতভাবে প্রেসক্রিপশন থেকে প্রাসঙ্গিক-নির্ভর উপর নির্ভর করে ফিরে আসে। এটি সার্ভারের কাছে ছেড়ে দেওয়ার সিদ্ধান্ত নেওয়া হয়েছে, যেমন সার্ভারটি প্রসঙ্গটি বোঝে, যেখানে সর্বজনীন মানক পারে না।

— বব

2

ইউআরএলগুলি সংক্ষিপ্ত সংবেদনশীল হওয়া উচিত যদি না তাদের কারণ না হওয়ার কোনও ভাল কারণ না থাকে।

এটি বাধ্যতামূলক নয় (এটি কোনও আরএফসির কোনও অংশ নয়) তবে এটি ইউআরএলগুলির যোগাযোগ এবং সঞ্চয়স্থানকে আরও নির্ভরযোগ্য করে তুলেছে।

যদি আমার কোনও ওয়েবসাইটে দুটি পৃষ্ঠা থাকে:

http://stackoverflow.com/ABOUT.html

এবং

http://stackoverflow.com/about.html

কিভাবে তাদের পার্থক্য করা উচিত? হতে পারে একটি 'চিৎকার শৈলী' (ক্যাপস) লিখিত - তবে আইএ দৃষ্টিকোণ থেকে, ইউআরএল-এর ক্ষেত্রে কোনও পার্থক্য করা উচিত নয়।

তদুপরি, অ্যাপাচিতে এটি কার্যকর করা সহজ - কেবলমাত্র CheckSpelling Onmod_Speling থেকে ব্যবহার করুন ।

— konchog
সূত্র

0

পুরানো প্রশ্ন কিন্তু আমি এখানে হোঁচট খেয়েছি তাই কেন এটিকে ঘৃণা করবেন না কারণ প্রশ্নটি বিভিন্ন দৃষ্টিকোণ চেয়েছে এবং একটি নির্দিষ্ট উত্তর নয়।

ডাব্লু 3 সি এর সুপারিশ থাকতে পারে - যা আমি অনেক যত্ন নিয়েছি - তবে প্রশ্নটি এখানে থাকায় পুনর্বিবেচনা করতে চাই।

কেন ডাব্লু 3 সি ডোমেন নামগুলি কেস সংবেদনশীল হিসাবে বিবেচনা করে এবং কেস পরে সংবেদনশীল হিসাবে ছেড়ে যায়?

আমি ভাবছি যে যুক্তিটি হ'ল ইউআরএল এর ডোমেন অংশটি কোনও ব্যবহারকারী দ্বারা হাতে টাইপ করা হয়। হাইপার টেক্সট হওয়ার পরে সমস্ত কিছুই মেশিনের মাধ্যমে সমাধান করা হবে (পিছনে ব্রাউজার এবং সার্ভার)।

মেশিনগুলি মানুষের থেকে কেস সংবেদনশীলতার চেয়ে ভাল পরিচালনা করতে পারে (প্রযুক্তিগত নয় :))।

তবে প্রশ্নটি কেবল কারণ মেশিনগুলি হ্যান্ডেল করতে পারে যে এটি সেইভাবে করা উচিত?

আমি বলতে চাইছি hereIsTheResourceবনাম বসে থাকা কোনও সংস্থান নামকরণ এবং অ্যাক্সেস করার সুবিধা কীhereistheresource ?

পার্শ্বটি উটের কেসের চেয়ে বেশি পঠনযোগ্য যা আরও বেশি পঠনযোগ্য। মানুষের কাছে পাঠযোগ্য (প্রযুক্তিগত ধরণের সহ)

সুতরাং এখানে আমার বিষয়গুলি:

রিসোর্স পাথ প্রোগ্রামিং স্ট্রাকচারের মাঝখানে এবং কোথাও ব্রাউজারের পিছনে একটি শেষ ব্যবহারকারীর কাছাকাছি থাকা যায়।

আপনার ইউআরএল (ডোমেন নাম বাদে) ক্ষেত্রে সংবেদনশীল হওয়া উচিত যদি আপনার ব্যবহারকারীরা এটি স্পর্শ করে বা টাইপ করে থাকে ইত্যাদি etc.

আপনার ইউআরএল (ডোমেন নাম বাদে) কেস সংবেদনশীল হওয়া উচিত যদি আপনার ব্যবহারকারীরা কখনই হাত দিয়ে টাইপ না করে।

উপসংহার

পথটি কেস সংবেদনশীল হওয়া উচিত। আমার পয়েন্টগুলি কেস সেনসিটিভ পাথের দিকে ঝুঁকছে।

— bhantol
সূত্র

0

ইউআরএল অক্ষরগুলি হেক্স কোডে রূপান্তরিত হয় (যদি আপনি কখনই ইউআরএলগুলিতে% 20 ইত্যাদি হিসাবে প্রদর্শিত হচ্ছে তা লক্ষ্য করেছেন) এবং যেহেতু লোয়ার এবং আপার ক্ষেত্রে পৃথকভাবে হেক্স মান রয়েছে, এটি সঠিক ধারণা দেয় যে URL গুলি অবশ্যই স্পষ্টভাবে সংবেদনশীল। তবে প্রশ্নের স্পিরিটটি মনে করা উচিত যে এটি মানক এবং আমি না বলি, তবে তারা। এটি যদি কোনও শেষ ব্যবহারকারীর জন্য নির্বিশেষে কাজ করতে চায় তবে তাদের কোডগুলিতে এটি অ্যাকাউন্টে বিকাশকারী / সরবরাহকারীর উপর নির্ভর করে।

— অতিথি
সূত্র

এটি একটি আকর্ষণীয়। নিয়মিত ই ASCII অক্ষর (যার উপরের এবং নিম্নতর কেস থাকে) আসলে ঠিক কি রূপান্তরিত হয় না? এটি কেবল শূন্যস্থান এবং বর্ধিত অক্ষর যা ইউআরএল থেকে রক্ষা পেয়েছে। কোন বর্ধিত অক্ষর একটি উচ্চ / নিম্ন কেস সংশোধক আছে?

— টাইগারক্র্যাশ

0

আমি মনে করি এটি এবং অনুমানগুলি যা বলে না তার চারপাশের অনেক প্রশ্নের প্রশ্নের বিন্দুটি অনুপস্থিত। করা উচিত তারা কেস সংবেদনশীল হতে পারে? এটি আসলে বোঝা প্রশ্ন। ব্যবহারকারীর দৃষ্টিকোণ থেকে, কেস সংবেদনশীলতা একটি ব্যথার বিন্দু, সকলেরই জানা নেই যে কোনও পার্থক্য করে। ইউআরআই হওয়া উচিত কিনা তা প্রশ্নটির প্রসঙ্গে নির্ভর করে। প্রযুক্তিগত নমনীয়তার জন্য, হ্যাঁ, তাদের হওয়া উচিত। ব্যবহারের জন্য, না, তাদের হওয়া উচিত নয়।

— rspring1975
সূত্র

ন্যায়সঙ্গতভাবে, "জিজ্ঞাসা করা" জিজ্ঞাসা করা কোনও প্রশ্ন মুলত মতামত ভিত্তিক এবং স্ট্যাকওভারফ্লো থেকে সরানো যেতে পারে । (আরও: stackoverflow.blog/2010/09/29/good-subjective-bad-subjective )

— chharvey

0

কেস সংরক্ষণ

ইউআরএলগুলি ক্লায়েন্ট এবং সার্ভারের মধ্যে কেস-সংরক্ষণ করা হয় । তবে বেশ কয়েকটি কারণে ইউআরএল এর অংশগুলি সার্ভারের উপর নির্ভর করে কেস-সংবেদনশীল হতে পারে বা নাও হতে পারে ।

কেস সংবেদনশীলতা

URL এবং এর নিম্নলিখিত সাহসী অংশগুলি সাইট এবং / অথবা সার্ভার কনফিগারেশনের উপর নির্ভর করে কেস-সংবেদনশীল হতে পারে।

http: // www। উদাহরণ. com /abc/def.ghi?jkl=mno#pqr

ব্যবহারকারী @ উদাহরণ.com

যুক্তিসহ ব্যাখ্যা

URL গুলিতে কেস-সংবেদনশীলতার কয়েকটি ব্যবহার থাকতে পারে uses প্রধানত:

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

একজন বিকাশকারী হিসাবে, আমি বিশ্বাস করি উপরেরগুলি প্রায়শই আরও ভাল উপায়ে পরিচালনা করা যায় তবে আমি আরও বুঝতে পারি এমন পরিস্থিতি রয়েছে যেখানে কোনও পরিস্থিতি এটির অনুমতি দেয় না।

উদাহরণস্বরূপ, একটি বিদ্যমান পণ্যটি কল্পনা করুন যার জন্য "জিইটি" ইউআরএলতে প্রচুর ডেটা রাখা দরকার, তবুও এটি অবশ্যই সমস্ত বড় সার্ভার, ব্রাউজার এবং ক্যাশে / প্রক্সি মেকানিজমের সর্বোচ্চ URL দৈর্ঘ্যের সাথে সামঞ্জস্যপূর্ণ হতে হবে। একটি মাঝারি দৈর্ঘ্যের কমান্ড স্ট্রিংয়ের (কিছু পুরানো ব্রাউজারের জন্য 1,024 অক্ষরের নীচে) ফিট করার জন্য, আপনার প্রতিটি অনন্য URL- নিরাপদ অক্ষর ব্যবহার করতে হবে (যা মূলত বেস64url এনকোডিংটি কী)।

একটি আদর্শ বিশ্বের

URL গুলি কেস-সংবেদনশীল হওয়া উচিত কিনা তা বিতর্কযোগ্য। আমি ব্যক্তিগতভাবে বিশ্বাস করি যে সরলতার জন্য এগুলি হওয়া উচিত নয় (যদিও এটি দীর্ঘতর ইউআরএল তৈরি করতে পারে তবে সহজেই আমাদের কেসগুলি পরিচালনা করতে শতকরা পালাতে হবে যেখানে সঠিক অক্ষরের সংরক্ষণ নিশ্চিত করতে হবে এবং ইউআরএলটিতে ডান ব্যতীত অন্য কোনও ডেটা স্থানান্তর করার উপায় রয়েছে) ।

ব্যবহারযোগ্যতা বাড়াতে কেস-সংবেদনশীল ইউআরএলগুলি অনেক জনপ্রিয় সাইট এবং পরিষেবাদির জন্য স্পষ্টভাবে সক্ষম করা হয়েছে এই সত্যের উপর ভিত্তি করে অনেকেই সম্মত বলে মনে হয়। সর্বাধিক বিশিষ্ট উদাহরণ ইমেল ঠিকানাগুলির ব্যবহারকারীর নাম। বেশিরভাগ ইমেল সরবরাহকারী কেস এবং কখনও কখনও বিন্দু এবং অন্যান্য প্রতীকগুলিকেও উপেক্ষা করবে ("j.smith@example.com" "JSMITH@example.com" এর মতোই)। যদিও অনুমান অনুযায়ী ইমেল ব্যবহারকারীর নামগুলি ডিফল্টরূপে কেস-সংবেদনশীল।

যাইহোক, আসল বিষয়টি হ'ল আমি বা অন্যরা যা চায় তা সত্ত্বেও, বর্তমানে কীভাবে কাজ করছে তার এই অবস্থা। এবং যদিও কেস-সংবেদনশীল ইউআরএল স্ট্যান্ডার্ডে চূড়ান্তভাবে বিশ্বব্যাপী স্থানান্তরিত হওয়া সম্ভব, তবুও সম্ভবত কেস-সংবেদনশীলতাটি বিভিন্ন কারণে ওয়েবের চারপাশে ব্যাপকভাবে ব্যবহৃত হচ্ছে।

সেরা অনুশীলন

যতদূর সেরা অনুশীলনগুলি যায়, একজন ব্যবহারকারী হিসাবে আপনি বেশিরভাগ পরিস্থিতিতে যুক্তিসঙ্গতভাবে ছোট হাতের কাছে আটকে থাকতে পারেন এবং জিনিসগুলি কাজ করার আশা করতে পারেন। প্রধান ব্যতিক্রমগুলি হ'ল ইউআরএলগুলি যা কেস-ভিত্তিক এনকোডিং বা ডাইরেক্ট ফাইল সিস্টেমের সমতুল্য সহ নথির পাথ ব্যবহার করে। তবে, এই জাতীয় জটিল URL গুলি ম্যানুয়ালি টাইপ না করে সাধারণত কপি-পেস্ট করা হয় (বা কেবল ক্লিক করা হয়)।

ওয়েব বিকাশকারী হিসাবে আপনার যতটা সম্ভব URL- কে কেস-সংবেদনশীল হিসাবে বিবেচনা করা উচিত। যদিও উপরে উল্লিখিত হয়েছে, প্রসঙ্গের উপর নির্ভর করে স্পষ্টত কিছু-এড়ানো-এড়ানো পরিস্থিতি রয়েছে।

— Beejor
সূত্র

-1

প্রশ্নটি কী ইউআরএল কেস সংবেদনশীল হওয়া উচিত?

সংবেদনশীল URL এর পিছনে আমি কোনও ব্যবহার বা ভাল অনুশীলন দেখতে পাচ্ছি না। এটি নির্বোধ, এটি সফল হয় এবং সর্বদা এড়ানো উচিত।

আমার মতামতটি ব্যাক আপ করার জন্য, যখন কেউ কোন ইউআরএলকে জিজ্ঞাসা করে, আপনি কীভাবে ব্যাখ্যা করতে পারবেন যে ইউআরএলের কোন অক্ষর উচ্চ বা নিম্নতর হয়? এটি বাজে কথা এবং অন্যথায় কখনও আপনাকে বলা উচিত নয়।

— HenriKoppen
সূত্র

32

সংবেদনশীল হওয়ার ইউআরএলগুলির একটি সুবিধা রয়েছে। কিছু ওয়েবসাইটগুলিতে, যেখানে অবজেক্টগুলি ইউআরএল-এর মাধ্যমে উল্লেখ করা যায় এমন অনন্য আইডি সহ এনকোড করা থাকে, এনকোডিংটি বেস 36 এর পরিবর্তে বেস 64 এর মতো কিছু হতে পারে । এটি আপনাকে একই সংখ্যক ইউআরএল অক্ষরগুলিতে তাত্পর্যপূর্ণভাবে আরও অনন্য অবজেক্টগুলিকে এনকোড করতে দেয়। উদাহরণস্বরূপ, foo.com/000 - foo.com/zzz (কেস সংবেদনশীল) 36 ^ 3 অনন্য অবজেক্টের উল্লেখ করতে পারে, যেখানে foo.com/000 - foo.com/ZZZ (কেস সংবেদনশীল, অর্থ foo.com/zzz এবং foo.com/ZZZ বিভিন্ন পাথ), 62 ^ 3 অবজেক্টের উল্লেখ করবে।

— হার্ট সিমহা

6

এটি কোনও উত্তর নয়, এটি একটি মতামতযুক্ত মন্তব্য।

— টিন ম্যান

1

আমি একটি উদাহরণ সহ এটি ব্যাক আপ। ইউআরএলগুলি লোকেদের দ্বারা ব্যবহৃত হয় - কম্পিউটারগুলি নয় মূল প্রশ্নটি দেখুন। এটি খুব কঠিন তাই দেখুন যে কোনও লিঙ্কটি কেন কাজ করছে না এবং যেহেতু প্রায় সবগুলি ডোমেনই সংবেদনশীল the ডাউনভোটগুলি আমার কণ্ঠের সুরের জন্য (যা খারাপ), বা প্রযুক্তিগত লোকেরা ব্যবহারকারীর অভিজ্ঞতার চেয়ে প্রযুক্তিগত সৌন্দর্য বেছে নেওয়ার প্রবণতা।

— হেনরিকপ্পেন

1

@ থিনম্যান এটি মতামত উত্সাহমূলক প্রশ্নের উত্তর।

— ছারভে

আমি @ হার্টসিংহের সাথে একমত এবং যেহেতু প্রশ্নটি মতামত চেয়েছে: ইউআরএল রুটের কিছু অংশ যদি কোনও অনন্য বস্তু সনাক্ত করতে ব্যবহার না করা হয় তবে দয়া করে ইন্টারনেটে যা কিছু ভাল তা ভালবাসার জন্য দয়া করে এটিকে সংবেদনশীল করবেন না।

— জায়েবরো

-3

লিনাক্স সার্ভারে হোস্ট করা ওয়েবসাইটগুলির জন্য, URL টি সংবেদনশীল। http://www.google.com/about এবং http://www.google.com/About বিভিন্ন স্থানে পুনঃনির্দেশিত হবে। উইন্ডোজ সার্ভারে থাকাকালীন, ইউআরএল কোনও ফোল্ডারের নামকরণের মতো, কেস-সংবেদনশীল এবং একই জায়গায় পুনর্নির্দেশ করা হবে।

— বিষ্ণু
সূত্র

-6

সংবেদনশীল ইউআরএল তৈরি করা সম্ভব make

RewriteEngine on
rewritemap lowercase int:tolower
RewriteCond $1 [A-Z]
RewriteRule ^/(.*)$ /${lowercase:$1} [R=301,L]

গুগল ডট কম..গুগলাল.কম ইত্যাদি গুগল.কম এ সরাসরি তৈরি করা

— রেনজিথ গোপি
সূত্র

এটি প্রশ্নের উত্তর দেয় না

— মনোক্রোম

3

প্রশ্নটি হল: "ইউআরএলটি কেস সংবেদনশীল হওয়া উচিত?" আপনার উত্তরটি হল: "কীভাবে সংবেদনশীল ইউআরএলগুলি তৈরি করবেন"

— রিয়েলপিকে