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 << 32) | info.nFileSizeLow;
ULONGLONG allocated = ((ULONGLONG)info.dwAllocationSizeHigh << 32) | info.dwAllocationSizeLow;
if (logical > 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++免费学习笔记（深入）”；
