ទទួលយកការឆ្លើយតបប្រភេទ binary របស់ libcurl ចូល C++ std::string

Proxy អាចទាញយក HTML បានដោយជោគជ័យ ហើយនៅតែធ្វើឱ្យរូបភាពខូចខាត នៅពេលចម្លងវាចូល buffer របស់ C++។ មុនពេលផ្លាស់ប្តូរ proxy protocol សូមពិនិត្យ callback ទទួល និងវត្ថុដែលផ្តល់ជា context របស់វា។

CURLOPT_WRITEDATA ផ្តល់ pointer ទៅ 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;
}

ចុះឈ្មោះផ្នែកទាំងពីរនៅលើ handle សាមញ្ញដែលប្រើសម្រាប់ការផ្ទេរ:

std::string response;
curl_easy_setopt(handle, CURLOPT_WRITEFUNCTION, receive);
curl_easy_setopt(handle, CURLOPT_WRITEDATA, &response);

ការហៅ append ប្រើចំនួន byte ដែលបានផ្តល់។ ទិន្នន័យ callback មិនបញ្ចប់ដោយ null ហើយរូបភាពអាចមាន byte សូន្យ; ការវាស់វែងដោយ strlen នឹងបាត់បង់ផ្នែកមួយនៃតួ។ ការឆ្លើយតបក៏អាចមកតាមរយៈការហៅ callback ជាច្រើនដែលមានទំហំខុសៗគ្នា។

ការត្រឡប់ចំនួន byte ដែលបានប្រើប្រាស់ ទទួលយកដុំនោះ។ ការត្រឡប់ចំនួនខុសគ្នា បញ្ឈប់ការផ្ទេរជាមួយកំហុសសរសេរ។ អ្នកការពារករណីលើកលែងរារាំងការបរាជ័យនៃការបែងចែកអង្គចងចាំពីការរត់ចេញពីព្រំដែន callback C; អ្នកហៅនៅតែត្រូវពិនិត្យលទ្ធផលផ្ទេរមុនពេលចាត់ទុក response ជាឯកសារពេញលេញ។

រក្សា string ឱ្យនៅរស់រហូតដល់ការផ្ទេរបញ្ចប់។ ប្រសិនបើការសរសេរ socket ប្រភេទ asynchronous បញ្ជូនមាតិការបស់វាបន្តទៀត សូមរក្សា byte ទាំងនោះឱ្យនៅរស់រហូតដល់ការសរសេរនោះបញ្ចប់ដែរ។ សម្រាប់ការឆ្លើយតបធំៗ ការរៀបចំ streaming មានដែនកំណត់គឺប្រសើរជាងការប្រមូលតួទាំងមូល។