(चूंकि यह मेरा पहला SO सवाल है, मुझे बस कहना है कि मुझे उम्मीद है कि यह ज़ेंड-विशिष्ट भी नहीं है। जहां तक मैं यह कह सकता हूं कि यह नहीं होना चाहिए एक समस्या। हालांकि मैं इसे ज़ेंड-विशिष्ट फोरम में पोस्ट कर सकता था, मुझे लगता है कि मुझे कम से कम एक अच्छा जवाब मिलने की संभावना है, खासकर जब उत्तर में एमआईएम-संबंधित मुद्दों को शामिल किया जा सकता है जो ज़ेंड फ्रेमवर्क को पार करते हैं। मैं मूल रूप से यह समझने की कोशिश कर रहा हूं कि मुझे जिस मुद्दे का सामना करना पड़ रहा है उसे ज़ेडएफ बग माना जाना चाहिए, या अगर मैं कुछ गलत समझ रहा हूं या इसका दुरुपयोग कर रहा हूं।)समझ में नहीं आ रहा है कि Zend_Mail :: addHeader() स्ट्रिप्स न्यूलाइन
मैं एक एमआईएमई संदेश बनाने के लिए ज़ेंड_Mail का उपयोग कर रहा हूं एक ईमेल वितरण सेवा, SendGrid के माध्यम से भेजा गया। उनका मंच आपको अपने एसएमटीपी सर्वर के माध्यम से ईमेल भेजने की इजाजत देता है, लेकिन जब आप एक विशेष हेडर (एक्स-एसएमटीपीएपीआई) का उपयोग करते हैं तो अतिरिक्त सुविधाएं देता है जिसका मूल्य मालिकाना पैरामीटर की JSON-encoded स्ट्रिंग है, जो काफी लंबा हो सकता है।
आखिरकार, जो हेडर मैं पास कर रहा था वह बहुत लंबा हो गया (मुझे लगता है> 1000 वर्ण), और मुझे त्रुटियां मिलीं। मैं उलझन में था क्योंकि मुझे पता था कि यह Zend_Mail :: addHeader() के मान को पार करने से पहले PHP के मूल वर्डवाप() फ़ंक्शन के माध्यम से पारित हो रहा था, इसलिए मैंने सोचा कि रेखा की लंबाई कभी भी समस्या नहीं होनी चाहिए।
यह पता चला है कि addHeader() न्यूलाइनों को जानबूझकर स्ट्रिप करता है, और टिप्पणियों के माध्यम से कोई विशेष स्पष्टीकरण नहीं देता है।
// In Zend_Mail::addHeader()
$value = $this->_filterOther($value);
// In Zend_Mail::_filterOther()
$rule = array("\r" => '',
"\n" => '',
"\t" => '',
);
return strtr($data, $rule);
ठीक है, यह पहली बार में उचित लग रहा था - शायद जेडएफ स्वरूपण और लाइन रैपिंग का पूरा नियंत्रण चाहता है। अगली विधि :: addHeader() Zend_Mail में कहा जाता
$value = $this->_encodeHeader($value);
इस विधि मूल्य encodes है (या तो उद्धृत-मुद्रण योग्य या उचित रूप में बेस 64) उचित लंबाई के लाइनों में है और यह हिस्सा है, लेकिन केवल अगर यह होता है "गैर-प्रिंट करने योग्य वर्ण", जैसा कि Zend_Mime :: द्वारा निर्धारित किया गया है ($ मूल्य)।
उस विधि को देखते हुए, न्यूलाइन (\ n) वास्तव में गैर-प्रिंट करने योग्य पात्र माना जाता है! इसलिए अगर उन्हें पिछले विधि कॉल में स्ट्रिंग से बाहर नहीं किया गया था, तो लंबे हेडर को क्यूपी के रूप में एन्कोड किया जाएगा और 72-चार लाइनों में घुमाया जाएगा, और सब कुछ ठीक काम करेगा। असल में, मैंने एक परीक्षण किया जहां मैंने _filterOther() को कॉल करने पर टिप्पणी की, और लंबा हेडर एन्कोड हो जाता है और बिना किसी समस्या के चला जाता है। लेकिन अब मैंने जेडएफ को एक लापरवाही हैक बनाया है, जिसे मैंने हटाई गई रेखा के पीछे वास्तव में समझने के बिना किया है, इसलिए यह दीर्घकालिक समाधान नहीं हो सकता है।
मेरा मध्यम अवधि का समाधान ज़ेंड_Mail का विस्तार करने और एक नई विधि, addHeaderForceEncode() बनाने के लिए किया गया है, जो हमेशा शीर्षलेख के मान को एन्कोड करेगा, और इस प्रकार इसे हमेशा छोटी रेखाओं में घुमाएगा। लेकिन मैं अभी भी संतुष्ट नहीं हूं क्योंकि मुझे समझ में नहीं आता कि क्यों _filterOther() कॉल पहली जगह में जरूरी था - शायद मुझे इसके आसपास काम नहीं करना चाहिए।
क्या कोई मुझे बता सकता है कि यह व्यवहार न्यूलाइन को अलग करने का क्यों अस्तित्व में है? ऐसा लगता है कि अनिवार्य रूप से उन परिस्थितियों का कारण बनता है जहां एक शीर्षलेख बहुत लंबा हो सकता है यदि इसमें न्यूलाइन के अलावा कोई भी "गैर-प्रिंट करने योग्य वर्ण" नहीं है।
मैंने इस विषय पर विभिन्न खोजों का एक गुच्छा किया है और कुछ जेडएफ बग रिपोर्टों को देखा है, लेकिन किसी ने इस बारे में बात नहीं देखी है। आश्चर्य की बात है कि यह वास्तव में एक अस्पष्ट मुद्दा प्रतीत होता है। एफवाईआई मैं जेडएफ 1.11.11 के साथ काम कर रहा हूं।
अद्यतन: मामले में किसी को भी जेडएफ मुद्दा मैं इस बारे में खोला पालन करने के लिए, चाहता है यहाँ यह है: Zend_Mail::addHeader() UNfolds long headers, then throws exception
स्टैक ओवरव्लो सब कुछ जवाब दे सकता है;) +1 यहां आपके पहले प्रश्न के लिए। – Flavius
मुझे स्वागत महसूस करने के लिए धन्यवाद। – LinusR