Windows NTFS压缩不提供文件“压缩比例”属性,仅能通过GetFileInformationByHandle获取逻辑大小与分配大小估算比例,且分配大小为簇对齐的近似值,非精确压缩后字节数。

Windows 压缩卷上的文件没有“压缩比例”这个属性
Windows 的 NTFS 压缩(Compact OS / compact.exe)是透明的、按簇粒度进行的块级压缩,系统不记录也不暴露单个文件的压缩前/后大小比。所谓“压缩比例”,你无法通过标准 API(如 GetFileSizeEx、GetFileAttributesEx)或 PowerShell(Get-Item)直接读到。
能拿到的只有压缩前后大小的近似估算
NTFS 压缩不保证每个文件都可逆地压缩出精确比例——有些文件(如已压缩的 .zip、.jpg)可能膨胀,有些则被合并进共享簇。实际可用的方法只有:读取文件逻辑大小 + 尝试获取其在磁盘上占用的实际字节数(即“分配大小”),再做除法估算。
-
GetCompressedFileSize已废弃,返回值不可靠,尤其对大文件或稀疏文件会截断 - 推荐用
GetFileInformationByHandle,检查返回结构体中的nFileSizeLow(逻辑大小)和nNumberOfLinks无关,关键看dwReserved0字段?错——真正有效的是dwReserved0在 Win10+ 中已被弃用;正确字段是dwReserved0不再承载含义,应改用GetDiskFreeSpaceEx+GetFileInformationByHandle配合FILE_FLAG_NO_BUFFERING?也不对——最稳的方式是调用DeviceIoControl发送FSCTL_GET_COMPRESSION查压缩状态,再用GetFileInformationByHandle拿dwAllocationSizeLow和dwAllocationSizeHigh - 注意:
dwAllocationSize是文件在磁盘上实际占的字节数(向上对齐到簇),不是压缩后精确字节,但它是目前最接近“压缩后大小”的可观测指标
实操代码片段:用 GetFileInformationByHandle 获取逻辑大小与分配大小
HANDLE h = CreateFile(L"test.txt", GENERIC_READ, FILE_SHARE_READ, nullptr,
OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, nullptr);
if (h != INVALID_HANDLE_VALUE) {
BY_HANDLE_FILE_INFORMATION info = {};
if (GetFileInformationByHandle(h, &info)) {
ULONGLONG logical = ((ULONGLONG)info.nFileSizeHigh 0 && allocated > 0) {
double ratio = (double)allocated / logical; // 注意:ratio > 1 表示未压缩甚至膨胀
printf("Logical: %llu, Allocated: %llu, Ratio: %.3f\n", logical, allocated, ratio);
}
}
CloseHandle(h);
}
容易踩的坑:NTFS 压缩 ≠ ZIP,别拿 ZIP 思维套用
NTFS 压缩是透明的、无元数据的、不跨文件共享字典的。它不生成额外索引,也不存储压缩算法标识(始终是 LZNT1 或 XPRESS4K,取决于系统版本)。这意味着:
- 你不能从文件本身反推用了哪种算法,
FSCTL_GET_COMPRESSION只返回是否启用压缩,不返回算法名 - 同一目录下两个相同内容的文件,不会共享压缩块;它们各自独立压缩
- 小文件(
-
compact /c命令开启压缩后,新写入内容才生效;已有数据需手动运行compact /c /s触发重压缩
真要算“比例”,只能靠 dwAllocationSize 估算,且必须接受它只是粗略参考——尤其当文件被多次修改、碎片化严重时,分配大小会包含空闲簇间隙,比例失真明显。
C++免费学习笔记(深入):立即使用
在学习笔记中,你将探索 C++ 的入门与实战技巧!











