क्या मेरे लिए निचले मामले में ईमेल पता होना आवश्यक है


11

मैं एक फ्लायर डिजाइन कर रहा हूं जिस पर एक ईमेल पता है।

क्या मेरे लिए लोअर केस में ईमेल एड्रेस होना आवश्यक है?

या अधिक जोर लगाने के लिए मेरे पास ऊपरी मामले में हो सकता है?

मैंने अपना शोध नेट पर किया था, लेकिन सभी परिणाम ईमेल पते से संबंधित प्रतीत होते हैं, न कि यह एक उड़ता पर दिखाई देता है।

मेरा ग्राहक ऊपरी मामले में होने के विचार को पसंद नहीं करता है।


13
यदि आपका ग्राहक इसे पसंद नहीं करता है .. तो इसे न करने के लिए पर्याप्त कारण होना चाहिए। मैं किसी भी ग्राहक के साथ इस तरह के मामले पर अपना पक्ष नहीं रखूंगा। यह मेरे लिए उतना महत्वपूर्ण नहीं होगा।
स्कॉट

4
याद रखें कि ईमेल पते डिफ़ॉल्ट रूप से संवेदनशील हैं
फेरीबाग

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

4
@ 1171111 आधिकारिक smtp विनिर्देश पढ़ें : "मेलबॉक्स का स्थानीय-भाग केस संवेदनशील के रूप में माना जाना चाहिए", इसलिए कहा जा सकता है कि ईमेल पते (आंशिक रूप से) डिफ़ॉल्ट रूप से संवेदनशील मामला है। कि ज्यादातर लोग उन्हें अपने ही सर्वर पर असंवेदनशील बना देते हैं, यह बिल्कुल अलग मामला है
फेरीबाग

6
@Ferrybig: विनिर्देशन के लिए आवश्यक है कि कोई भी इकाई जो संदेश प्रेषित करती है, उसे भेजने वाले द्वारा उपयोग किए गए ऊपरी और निचले मामले का समान संयोजन प्रदान करना चाहिए, जो ऐसे परिवहन एजेंटों को केस-संवेदी बनाता है। संदेश का अंतिम निपटान प्राप्तकर्ता तक है। यदि कोई संदेश प्राप्त करने वाला अंतिम होस्ट fredjones, FredJones, FREDJONES और यहां तक ​​कि BarneyRubble के साथ एक ही मेलबॉक्स की पहचान करना चाहता है, तो ऐसा करना मुफ्त होगा। यदि वह चार अलग-अलग मेल बॉक्स के रूप में इलाज करना चाहता है, तो उसे भी अनुमति दी जाएगी।
सुपरकैट

जवाबों:


22

ग्राहकों का अंतिम कहना है। भले ही आप इससे असहमत हों।

यह अवहेलना करना कि शायद तकनीकी कारणों से अपरकेस एक बुरा विचार है। और इस तथ्य की अवहेलना करते हुए कि ऊपरी मामले में पठनीयता कम होती है और अक्सर "जोर" का विपरीत प्रभाव पड़ता है ... ग्राहक दिशा हमेशा निर्णायक कारक होती है।

यदि ग्राहक इसे पसंद नहीं करता है, तो इसे न करें।

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


ईमेल पते के मामले का कोई तकनीकी असर नहीं है।
कार्ल

3
@Carl जब तक ईमेल सर्वर केस सेंसिटिविटी के कारण अज्ञात ईमेल को अस्वीकार नहीं करता है। MYEMAIL@example.com कुछ मेल सर्वरों के लिए myemail@example.com के समान नहीं है। यह दुर्लभ है, हाँ। लेकिन यह असंभव नहीं है
स्कॉट

हालांकि, विपरीत मामले में जहां ग्राहक सभी कैप्स में ईमेल पता चाहता था, यह तुच्छ रूप से परीक्षण किया जा सकता था कि यह ठीक है या नहीं
OGHaza

