स्क्रिप्ट से मेल को सही तरीके से कैसे भेजें (विशेष रूप से - PHP में)

पाठ का पहला भाग होस्टिंग प्रदाता Netangels के निर्देशों से लिया गया है। दूसरा कॉपीराइट है।



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



यह सुनिश्चित करने के लिए कि आपका संदेश सही मायने में भेजा गया है, आपके पास मेल संदेश के प्रारूप के बारे में कम से कम बुनियादी विचार होने चाहिए। मेल संदेश का प्रारूप कई मानकीकृत दस्तावेजों में वर्णित है, जिनमें से मुख्य आरएफसी 822 हैं (अंग्रेजी में सादे पाठ को प्रसारित करने के लिए प्रारूप का वर्णन करता है) और आरएफसी 2045 इसके बाद (मनमाने डेटा संचारित करने के लिए इस प्रारूप के विस्तार का वर्णन करता है)।

ईमेल प्रारूप

उपरोक्त मानकों के अनुसार संकलित एक पाठ संदेश का सबसे सरल उदाहरण है और भेजे जाने के लिए तैयार है।

से: =? Windows-1251? B? 0J7RgtC / 0YDQsNCy0LjRgtC10LvRjD89? = <Putin@kremlin.ru>

To: =? Windows-1251? B? 0J / QvtC70YPRh9Cw0YLQtdC70Yw / PQ ==? = <Info@netangels.ru>

विषय: =? Windows-1251? B? 0Y3RgtC + INGC0LXQvNCwINGB0L7QvtCx0YnQtdC90LjRjz89? =

सामग्री-प्रकार: पाठ / सादा; charset = "विंडोज़ -1251"

सामग्री-अंतरण-एन्कोडिंग: 8bit



यह रूसी में एक ईमेल है

कई लाइनें शामिल हैं

यह इस प्रारूप में है कि मेल भेजने के लिए क्लाइंट (एमएस आउटलुक या मोज़िला थंडरबर्ड) संदेश तैयार करता है और फिर प्राप्तकर्ता को भेजता है (वैसे, अधिकांश ईमेल क्लाइंट आपको मोज़िला थंडरबर्ड में संदेश के स्रोत कोड को देखने की अनुमति देते हैं, उदाहरण के लिए, कीबोर्ड शॉर्टकट Ctrl + U का उपयोग करें) । PHP भाषा में हमारी स्क्रिप्ट का कार्य बिल्कुल समान अक्षर प्रारूप को प्राप्त करना है।



जैसा कि आप ऊपर के उदाहरण से देख सकते हैं, ईमेल में दो भाग होते हैं: हेडर एक (शीर्ष) में रखे जाते हैं, और दूसरे में अक्षर का पाठ (निचला)। इन भागों को एक दूसरे से एक खाली स्ट्रिंग द्वारा अलग किया जाता है। शीर्षकों में पत्र (विषय), नाम और प्रेषक का नाम (से), प्राप्तकर्ता (टू) और अन्य जानकारी के विषय वाली लाइनें शामिल हैं। सरलतम स्थिति में, प्रत्येक पंक्ति में "शीर्षकनाम: शीर्षक शीर्षक" की एक जोड़ी होती है। यह विशेष रूप से जोर देने के लिए आवश्यक है कि, मानकों के अनुसार, शीर्षकों को किसी भी परिस्थिति में ऐसे वर्णों को शामिल करना चाहिए जो ASCII तालिका में मौजूद नहीं हैं - लैटिन अक्षर, संख्या, विराम चिह्न और छद्म विज्ञान।

मेल संदेश के शीर्षलेखों में रूसी पात्रों का उचित उपयोग

तो, स्पष्ट रूप में, शीर्षक में रूसी पाठ मौजूद नहीं होना चाहिए, इसलिए, इसे वहां शामिल करने के लिए, इस पाठ को पहले एन्कोड किया जाना चाहिए। मानक "निषिद्ध" वर्ण एन्कोडिंग के लिए एक विधि का वर्णन करते हैं। सामान्य प्रारूप निम्नानुसार है:

=? एन्कोडिंग? एन्कोडिंग विधि? एन्कोडेड पाठ? =

