क्या प्लस को मेल्टो में एन्कोड किया जाना चाहिए: हाइपरलिंक?

Question

जब एक mailto हाइपरलिंक में एक पता टैग (उर्फ उप-पता) के साथ एक ईमेल पता रखने …

<a href="mailto:[e-mail]">mail us now!</a>

... ईमेल में प्लस URL एनकोडेड होना चाहिए?

<a href="mailto:[e-mail]">mail us now!</a>

मैं इसका पता नहीं लगा सकता, और प्रलेखन विरोधाभासी है। हमारे वास्तविक विश्व परीक्षणों ने मिश्रित परिणामों का उत्पादन किया है, जिससे यह और भी अधिक भ्रमित हो गया है।

Comments

क्या आप अपने वास्तविक दुनिया परीक्षणों के तरीकों और परिणामों पर अधिक विशिष्ट हो सकते हैं? क्या कुछ ईमेल क्लाइंट / सेवाएं इसे ठीक से मानते हैं और अन्य लोग इसे ठोकते हैं? क्या आप अधिक विशिष्ट हो सकते हैं?

— ब्रायनसन

@bryson मुझे पता है कि "gmail का उपयोग करके भेजें" क्रोम एक्सटेंशन के पास मेलआउट में अनएन्कोडेड प्लस के साथ मुद्दे थे: उदाहरण के लिए, लेकिन शायद यह एक बग है।

— जेफ एटवुड

बस जो भी क्रोम के साथ काम करता है उसका उपयोग करें।

— हार्डवेयरगुई

Answer 1

प्लस का उपयोग URL में रिक्त स्थान को एन्कोड करने के लिए किया जाता है, HTML में नहीं और SMTP में नहीं (RFC2821)। हालांकि, चूंकि mailto:[e-mail]एक यूआरआई है (इसमें एक प्रोटोकॉल, प्रोटोकॉल विभाजक और प्रोटोकॉल पता है) तो इसे यूआरआई के रूप में माना जाना चाहिए और इसे प्रतिशत एन्कोडेड होना चाहिए ।

इसलिए, ग्राहक पर निर्भर है कि वह एन्कोडेड प्रतिनिधित्व को सही ढंग से हल करे और जहां तक ​​उचित हो, उसे डिकोड करे। इस मामले पर माइक्रोसॉफ्ट का आधिकारिक अधिकार है ।

यदि आप ईमेल पते के अक्षर URI आरक्षित हैं, तो आपको mailto पर URL एन्कोडिंग: HTML में एम्बेड किए गए URL को लागू करना चाहिए। यह सुनिश्चित करता है कि आप सही काम कर रहे हैं। ग्राहक को यह निर्भर है कि वह प्राप्त होने वाले यूआरआई को उचित रूप से डिकोड करें। हाँ, [e-mail]एक बहुत ही मान्य ईमेल है; हाँ [e-mail]भी मान्य है। हाँ, वे दो अलग हैं, लेकिन क्या वे अलग तरह से व्यवहार किया जाएगा ग्राहक पर निर्भर है ...

जैसा कि आपने पहले उल्लेख किया था, सभी क्लाइंट इसे सही ढंग से प्रस्तुत नहीं करते हैं। मेरा सुझाव है कि सबसे अधिक संभावना ग्राहक (जीमेल? ब्राउज़र आधारित क्लाइंट? आउटलुक?) का उपयोग करें जो आपके उपयोगकर्ता उपयोग करेंगे और कर रहे हैं जो ग्राहक करता है। आपने कहा कि आपने जीमेल पर परीक्षण किया है? आपने इसका परीक्षण कैसे किया? एक "ब्राउज़र आधारित मेल्टो: क्लाइंट (जैसे ऐड-ऑन से फ़ायरफ़ॉक्स और जीमेल ऑफ़र) के साथ, यूआरआई की संभावना सबसे अधिक डिकोड नहीं की जा रही है (जैसा कि यह होना चाहिए)।

Comments

