curl下载HTTPS正文是乱码：--compressed与Content-Encoding分层排查

curl访问HTTPS时退出码为0，证书也没有报错，但保存的文本打开全是乱码。先别急着改证书，更不要加关闭验证的选项。它可能只是服务器返回了gzip编码的数据，而当前命令没有解码。TLS负责连接身份与传输保护，不替你判断文件是不是可直接阅读的业务正文。

一、先分清三个不同的问题

第一层是TLS证书链和主机名验证；第二层是HTTP状态与响应头；第三层才是正文解码及业务验收。Content-Encoding描述服务器对表示应用的内容编码，和Content-Type描述的数据类型不是同一回事。一个text/plain响应完全可能先经过gzip编码再传输；本地直接用文本工具打开这些压缩字节，自然不像正文。

不要混淆gzip归档、HTTP内容编码与Transfer-Encoding传输编码。先明确交付物是归档还是解码文本。

图为概念分层，不是操作时序；--compressed在请求前启用，"验收"指解码后内容，且要求curl支持对应编码。

二、保留原始证据，再决定是否解码

先查版本和编译能力。libz等信息有助于确认gzip依赖，不能照搬其他构建的brotli或zstd支持结论。

bash 复制代码

curl --version

example.com/data是占位地址，请替换为授权目标。示例绕开代理，仅适用于允许直连的环境；企业代理链路需另行记录。

bash 复制代码

curl -q --noproxy '*' --http1.1 --connect-timeout 3 --max-time 10 \
  -sS -D raw.headers -o raw.body \
  -w 'http=%{http_code} bytes=%{size_download}\n' \
  'https://example.com/data'
python3 -c "from pathlib import Path; print(Path('raw.body').read_bytes()[:8].hex())"

对照状态、Content-Encoding、Content-Type和正文开头。gzip常见魔数1f8b只是线索，不证明完整性。乱码也可能来自字符集、二进制格式或错误资源。

三、--compressed做了什么，没有做什么

curl手册说明，--compressed会请求使用受支持的压缩编码，并自动解压响应。它不等于手工设置Accept-Encoding请求头：单独加请求头并不会因此启用curl自动解码。服务器是否使用gzip仍取决于协商与服务端行为；本实验故意固定返回gzip，只用来隔离观察客户端差异，不代表所有站点都会这样响应。

bash 复制代码

curl -q --noproxy '*' --http1.1 --connect-timeout 3 --max-time 10 \
  --compressed -sS -D decoded.headers -o decoded.body \
  -w 'http=%{http_code} bytes=%{size_download}\n' \
  'https://example.com/data'
python3 -c "from pathlib import Path; print(repr(Path('decoded.body').read_bytes()))"

一个容易误判的地方是：curl解码正文后，不会相应改写通过-D保存的响应头。decoded.body已经是明文，但decoded.headers仍可能有Content-Encoding: gzip。不要看到这条头就对已解码文件再次gzip解压。下载统计同样不要直接当作解码后文件尺寸；应该另查本地实际文件长度。

四、本机隔离实验：只改变编码与客户端选项

本次在回环地址临时启动TLS服务，临时测试CA签发包含example.com主机名的叶证书，客户端通过本机地址映射连接并显式信任该CA。没有关闭证书验证。服务固定HTTP/1.1、TLS 1.2，业务期望正文为三个字节OK换行，gzip编码后再发送。证书、密钥和监听随实验结束清理；这不是生产证书、CDN、浏览器或HTTP/2实测。

本机对照	实际观察	能说明什么
不启用自动解码	退出0，保存gzip字节	传输成功不等于文本已解码
单独发Accept-Encoding: gzip	退出0，仍保存gzip字节	请求头不能代替解码选项
启用--compressed	退出0，正文为OK换行，保存头仍写gzip	正文已解码，响应头未改写
使用不相关CA	退出60，服务未收到HTTP请求	先解决信任链，不能靠解码修复

五、下载脚本：验证完成前不覆盖旧文件

不要用未验证数据覆盖旧文件。下面的测试契约是HTTP 200且正文严格等于OK换行；真实JSON、软件包或配置应改用解析器、结构规则、可信哈希或签名。

bash 复制代码

set -eu
# 仅适用于本示例约定：最终正文必须严格等于 OK 换行。
tmp=$(mktemp './download.XXXXXX')
trap 'rm -f -- "$tmp"' EXIT
http=$(curl -q --noproxy '*' --http1.1 --connect-timeout 3 --max-time 10 \
  --compressed -fsS -D accepted.headers -o "$tmp" -w '%{http_code}' \
  'https://example.com/data')
[ "$http" = 200 ]
python3 - "$tmp" <<'PY'
from pathlib import Path
import sys
assert Path(sys.argv[1]).read_bytes() == b'OK\n', 'unexpected body'
PY
mv -- "$tmp" result.txt

临时文件与目标同目录，验收后才改名，不承诺断电持久性或并发安全。失败清理临时正文并保留旧result.txt。响应头留证但须脱敏。

本机还用空200、错误正文、304与500作为反例：它们均不能替换旧文件；错误CA也不能通过。-f可以让HTTP错误触发失败，但304不是它要拦截的4xx/5xx，所以脚本仍需显式判断期望状态。这是在编码排查之后补齐验收，不是把所有无正文都归为压缩问题。

六、遇到异常时按证据定位

观察	优先检查	不要这样处理
curl退出60	CA信任、主机名、证书链	用解码参数替代验证
头写gzip、落盘像压缩数据	是否仅手工发了Accept-Encoding	直接认定证书失败
头写gzip、正文已是明文	是否已启用自动解码	重复解压同一正文
开启解码仍异常	真实编码、构建支持、服务端头体一致性	伪造成功退出码

示例不自动跟随跳转。多组响应头应确认所属链路，异常保留完整stderr与版本再核对手册。本机通过不代表生产正常。

七、上线验收清单

证书验证始终开启；临时测试CA不能进入生产信任库。
记录curl版本、目标授权范围、实际代理路径与最终HTTP状态。
响应头、原始字节和解码结果分开留证，确认没有二次解压。
验证业务格式、大小和完整性；失败不覆盖旧文件，敏感头脱敏。
需要哈希校验时，先明确校验的是压缩归档还是解码后的文件。

八、官方依据与适用边界

curl手册说明自动解码及保存头不随之改写；RFC 9110第8.4、12.5.3节定义内容编码与协商。证书说明区分TLS验证。文档事实与本机实验分开，不冒充生产观测。

curl官方手册；RFC 9110 HTTP语义；curl TLS证书验证说明。