קבלת תגובות בינאריות של libcurl אל std::string ב-C++

פרוקסי יכול לאחזר HTML בהצלחה ובכל זאת לפגום בתמונה בזמן העתקתה אל מאגר C++. לפני שתשנו את פרוטוקול הפרוקסי, בדקו את פונקציית הקריאה החוזרת של הקבלה ואת האובייקט המועבר כהקשר שלה.

CURLOPT_WRITEDATA מספק מצביע אל פונקציית הכתיבה החוזרת. ללא פונקציה חוזרת מותאמת, כותב ברירת המחדל של libcurl מצפה ל-FILE *. כתובת כמו &response, שבה response הוא std::string, הגיונית רק כאשר הפונקציה החוזרת שלכם ממירה את ההקשר הזה חזרה לטיפוס המיועד.

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 משתמשת במספר הבייטים שנמסר. נתוני הפונקציה החוזרת אינם מסתיימים באפס, ותמונה עשויה להכיל בייטי אפס; מדידה עם strlen תאבד חלק מהגוף. תגובה יכולה גם להגיע דרך קריאות חוזרות רבות בגדלים שונים.

החזרת מספר הבייטים שנצרך מקבלת את הקטע. החזרת מספר שונה מפסיקה את ההעברה עם שגיאת כתיבה. שומר החריגות מונע מכשל הקצאה לפרוץ את גבול הקריאה החוזרת של C; הקורא עדיין חייב לבדוק את תוצאת ההעברה לפני שיתייחס ל-response כאל קובץ שלם.

השאירו את המחרוזת חיה עד שההעברה תסתיים. אם כתיבת סוקט אסינכרונית מעבירה לאחר מכן את תוכנה, השאירו את הבייטים האלה חיים עד שגם הכתיבה הזו תסתיים. עבור תגובות גדולות, סידור זרימה תחום עדיף על צבירת הגוף כולו.