2
जब ईमेल पते की बात आती है तो कोई "बुरा" या "अच्छा" विचार नहीं होता है, मूल रूप से सिर्फ ऐनक होते हैं, जो बताता है कि @ से पहले का हिस्सा जो कुछ भी हो सकता है सर्वर (केस-सेंसिटिव होने के नाते) और उसके बाद वाला हिस्सा @ हमेशा केस-असंवेदनशील है, क्योंकि वह डोमेन है।
पीटर डब्ल्यू

13

उत्तर प्रदेश में एक ईमेल पता लगाना एक बहुत ही बुरा विचार है। "एम्पासिस" के रूप में इस प्रकार का उपयोग करने से आपको कुछ अन्य विकल्प नहीं मिलेंगे।

उसके लिए खेद है।

जैसा कि दूसरों ने टिप्पणी की है, जबकि एक ईमेल पते में उपयोगकर्ता का नाम केस-असंवेदनशील है, डोमेन नाम नहीं है। कुछ चरम मामलों में, YouCouldUseCamelCase राजधानियों का उपयोग। उनका उपयोग लंबे शब्दों पर किया जाता है। लेकिन किसी सार्वजनिक ईमेल के पहले भाग के रूप में एक लंबा शब्द चुनना भी एक बुरा विचार है।

कभी-कभी एक डोमेन नाम के लिए आवश्यक हो सकता है। FreeDomainNames.Example.com

सच्चाई यह है कि आपको अभी विचार छोड़ देना चाहिए। यहां तक ​​कि टिप्पणियों में, आपके पास तकनीकी तर्कों के बाद भी आपके दिमाग में तय किया गया विचार है

मुझे खेद है लेकिन यह एक फ्लायर से संबंधित है जिसे मैं डिजाइन कर रहा हूं।

नहीं, आप अपना सेल फ़ोन कवर नहीं डिज़ाइन कर रहे हैं जहाँ आप चाहें तो यूनिकॉर्न का उपयोग कर सकते हैं।

आप संभावित रूप से ग्राहकों को भ्रमित कर रहे हैं, संभावित रूप से ईमेल को आने से रोकते हैं और क्लाइंट के साथ खिलवाड़ करते हैं जो इसे पसंद नहीं करते हैं। इसके बारे में सोचते रहने का एक भी तर्क नहीं है।

आकार बदलें, फ़ॉन्ट बदलें, मोटाई बदलें, वजन बदलें, कर्नेल बदलें, एक रूपरेखा डालें, एक बुलेट लगाएं, एक आइकन डालें, एक विस्फोट डालें, एक होलोग्राम लगाएं ... आपके पास विकल्प हैं।

यदि क्लाइंट ऐसा करना चाहता था तो कुछ तर्क हो सकते हैं। पर ये स्थिति नहीं है।


3
बयान "एक ईमेल पता केस-असंवेदनशील है" आम तौर पर, लेकिन सार्वभौमिक रूप से सच नहीं है। डोमेन-नाम भाग को केस-असंवेदनशील होना आवश्यक है, और कई ईमेल होस्ट स्थानीय भाग को असंवेदनशील बनाते हैं, लेकिन उन्हें ऐसा करने की आवश्यकता नहीं होती है।
मोंटी हार्डर

यही कारण है कि मैंने "डोमेन नाम" बताया। मैं उसे संपादित करूँगा।
राफेल

@ राफेल मैंने अभी विचाराधीन वाक्य को संपादित करने का सुझाव दिया है क्योंकि यह अभी भी काफी अस्पष्ट और भ्रामक था।
जानुस बह्स जेकेट

8

बड़ा, bolder == अधिक ध्यान देने योग्य, अधिक सुपाठ्य।

ALLCAPS == चिल्लाना और वास्तव में पढ़ना कठिन है।

