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 पूर्ण फाइल मानण्यापूर्वी हस्तांतरणाचा निकाल तपासला पाहिजे.

हस्तांतरण संपेपर्यंत स्ट्रिंग जिवंत ठेवा. जर असिंक्रोनस सॉकेट लेखनानंतर त्याची सामग्री पुढे पाठवत असेल, तर ते लेखनही पूर्ण होईपर्यंत ते बाइट जिवंत ठेवा. मोठ्या प्रतिसादांसाठी, संपूर्ण शरीर जमा करण्यापेक्षा मर्यादित स्ट्रीमिंग व्यवस्था अधिक योग्य आहे.