libcurl请求Docker API返回数据带冗余乱码导致JSON解析失败如何解决

你遇到的末尾冗余乱码本质是两类常见错误共同导致的：

• 未启用libcurl的HTTP传输自动解码，拿到了*原始分块传输（Chunked）*的响应内容，你看到的a489就是分块的十六进制长度标识
• 自定义写回调的内存处理逻辑存在缺陷，将未初始化的内存或者多余的非响应内容写入了最终存储的字符串中

1. 开启libcurl自动解码配置 #

在初始化curl句柄后添加以下配置，让libcurl自动处理分块编码、gzip压缩等传输层编码，直接返回纯响应体：

// 自动识别并解码所有支持的传输编码（包括chunked、gzip、deflate等）
curl_easy_setopt(curl, CURLOPT_ACCEPT_ENCODING, "");
// 显式开启HTTP传输解码（libcurl新版本默认开启，用于兼容旧版本）
curl_easy_setopt(curl, CURLOPT_HTTP_TRANSFER_DECODING, 1L);

2. 修正自定义写回调的实现 #

90%以上的这类问题都是写回调的内存处理错误，以下是标准的正确实现：

// 入参buf为存储响应的std::string指针，需在curl请求初始化时通过CURLOPT_WRITEDATA传入
size_t write_callback(char* ptr, size_t size, size_t nmemb, std::string* buf) {
    if (buf == nullptr) return 0;
    size_t real_size = size * nmemb;
    // 直接按实际接收字节数append，std::string会自动管理长度，无需手动处理空终止符
    buf->append(ptr, real_size);
    return real_size;
}

如果你使用自行管理的char*缓冲区，必须在所有数据接收完成后，在缓冲区末尾追加'\0'，且缓冲区分配大小需要比实际接收的字节数多1字节，用于存储空终止符。

3. 补充前置校验 #

在JSON解析前增加校验逻辑，避免无效内容进入解析流程：

• 检查curl_easy_perform返回值为CURLE_OK后再处理响应内容
• 非分块传输场景可以校验响应头Content-Length和实际接收的响应体长度是否匹配
• 可以临时开启CURLOPT_VERBOSE打印传输日志，快速定位编码处理异常

内容的提问来源于stack exchange，提问作者aszswaz