मैं कभी-कभी खान, TxxxxxMedia पर शीर्षक के मामले का उपयोग करता हूं, जिससे इसे पढ़ना आसान हो जाता है और मेरा मेल सर्वर इसे बुरा नहीं मानता।

लेट एडिट
अन्य के अनुसार, बाद में, यहाँ उत्तर, किसी भी सर्वर को डोमेन नाम में किसी भी प्रकार के केस में भेदभाव नहीं करना चाहिए, केवल @ से पहले के भाग में ही संभव है, इसलिए कैमलकेस या टाइटलकेस ठीक है।


हाँ, लेकिन यह वास्तव में सर्वर पर निर्भर करता है। हालांकि एक परीक्षण shoiuldnt स्टेजिंग कठिन होना चाहिए।
पूजा

1
"ALLCAPS == चिल्लाना" मैं अधिक सहमत नहीं हो सकता था, लेकिन मैंने ऐसे फोंट देखे हैं जो मूल रूप से सभी कैप हैं, फिर भी किसी तरह चिल्लाओ-य के रूप में नहीं आने का प्रबंधन करते हैं।
मंकीज़े

6

मेल मानक कहता है कि @ के पहले जो केस-संवेदी हो सकता है और वह होस्ट सिस्टम के नियंत्रण में है, और @ के बाद जो है वह असंवेदनशील है क्योंकि यह मेल डिलीवरी सिस्टम के नियंत्रण में है।

व्यवहार में उपसर्ग को बहुत कम ही मामला संवेदनशील माना जाता है (मैंने ऐसी किसी प्रणाली का कभी सामना नहीं किया है), इसलिए आप अपने इच्छित किसी भी आवरण का उपयोग कर सकते हैं और यह बहुत ही उच्च संभावना के साथ काम करेगा। मेरा आधिकारिक पता कुछ ऐसा है john.smith@somedomain.frऔर मैं इसे हमेशा प्रस्तुत करता हूं John.Smith@somedomain.fr; मैं 25 से अधिक वर्षों के लिए कोई समस्या नहीं है ...


3
मैंने उन प्रणालियों का सामना किया है जो वास्तव में परवाह करते थे। इसकी दुर्लभ लेकिन आप इसे देखभाल कर सकते हैं। लेकिन ive देखा सिस्टम है कि परवाह नहीं क्या आप अपने उपयोगकर्ता नाम से पहले बिंदीदार हिस्से में टाइप किया।
पूजा

यह वास्तव में ऐसा नहीं है कि एक ईमेल पते का सिर्फ एक उदाहरण देने के लिए आश्वस्त होना जो एक मामले में असंवेदनशील तरीके से काम करता है: इसमें कोई संदेह नहीं है कि वे मौजूद हैं, लेकिन यह कोई सबूत नहीं है कि विपरीत भी मौजूद नहीं है :)
भजन

@psmears के रूप में यह अनुमति दी है, लेकिन यह काफी दुर्लभ है और दृढ़ता से ऐसा करने के लिए हतोत्साहित किया जाता है।
जीन-बैप्टिस्ट यूनेसे

1
आपके एक सर्वर ने कभी परवाह नहीं की। यह किसी और के सर्वर की देखभाल करेगा या नहीं इसके बारे में कुछ नहीं कहता है। हालांकि, यह परीक्षण करने के लिए काफी आसान है। JOHN.SMITH@SOMEDOMAIN.FR को एक ईमेल भेजें और देखें कि क्या आता है। यदि हां, तो उस पते को प्राप्त करना सभी के लिए काम करेगा।
सीजे डेनिस

@CJDennis मैं कई अलग-अलग प्रदाताओं (GAFA और एक जैसे, निजी कंपनियों, सार्वजनिक संस्थानों, निजी सर्वर आदि) से कई पते था, मैंने कभी भी मेल के साथ केस समस्या का प्रयोग नहीं किया है। मेल सर्वर सॉफ्टवेयर्स इतने सारे नहीं हैं और लगभग हर एडमिन तीन या चार उपलब्ध में से एक का उपयोग करता है और लगभग उसी तरह के कॉन्फ़िगरेशन का उपयोग करता है (जो मामले की परवाह नहीं करता है)।
जीन-बैप्टिस्ट यूनास ने

