2008-09-23 14 views
136

यह /about_us या /हमारे बारे में होना चाहिए?यूआरएल: डैश बनाम अंडरस्कोर

उपयोगिता बिंदु से, मैं व्यक्तिगत रूप से सोचता हूं कि /लगभग- अंतिम उपयोगकर्ता के लिए बहुत बेहतर है, फिर भी Google और अधिकांश अन्य वेबसाइटें (और जावास्क्रिप्ट ढांचे) अंडरस्कोर नामकरण पैटर्न का उपयोग करती हैं। क्या यह सिर्फ शैली का मामला है? क्या डैश के साथ कोई संगतता समस्या है?

+4

क्यों नहीं */सूचकांक ____ 1125.aspx * –

+41

ओह, चलो (है कि चार अंडरस्कोर, बहुत महत्वपूर्ण! है)। मुझे इस प्रश्न और उत्तरों में दिलचस्पी है। प्रश्न 52 अपवेट्स है, और आपने इसे बंद कर दिया है? यह प्रोग्रामिंग के बारे में है। वेब प्रोग्रामिंग।विकसित होने वाली वेबसाइट में निर्देशिकाओं का नाम कैसे तय करना है इसका निर्णय लेना। – Kaydell

+3

[ऐसी साइट पर डुप्लिकेट प्रश्न जहां यह समस्या * निश्चित रूप से विषय पर * है।] (Http://webmasters.stackexchange.com/questions/374/urls-should-i-use-hyphens-underscores-or-plus- प्रतीकों) –

उत्तर

26

यह सिर्फ एक अनुमान है, लेकिन यह वे एक उठाया लगता है कि लोगों को सबसे शायद नहीं होगा एक नाम पर उपयोग। इस तरह से आप एक ऐसा नाम प्राप्त कर सकते हैं जिसमें एक हाइफेनेटेड शब्द शामिल हो, और अभी भी अंडरबार को शब्द डेलीमीटर के रूप में उपयोग करें, उदा। UseTwo-wayLinks को use_two-way_links में परिवर्तित किया जा सकता है।

आपके उदाहरण में,/हमारे बारे में/हमारे बारे में हाइफेनेटेड शब्द "about-us" नामक एक निर्देशिका होगी (यदि ऐसा कोई शब्द मौजूद है, और/about_us दो शब्द वाक्यांश "हमारे बारे में" नामित एक निर्देशिका होगी

+10

उचित अनुमान है, लेकिन जैसा कि यह पता चला है, पूरी तरह से असत्य। -1। –

+1

क्या आपके पास @MarkAmery का संदर्भ है? सवाल यह है कि Google अंडरस्कोर का उपयोग क्यों करेगा। यदि आप सुझाव दे रहे हैं कि वे नहीं करते हैं, तो यह उत्तर का मुद्दा नहीं है, लेकिन सवाल का मुद्दा है। – billjamesdev

+1

सबसे पहले, जैसा अनुमान लगता है, काफी उचित है। मैं अनुमान के हिस्से के रूप में जोड़ता हूं कि प्रोग्रामर डैश को घटाव के रूप में उपयोग करते हैं ताकि अंडरस्कोर का उपयोग किया जा सके; शायद प्रोग्रामर द्वारा बनाए गए यूआरएल, उस सम्मेलन का पालन करें। हालांकि एक वास्तविक व्याख्या बेहतर होगी। किसी भी बैकअप के बिना मार्क -1 के साथ बढ़ता है; इच्छा है कि मैं टिप्पणी -1 दे सकता हूं। –

3

मुझे लगता है कि डैश उपयोगकर्ता परिप्रेक्ष्य से बेहतर है और यह एसईओ में हस्तक्षेप नहीं करेगा।

यह सुनिश्चित नहीं है कि अंडरस्कोर सम्मेलन कहां से शुरू हुआ या क्यों।

एक छोटी सी अधिक जानकार debate

2

निजी तौर पर अश्वेत पात्रों में से एक भी स्ट्रिंग के लिए।, मैं या about_us-हमारे बारे में उपयोग करने से बचें चाहते हैं, और बस के बारे में उपयोग करें।

+3

/के बारे में/हमें/नहीं/गंभीरता से/यह/है/यह :) –

+10

और यह आपका समाधान है? ठीक है, "about_our_customers" या "abouts" के असंख्य सेट के बारे में क्या मैं इसके साथ आ सकता हूं जो प्रासंगिक हो सकता है। किसी समस्या को अनदेखा करना! = समाधान। – billjamesdev

+2

'/ delete_answer' के बारे में क्या? –

7

मैं अंडरस्कोर के साथ अधिक सहज हूँ। सबसे पहले, वे मेल variable_names_are_not-subtraction के मेरे नियमित प्रोग्रामिंग अनुभव के साथ, दूसरा, और मुझे विश्वास है कि इसका पहले से ही उल्लेख किया गया है, शब्दों में हाइफ़न हो सकते हैं, लेकिन उनके पास कभी भी अंडरस्कोर नहीं है। वास्तव में बेवकूफ उदाहरण चुनने के लिए, "राष्ट्र-राज्य देश" अलग है रोम "राष्ट्र राज्य देश"। पूर्व "राष्ट्र-राज्यों की भूमि" जैसे कुछ का अनुवाद करता है (सोचो "यह यहां बंदूक देश है! सबसे अच्छा कदम, याहर?"), जबकि उत्तरार्द्ध कभी-कभी समानार्थी शब्दों की सूची जैसा दिखता है। http://example.com/nation-state-country/ का अर्थ http://example.com/nation-state_country/ जैसा नहीं है, और फिर भी, अगर हाइफ़न शब्द में वर्णों के अलावा delimiters/"space" हैं, तो यह कर सकता है। उत्तरार्द्ध वास्तविक उद्देश्य के रूप में अधिक स्पष्ट लगता है, जबकि पूर्व कुछ भी उस सूची की तरह दिखता है, यदि कुछ भी हो।

+1

बस एक साइड नोट, लिस्प या स्कीम पारंपरिक उपयोग चर/फ़ंक्शन नाम जैसी भाषाएं डैश से अलग होती हैं, क्योंकि शून्य किसी अन्य की तरह फ़ंक्शन का पहचानकर्ता है (और वास्तव में, वे पहचानकर्ताओं में बड़े वर्ण सेट की अनुमति देते हैं)। –

1

कुछ पुराने वेब होस्टिंग और DNS सर्वरों में वास्तव में यूआरएल के लिए अंडरस्कोर को पार्स करने में समस्याएं होती हैं, ताकि इन तरह के सम्मेलनों में भाग ले सकें। https://blog.codinghorror.com/of-spaces-underscores-and-dashes/

दोनों को कमियां हैं:

+2

हाँ, लेकिन यह केवल होस्टनाम में है। – Anirvan

11

जेफ इस पर कुछ विचार है। मैं सुझाव दूंगा कि आप एक चुनें और सुसंगत रहें।

+0

+1 क्योंकि यह उल्लेख करता है कि Google इसकी अपेक्षा करता है, जिसे मैं जानता हूं कि यह कैसा दिखता है उससे कहीं अधिक महत्वपूर्ण है। – tj111

5

अंडरस्कोर स्पेस को प्रतिस्थापित करता है जहां व्हाइटस्पेस की अनुमति नहीं है। डैश (हाइफ़न) एक शब्द का हिस्सा हो सकता है, इस प्रकार हाइफ़न वाले शब्दों में शामिल होना जो पहले से ही हाइफ़न शामिल हैं बदसूरत/भ्रमित है।

बुरा:

/low-budget-movies 

अच्छा:

/low-budget_movies 
+32

मुझे इसके साथ असहमत होना है। इन दिनों यह सिर्फ डैश का उपयोग करने के लिए प्रथागत है। गैर प्रोग्रामर अंडरस्कोर दृष्टिहीन अनैतिक पाते हैं। पहले उदाहरण के साथ कुछ भी गलत नहीं है। यह वास्तव में पढ़ने के लिए और अधिक अनुकूल है। – allesklar

+9

अर्थात् आप सही हैं, लेकिन भेद यूआरएल में उपयोग के लिए उपयोगी से अधिक भ्रमित हो सकता है। लोगों को "ए-बी-सी-डी-ई" की तुलना में "ए-बी-सी-डी-ई" याद रखने की अधिक संभावना है। –

+4

गंभीर बुरी सलाह। – Robs

2

अंतिम-उपयोगकर्ता को देखने के लिए मैं पसंद करते हैं "के बारे में-हमें" या "हमारे बारे में" "about_us" नहीं

0

मैं व्यक्तिगत रूप से होगा सभी डैश और अंडरस्कोर से बचें और कोड में camelCase या PascalCase का चयन करें।

ऊंट पर विकिपीडिया लेख इसके मूल के पीछे तर्क का थोड़ा सा बताता है। वे

  1. लेज़ी प्रोग्रामर जो पठनीयता
  2. "ऑल्टो" कुंजीपटल Xerox PARC पर है कि कोई अंडरस्कोर कुंजी था के बारे में _ कुंजी
  3. संभावित भ्रम के लिए पहुँच रहा पसंद नहीं आया के लिए राशि।

यदि उपयोगकर्ता स्ट्रिंग को देखना है तो मैं उपर्युक्त में से कोई भी नहीं करूँगा और "हमारे बारे में" उपयोग करूंगा। या "इसके बारे में" अगर मुझे ऊंट के रूप में जाना पड़ा तो उत्पाद नामों जैसे कुछ क्षेत्रों में सामान्य उपयोग में फैल गया है। यानी थिंकपैड, टीवो

+0

खोज इंजन कैसे पता चलेगा कि कोई शब्द कहां से शुरू होता है या समाप्त होता है? –

+0

खोज इंजन PascalCase के साथ किसी अन्य डिलीमीटर के समान क्यों नहीं होगा, चाहे वह _ हो - या: उस मामले के लिए? –

+1

अच्छी सलाह ... क्या यह प्रश्न कोड के बारे में पूछ रहा था। यूआरएल [आमतौर पर] केस-असंवेदनशील होते हैं, और आमतौर पर लोअरकेस में दिखाए जाते हैं। – Armstrongest

12

मैं हर समय अंडरस्कोर का उपयोग करता था, अब मैं केवल उन वेबसाइटों के हिस्सों के लिए उपयोग करता हूं जो मैं नहीं चाहता कि कोई भी सीधे लिंक, जेएस फाइल, सीएसएस, ... आदि

एक एसईओ बिंदु दृश्य से, घोड़ों के मुंह http://www.mattcutts.com/blog/dashes-vs-underscores/ से विस्तृत स्पष्टीकरण के लिए, डैश इसे संभालने का पसंदीदा तरीका प्रतीत होता है।

अन्य समस्या जो प्रोग्रामर की तुलना में आम जनता के साथ अधिक होती है, यह है कि जब अंडरस्कोर के साथ एक हाइपरलिंक रेखांकित किया जाता है, तो आप अंडरस्कोर नहीं देख सकते हैं। उन्नत उपयोगकर्ता इसे काम करेंगे, लेकिन जो सार्वजनिक शायद नहीं करेगा।

अभी भी डैश के वरीयता में कोड में अंडरस्कोर का उपयोग करें - प्रोग्रामर उन्हें समझते हैं, अन्य लोग नहीं करते हैं।

0

यूआरएल में रिक्त स्थान की अनुमति है, तो आप एक लिंक में "/ हमारे बारे में" का उपयोग कर सकते हैं (हालांकि इसे "/ लगभग% 20us" में एन्कोड किया जाएगा। लेकिन ईमानदार रहें, यह हमेशा व्यक्तिगत वरीयता होगी, इसलिए वहां है कोई वास्तविक जवाब यहाँ दिया जाता है।

मैं परंपरा है कि डैश, शब्दों में दिखाई दे सकता है तो खाली स्थानों को अंडरस्कोर करने के लिए परिवर्तित किया जाना चाहिए के साथ जाना होगा।

35

गूगल अतीत में एक शब्द विभाजक के रूप में रेखांकित का इलाज नहीं किया , जो मैंने सोचा था कि वह बहुत पागल था, लेकिन स्पष्ट रूप से यह अब करता है। इस इतिहास के कारण, डैश को प्राथमिकता दी जाती है। हालांकि अंडरस्कोर अब एक एसईओ बिंदु दृश्य से अनुमत है, मुझे अभी भी लगता है कि डैश सबसे अच्छे हैं।

एक लाभ यह है कि आपका औसत अर्ध-कंप्यूटर-निरक्षर वेब सर्फर कीबोर्ड पर डैश टाइप करने में सक्षम होने की अधिक संभावना है, वे यह भी नहीं जानते कि अंडरस्कोर क्या है।

+9

आपका औसत अर्ध-कंप्यूटर-निरक्षर वेब सर्फर पता बार और खोज के बीच अंतर बताने में सक्षम होने की संभावना नहीं है। आपका औसत उपयोगकर्ता टाइप की तुलना में क्लिक करने की अधिक संभावना है। बस कहना है ' – Armstrongest

+1

Google अभी भी अंडरस्कोर को एक शब्द विभाजक के रूप में नहीं मानता है: http://www.youtube.com/watch?v=AQcSFsQyct8 – Sembiance

8

एसईओ गुरु Jim Westergren tested this एक सख्त एसईओ परिप्रेक्ष्य से 2005 में वापस आया और निष्कर्ष पर आया कि + (प्लस) वास्तव में सबसे अच्छा शब्द डेलीमीटर था। हालांकि, यह उचित प्रतीत नहीं होता है और खोज इंजन के एल्गोरिदम में एक बग के कारण हो सकता है। वह पठनीयता और एसईओ दोनों के लिए - (डैश) की सिफारिश करता है।

3

मैं इस आधार पर डैश पसंद करता हूं कि एक अंडरस्कोर एक लिंक रेखांकित करके कुछ हद तक अस्पष्ट हो सकता है। टेक्स्ट यूआरएल मुख्य रूप से व्याकरणिक रूप से सही होने की बजाय एक नज़र में पहचाने जाने के लिए होते हैं, इसलिए हाइफेनेटेड शब्दों में उपयोग के लिए डैश को संरक्षित करने के लिए तर्क सीमित है।

जहां टेक्स्ट यूआरएल की सटीकता महत्वपूर्ण है, इसे किसी को पढ़ते समय, इस स्थिति में आप किसी स्पेस (या इसके विपरीत) के लिए अंडरस्कोर को भ्रमित नहीं करना चाहते हैं।

ए भी डैश को अधिक सौंदर्यपूर्ण रूप से प्रसन्न करता है, अगर यह किसी भी चीज़ के लिए मायने रखता है।

44

यह सिर्फ बनाम अंडरस्कोर पानी का छींटा नहीं कर रहा है:

  • रिक्त स्थान के साथ पाठ
  • textwithoutspaces
  • इनकोडिंग% 20spaces%% 20in 20URL
  • underscore_means_space
  • पानी का छींटा-साधन-अंतरिक्ष
  • प्लस + ​​मतलब + स्पेस
  • ऊंटकेस
  • PascalCase
  • (और एकल उद्धरण बनाम दोहरे उद्धरण)
  • स्लैश/साधन/अंतरिक्ष
  • dot.means.space
+31

वाइल्ड वाइल्ड वेब में आपका स्वागत है! –

147

From Google Webmaster Central

"रिक्त स्थान में उद्धृत लेख"

अपने यूआरएल में विराम चिह्न का उपयोग करने पर विचार करें। यूआरएल http://www.example.com/green-dress.html http://www.example.com/greendress.html से हमारे लिए अधिक उपयोगी है। हम अनुशंसा करते हैं कि आप अपने URL में अंडरस्कोर (_) के बजाय हाइफ़न (-) का उपयोग करें।

+3

Google ने समझाया क्यों नहीं? माना जाता है कि इसका विश्लेषण पार्सिंग पते के साथ कुछ करना है? या शायद यह सिर्फ एक अंत उपयोगकर्ता मुद्दा है। –

+4

यह भी ध्यान देने योग्य है कि अंडरस्कोर_टेक्स्ट पूरी तरह से कुछ उपकरणों में डबल क्लिक करके और मोबाइल पर लंबे समय से दबाने के द्वारा चयन योग्य है, जबकि डैश से अलग-अलग पाठ के साथ एक ही क्रिया प्रत्येक अलग शब्द का चयन करती है। इस बारे में सोचें कि क्या उपयोगकर्ता कभी यूआरएल – Titus

+0

से कुछ कॉपी करने का प्रयास करेगा, मुझे लगता है कि आपने @Titus पर एक कारणता लूप मारा होगा, क्योंकि यह वास्तविक रूप से वास्तविक है ... अंग्रेजी, जो शब्दों में डैश करता है, लेकिन ' टी अंडरस्कोर है। – billjamesdev

33

यहाँ डैश के पक्ष में कुछ बिंदु हैं:

  • डैश अंडरस्कोर (source) पर Google द्वारा सिफारिश की है।
  • डैश अंतिम उपयोगकर्ता से अधिक परिचित हैं।
  • मानक कीबोर्ड पर डैश लिखना आसान है (शिफ्ट करने की कोई आवश्यकता नहीं है)।
  • डैश अंडरलाइन के पीछे छिपा नहीं है।
  • डैश यूआरएल के संदर्भ में अधिक देशी महसूस करते हैं क्योंकि उन्हें डोमेन नामों में अनुमति है।
संबंधित मुद्दे