क्या किसी के पास कोई वास्तविक डेटा है कि वह कहां काम करता है?

— वेज फर्लांग जू

अच्छी तरह से मैं एक विशिष्ट नोट करता हूं कि Microsoft क्या काम करता है ...

— jcolebrand

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

— मैथ्यू पढ़ें

यदि आपने +URI में एनकोड किया है, तो @भी इनकोड करना होगा क्योंकि यह एक आरक्षित वर्ण भी है। यदि आप RFC को ध्यान से पढ़ते हैं, तो आपको पता चलेगा कि एक अपारदर्शी भाग में, +कानूनी है।

— यूजीन योकोटा

मैं गलत हो सकता हूं लेकिन क्या यह उपयोगकर्ता नाम को होस्ट से अलग करने के लिए आरक्षित नहीं है (जैसे [e-mail]/path में )? फिर यह पते में अपनी जगह बना लेगा क्योंकि यह उपयोगकर्ता नाम को होस्ट से अलग करता है।

— मैकिज पीचोटका

Answer 2

आप सांकेतिक शब्दों में बदलना +, लेकिन आप के लिए नहीं है।

सबसे पहले, हमें यह सहमत होना चाहिए कि RFC 2396mailto द्वारा निर्दिष्ट एक सामान्य URI का एक उदाहरण है । (यह XHTML और HTML 4 का उपयोग है)।

अब हम RFC 2396 में आरक्षित वर्णों की सूची का पता लगाते हैं।

reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
              "$" | ","

URI पूर्ण और सापेक्ष में विभाजित होता है:

URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]

और क्योंकि योजना mailto:निर्दिष्ट है यह एक पूर्ण यूआरआई है:

absoluteURI   = scheme ":" ( hier_part | opaque_part )

और दोनों पैटर्न के hier_partसाथ शुरू करने के लिए /, mailtoएक अपारदर्शी हिस्सा है।

opaque_part   = uric_no_slash *uric

uric_no_slash = unreserved | escaped | ";" | "?" | ":" | "@" |
                "&" | "=" | "+" | "$" | ","

uric          = reserved | unreserved | escaped

तो प्रतिबंध आप से बचने के लिए किया है वह यह है कि /अगर यह पहले चरित्र की बात आती है, लेकिन उसके बाद आप सहित आरक्षित अक्षरों में डाल सकते हैं +और @।

इसका समर्थन करने के लिए यहां एक और RFC है। 2010 में प्रकाशित RFC 6068 नामक नवीनतम RFCs में , यह कहता है:

'mailto'इसी तरह यूआरआई बनाने वाले सॉफ्टवेयर का उपयोग किए जाने वाले किसी भी आरक्षित वर्ण को एन्कोड करने के लिए सावधान रहना होगा। HTML फॉर्म एक प्रकार का सॉफ्टवेयर है जो 'mailto'URI बनाता है। वर्तमान कार्यान्वयन के रूप में एक अंतरिक्ष सांकेतिक शब्दों में बदलना '+', लेकिन यह समस्या पैदा करता है क्योंकि '+'एक अंतरिक्ष के लिए इस तरह के एक खड़े '+'एक 'mailto' URI में एक असली से अलग नहीं किया जा सकता है । 'mailto'यूआरआई का निर्माण करते समय , सभी रिक्त स्थान के रूप में इनकोडिंग किया जाना चाहिए %20, और '+'पात्रों को एनकोड किया जाना चाहिए %2B। कृपया ध्यान दें कि '+' पात्रों को अक्सर एक उप पते के लिए एक ईमेल पते के हिस्से के रूप में उपयोग किया जाता है, उदाहरण के लिए <[e-mail]>।

Comments

मैं उस व्याकरण से पूरी तरह परिचित नहीं हूँ, हालाँकि, यह पात्रों को अनारक्षित पूल से अलग सूचीबद्ध करता है, जो यह दर्शाता है कि + एक आरक्षित वर्ण है। यह इंगित नहीं करता है कि इसे एन्कोड किया जाना चाहिए। Microsoft इसे एनकोड करने के लिए कहता है। C'est la vie, मुझे देखने का इंतजार है।

