libcurl کے بائنری جوابات کو C++ std::string میں وصول کریں
callback context کے طور پر 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 کو مکمل فائل ماننے سے پہلے منتقلی کا نتیجہ اب بھی جانچنا ہوگا۔
منتقلی مکمل ہونے تک اسٹرنگ کو زندہ رکھیں۔ اگر کوئی غیر متزامن ساکٹ تحریر پھر اس کا مواد آگے بھیجے، تو ان بائٹس کو اس تحریر کے مکمل ہونے تک زندہ رکھیں۔ بڑے جوابات کے لیے، پورے جسم کو جمع کرنے کے بجائے محدود اسٹریمنگ انتظام بہتر ہے۔