C++ std::string में libcurl के बाइनरी प्रतिसाद प्राप्त करें

एक प्रॉक्सी HTML सफलतापूर्वक प्राप्त कर सकता है और फिर भी किसी छवि को C++ बफ़र में कॉपी करते समय खराब कर सकता है। प्रॉक्सी प्रोटोकॉल बदलने से पहले, रिसीव callback और उसके context के रूप में पास की गई वस्तु जाँचें।

CURLOPT_WRITEDATA राइट callback के लिए एक संकेतक देता है। कस्टम callback के बिना, libcurl का डिफ़ॉल्ट राइटर FILE * की अपेक्षा करता है। &response जैसा पता, जहाँ response एक std::string है, तभी अर्थपूर्ण होता है जब आपका callback उस context को वापस इच्छित प्रकार में बदलता है।

static size_t receive(char* data, size_t size,
                      size_t count, void* context) {
    const size_t bytes = size * count;
    auto* body = static_cast<std::string*>(context);
    try {
        body->append(data, bytes);
    } catch (...) {
        return 0;
    }
    return bytes;
}

दोनों हिस्सों को स्थानांतरण में उपयोग होने वाले सरल हैंडल पर पंजीकृत करें:

std::string response;
curl_easy_setopt(handle, CURLOPT_WRITEFUNCTION, receive);
curl_easy_setopt(handle, CURLOPT_WRITEDATA, &response);

append कॉल दिए गए बाइट गणना का उपयोग करता है। callback डेटा null-terminated नहीं होता, और किसी छवि में शून्य बाइट हो सकते हैं; strlen से मापने पर शरीर का कुछ भाग खो जाएगा। कोई प्रतिसाद विभिन्न आकारों के कई callback आह्वानों के माध्यम से भी आ सकता है।

उपभोग की गई बाइट गणना लौटाने पर टुकड़ा स्वीकार होता है। भिन्न गणना लौटाने पर स्थानांतरण लेखन त्रुटि के साथ निरस्त हो जाता है। अपवाद रक्षक आवंटन विफलता को C callback सीमा से बाहर निकलने से रोकता है; कॉलर को response को पूर्ण फ़ाइल मानने से पहले स्थानांतरण परिणाम अवश्य जाँचना चाहिए।

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