HttpURLConnection getContentLength()与浏览器返回值不一致原因排查

这个问题我之前也碰到过，大概率是**内容压缩（gzip/deflate）**导致的差异，咱们一步步拆解：

核心原因：请求头的Accept-Encoding差异 #

现代浏览器默认会在请求中带上 Accept-Encoding: gzip, deflate, br 头，告诉服务器："我能处理压缩后的内容，尽量给我发压缩版的"。服务器收到这个请求后，会返回压缩后的图片文件，此时响应头里的 Content-Length 就是压缩后的字节数（也就是你在浏览器里看到的28456），同时还会附带 Content-Encoding: gzip 标识。

而你的代码里，HttpURLConnection 默认不会添加 Accept-Encoding 头，服务器会认为你无法处理压缩内容，直接返回原始未压缩的文件（或在HEAD请求中返回原始文件的大小），所以 getContentLength() 拿到的是原始图片的真实大小29493。

验证与解决方法 #

1. 在请求中添加Accept-Encoding头 #

修改代码，告诉服务器你支持压缩内容，这样返回的 Content-Length 就会和浏览器显示的传输大小一致：

URL url = new URL("https://radio-lanka-rs.firebaseapp.com/imgs/12_20190303.png");
HttpURLConnection con = (HttpURLConnection) url.openConnection();
con.setRequestMethod("HEAD");
// 添加支持压缩的请求头
con.setRequestProperty("Accept-Encoding", "gzip, deflate");
int size = con.getContentLength(); // 现在应该返回28456，和浏览器一致

2. 注意HEAD请求的特殊性 #

有些服务器对HEAD请求的处理比较特殊——即使你发送了 Accept-Encoding 头，它也可能返回原始文件的大小（因为HEAD请求不需要传输实体内容，服务器可能懒得做压缩计算）。如果遇到这种情况，改用GET请求并添加压缩头，就能拿到正确的压缩后大小。

3. 确认浏览器显示的数值含义 #

浏览器开发者工具的「网络」面板里，通常会显示两个大小：

• 传输大小：实际通过网络传输的压缩后字节数（就是你看到的28456）
• 资源大小：原始文件的未压缩大小（对应代码里拿到的29493）

你可以检查一下浏览器里的这两个数值，确认自己看的是哪一个。

额外提醒 #

如果用GET请求并开启了压缩，HttpURLConnection 会自动帮你解压内容，但 getContentLength() 返回的仍然是压缩后的字节数。如果你需要获取原始文件的大小，要么用HEAD请求不带压缩头，要么读取解压后的流并计算字节数。

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