एन्कोडिंग किसी भी सूची "विंडोज़ -1251", "कोइ -8-आर", "यूटीएफ -8" आदि हो सकती है। सभी मामलों में, एक नियम के रूप में, संदेश की एन्कोडिंग उस एन्कोडिंग के साथ मेल खाएगी जिसमें साइट संचालित होती है। यही है, ज्यादातर मामलों में यह "विंडोज़ -1251" होगा, कम बार - "यूटीएफ -8"।



एन्कोडिंग विधि इंगित करती है कि कैसे रूसी पात्रों को एक सुरक्षित सेट में परिवर्तित किया जाएगा। दो विधियों को परिभाषित किया गया है: तथाकथित "क्यू-एन्कोडिंग" (एक एकल पत्र "क्यू" द्वारा इंगित) और "बेस 64" (एक अक्षर "बी" द्वारा दर्शाया गया है)।



दुर्भाग्य से, कोई मानक फ़ंक्शन नहीं है जो पीएचपी में एक नियमित स्ट्रिंग को क्यू-एन्कोडेड पाठ में बदल सकता है, लेकिन एक ऐसा फ़ंक्शन है जो बेस 64 में इसी तरह का रूपांतरण कर सकता है। तो, ईमेल संदेश की विषय पंक्ति को सही ढंग से बनाने के लिए PHP कोड इस तरह दिख सकता है:

$ विषय = "=? खिड़कियां? 1251? बी?"। base64_encode ($ _ POST ["विषय"])। "; =";

यहाँ यह माना जाता है कि चर $ _POST ["विषय"] में आपको एन्कोडिंग विंडो -1251 में रूसी में दर्ज किए गए मेल संदेश का विषय है।



प्रेषक या प्राप्तकर्ता का पता "user@example.com" या "Username <user@example.com" के रूप में लिखा जा सकता है। दूसरे मामले में, उपयोगकर्ता नाम को उसी तरह से परिवर्तित किया जाना चाहिए जैसे पिछले उदाहरण में। निम्नलिखित एक उदाहरण है जो मानता है कि चर $ _POST ["उपयोगकर्ता नाम"] में उपयोगकर्ता नाम और चर $ _POST ["ईमेल"] में अपना ईमेल पता है:

$ प्रेषक = "=? विंडोज़? 1251? बी?"। base64_encode ($ _ POST ["उपयोगकर्ता नाम"))। "? = <"। $ _POST ["ईमेल"]। ">";

सामग्री-प्रकार: मल्टीपार्ट / ???

कोई भी डेवलपर जो अनुलग्नकों या HTML पत्रों के साथ पत्र भेजने की समस्या को हल करने में कामयाब रहा है, इस शीर्षक से परिचित है। और अक्सर PEAR :: Mail_mime जैसे पुस्तकालयों का उपयोग किए बिना गठित पत्र सही ढंग से प्रदर्शित नहीं होते हैं। अभ्यास से पता चलता है कि यदि आप एक मानक का पालन करते हैं जो RFC (विशेष रूप से, RFC 2046 ) में सेट किया गया है, तो एक पत्र की रचना करते समय, क्लाइंट प्रोग्राम्स के विशाल बहुमत (जिनमें मोज़िला थंडरबर्ड जैसे मानकों का पालन करना पसंद है) पत्र को सही ढंग से प्रदर्शित करते हैं। इसके अलावा, हम इस तथ्य से आगे बढ़ेंगे कि इस दस्तावेज़ का पाठक कमांड के मूल सिंटैक्स को समझता है और समझता है कि सीमा क्या है और पत्र के प्रत्येक भाग के लिए सामग्री-प्रकार निर्दिष्ट करना क्यों आवश्यक है। हम मुख्य गलतियों को नोट करने की कोशिश करेंगे।

गलती एक - अवैध उपप्रकार

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

