curl 命令行选项--tr-encoding详解请求压缩 Transfer-Encoding 并自动解压【免费下载链接】curlA command line tool and library for transferring data with URL syntax, supporting DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, MQTTS, POP3, POP3S, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS and WSS. libcurl offers a myriad of powerful features项目地址: https://gitcode.com/GitHub_Trending/cu/curl--tr-encoding是 curl 提供的 HTTP 专用开关用于在请求中声明希望接收压缩的 Transfer-Encoding传输编码响应并在数据接收过程中由 curl 自动解压。本文基于 curl 源码仓库中的 docs/cmdline-opts/tr-encoding.md 展开结合 src/tool_getparam.c、lib/http.c、lib/content_encoding.c 与测试用例 tests/data/test1277完整讲解该选项的用法、底层实现、与--compressed的差异以及对应的 libcurl API。读完本文你将理解为什么 curl 官方文档明确提示这个选项通常不是你想要的以及现代 HTTP 压缩实践应当选择哪种方式。选项概览--tr-encoding在 curl 命令行手册中的元数据定义如下来源docs/cmdline-opts/tr-encoding.md属性值长选项名--tr-encoding添加版本7.21.6帮助文本Request compressed transfer encoding适用协议HTTP所属分类http重复使用Multi: boolean布尔开关可多次指定关联选项--compressed示例--tr-encoding $URL从选项注册表src/tool_getparam.c 中{tr-encoding, ARG_BOOL, , C_TR_ENCODING}可以看出这是一个不带短选项的布尔开关其作用是向服务器发出压缩传输编码的请求并在 curl 接收响应的过程中自动完成解压。工作原理从请求头到自动解压启用--tr-encoding后curl 在发出的 HTTP 请求中附加TE: gzip请求头声明客户端可以接受以 gzip 传输编码Transfer-Encoding编码的响应如果服务器支持并愿意它可以用压缩的 Transfer-Encoding 发送响应体curl 则在收到数据的同时完成解压。这与 Content-Encoding 机制有本质区别Transfer-Encoding 严格来说是传输层面的编码必须在数据到达客户端之前就被解码。命令行解析链路在命令行层面该选项的解析路径清晰可查选项定义位于 src/tool_getparam.ctr-encoding被注册为ARG_BOOL类型的C_TR_ENCODING枚举解析命中后执行config-tr_encoding toggle;src/tool_getparam.c 的C_TR_ENCODING分支将开关状态存入 src/tool_cfgable.h 中定义的BIT(tr_encoding)位字段最终构造 libcurl 句柄时src/config2setopts.c 将其映射为 libcurl 选项if(config-tr_encoding) my_setopt_long(curl, CURLOPT_TRANSFER_ENCODING, 1);即命令行--tr-encoding等价于 libcurl 的CURLOPT_TRANSFER_ENCODING选项默认值为 0即关闭见 docs/libcurl/opts/CURLOPT_TRANSFER_ENCODING.md。请求侧实现TE: gzip的发送条件在 lib/http.c 的 HTTP/1.1 请求头构造逻辑中TE头仅在以下三个条件同时满足时才会被发出case H1_HD_TE: #ifdef HAVE_LIBZ if(!Curl_checkheaders(data, STRCONST(TE)) >/* supported content decoders only for transfer encodings */ static const struct Curl_cwtype * const transfer_unencoders[] { Curl_httpchunk_unencoder, NULL };也就是说curl 的传输编码解压器目前只有chunked分块解码器。当响应同时带有Transfer-Encoding: gzip, chunked时典型组合如测试 tests/data/test1277 中的Transfer-Encoding: gzip, chunkedcurl 会依序处理若传输编码中不含chunked则按 lib/http.c 的逻辑curl 会关闭连接并忽略Content-Length因为传输编码下的Content-Length不可信依赖连接关闭来标记消息结束。此外lib/content_encoding.c 中Curl_build_unencoding_stack()的实现还体现了严格的消息语义校验若chunked不是最后一个传输编码直接拒绝响应并返回CURLE_BAD_CONTENT_ENCODINGReject response due to chunked not being the last Transfer-Encoding依据是 RFC 9112 第 6.1 节重复的chunked解码器会被忽略RFC 9112 规定同一消息体不得多次应用 chunked 传输编码参见 curl issue #13451 的处理。命令行实战用法--tr-encoding的用法与其他布尔开关一致直接附带在 curl 命令行中即可# 请求压缩的 Transfer-Encoding 响应并自动解压 curl --tr-encoding https://example.com # 显式关闭默认即关闭可省略 curl --tr-encodingfalse https://example.com # 组合使用同时请求 Content-Encoding 与 Transfer-Encoding 压缩 curl --tr-encoding --compressed https://example.com开启后如果服务器配合返回的响应体会在接收过程中被自动解压用户拿到的数据已经是原始未压缩内容无需手动处理。一个值得注意的细节Connection: TE在测试用例 tests/data/test1277 的协议校验部分可以看到 curl 启用--tr-encoding后实际发送的请求头序列GET /1277 HTTP/1.1 Host: ... Accept: */* TE: gzip Accept-Encoding: xxx Connection: TE其中TE: gzip与Connection: TE成对出现——根据早期 HTTP/1.1 规范RFC 2616TE头属于需要伴随Connection声明端到端传输的逐跳hop-by-hop头。该测试同时展示了--tr-encoding与--compressed可以并存二者分别影响TE:头与Accept-Encoding:头互不冲突。与--compressedContent-Encoding的关键区别--tr-encoding在历史上曾被设想为 HTTP 自动压缩的主要方式但正如 docs/cmdline-opts/tr-encoding.md 明确指出的对于所有实际用途使用 Content-Encoding 的--compressed已经取代了传输编码。因此--tr-encoding通常不是你想要的那个选项。两种机制的核心差异总结如下维度--tr-encodingTransfer-Encoding--compressedContent-Encoding请求头TE: gzipAccept-Encoding: 支持的算法空串时自动列出全部内置算法响应头Transfer-Encoding:Content-Encoding:语义传输层面的编码逐跳生效数据到达客户端前必须解码实体内容的编码端到端语义可长期保存服务端支持历史上支持较少客户端/服务器两端使用都不广泛现代 HTTP 压缩事实标准普及度极高libcurl 选项CURLOPT_TRANSFER_ENCODINGCURLOPT_ACCEPT_ENCODING关于--compressed的细节来源docs/cmdline-opts/compressed.md 与 docs/libcurl/opts/CURLOPT_ACCEPT_ENCODING.mdcurl 支持的 Content-Encoding 算法取决于编译时内置的能力常见包括identity不压缩、deflatezlib、gzip以及视构建配置brbrotli7.57.0 起和zstd7.72.0 起设置CURLOPT_ACCEPT_ENCODING为空字符串时libcurl 会生成包含全部内置算法的Accept-Encoding:头与--tr-encoding相同Accept-Encoding也只是请求而非命令服务器可以选择不压缩需要特别留意当使用--compressed并保存响应时保存下来的响应头不会被修改。如果之后单独解释这些头Content-Encoding头可能仍在声明内容是压缩的而实际上内容已被解压——这是常见的陷阱若服务器返回了 curl 不支持的编码curl 会报告错误。由于Transfer-Encoding压缩从未获得与Content-Encoding同等的普及度绝大多数场景下应优先使用--compressed来获得自动压缩与解压能力。对应的 libcurl API 用法对于基于 libcurl 编程的场景--tr-encoding对应CURLOPT_TRANSFER_ENCODING选项原型与用法如下docs/libcurl/opts/CURLOPT_TRANSFER_ENCODING.md#include curl/curl.h CURLcode curl_easy_setopt(CURL *handle, CURLOPT_TRANSFER_ENCODING, long enable);示例代码int main(void) { CURL *curl curl_easy_init(); if(curl) { CURLcode result; curl_easy_setopt(curl, CURLOPT_URL, https://example.com); curl_easy_setopt(curl, CURLOPT_TRANSFER_ENCODING, 1L); /* 启用 */ result curl_easy_perform(curl); curl_easy_cleanup(curl); } }传入1L启用0关闭默认值为 0docs/libcurl/opts/CURLOPT_TRANSFER_ENCODING.md 的 DEFAULT 节该选项仅对 HTTP 生效自 libcurl 7.21.6 起可用。相关选项CURLOPT_HTTP_TRANSFER_DECODING需要与CURLOPT_TRANSFER_ENCODING区分的是CURLOPT_HTTP_TRANSFER_DECODINGdocs/libcurl/opts/CURLOPT_HTTP_TRANSFER_DECODING.md。后者控制的是响应侧的传输解码行为libcurl 默认值为 1会对Transfer-Encoding: chunked响应做自动分块解码只有显式设为 0 时才禁用。换句话说--tr-encoding管的是请求压缩发送TE: gzip而 chunked 解码默认始终开启与是否请求压缩无关。测试验证行为在仓库中的可复现证据curl 仓库的回归测试 tests/data/test1277 专门覆盖了同时带 Content-Encoding 与 Transfer-Encoding的场景测试命令为http://%HOSTIP:%HTTPPORT/%TESTNUMBER --tr-encoding --compressed同时开启两个压缩选项服务器响应同时携带Transfer-Encoding: gzip, chunked与Content-Encoding: deflate测试前置条件声明需要libz特性featureslibz/features与 lib/http.c 中HAVE_LIBZ的编译条件一一对应协议校验部分确认客户端请求中包含TE: gzip与Connection: TE。该用例是验证启用--tr-encoding后请求头正确发送、压缩响应可正确解码的直接证据。此外--tr-encoding还出现在 tests/data/test1122、tests/data/test1123、tests/data/test1124、tests/data/test1125、tests/data/test1170、tests/data/test1171、tests/data/test1546、tests/data/test1617、tests/data/test2119 等多个测试用例中覆盖了传输编码与内容编码组合的多种解析路径。使用建议与注意事项综合 docs/cmdline-opts/tr-encoding.md 及配套源码使用该选项时有几点值得注意优先选择--compressed官方文档明确指出 Transfer-Encoding 压缩方案在实用性上已被 Content-Encoding 取代常规 HTTP 压缩需求应使用--compressed编译依赖限制TE: gzip仅在 curl 构建时启用了 zlibHAVE_LIBZ的前提下才会发送若构建未包含 zlib该选项实际不产生请求头效果请求头冲突若用户通过-H TE: ...显式设置了TE头curl 不会重复添加自动生成的TE: gzip协商而非命令无论--tr-encoding还是--compressed都只是向服务器发出请求服务器完全可以选择以未压缩方式响应解压扩展风险参考 docs/cmdline-opts/compressed.md 的警告解压可能使极小传输膨胀为巨量字节若需限制体积可配合--max-filesize使用并将压缩选项限定在可信站点。参考文档与源码索引选项手册docs/cmdline-opts/tr-encoding.md、docs/cmdline-opts/compressed.md命令行实现src/tool_getparam.c选项注册与解析、src/config2setopts.c映射为CURLOPT_TRANSFER_ENCODING库实现lib/http.cTE: gzip请求头构造与响应解码栈构建、lib/content_encoding.c传输/内容解码器注册与校验libcurl APIdocs/libcurl/opts/CURLOPT_TRANSFER_ENCODING.md、docs/libcurl/opts/CURLOPT_ACCEPT_ENCODING.md、docs/libcurl/opts/CURLOPT_HTTP_TRANSFER_DECODING.md测试用例tests/data/test1277双编码组合验证【免费下载链接】curlA command line tool and library for transferring data with URL syntax, supporting DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, MQTTS, POP3, POP3S, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS and WSS. libcurl offers a myriad of powerful features项目地址: https://gitcode.com/GitHub_Trending/cu/curl创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
