libcurl 编译说明

libcurl 正常不依赖第三方库也可以进行编译使用，但是只能访问不带ssl通道的http,不能访问https，而且不支持gzip
一般现在常用的https中的ssl是使用openssl、gzip使用zlib
下面是如何编译libcurl，我们在项目中使用的是第二种方式，VC项目的方式。

zlib编译

cd $zlibdir
nmake -f win32/Makefile.msc

openssl编译

openssl 编译

构建编译环境

将openssl的include与lib和zlib的include与lib分别拷贝到curl平级目录中，类似下图中的目录结构，我这边编译是生成一个总的curl库，zlib与openssl以静态库的方式打包进libcurl的库中。

本地curl命令行编译

cd  $curldir/winbuild
nmake /f Makefile.vc mode=dll DEBUG=no ENABLE_UNICODE=yes WITH_SSL=static WITH_ZLIB=static ZLIB_PATH=D:\SevenWorkSpace\Curl_workspace\zlib SSL_PATH=D:\SevenWorkSpace\Curl_workspace\openssl

生成在

本地Curl VC项目编译

编译后生成在

总结与经验
经过对比和测试，这两种编译出来的库都可以正常进行使用，但是由于编译时输入的编译器参数不同，还是需要特殊进行考虑使用方式。
我这边之前的项目中是使用的第二种方式进行的编译，所以后续在这次添加gzip使用时没有使用第一种编译方式生成的库。
由于在网上找到的都是第一种方式编译出来的发现编译后的库文件比较小，如图：

对比了编译时的命令行，发现很多编译器相关的选项并不一致，并且实际命令行编译后的动态库会多一个调试标记，所以考虑再三还是延续老的方式（VC项目）进行编译。不过测试使用时两种编译方式编译出来的库都可以正常使用。
通过抓取命令行与实际VC项目中的编译选项，分析makefile中ZLIB相关的编译选项，
发现ZLIB源码端启用是多开启了三个宏定义

所以直接在VC项目中启用这三个宏即可

使用gzip

curl_easy_setopt(m_pcurl, CURLOPT_ACCEPT_ENCODING, “”);
使用此方法调用服务端时可以根据本地支持的压缩算法进行申请
如果本身libcurl编译时没有包含zlib
抓包时访问数据会是

如果使用包含zlib的libcurl库抓包数据为

如果服务端开启了gzip支持，则抓包会看到类似的返回效果

完结，C++真是麻烦。还有哪个语言还要自己考虑这些东西的。。。。

编程道路很漫长，且行且珍惜