• मिश्रित - का उपयोग तब किया जाता है जब एक एकल मेल संदेश के भीतर एक दूसरे से कई स्वतंत्र होते हैं, और समान भाग होते हैं। इस तरह के पत्र का सबसे सरल उदाहरण एक लगाव के साथ एक संदेश है।
  
  वैकल्पिक - का उपयोग तब किया जाता है जब किसी एकल मेल संदेश में विभिन्न क्लाइंट सॉफ़्टवेयर पर प्रदर्शन के लिए समान जानकारी वाले कई भाग होते हैं - उदाहरण के लिए, एक पाठ और एक ही संदेश का HTML संस्करण।
  
  संबंधित - का उपयोग तब किया जाता है जब एक एकल मेल संदेश में कई भाग होते हैं जो एक अंतिम दस्तावेज़ बनाते हैं। एक आकर्षक उदाहरण चित्रों के साथ एक HTML पत्र है। याद रखें, मानक के अनुसार, केवल इस मामले में तत्वों के कंटेंड-आईडी से लिंक होता है (फ़ॉर्म का <img src = "cid: image">) काम करना चाहिए।
  
  निर्देशानुसार याद रखें और उपयोग करें।
  
  
  
  

  गलती दो - भागों का गलत क्रम

  पत्र में जिन भागों को दर्शाया गया है, उनका क्रम अक्सर इस बात के लिए महत्वपूर्ण होता है कि ग्राहक को संदेश कैसे प्रदर्शित किया जाएगा।
  
  
  • मिश्रित - हमारे कार्यों के लिए भागों का क्रम मायने नहीं रखता है।
    
    वैकल्पिक - भागों को व्यवस्थित किया जाना चाहिए, सरल से अधिक जटिल तक। RFC ग्राहक के क्लाइंट द्वारा कुछ अक्षर संस्करणों को चुनने की प्रक्रिया को कुछ इस तरह से नियंत्रित करता है: "सामान्य तौर पर, मेल क्लाइंट को उपलब्ध दस्तावेज़ के नवीनतम संस्करण को प्रदर्शित करना चाहिए।" यानी पत्र के टेक्स्ट और HTML संस्करण बनाते समय, आपको पाठ को आगे रखना होगा।
    
    संबंधित - कतार में पहला भाग मुख्य भाग (HTML दस्तावेज़, उदाहरण के लिए) होना चाहिए। अन्य सभी निम्नलिखित हैं। द्वारा और बड़े, मानक एक विशेष पैरामीटर "स्टार्ट" को नियंत्रित करता है, जो दस्तावेज़ के मुख्य भाग को इंगित करता है, लेकिन इसका दुरुपयोग न करना बेहतर है।
    
    
    
    

    तीसरी त्रुटि - केवल एक उपप्रकार का चयन करें

    अक्सर डेवलपर जो प्रोग्राम से पत्र बनाता है वह भूल जाता है कि पत्र के किसी भी भाग में सामग्री-प्रकार: मल्टीपार्ट हो सकता है, जिसका अर्थ है कि पेड़ की संरचना के कुछ सदृश निर्माण करना संभव है जो यह सुनिश्चित करता है कि पत्र का प्रत्येक भाग सही जगह लेता है। यहां पाठ और HTML संस्करणों (चित्रों के साथ HTML), साथ ही संलग्न एमएस वर्ड दस्तावेज़ के साथ एक पत्र की संरचना इस प्रकार है:
    
    
    
    
    • सामग्री-प्रकार: मल्टीपार्ट / मिश्रित
      
      
      • सामग्री-प्रकार: मल्टीपार्ट / वैकल्पिक
        
        
        • सामग्री-प्रकार: पाठ / सादा
          
          सामग्री-प्रकार: मल्टीपार्ट / संबंधित
          
          
          • सामग्री-प्रकार: पाठ / html
            
            सामग्री-प्रकार: छवि / जेपीईजी
            
            सामग्री-प्रकार: छवि / जेपीईजी
          
          
          सामग्री-प्रकार: आवेदन / msword
        
        
        
        
        

        और अंत में, कुछ और सिफारिशें

        • हमेशा पत्र का एक पाठ / सादा संस्करण बनाएं - कोई भी यह अनुमान नहीं लगा सकता है कि आपका पत्र कैसे पढ़ा जाएगा।
          
          आलसी मत बनो और मानकों का पालन करो।
          
          यदि रुचि है - http://people.dsv.su.se/~jpalme/ietf/mhtml-test/mhtml.html कुछ उदाहरण हैं।