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-কে সম্পূর্ণ ফাইল হিসেবে গণ্য করার আগে স্থানান্তরের ফলাফল পরীক্ষা করতে হবে।

স্থানান্তর শেষ না হওয়া পর্যন্ত স্ট্রিংটি জীবিত রাখুন। যদি একটি অ্যাসিঙ্ক্রোনাস সকেট লেখা পরে এর বিষয়বস্তু ফরোয়ার্ড করে, তবে সেই লেখাও সম্পূর্ণ না হওয়া পর্যন্ত সেই বাইটগুলি জীবিত রাখুন। বড় প্রতিক্রিয়ার জন্য, পুরো শরীর জমা করার চেয়ে সীমিত স্ট্রিমিং ব্যবস্থা পছন্দনীয়।