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 ને સંપૂર્ણ ફાઈલ ગણતા પહેલા ટ્રાન્સફર પરિણામ ચકાસવું જ પડશે.

ટ્રાન્સફર પૂર્ણ ન થાય ત્યાં સુધી સ્ટ્રિંગને જીવંત રાખો. જો અસિંક્રોનસ સોકેટ લેખન પછી તેની સામગ્રી આગળ મોકલે, તો તે લેખન પણ પૂર્ણ ન થાય ત્યાં સુધી તે બાઈટને જીવંત રાખો. મોટા પ્રતિભાવો માટે, આખું શરીર એકઠું કરવા કરતાં મર્યાદિત સ્ટ્રીમિંગ ગોઠવણી વધુ યોગ્ય છે.