— jcolebrand

जब कोई हिस्सा शुरू नहीं होता है /, तो +वह आरक्षित वर्ण नहीं रह जाता है।

— यूजीन योकोटा

मैं असहमत हूं। "ईमेल पते" बहुत अजीब तरह से परिभाषित हैं, और पहली जगह में कुछ देखभाल के साथ इलाज किया जाना चाहिए। वह मानक बहुत भ्रामक है। सौभाग्य से, हम यहां असहमत हैं।

— jcolebrand

Answer 3

प्रासंगिक RFC के एक सख्त पढ़ने का कहना है कि "+" को एन्कोड किया जाना चाहिए।

धारा 2, पृष्ठ 2 के शीर्ष पर http://tools.ietf.org/html/rfc2368 कहते हैं:

"ध्यान दें कि सभी URL" में "वर्णों को इनकोड किया जाना चाहिए: विशेष रूप से, कोष्ठक, अल्पविराम और प्रतिशत चिह्न ("% "), जो आमतौर पर" मेलबॉक्स "वाक्यविन्यास में होता है।

URIs के लिए RFC (http://tools.ietf.org/html/rfc3986#section-2.2) आरक्षित वर्ण के रूप में "+" सूची देता है।

उस ने कहा, "सही" क्या जरूरी नहीं है कि सभी ब्राउज़रों में काम करेगा। कुछ ब्राउज़र स्पष्ट रूप से हमेशा सही चीज़ों को संभालेंगे जैसे कि वे गलत थे और जैसे कि वे सही थे।

संपादित करें: RFC6068 और इसके "MAY" के रूप में, मैं इसे संदर्भ निर्भर के रूप में पढ़ूंगा। यदि आप पाठ पढ़ने के लिए URL लिख रहे हैं, तो "+" अधिक समझ में आएगा, हालांकि यदि आप इसे HTML में लिख रहे हैं , तो RFC3986 की सख्त व्याख्या "मान्य HTML" विचारों के साथ अधिक इनलाइन होगी और इसलिए मूल्य का उपयोग करके कुछ भी उम्मीद है कि यह एन्कोड किया जाएगा।

Comments

RFC 3986 में, के mailtoरूप में माना जाएगा path-rootless, जो pcharद्वारा परिभाषित अनुक्रम की अनुमति देता है (unreserved / pct-encoded / sub-delims / ":" / "@")। +का हिस्सा है sub-delims। इतना सख्त पढ़ने का कहना +है कि प्रतिशत एन्कोडिंग की आवश्यकता नहीं है।

— यूजीन योकोटा

Answer 4

प्रति नया RFC http://tools.ietf.org/html/rfc6068#section-5

  ... '+' MAY BE encoded as %2B

तो मुझे लगता है कि उत्तर नहीं है, लेकिन हो सकता है?

Answer 5

मुझे लगता है कि यह एन्कोडिंग है या नहीं, इससे वास्तविक फर्क नहीं पड़ेगा। समस्या मेल क्लाइंट हैं। परीक्षा के लिए, याहू मेल केवल उप-प्रवेश के लिए हाइफ़न का उपयोग करता है जबकि गेल प्लस का उपयोग करता है।

यह मेरा 2 सेंट है ...

EDIT: नीचे दी गई प्रतिक्रिया का एक ठोस बिंदु है।

Comments

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

— जेफ एटवुड

समस्या URI के अनुरोध को पार्स करने वाली एप्लिकेशन है। यदि यह URLEncoded डेटा प्राप्त करने की अपेक्षा करता है, तो यह डेटा को डिकोड करेगा, लेकिन यह न तो आपके लिए उचित है (न ही झूठे सांकेतिक शब्दों में बदलना) और न ही क्लाइंट (मान्यताओं को बनाने के लिए)। प्रोटोकॉल अपेक्षित एन्कोडिंग को निर्देशित नहीं करता है, क्लाइंट करता है। आगे के एडिट्स देखें कि मैं A से @Wez

— jcolebrand

Answer 6

RFC1738

3.5। mailto

Mailto URL योजना का उपयोग किसी व्यक्ति या सेवा के इंटरनेट मेलिंग पते को निर्दिष्ट करने के लिए किया जाता है। इंटरनेट मेलिंग पते के अलावा कोई अतिरिक्त जानकारी मौजूद या निहित नहीं है।

एक mailto URL फॉर्म लेता है:

    mailto:<rfc822-addr-spec>

जहाँ RFC 822 में निर्दिष्ट किया गया है (क) एड्र-स्पेक की एन्कोडिंग । Mailto URL के भीतर, कोई आरक्षित वर्ण नहीं हैं।

ध्यान दें कि प्रतिशत चिह्न ("%") आमतौर पर RFC 822 पतों के भीतर उपयोग किया जाता है और इनकोड किया जाना चाहिए।

कई URL के विपरीत, mailto स्कीम सीधे एक्सेस की जाने वाली डेटा ऑब्जेक्ट का प्रतिनिधित्व नहीं करती है; इसमें कोई अर्थ नहीं है कि यह किस वस्तु को डिजाइन करता है। इसका MIME में संदेश / बाहरी-शरीर के प्रकार से भिन्न उपयोग है।

चूंकि कोई आरक्षित वर्ण नहीं हैं, इसलिए इसे एन्कोड किया जाना चाहिए।

Comments

और फिर भी प्रति टूल्स.ietf.org/html/rfc6068 "जब" मेल्टो 'URI का उत्पादन करते हैं, तो सभी रिक्त स्थान SHOULD को% 20 के रूप में एन्कोड किया जाएगा, और' + 'अक्षर MAY को% 2B के रूप में एन्कोड किया जाएगा "

— जेफ एटवुड

Since there are no reserved characters it should be encoded.ummmm कि कोई मतलब नहीं है।

— jcolebrand

@jcolebrand '+' URL स्कीम में एक विशेष पात्र है और इस तरह उसे एन्कोड किया जाना चाहिए, जब उसकी कोई विशेष भूमिका न हो - यानी। जब यह आरक्षित नहीं है।

— एस.कोव

@ जेफ वास्तव में - एक पुराने RFC दुनिया में रहने के लिए मेरा बुरा। तब tools.ietf.org/html/rfc2119 मूल रूप से आपको वह करने के लिए कहता है जो आपको लगता है कि आप सबसे अच्छा मानते हैं।

— एस.वी.कोव

ऐसा लगता है कि .... आत्मा में पीछे की ओर जिस तरह से मैं शुरू में निर्देश पढ़ता हूं।

— jcolebrand

Answer 7

प्रति RFC 6068 के रूप में उत्तर में वर्णित है, तो आप के रूप में प्लस चिह्न सांकेतिक शब्दों में बदलना होगा %2B।

भ्रम का कारण यह है कि एक स्थान को प्लस में बदलना वास्तव में मानक URL एन्कोडिंग का हिस्सा नहीं है, यह फॉर्म पैरामीटर एन्कोडिंग (यानी application/x-www-form-urlencoded) का हिस्सा है

यह PHP के बीच का अंतर की तरह है rawurlencode()और urlencode()।

तो RFC 6068 क्या कह रहा है कि एक mailto:URL को "कच्चे" मानक URL एन्कोडिंग ( RFC 3986 के अनुसार ) का उपयोग करना चाहिए , और URL में दिखाई देने वाला एक प्लस चिन्ह हमेशा शाब्दिक प्लस चिह्न के रूप में माना जाना चाहिए, न कि एक स्थान के रूप में। प्रपत्र एन्कोड किया गया।

यदि स्थानीय क्लाइंट प्लस को टूटी हुई जगह में परिवर्तित करता है।