libcurl ਦੇ ਬਾਈਨਰੀ ਜਵਾਬ C++ std::string ਵਿੱਚ ਪ੍ਰਾਪਤ ਕਰੋ

ਇੱਕ ਪ੍ਰੌਕਸੀ 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 ਨੂੰ ਪੂਰੀ ਫਾਈਲ ਮੰਨਣ ਤੋਂ ਪਹਿਲਾਂ ਟ੍ਰਾਂਸਫਰ ਨਤੀਜਾ ਜਾਂਚਣਾ ਚਾਹੀਦਾ ਹੈ।

ਟ੍ਰਾਂਸਫਰ ਖ਼ਤਮ ਹੋਣ ਤੱਕ ਸਟ੍ਰਿੰਗ ਨੂੰ ਜੀਵਤ ਰੱਖੋ। ਜੇ ਕੋਈ ਅਸਿੰਕ੍ਰੋਨਸ ਸਾਕਟ ਲਿਖਤ ਫਿਰ ਇਸਦੀ ਸਮੱਗਰੀ ਅੱਗੇ ਭੇਜਦੀ ਹੈ, ਤਾਂ ਉਹ ਬਾਈਟ ਉਸ ਲਿਖਤ ਦੇ ਪੂਰਾ ਹੋਣ ਤੱਕ ਜੀਵਤ ਰੱਖੋ। ਵੱਡੇ ਜਵਾਬਾਂ ਲਈ, ਪੂਰੇ ਸਰੀਰ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਦੀ ਬਜਾਏ ਸੀਮਿਤ ਸਟ੍ਰੀਮਿੰਗ ਪ੍ਰਬੰਧ ਬਿਹਤਰ ਹੈ।