5

मेल सिस्टम पर निर्भर करता है। कई मेल सिस्टम वास्तव में परवाह नहीं करते हैं, लेकिन उन्हें देखभाल के लिए कॉन्फ़िगर किया जा सकता है। कुछ सिस्टम आपको मेल पतों में अतिरिक्त सामान रखने की अनुमति भी देते हैं, डाक्यूमेंट के लिए अपने मेल प्रदाता से पूछें।


मुझे खेद है लेकिन यह एक फ्लायर से संबंधित है जिसे मैं डिजाइन कर रहा हूं। फिर भी धन्यवाद।
ब्योर्न लिजा

4
@BjornLiza अगर आप नहीं जानते हैं तो आप बदल नहीं सकते।
पूजा

2

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

क्या यह एक प्रिंटेड फ्लायर है? यदि हां, तो ईमेल पते पर सबसे अच्छा तरीका जोर दें ताकि लोग इसे आसानी से पढ़ सकें और इसे याद रख सकें।

यदि यह एक लंबा जटिल पता है, तो आपको इसे एक दूसरे से शब्दों को अलग करने के लिए स्टाइल करना चाहिए।

सभी अक्षरों को बिना किसी रिक्त स्थान के एक साथ चलाने की आवश्यकता है।

प्रत्येक शब्द के पहले अक्षर के साथ वाक्य मामले को सबसे अधिक सुपाठ्य माना जाता है।

मैं व्यक्तिगत रूप से शब्दों के बीच की अवधि को जोड़ने से असहमत हूं, लेकिन यह "@" प्रतीक से पहले की पसंद है।

".Com" को डी-जोर दिया जा सकता है, छोटा किया जा सकता है या छोड़ा जा सकता है यदि यह जीमेल जैसा आम है।

यदि यह एक डिजिटल फ्लायर है और ईमेल लिंक को काम करना चाहिए और क्लिक करने योग्य होना चाहिए, तो सभी समान नियम लागू होते हैं क्योंकि html और css एक लिंक को ईमेल पते के पूर्ण पाठ संस्करण के अलावा किसी अन्य चीज़ के रूप में छिपाने की अनुमति देते हैं।

अपने ईमेल पते के पाठ को अपने ग्राहक की इच्छाओं का सम्मान करते हुए फिट होने का सबसे अच्छा तरीका स्टाइल करें, शायद एक ईमेल आइकन की तरह एक ग्राफिक जोड़ें, और पूरी चीज़ को सक्रिय ईमेल लिंक बनाएं।


एक मुद्रित फ्लायर पर, ईमेल पते के किसी भी हिस्से को कभी भी हटाएं। आप बस एक जीमेल पते के .com बिट को हटा नहीं सकते हैं और लोगों से इसे प्राप्त करने की अपेक्षा करेंगे - वे नहीं करेंगे। वे आपके नाम @ gmail पर एक ईमेल भेजेंगे और जब यह नहीं आएगा तो निराश और क्रोधित होंगे। शब्दों के बीच की अवधि जोड़ना भी स्पष्ट रूप से एक मौजूदा ईमेल पते के साथ एक फ्लायर बनाने के लिए काम नहीं करने वाला है - यह एक विकल्प है जब एक ईमेल खाता सेट करते हैं, न कि किसी डिज़ाइन पर मौजूदा टाइप करते समय। सजा का मामला है, जैसा कि दूसरों ने कहा है, संभावित रूप से जोखिम भरा और विनाशकारी है और यह भी बुरा लगता है।
जानूस बह्स जेकेट

-1

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.